Общо взето идеята беше сходна, праща константи данни и следи с анализатора за появата на нещо различно, което да използва за тригер.

Има ли някаква активност, която да се появява след 2е6 време? Нещо което да дърпа повече ток на ниво платформа?

Сравнително лесен начин да провериш дали е някаква времева константа (разряд на кондензатор, токов пик т.н.) или препълване на брояч, е да намалиш броя на пакетите. На всеки 6 мс изхвърляш вместо да изпращаш по юарта. Ако грешката започне да се появява след 4е6 пакета значи е времева константа.

Да и аз това имах в предвид да се пусне процесора да праща някакви байтове и да се види дали почват да се променят. Това ако има някакъв шифт на битове.
Ако пък има изпускане на байтове, да се направи да върти от 0x00 до 0xFF да се види кои изпуска. Примерно със Docklight да се следи трафика.
При положение, че при затваряне и повторно отваряне на порта се получава се насочваме към драйвера на FTDI. Или просто програмата която показва данните да не дава грешка.
Т.е. целта на проверката е да се провери първо дали системата FTDI<->PC драйвер работи коректно със сурови данни.

Това че става след определен брой пакети е по-смущаващото, иначе да бърка данни не би ме учудило, но толкова константно да се появява в хедъра .. между другото това са много данни, на тая скорост ... мен ме учудва че няма повече сгрешени, 2 млн пакета, по 734 байта .. бая, дори да приемем че данните са доста повече сравнени с хедъра пак при толквоаз пакети би трябвало да има и сбъркани хедъри доста преди тия 2 млн отчета.

Виж дали в конфигурацията на семплирането и делителите работиш навсякъде с цели числа. Ако ли не, може да имаш минимален дрифт на точката на семплиране и след 2е6 пакета да почне да семплира по фланките. Това може да се тества сравнително лесно ако активираш auto baud rate. За целта може да се наложи да добавиш парити битове, тъй като някои контролери го изискват за ауто бауд рейт.

Какви капацитети имаш вързани на линка? Можеш ли да увеличиш тока на Тх драйвера?

прекалено ти е дълга веригата от вероятности и неизвестности, че да може да се анализира разумно.
твърде много мотики си разхвърлял из градината, като някои са от любимия ми модел с две и повече дръжки.

трябва да я разбиеш на парчета и да ги чешеш едно по едно.

исторически погледнато, според ITU си навлязъл в сивата зона.
по техни препоръки асинхронен интерфейс е добре да се ползва до към мегабит. нагоре вече се минава на синхронен, с явна или неявна синхронизация клок/данни (примерно T1/E1)

няколко общи думи за UART-ите.
предаването е ясно, там няма твърде много разновидности.
битовото приемане е с оверсемплинг и последваща арбитрация, да кажем 6 от 8 или 12 от 16. първите числа могат да варират, понякога даже могат и да се сетват.

ако гледаме варианта 6/8, това значи, че семплиращата честота трябва да ти е 8 (или 16) пъти по-голяма от битрейта.
18650 типовете могат да се клочат с 32MHz, някои позволяват и 40.
ако приемем клок 32.26MHZ и х16 умножител, при двата делителя =1 се получава максимален битрейт 2,016,000.
всичко това не е изсмукано от пръстите и си има практически инженерни обусловености.

разбира се, ако наклочиш UART-a s 40, 60, 80 или дори с 96MHz, ще вдигнеш теоретичния битрейт, но хората (навремето) са правили всякакви изследвания и не го считат за правилно.
също така въобще не е добра идея да работиш с делители =1

---

предполагам, щом говориш за PC, иде реч за RS232. не е лошо да погледнеш чаршафите на конкретните буфери. но дори и да държат такива скорости, пак ще е конкретна постановка.

за мен най-вероятното място е FTDI чиплето, възможно в комбинация със седящия зад него драйвер и ОС (нищо не споменаваш за това).
по същество чиплето е микроконтролер, програмиран да върши тази конкретна функция (UART-USB бридж).
и какви мухи почват да му бръмчат в адресното пространство, най вероятно и в FTDI не могат да кажат.
драйверите им също не се славят с оптималност. а ако се намесени и някакви М$ ОС-ове...

та първото нещо, което трябва да изолираш и/или изследваш е баш тази част.

---

не е лошо да се сдобиеш с достъп до нискоскоростен BERT анализатор/генератор. отделно желязо, по възможност самостоятелно, с копчета и дисплей.
генератора ти пуска оптимизирана битова последователност, може да вкарва контролирано и грешки. в приемника проверяваш и верифицираш тази последователност (BERT->FTDI).
ако има анализаторни функции, може и на обратното (MAX->BERT)
въпроса е дали ще намериш BERT за твоя битрейт

---

може и да пософтуеристваш и да вържеш два контролера да си говорят.
виж ITU O.150 и O.151 за препоръки кое и как.
аз НЕ бих вързал два еднакви контролера, не е много ясно какво ще тестваш - софтуера или IP-то на UART-a.

А дали не можеш да свържеш въпросните 2е6 пакета с време - примерно времето след включване на захранването или влеме след активиране на комуникацията/ използването на проца в активен режим?

Идеята ми е, че по време на работа, устройството ти, както и FTDI чипа се нагряват, като е възможно да променят честотата на кварцовете и от двете страни на линията.

