Форум arduino.ua

А якщо правильно упакувати, то і таблиці в півтора раза менші, і виконання навіть швидше. Має вийти десь 5.5 мкс.

const uint16_t PROGMEM intr[512] = { 0x000, 0x001, ... 0x510, 0x511 };
const uint16_t PROGMEM frac[128] = { 0x000, 0x008, ... 0x984, 0x992 };
char out[6];

void convert(uint32_t n)
{
    char *dst = out;
    uint16_t d;
    d = pgm_read_word(intr + ((n >> 19) & 511));
    *dst++ = d >> 8;
    *dst++ = (d >> 4) & 0xf;
    *dst++ = d & 0xf;
    d = pgm_read_word(frac + ((n >> 12) & 127));
    *dst++ = d >> 8;
    *dst++ = (d >> 4) & 0xf;
    *dst = d & 0xf;
}

А SMCR, по-вашому, де визначено? На avr-libc і весь ардуіно фреймворк побудований, так що це як раз із бібліотекою. Тільки замість бібліотечної функції чи макроса прямий доступ до регістра. Цілком можна і так, якщо не планується компілювати для контролерів, у яких sleep modes визначаються не через SMCR.

Дивно, бо для єдиної інструкції у виразі в asm це не має значення. А для кількох інструкцій без \n була б синтаксична помилка.

\n для асемблера, бо компілятор спочатку зклеює сусідні строкові літерали, потім передає асемблеру. А асемблеру потрібно розрізняти рядки з мнемоніками. Але для єдиної інструкції це не обовʼязково.
\t для краси, щоби при виводі асемблерного лістингу наступний рядок був з відступом.

Що значить "збивається"?

4 мкс - це 64 такта. Спробую вгадати, ви помістили в обробник чималий шматок коду, який потребує зберігання/відновлення всіх регістрів. 32 інструкції pop по 2 такта в епілозі обробника, от вам і 4 мкс.
По-хорошому, обробник має складатись з єдиної інструкції reti: тільки розбудити процесор зі сплячки і завершитись.

Покажіть же, як ініціалізуєте таймер, що виконується в обробнику, як синхронізуєте переривання з рештою коду.

При наявній на даний момент інформації - можуть хіба що екстрасенси-телепати.

Старший байт 16-бітної змінної. У автора там наче б то індекс для масиву зі шрифтом.

Це дизасемблинг обʼєктного файлу (.o) до релокації, в ньому всі адреси нульові. При лінковці вже лінкер підставить потрібні адреси. Там буде адреса другого байта

Нє, там буде інша адреса. Тут має бути зрозуміліше: https://godbolt.org/z/zKqrK7szG

За конвенцією в r1 завжди нуль. Саме тому після інструкцій mul, а також в преамбулі ISR компілятор його обнуляє. Є сумніви щодо доцільності такого рішення, але вже так.

Просто завантажує (Load Direct from Data Space) та вивантажує (Store Direct to Data Space) значення регістрів з/в памʼять. Так, в нерелокованому коді нульові адреси збивають з пантелику.

По-хорошому, такі фрагменти потрібно одразу писати на асемблері, чи на вбудованому, чи в окремому файлі. Воно-то можна зкомпонувати вирази мовою високого рівня і підібрати необхідну кількість нопів. Але при подальших змінах в коді, чи при компіляції іншою версією, або з іншими опціями згенерований код може стати іншим, і все попливе.

Наприклад, такий код (еквівалентний рядку вашого):

uint32_t serialBuf;
uint16_t i14;

__attribute__((naked)) void foo()
{
    i14 = ((serialBuf & 0x400) == 0) ? 0 : 1;
}

Або, те ж саме:

i14 = !!(serialBuf & 0x400);

GCC версії 15.1.0 з опціями "-mmcu=atmega328p -Os" компілює в

00000000 <_Z3foov>:
   0:   80 91 00 00     lds     r24, 0x0000     ; 0x800000 <__SREG__+0x7fffc1>
   4:   82 fb           bst     r24, 2
   6:   88 27           eor     r24, r24
   8:   80 f9           bld     r24, 0
   a:   80 93 00 00     sts     0x0000, r24     ; 0x800000 <__SREG__+0x7fffc1>
   e:   10 92 00 00     sts     0x0000, r1      ; 0x800000 <__SREG__+0x7fffc1>

9 тактів, ніякої залежності від значень.

А GCC версія 7.3.0 з ардуінівського тулчейна з тими ж опціями компілює в

