Ви не увійшли.
Там виводиться байт 0b01010101 молодшим бітом вперед
При константному значенні цей код компілиться в пари ldi/out. Кожна з цих інструкцій на atmega328p виконується за один такт. При 16 МГц один біт за 125 нс, 8 біт за 1 мкс за 937.5 нс.
Як давно осцилограф калібрували?
Або може у вас якийсь китайський емулятор атмеги на 32-бітному ядрі та 72 МГц, таке теж трапляється.
Остання редакція dimich (2025-08-21 01:14:59)
Неактивний
Ще може бути, що ваш компілятор виявився розумніший, і згенерував щось типу
ldi r24,lo8(1)
out 0x5,r24
out 0x5,__zero_reg__
out 0x5,r24
out 0x5,__zero_reg__
out 0x5,r24
out 0x5,__zero_reg__
out 0x5,r24
out 0x5,__zero_reg__
Це 8 біт за 0.5 мкс. Але ж це константні дані. Для знакогенерації чи інших фіксованих картинок ок, для довільного зображення вже так не буде.
Остання редакція dimich (2025-08-21 02:18:30)
Неактивний
китайський емулятор атмеги на 32-бітному ядрі та 72 МГц
Blue pill? Так в ньому інша система команд повинна бути і gpio трохи інакше влаштовано мабуть.
Можна подивитися як влаштована ліба для адресних світлодіодів, там досить швидко біти виводяться. І на форумі був пост про генерацію відео, але там було stm32.
Blue pill? Так в ньому інша система команд повинна бути
і gpio трохи інакше влаштовано мабуть.
Нє, Blue Pill - то ж наче STM32.
Колись попалась в руки "атмега", корпус явно перемаркований, таймінги дивні, не відповідають даташиту. Деякі фʼюзи не шились, ще якісь дивності з периферією були. Міряв споживання в різних режимах - на атмегу зовсім не схоже, і пульсації струму 72 МГц. Хоча шилась по-AVRівськи і AVRівський байткод виконувала. Потім перестала по ISP відповідати. Думав, може SPIEN фʼюз злетів. Вирішив 12-вольтовим програматором до неї достукатись, вона і згоріла нафіг.
Можна подивитися як влаштована ліба для адресних світлодіодів, там досить швидко біти виводяться.
Для довільних даних швидше як 2 такта на біт все одно не отримати. А якщо чисто програмно, не використовуючи SPI чи UART, то ще час на завантаження саміх даних в регістри.
Мені вдавалось колись генерувати зображення на атмезі, і VGA, і PAL. Але фіксовані фрагменти по пікселю за такт, або довільні дані по 2 такта. При тактовій 20 МГц це було щось біля 300 з чимось пікселів по горизонталі.
І на форумі був пост про генерацію відео, але там було stm32.
Там була генерація апаратним LTDC.
Остання редакція dimich (2025-08-21 06:48:55)
Неактивний
Схоже, що це найкраще пояснення того, що відбувається.
Але приведений вами код в такі інструкції не скомпілиться, бо у вас же пишеться весь регістр PORTB. Компілятор не знає, що з нього потрібен тільки один біт, а решта ігнорується. Хіба що значення після кожного зсуву заздалегідь завантажились в 7 регістрів.
Можливо, компілювався схожий, але дещо відмінний від цього код. Потрібно дивитись дизасемблером, що там відбувається насправді.
Неактивний
Хм. Виводити дані через spi, порахувати такти, щоб наступний байт завантажувався зразу після вивантаження- тоді можна або без розривів, або з мінімальними. Але проблема- пам'яті не вистачить.
Хіба що кілька рядків виводити.
Хм. Виводити дані через spi, порахувати такти, щоб наступний байт завантажувався зразу після вивантаження- тоді можна або без розривів, або з мінімальними.
Саме так і реалізується.
Але проблема- пам'яті не вистачить.
Якщо виводити текст, то багато пам'яті не потрібно: шрифт на флешці лежить. За 16 тактів можна багато чого встигнути
Неактивний
Все одно є сумніви в доцільності. Хіба що для ачівки з ненормального програмування. Якщо це повноцінний дисплей- ціна більш підходящої мікросхеми не грає ніякої ролі. Якщо OSD - тим більше, max7456 все рішає.
Щодо практичної доцільності - то автору видніше. А щодо ненормальності я би посперечався. Якраз такі задачі дають розуміння нутрощів як конкретної платформи, так і в загальному. І розуміння предметної області. Без такого розуміння тільки скетчі ліпити з готових бібліотек за вказівками AI.
Та й порція ендогенного дофамінчику природнім шляхом - це приємно.
Неактивний
Трохи розвію туман. Пристрій повинен приймати послідовні 32-розрядні слова і відображати на моніторі їх декодований вміст у вигляді 24 текестових рядків (виключно цифри) довжиною по 25...30 символів. Ідей є кілька. Вирішив почати з Arduino. Прийом інформації вже реалізовано - для цього вистачило періоду і тривалості рядкових синхроімпульсів. Наразі триває боротьба за формування відеосигналу в форматі 640*480*60 Гц
Остання редакція MikeM (2025-08-21 22:12:05)
Неактивний
Прийом інформації вже реалізовано - для цього вистачило періоду і тривалості рядкових синхроімпульсів.
Якщо девайс сам обирає коли приймати, тобто є мастером шини, то такий варіант цілком робочий.
Наразі триває боротьба за формування відеосигналу в форматі 640*480*60 Гц
Для атмеги є реалізації, наприклад.
Нажаль, свою реалізацію навряд чи вже знайду, грався з цим років 20 тому.
Є цікаві рішення і на інших платформах.
Розглядали інші варіанти? Будь-яка козявка з апаратним HDMI-контролером значно спростила би реалізацію. А якщо потреба відображати саме на VGA, то можна через готовий перехідник.
Остання редакція dimich (2025-08-22 00:01:06)
Неактивний
Raspberry Pi Zero?
Як на мене, то це занадто.
Я спробував виводити послідовний код через SPI. Виводить 8 біт за мікросекунду, а потім ще мікросекунду чекає. Чи можна вплинути на цю зайву затримку?
Неактивний
Я спробував виводити послідовний код через SPI. Виводить 8 біт за мікросекунду, а потім ще мікросекунду чекає. Чи можна вплинути на цю зайву затримку?
Так покажіть код, яким виводите. Мабуть же там ще якісь інструкції виконуються.
На "звичайному" SPI завжди будуть проміжки в один чи два такта між байтами. Принаймні мені так і не вдалось їх позбутись. Але не ціла мікросекунда, то щось не так в коді.
Щоб отримати безперервний потік, потрібно виводити через USART в режимі SPI. Звісно, вивод буде на TX пін, а не на MOSI.
Остання редакція dimich (2025-08-22 19:37:10)
Неактивний