Jak resit bufferovani UARTU v MCU

RV vicek.radek@cpost.cz
Čtvrtek Březen 23 11:39:28 CET 2006


Tak jsem hledal protokoly a vypadlo mi z toho tohle: 
http://www.hw.cz/Produkty/ART1313-Seriovy-LCD-terminal.html
;-)   


No premyslim o tom, ale pripada mi to zbytecne - tedy ne ze bych mel 
neco proti nejakym standardum - ale ten protokol ma jednu nevyhodu a to, 
ze nafukuje tu komunikaci o velky pocet ridicich znaku a navic je pro 
jeho implementaci mit rizeni provozu na lince. Ja jsem kvuli tomu prave 
implementoval oddelovac prikazu, abych nemusel resit parsovani ridicich 
sekvenci v MCU.
Jednodussi protokol je i vyhodou pro ovladani z MCU - neni treba toho 
tolik sypat a implementovat.

Je to asi take o tom, ze je to urceno pro bastlice a ne pro prumyslove 
uziti jako prevodnik z HW serveru - pokud budu delat neco co ma byt 
pouzitelne ve standardizovanem prostredi tak je to jasne.

Co se tyka bufferovani: On je trochu problem s tim, ze ovladam celkem 
pomale zarizeni jako je tenhle radic LCD a at je to jak chce musim i ja 
na nej cekat coz to trochu komplikuje.
Momentalne je to tak, ze se komunikuje 9600 8N1 a i pri vypisu celeho 
radku najednou staci cekat 100ms (mozna min). Kdyz jsem se tuhle "chybu" 
snazil jeste vecer nejak obejit v SW v PC tak jsem tam nastavil mezi 
dvema prikazy prave tuhle pauzu. Vetsinou kdyz potrebuji zapsat z PC tak 
mi na to staci dva prikazy (v pripade dvouradkoveho LCD) - abych nemusel 
zbytecne cekat v programu PC chtel bych prave implementovat zpracovani 
nekolika prikazu poslanych najednou. Tak me napada, ze rozsirim 
"protokol" o prikaz pauzy - tedy cekani mezi vykonanim dalsiho prikazu.

Co se tyka toho proc nechci pouzit zpetnou linku - to je proto, ze chci 
jen pomoci jednoho UARTu obsluhovat dve zarizeni. Ted to zkousim na te 
meteostanici - momentalne mi meteostanice meri teplotu a RH a to se 
slozite pocita v MCU jen abych to mohl plesknout na displej a zaroven 
posilam surova data na PC kde to spocitam mnohem presneji a odeslu na 
web. Jenze mi prijde zbytecne mit u kazdeho zarizeni displej a navic 
zbytecne velkej MCU. Server mi stejne bezi tak bych jej chtel vyuzit.

Predstava je tedy takova, ze ted mam hotovej vystupni zobrazovac (bude 
mozne radit displeje na jednu linku) a pomoci ni umistit displeje na 
ruzna mista po byte a posilat ze serveru na ne info jake bude treba.
Stejne tak si pohravam s obracenou myslenkou - tedy jakehosi 
koncentratoru vstupnich linek - tedy od zarizeni pujde vystupni linka na 
zarizeni, ktere tyto data bud e prenaset jednou linkou do PC.
Prvni na cem to budu chtit vyzkouset je prave meteostanice - ne vsechno 
se da merit na jednom miste a to prinasi problemy s privody a nutnosti 
stejne resit zpracovani primo u cidla.
Vyhledove by to mohlo ridit celej byt a navic budu mit prehled o tom co 
se deje v byte odkudkoliv kde bude internet - snad konecne budu mit od 
1.4. verejnou IP.

RadekCX

Jan Waclawek napsal(a):
> RV wrote:
> ad protokol... ak by som ja nieco taketo robil, pokusim sa pouzit nejaku 
> podmnozinu prikazov VT52/VT100 alebo nejakeho ineho terminaloidneho 
> standardu; ale to je asi vec vkusu, zasa az taky hrozne prakticky vyznam 
> to nema.
>   
> No, ak ste vylucili "spätnú linku" (t.j. handshake, ci uz HW alebo SW), 
> tak ostava jedine zabezpecit, aby ste stihli spracovat prichadzajuce 
> byte a nasledne prikazy dostatocne rychlo. To prve pouzitim prerusenia, 
> to druhe preratanim si kolko trva vykonanie najdlhsieho prikazu a 
> "organizacnym" zabezpecenim, aby nestihol prijst cely nasledujuci prikaz 
> rychlejsie ako sa vykona predchadzajuci (bud vhodne nizkou baudovou 
> rychlostou, alebo vhodne rychlym vykonavanim prikazov :-) alebo musi 
> vysielajuca strana vediet ze musi robit medzery).
>
> wek
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
>
>   





Další informace o konferenci Hw-list