Ви не увійшли.
Там виводиться байт 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)
Неактивний
Arduino на atmega взагалі для нових проектів не бачу смислу використовувати. Так, воно добре описане. Але за 20 років людство придумало купу різних приспособ. Від більш швидких і дешевих контролерів до апаратних штук типа max7456. Це якщо цікавить результат а не процес
Щоб отримати безперервний потік, потрібно виводити через USART в режимі SPI.
В SPI мені вдалося звести інтервал між суміжними байтами до 0,125 наносекунди.
А USART в режимі SPI хіба не буде додавати стартові і стопові біти?
... до апаратних штук типа max7456.
Чи може max7456 працювати на повний екран?
Остання редакція MikeM (2025-08-24 11:16:24)
Неактивний
Чи може max7456 працювати на повний екран?
Треба курити даташіт. В ньому багато налаштувань. А вам треба 24 рядки по 30 символів чи саме повний екран?
>> Displays Up to 16 Rows x 30 Character
Сорян, під ваші вимоги не підходить.
В SPI мені вдалося звести інтервал між суміжними байтами до 0,125 наносекунди.
Ви не помилились з приставкою? 0,125 наносекунди чи мікро?
Ось щойно перевірив: при затримці між записами в SPDR 17 тактів дані виводяться нормально, інтервал 125 нс. При затримці 16 тактів виводиться нуль. При затримці 15 і менше запис в регістр взагалі ігнорується.
А USART в режимі SPI хіба не буде додавати стартові і стопові біти?
Не буде, на то він і SPI-режим.
Остання редакція dimich (2025-08-24 14:57:51)
Неактивний
Звичайно переплутав. Вони такі маленькі, що можна і переплутати
У мене вийшло так:
SPDR = codePage[i0++]; __asm__("nopnt""nopnt""nopnt""nopnt""nopnt""nopnt");// бекслеші чомусь з'їдаються
...
...
...
SPDR = codePage[i24++]; __asm__("nopnt""nopnt""nopnt""nopnt""nopnt""nopnt");// бекслеші чомусь з'їдаються
Один рядок - один "поверх" одного символа.
Якщо використовувати цикл (звичайно, без NOPів, з'являється додаткова затримка, впоратись з якою не вдається
Остання редакція MikeM (2025-08-24 17:21:35)
Неактивний
бекслеші чомусь з'їдаються
Баг форума. Їх потрібно дублювати. І після попереднього перегляду також. Дуже незручно.
SPDR = codePage[i0++]; __asm__("nopnt""nopnt""nopnt""nopnt""nopnt""nopnt");// бекслеші чомусь з'їдаються
...
SPDR = codePage[i24++]; __asm__("nopnt""nopnt""nopnt""nopnt""nopnt""nopnt");// бекслеші чомусь з'їдаютьсяЯкщо використовувати цикл (звичайно, без NOPів, з'являється додаткова затримка, впоратись з якою не вдається
Можна перед циклом вказати #pragma GCC unroll N, де N дорівнює або більше кількості ітерацій.
#pragma GCC unroll 25
for (uint8_t i = 0; i < 25; i++) {
...
}
Тоді компілятор має повністю розгорнути цикл, якщо кількість ітерацій відома на момент компіляції.
Ітерація цикла з перевіркою умови в рантаймі на AVR виконується мінімум за 3 такта. А у вас ще й пост-інкремент різних змінних, для яких компілятор не має змоги застосувати інструкцію LD з пост-інкрементом.
Було б корисно подивитись дизасемблером, що там компілятор нагенерував, і порахувати такти.
Мені невідома логіка побудови растру у вашій програмі, тому не дуже розумію, навіщо на кожну колонку окрема змінна. Може це теж можна оптимізувати. Памʼятаю, мені вдавалось зекономити декілька тактів, змінивши формат зберігання шрифта на interlaced (переплетений?): зазвичай шрифт зберігається по порядку символів: спочатку N байт першого символа, де N - висота в пікселях, потім N байт другого і т.д. А у мене формат був: спочатку 256 байт верхнього "поверха" кожного символа, потім 256 другого зверху "поверха" і т.д. Це дозволило позбутись множення на висоту символа на кожній ітерації. Але не знаю, чи доцільно це застосовувати у вашій реалізації.
Якщо у вас там тільки цифри, то інтервал в 125 нс (1 "віртуальний" піксель) не має сильно заважати. Тільки ж AVR'івський контролер SPI при CPHA=1 "тягне" останній біт до наступного байта, тобто буде не просто темний проміжок, а "розтягнуті" крайні пікселі. А при CPHA=0 сигнал потрібно інвертувати. Хоча й при використанні USART SPI теж потрібен зовнішній інвертор.
Неактивний
Окрема зиінна на кожну колонку для того, щоб зменшити об'єм обчислень під час формування відеосигналу. Кодова таблиця класична: суміжні N байтів описують поверхи одного символа. При формуванні порожнього екранного рядка визначаються 25 символів, які будуть відображатися в наступних N рядках і в змінні і0 ... і24 записуються стартові адреси описів відповідних символів в кодовій таблиці. Після відображення чергового поверха чергового символа до відповідного іХ додається 1, щоб в наступному рядку відображався наступний поверх. Коли всі поверхи відображені, в наступному порожньому екранному рядку виконуються обчислення початкових адрес для наступних 25 символів.
Якщо і0 ... і24 замінити елементами масиву, то на їх інкремент знадобиться суттєво більше часу. Хоча з "unroll" варто спробувати
Хвіст, що може тягнутися за символом враховано. Останній біт завжди нульовий
Остання редакція MikeM (2025-08-24 19:06:17)
Неактивний
Тут прямо проситься stm32, в якій більше мегагерців. Чи Ch32v003.