Ви не увійшли.
- Теми: Активні | Без відповіді
- Форум
- » Програмування Arduino
- » Регістрова змінна
- » Відповісти
Відповісти
Огляд теми (нові повідомленні вгорі)
- dimich
- 2025-08-22 18:47:04
Я спробував виводити послідовний код через SPI. Виводить 8 біт за мікросекунду, а потім ще мікросекунду чекає. Чи можна вплинути на цю зайву затримку?
Так покажіть код, яким виводите. Мабуть же там ще якісь інструкції виконуються.
На "звичайному" SPI завжди будуть проміжки в один чи два такта між байтами. Принаймні мені так і не вдалось їх позбутись. Але не ціла мікросекунда, то щось не так в коді.
Щоб отримати безперервний потік, потрібно виводити через USART в режимі SPI. Звісно, вивод буде на TX пін, а не на MOSI.
- MikeM
- 2025-08-22 14:01:36
Raspberry Pi Zero?
Як на мене, то це занадто.
Я спробував виводити послідовний код через SPI. Виводить 8 біт за мікросекунду, а потім ще мікросекунду чекає. Чи можна вплинути на цю зайву затримку?
- dimich
- 2025-08-22 05:56:14
Хм, здається, я здогадуюсь, чому так мало козявок з HDMI. Це ж проприєтарний стандарт. За кожний розʼєм на виробі потрібно ліцензійний збір сплачувати.
- dimich
- 2025-08-22 01:23:39
А можна приклад козявки з HDMI?
Raspberry Pi Zero?
- MikeM
- 2025-08-22 00:21:01
А можна приклад козявки з HDMI?
- dimich
- 2025-08-21 23:59:18
Прийом інформації вже реалізовано - для цього вистачило періоду і тривалості рядкових синхроімпульсів.
Якщо девайс сам обирає коли приймати, тобто є мастером шини, то такий варіант цілком робочий.
Наразі триває боротьба за формування відеосигналу в форматі 640*480*60 Гц
Для атмеги є реалізації, наприклад.
Нажаль, свою реалізацію навряд чи вже знайду, грався з цим років 20 тому.
Є цікаві рішення і на інших платформах.
Розглядали інші варіанти? Будь-яка козявка з апаратним HDMI-контролером значно спростила би реалізацію. А якщо потреба відображати саме на VGA, то можна через готовий перехідник.
- MikeM
- 2025-08-21 22:10:35
Трохи розвію туман. Пристрій повинен приймати послідовні 32-розрядні слова і відображати на моніторі їх декодований вміст у вигляді 24 текестових рядків (виключно цифри) довжиною по 25...30 символів. Ідей є кілька. Вирішив почати з Arduino. Прийом інформації вже реалізовано - для цього вистачило періоду і тривалості рядкових синхроімпульсів. Наразі триває боротьба за формування відеосигналу в форматі 640*480*60 Гц
- dimich
- 2025-08-21 17:38:35
Щодо практичної доцільності - то автору видніше. А щодо ненормальності я би посперечався. Якраз такі задачі дають розуміння нутрощів як конкретної платформи, так і в загальному. І розуміння предметної області. Без такого розуміння тільки скетчі ліпити з готових бібліотек за вказівками AI.
Та й порція ендогенного дофамінчику природнім шляхом - це приємно.
- jokeer
- 2025-08-21 10:13:42
Все одно є сумніви в доцільності. Хіба що для ачівки з ненормального програмування. Якщо це повноцінний дисплей- ціна більш підходящої мікросхеми не грає ніякої ролі. Якщо OSD - тим більше, max7456 все рішає.
- dimich
- 2025-08-21 08:33:44
Хм. Виводити дані через spi, порахувати такти, щоб наступний байт завантажувався зразу після вивантаження- тоді можна або без розривів, або з мінімальними.
Саме так і реалізується.
Але проблема- пам'яті не вистачить.
Якщо виводити текст, то багато пам'яті не потрібно: шрифт на флешці лежить. За 16 тактів можна багато чого встигнути 
- jokeer
- 2025-08-21 08:15:52
Хм. Виводити дані через spi, порахувати такти, щоб наступний байт завантажувався зразу після вивантаження- тоді можна або без розривів, або з мінімальними. Але проблема- пам'яті не вистачить.
Хіба що кілька рядків виводити.
- dimich
- 2025-08-21 07:45:41
Схоже, що це найкраще пояснення того, що відбувається.
Але приведений вами код в такі інструкції не скомпілиться, бо у вас же пишеться весь регістр PORTB. Компілятор не знає, що з нього потрібен тільки один біт, а решта ігнорується. Хіба що значення після кожного зсуву заздалегідь завантажились в 7 регістрів.
Можливо, компілювався схожий, але дещо відмінний від цього код. Потрібно дивитись дизасемблером, що там відбувається насправді.
- MikeM
- 2025-08-21 07:30:32
Ще може бути, що ваш компілятор виявився розумніший, і згенерував щось типу
Схоже, що це найкраще пояснення того, що відбувається. Дякую за думку
- dimich
- 2025-08-21 06:30:55
Blue pill? Так в ньому інша система команд повинна бути
і gpio трохи інакше влаштовано мабуть.
Нє, Blue Pill - то ж наче STM32.
Колись попалась в руки "атмега", корпус явно перемаркований, таймінги дивні, не відповідають даташиту. Деякі фʼюзи не шились, ще якісь дивності з периферією були. Міряв споживання в різних режимах - на атмегу зовсім не схоже, і пульсації струму 72 МГц. Хоча шилась по-AVRівськи і AVRівський байткод виконувала. Потім перестала по ISP відповідати. Думав, може SPIEN фʼюз злетів. Вирішив 12-вольтовим програматором до неї достукатись, вона і згоріла нафіг.
Можна подивитися як влаштована ліба для адресних світлодіодів, там досить швидко біти виводяться.
Для довільних даних швидше як 2 такта на біт все одно не отримати. А якщо чисто програмно, не використовуючи SPI чи UART, то ще час на завантаження саміх даних в регістри.
Мені вдавалось колись генерувати зображення на атмезі, і VGA, і PAL. Але фіксовані фрагменти по пікселю за такт, або довільні дані по 2 такта. При тактовій 20 МГц це було щось біля 300 з чимось пікселів по горизонталі.
І на форумі був пост про генерацію відео, але там було stm32.
Там була генерація апаратним LTDC.
- jokeer
- 2025-08-21 04:55:39
китайський емулятор атмеги на 32-бітному ядрі та 72 МГц
Blue pill? Так в ньому інша система команд повинна бути і gpio трохи інакше влаштовано мабуть.
Можна подивитися як влаштована ліба для адресних світлодіодів, там досить швидко біти виводяться. І на форумі був пост про генерацію відео, але там було stm32.