Форум arduino.ua

У U8g2 як мінімум заявлена підтримка "T6963" (хоча він T6963C), а RA6963 має бути сумісний з T6963C. Так що показуйте вашу схему підключеня та код. Код бажано мінімальний, тільки ініціалізація та відображення пари байтів пікселів.

Для початку - сформулювати вимоги до виробу. Які функції мають бути реалізовані, у якому вигляді? Ніколи не користувався фоторамками, тому надалі - лише здогадки.

1. Відображення картинки на дисплеї. Зображення буде прошите разом з ПЗ? Чи має завантажуватись із зовнішнього носія, наприклад, SD-карти? Чи має завантажуватись по Wi-Fi? Єдина картинка, чи декілька, які змінюються? Який критерій зміни: по таймеру, "вручну" користувачем?

2. Відтворення аудіо. Пищання мелодії біпером? Чи повноцінне аудіо? Як і для зображення, чи буде це єдиний прошитий фрагмент, чи з файла на зовнішньому носії, чи завантажуватись по Wi-Fi? Які формати файлів та кодеків мають підтримуватись? Які критерії початку/зупинки відтворення аудіо?

Відштовхуючись від вимог уже підбирати компоненти. Контролер - на ваш смак, аби були необхідні інтерфейси (які залежать від вимог). Мабуть же, у вигляді готового модуля. Особисто я спробував би реалізувати на ESP32.
Якщо зберігання файлів на SD-карті, то очевидно, знадобиться модуль SD-карти. Для повноцінного аудіо, можливо, знадобиться окремий I2S DAC. І динамік. Буде якийсь користувацький інтейфейс? Якщо так, то знадобляться або кнопки, або тачскрін.

Уточніть, будь ласка: допомогти з реалізацією - це допомогти розібратись із якимись технічними питаннями, чи виконати проект або його частину за відповідну оплату?

Також 5-й пін можна підключити до землі безпосередньо на цьому ж шарі, не через перехідний отвір.

PIO Assembly VGA Driver for RP2040 (Raspberry Pi Pico)

А якщо правильно упакувати, то і таблиці в півтора раза менші, і виконання навіть швидше. Має вийти десь 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 часів Давньої Греції. Тоді вибачаюсь, не подумав перед тим як радити, що у людей це може не працювати.