00000000 <_Z3foov>:
   0:   80 91 00 00     lds     r24, 0x0000     ; 0x800000 <__SREG__+0x7fffc1>
   4:   90 91 00 00     lds     r25, 0x0000     ; 0x800000 <__SREG__+0x7fffc1>
   8:   a0 91 00 00     lds     r26, 0x0000     ; 0x800000 <__SREG__+0x7fffc1>
   c:   b0 91 00 00     lds     r27, 0x0000     ; 0x800000 <__SREG__+0x7fffc1>
  10:   2a e0           ldi     r18, 0x0A       ; 10
  12:   b6 95           lsr     r27
  14:   a7 95           ror     r26
  16:   97 95           ror     r25
  18:   87 95           ror     r24
  1a:   2a 95           dec     r18
  1c:   01 f4           brne    .+0             ; 0x1e <_Z3foov+0x1e>
  1e:   81 70           andi    r24, 0x01       ; 1
  20:   99 27           eor     r25, r25
  22:   90 93 00 00     sts     0x0000, r25     ; 0x800000 <__SREG__+0x7fffc1>
  26:   80 93 00 00     sts     0x0000, r24     ; 0x800000 <__SREG__+0x7fffc1>

Дивіться дизассемблером, що генерується в кожному окремому випадку. Контекст виклику також істотно впливає на результат.
Можна за допомогою "avr-objdump -dz firmware.elf". Якщо збираєте власним Makefile, то генерацію асемблерного лістингу автоматизувати просто. В platformio також можна.
Опцією -S можна тимчасово вказати компілятору, щоб замість обʼєктного продукував асемблерний файл і на тому зупинявся.
Можна зберігати проміжні результати компіляції опцією -save-temps.
Для швидкого аналізу коду, що генерується, можна користустуватись godbolt.org. Тільки avr-gcc 7.3.0 чомусь там не знайшов.
Також майте на увазі, що link time optimization (опція -flto) може кардинально змінити код в результуючому .elf порівняно з тим, що в обʼєктному файлі. Тому кінцевий результат потрібно дивитись objdump'ом на .elf.

По суті, на обробку даних у вас є тільки час вертикального зворотнього "ходу променю".
Якщо горизонтальна синхронізація (HSync) генерується апаратно таймером по Output Compare Match, то це безперервний інтервал в 1.4 мс, тобто більше 22000 тактів. Плюс декілька десятків тактів під час кожного горизонтального синхроімпульсу та back porch.
Якщо HSync програмна на GPIO, то цей інтервал потрібно розбивати на безперервні фрагменти не більше як десь по 450 тактів.

Дивно. Ви ж це безпосередньо перед циклом "for" написали, а не десь на початку?
А, мабуть ви користуєтесь ардуінівським тулчейном з GCC 7.3.0. Ця прагма зʼявилась в GCC 8.
Просто я собі для platformio зробив пакунок atmelavr, який використовує avr-gcc, встановлений в системі (на даний момент 15.1.0), а не з їхнього репозиторію, який вони самі тягнуть з ардуїнівського з версією GCC часів Давньої Греції. Тоді вибачаюсь, не подумав перед тим як радити, що у людей це може не працювати.

Баг форума. Їх потрібно дублювати. І після попереднього перегляду також. Дуже незручно.

Можна перед циклом вказати #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 теж потрібен зовнішній інвертор.

Так покажіть код, яким виводите. Мабуть же там ще якісь інструкції виконуються.
На "звичайному" SPI завжди будуть проміжки в один чи два такта між байтами. Принаймні мені так і не вдалось їх позбутись. Але не ціла мікросекунда, то щось не так в коді.
Щоб отримати безперервний потік, потрібно виводити через USART в режимі SPI. Звісно, вивод буде на TX пін, а не на MOSI.

Raspberry Pi Zero?

Щодо практичної доцільності - то автору видніше. А щодо ненормальності я би посперечався. Якраз такі задачі дають розуміння нутрощів як конкретної платформи, так і в загальному. І розуміння предметної області. Без такого розуміння тільки скетчі ліпити з готових бібліотек за вказівками AI.
Та й порція ендогенного дофамінчику природнім шляхом - це приємно.

Але приведений вами код в такі інструкції не скомпілиться, бо у вас же пишеться весь регістр PORTB. Компілятор не знає, що з нього потрібен тільки один біт, а решта ігнорується. Хіба що значення після кожного зсуву заздалегідь завантажились в 7 регістрів.
Можливо, компілювався схожий, але дещо відмінний від цього код. Потрібно дивитись дизасемблером, що там відбувається насправді.