Dekodovanie UARTu -- a obecneji setrvavani v chybovem stavu pri UARTove zaplave znaku

[Marek Peca]

>>>> chcel by som sa spytat tunajsich odbornikov na telekomunikacie, na
>>>> nasledujuci problem. Mam vystup serioveho portu, kde je frekvencia
>>>> zakladneho generatora mimo povolenej tolerancie +-5%. Chcel by som sa
>>>> spytat, ci by bolo vhodne na dekodovanie takejto digitalnej sekvencie
>>>> pouzit nejaky algoritmus pre recovery hodin a dat. (..)

Odpoved bude zaviset vzdy na konkretnim "protokolu", ci spise aspon par 
zakladnim pravidlum (typu: jak kdy dlouho klid) nad UARTem, kterymi se ma 
provoz ridit.

Je totiz nutne si uvedomit, a velke mnozstvi lidi k tomuto poznani 
nedospeje vcas (mluvim z vlastni blbosti/trpke zkusenosti jednoho 
bastliveho odpoledne), ze:

=> Pokud UART setrvale vysila bez delsich "STOP" prodlev, muze nastat (a 
deje se to, pri takto spatne navrzenych systemech), ze prijimac setrvale 
prijima jinou sekvenci znaku, nez je vysilana. Tedy, pro urcite kombinace 
znaku dojde k tomu, ze start-bity jsou trvale prijimany jinde, nez ve 
skutecnosti jsou. Pauza (stop) cas od casu to vyleci. (Pak uz zbyde jen, 
vyresit ktery znak je prvni -- starost vyssi vrstvy.)

Odtud tedy k puvodni otazce: obnova hodin a dat urcite, alespon teoreticky 
a v dost rychlem vypocetnim/obvodovem prostredku, mozna je. Otazkou je, a 
to bez znalosti provozu nad UARTem lze tezko rici, jak zaridit, aby se 
takovyto zaves nahodou nezavesil na chybna mista bajtu. Sirka jednoho bitu 
je 10% znaku...

Pokud tam nejsou zadne vkladane synchronizacni symboly, asi to bude 
vzdycky dost nejisty vysledek, zvlast pokud jsou zpravy kuse a napr. 
nemaji scramblovany (komprimovany, CRCovany) vnitrek. Pri nenahodnych 
zpravach, resp. zpravach bez "nahodneho" prvku (CRC) bych to asi radsi 
rovnou vzdal.


ZdraviM.