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