От друга страна при даден клок на уарт-а и зададен "стандартен" баудрейт винаги работиш с някаква грешка. Та ако тази грешка ти е на "границата" (3% по смътни спомени) и като се добави температурен дрифт на честотата на кварца от нагряване на устройството и/или FTDI след определено време на работа (не в IDLE режим) - възможно е това да ти е проблема.

Предполагам, че тези грешки си ги смятал от твоята страна на жицата, но може би трябва да ги сметнеш и от страната на FTDI. Вероятно в документацията на FTDI чипа си пише кои баудрейтове с каква грешка ги поддържа.

Пробвай да избереш такъв баудрейт, при който уартовете на двата края на жицата да имат възможно най-малката грешка, която да е далече от граничната грешка от 3%, която споменах по-горе.

Моите 5ст:

Относно семплирането. Правилно семплиране може да се прави и само с 3 пъти по-висока честота. Но това е когато честотите са точни, а те никога не са. И от тук идва основното ограничение. Практиката да се ползва овърсемплинг от 8/16 в общия случай е по-скоро свързана с консумации и други съображения, които нямат нищо общо с правилното семплиране. Изключение е само при Манчестър кодиране, тогава големия овърсемплинг помага по-лесно да се синхронизират честотите още на бит ниво. Но при стандартен UART, особено ако се предава 0х00 или 0xFF имаш един фронт при старт бита и един фронт при стопа. Не е важно да ли ще ги семплираш с 3х или 300х, важно е 3 по какво или 300 по какво. По колкото и да се умножава правилото е, че не трябва да имаш грешка повече от половин бит за 10 бита. Или иначе казано Tx и Rx честотите трябва да не се разминават повече от 5%.
На теория има и ще детайли, но да не задълбавам. Ще кажа само, че на тия 3 мбит не би трябвало да са проблем (на теория), но практически не съм изненадан че има проблем. Демек от тая скорост нагоре обикновено почват да се появяват чисто практически проблеми, въпреки че теоретично всичко би трябвало да е ОК все още.
Относно практическите проблеми:
1) Хубаво е да се видят честотите ако може... При контролерите обичайно идват от PLL някакъв, не ги знам тия Максими как са. Но е хубаво да се провери ако е с PLL дали случайно не е със spread spectrum.
2) Формата на сигналите. Ако фронтове са размазани това значително стеснява прозорците за семплиране. Освен това фронтовете имат склонност да се променят в зависимост от температурата. Така че ако нещата са на ръба е нормално след като поработи малко и като позагреят транзисторите лееееко да мръднат фронтовете и да се окажат под ръба...
3) Захранването на ФТДИ чипа. Въпреки че тия чепове имат добра слава, на практика съм виждал преходници които като ги натовариш яко да предават, почват да харчат и захранванията им клякат. Съответно пак ако нещата са били на ръба стават под ръба... Аз задължително бих тествал с различни преходници.
4) Хубаво е да се провери дали наистина проблемът е хардуерен, т.е. някакво тестче само на комуникации с различни скорости и т.н.

Предполагам ФТДИ не правят такива глупости, но съм виждал УАРТ на Самсунг, който да семплира не посредством арбитрация ами просто да взима първата фланка на овърсамплинга, което при 1:4 те праща в първите 25% от периода... в комбинация с по-размити фронтове поради слаби драйвери или големи капацитети мазалото при порядък 1 Mbps и нагоре е програмирано. Ако можеш да намалиш скоростта, пробвай да видиш какво става. Ако проблемът не изчезне, а почне да се появява по-късно може да търсиш по драйверите за някакво препълване

този Максим има ли кеш

(страничен въпрос )А има ли варианти при които приемникът е със фазова синхронизация на клока ?

Имаш предвид клокът да се възстановява от данните - да всичко над 100MHz задължително е така, т.е. serdes... Но за да възстановиш клок той трябва да тече постоянно, т.е. трябва някакво кодиране от сорта на Манчестър или 8b/10b и тем подобни.

Не имам в предвид клока да е равен на baudrate (генериран с PLL/DDS) и фазата му да се синхронизира по start bit. Така и да бяга часовника винаги се синхронизира със START бита. Ако има натрупана грешка, тя се нулира във на следващият байт. Всъщност аз така имплементирам софтуерен уарт. При овърсемплинг предполагам синхронизацията се изразява в брой импулси.

За едно и също говорим, но това не е решение за универсален UART. За да е "равен" клока ти трябват някакъв минимален брой фазови детекции преди да го постигнеш. Въпросът е, че преди първия старт бит изобщо нямаш фази и тръгваш с "някакъв" клок и първия байт ти е на късмет. Даже не е само първия байт, просто си трябва някаква бройка и някаква периодичност. Евентуално след някакво време и при определени условия ще синхронизираш, но в общия случай не е решение за класически UART.

Предполагам ползваш windows щом споменаваш dll-и. Отчиташ ли някакви грешки?

При достатъчно бърз овърсамплинг и достатъчно кратък старт-байт-стоп пакет решението работи защото не позволява да акумулираш грешки извън рамките на един пакет. Обаче отношенито семплиране към дължина периода на бита трябва да е цяло число, за да не бяга точката на семплиране, особено при 1 Мбпс.