Dekodovanie UARTu

[Andrej Jancura]

Ahoj,

to mi je jasne, ze to potrebuje nejaku synchronizaciu, ale dakujem za
poznamku. Som myslel, ze by sa nejako dekodoval start a stop bity, ale asi
bude rozumnejsie tam tu preambulu dat.

A.


Dňa 20. februára 2014 0:24, Pavel KREJCI <krepa76 na gmail.com> napísal(-a):

> Jenze to tvoje recovery prave potrebuje taky nejakou "preamble" tedy
> hlavicku, aby se mohlo zasynchronizovat.
> PK
>
>
> 2014-02-19 17:22 GMT+01:00 Andrej Jancura <aj.hwlist na gmail.com>:
>
> Ahoj,
>>
>> Dňa 19. februára 2014 16:38, Jan Waclawek <konfera na efton.sk> napísal(-a):
>>
>> Aha, to je pokracovanie k
>>> http://list.hw.cz/pipermail/hw-list/2014-February/452501.html
>>>
>>
>> Ano je to dalsi diel... A v kutiku duse dufam, ze to nie su zase nejake
>> profesionalne technologie, pretoze s profesionalmi, obzvlast zelenymi,
>> nemam dobre skusenosti a radsej obchadzam aj ich tiene. :)
>>
>>
>>>
>>> Najjednoduchsie, a mozno aj najlepsie, je mat nejaky balickovaci
>>> protokol,
>>> a v ramci neho na zaciatku vyslat nejaky konkretny dohodnuty znak, na
>>> ktory sa moze chytit prijimac. Typicky sa na toto zvykne pouzit 0x55='U',
>>> co je spolu so start a stopbitom sekvencia nul a jedniciek vsetky v
>>> trvani
>>> jedneho bitu. Samozrejme to znamena, ze na prijimacej strane mas nieco
>>> realtimove, obvykle mcu, t.j. nieco co vie odmerat cas medzi hranami a
>>> prenastavit baudrate, bo s PC ci UART-to-USB cipmi si takto neporadis.
>>>
>>
>> Toto vsetko som domyslel aj ja. Dokonca ak by som pouzil moj oblubeny
>> pic16f690, tak ten ma aj auto baud presne na ten 0x55... Skor si vsak
>> myslim, ze riesenie s tym recovery je ovela robustnejsie a spolahlivejsie.
>> Samozrejme vyzaduje to iny pristup a pohlad na vec. Takze preto som sa
>> spytal. Nic ine ma nezaujima, teda nezaujima do tej miery, pokial to nie je
>> lepsie riesenie. Co riesenia, ktore sme tu prebrali minule nie su. A kedze
>> si myslim, ze to je typicka uloha resp. aplikacia, tak by to mohlo byt
>> kdesi aspon vysvetlene.
>>
>> A.
>>
>>
>>>
>>> wek
>>>
>>>
>>>
>>>
>>> >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. To je prva cast
>>> otazky a
>>> >druha je, ci by ste mi nemohli dat nejaky link na nazorne vysvetlenie
>>> toho
>>> >algoritmu. Google hodi kopec odkazov, ale nic nie je dostatocne
>>> jednoduche
>>> >a nazorne, bud to je sialena teoria alebo dostatocne neprehladna zmes
>>> >informacii a obrazkov. Mne je tato oblast neznama, pretoze mam iny
>>> odbor,
>>> >ale chcel by som si to dostudovat a trochu poexperimentovat. Vopred
>>> dakujem
>>> >za odpovede.
>>>
>>> _______________________________________________
>>> HW-list mailing list  -  sponsored by www.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>
>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>>
>
> _______________________________________________
> 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/607995b2/attachment.html>