Форум arduino.ua

Вправо? Цікаво, я би очікував навпаки, вліво. Буфер вносить затримку порядка десятка наносекунд, тобто відносно синхроімпульса сигнал зображення повинен приходити трошки раніше. Але тривалість пікселя 40 нс, так що це не було би декілька пікселів.
Хоча, з іншого боку, це означає, що розсинхронізація стала відбуватись пізніше. В ідеалі вона мала "зміститись" вправо настільки, що синхроімпульс нового рядка мав би приходити раніше, ніж ця розсинхронізація відбудеться.

Питання навмання: не пробували інвертувати полярність HSync?

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

Питання навмання: Не перевіряли цей монітор з джерелом заздалегідь робочого VGA сигнала, наприклад HDMI-VGA адаптером або старою відеокартою з VGA-виходом? Мені в свій час допоміг ось такий генератор. Може це особливість самого монітора, виробник зробив VGA-вхід "аби було"?

А як, наприклад, виглядають вертикальні лінії в один піксель з інтервалом в пару десятків пікселів?

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

Які номінали резисторів на кожному з пінів? (на фото не розібрати).

На схемі в проекті з гітхаба R-2R ЦАП, він робить певну аттенюацію. У вас, якщо на виході PI2 3.3В, то має бути десь 270-300 Ом.
На VSYNC і HSYNC навпаки, мають бути TTL-рівні, 82 Ома може бути забагато (від схеми монітора залежить).

Схоже на імпульси частотою близько 80 кГц, розмазані за рахунок характеристики навантаження. Що ще може бути на тактовому виході? Вони мабуть і пролазять у сигнал.

STM32F42X має кеш перед флешкою, тому час виконання одного і того ж коду з флешки не є константою з точністю до періоду такотового генератора. Інше питання, чи у вашому випадку джиттер обумовлений цією особливістю, чи особливостями реалізації у вашому коді.

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

Можна спробувати завантажити код в SRAM і виконувати звідти.

Arduino ISP - це програматор у вигляді окремого пристрою на базі attiny: https://docs.arduino.cc/retired/boards/arduino-isp
Вам потрібно, як зазначено вище, Arduino as ISP.

Так завжди виходить, коли код пишеться одразу, без чіткого розуміння що він має робити, та без попередньої розробки алгоритму (на папері з олівцем, так).

Ну, значення Buffer[0], Buffer[3] та Buffer[4] відповідають тим, на які перевіряєте. Що не так?

Ви впевнені, що саме таку послідовність має видавати дисплей? Це десь зазначено в описі протоколу?

Так умова спрацьовує тільки коли набереться 20 байт ТА байти у певних позиціях мають певні значення.

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

Тут же всі символи зливатимуться, "1 23" не відрізнити від "12 3".

for (auto i : Buffer) {
    Serial.print(i, HEX);
    Serial.print(' ');
}

Або, з лідируючими нулями:

for (auto i : Buffer) {
  char s[4];
  snprintf(s, sizeof(s), "%02x ", i);
  Serial.print(s);
}

Взагалі, якщо вся комунікація з дисплеєм іде по послідовному порту, а чіткого опису протоколу немає, я би для початку підʼєднав би його до компа і відлагодив комунікацію у програмі для компа, без всяких ардуін. На будь якій мові, яку знаєте, хоч C#, хоч Python, чи що інше. Потім би уже портував на ардуіну.

Та там весь код наркоманський.
Навіщо аж три таймера з однаковим інтервалом?

В ReadSerial()

      if (Buffer[0] == 0X5A & Buffer[3] == 0X83) {
          if (Buffer[4] == 0X50) {           

виконується навіть коли прочитано лише 1 байт, а в Buffer[3] і Buffer[4] може бути хто зна шо.

Точніше, в Buffer[3] і Buffer[4] значення ніколи і не записуються, бо як тільки прочитано один байт, Buffer_Len скидається в нуль.

І хіба дисплей відповідає такими ж командами, якими сам керується? Я в документацію не вчитувався, але це було би дуже дивно. Зазвичай керуючий пристрій видає команду на читання, потім зчитує результат.

Взагалі, якщо Serial читається побайтно, навіщо зайвий раз перевіряти available()?

Це:

if (Buffer[0] == 0X5A & Buffer[3] == 0X83)

з логічної точки зору працюватиме, але семантично мабуть малось на увазі

if (Buffer[0] == 0X5A && Buffer[3] == 0X83)

Можна припустити, що відображається число (N*256+M)/100, де N - перший байт двічі в BCD, M - другий байт один раз в BCD. Але це якесь збочення. Там же в цих дисплеях наче програмується формат даних для відображення. Може варто перепрограмувати сам дисплей, щоб сприймав дані у нормальному форматі, аніж підганяти дані під такий дивний формат?

О, це вже щось. Для 0x00 0x22 я би сказав, що це BCD, але тоді для 0x22 0x00 було би 22.00. Гіпотеза про BCD не підтверджується. Які значення на дисплеї відповідають наступним записаним значенням:
0x01 0x00
0x00 0x01
0x80 0x00
0x00 0x80
0x55 0x55
?

Тип float в C++ - це 4 байта (в більшості реалізацій це IEEE 754). В 2 байта без втрати точності вони не влізуть. В якому конкретно форматі потрібно представити значення float? Який порядок байт, little endian чи big endian?

Є здогадка, що ви хочете відображати температуру у вигляді двозначного десяткового числа. Якщо так, то для цього ніякого конвертування float в HEX не потрібно. Що за дисплей? В якому форматі він очікує дані, ASCII-коди символів?

Тут нічого специфічного для ардуіно, тут основи C++. В ардуіно хоч і недо-, але все таки підмножина С++. Потрібно навчитись читати код і діагностику компілятора, він же все підказує.

А якщо мета - навчитись програмувати, то вивчати C++ на прикладі ардуінівських бібліотек категорично не рекомендую.