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

[Andrej Jancura]

Ahoj,

mas dobre pripomienky, len som nepochopil, preco si zmenil predmet... Ak si
chcel upozornit na tie chybove stavy, tak si to mohol nechat v odpovedi, ja
by som si to uz nasiel. Neboj sa aj nad tym som premyslal a som za co
najjednoduchsie riesenie, pretoze dat kamsi svab, ktory zerie cca 50mA, nie
je pre mna akosi in. Dalsie reakcie v odpovedi.


2014-02-20 0:52 GMT+01:00 Marek Peca <marek na duch.cz>:

> 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.
>

Ja som za co najjednoduchsi protokol, teda len alfanumericke znaky a par
riadiacich. Ono toho do toho PIC aj tak nie je mozne zrejme viac natlacit,
aj keby som ho programoval v asembleri.


>
> 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.)
>

Myslel som, ze by som obcas poslal BREAK, obzvlast ak bude Tx rieseny
kompletne softwarom.


>
> 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...
>

Ze je to mozne, to mi jasne je, tak ako mi je jasne aj to, ze to je uz
hotove a vyriesene... Ale rad by som to vyriesil sam a nieco sa pri tom aj
naucil. Myslim, ze prvy krok je to, ze potrebujem 16x rychlejsie
vzorkovanie aby som obisiel tych 10%. Ostatne by tiez nemalo byt moc
zlozite, nakolko mi staci len jednoduchy UART bez chybovych hlasok, ktoremu
treba len spravne nastavit hodiny. Takze by sa to mohlo nacpat do nejakeho
jednoducheho cipu. Je to ale len moja prva predstava a zatial som to hlbsie
nebadal.


>
> 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.
>

Asi ti uniklo, ze to chcem ku malemu mcu, ktory ma na hrane oscilator. To
bude asi preto, ze si zmenil tu hlavicku. :) Rad by som sa kvoli nedostatku
pamati vyhol akemukolvek CRC ci nebodaj komprimovaniu dat.

A.


>
>
> ZdraviM.
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
------------- dal?í ?ást ---------------
HTML p?íloha byla odstran?na...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20140220/d4cb0e0c/attachment.html>