<div dir="ltr"><div>Ahoj,<br><br></div>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.<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-20 0:52 GMT+01:00 Marek Peca <span dir="ltr"><<a href="mailto:marek@duch.cz" target="_blank">marek@duch.cz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
chcel by som sa spytat tunajsich odbornikov na telekomunikacie, na<br>
nasledujuci problem. Mam vystup serioveho portu, kde je frekvencia<br>
zakladneho generatora mimo povolenej tolerancie +-5%. Chcel by som sa<br>
spytat, ci by bolo vhodne na dekodovanie takejto digitalnej sekvencie<br>
pouzit nejaky algoritmus pre recovery hodin a dat. (..)<br>
</blockquote></blockquote></blockquote></blockquote>
<br>
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.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Je totiz nutne si uvedomit, a velke mnozstvi lidi k tomuto poznani nedospeje vcas (mluvim z vlastni blbosti/trpke zkusenosti jednoho bastliveho odpoledne), ze:<br>
<br>
=> 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.)<br>
</blockquote><div><br></div><div>Myslel som, ze by som obcas poslal BREAK, obzvlast ak bude Tx rieseny kompletne softwarom.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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...<br>
</blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote><div><br></div><div>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.<br>
<br></div><div>A.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
ZdraviM.<br>
______________________________<u></u>_________________<br>
HW-list mailing list - sponsored by <a href="http://www.HW.cz" target="_blank">www.HW.cz</a><br>
<a href="mailto:Hw-list@list.hw.cz" target="_blank">Hw-list@list.hw.cz</a><br>
<a href="http://list.hw.cz/mailman/listinfo/hw-list" target="_blank">http://list.hw.cz/mailman/<u></u>listinfo/hw-list</a><br>
</blockquote></div><br></div></div>