Jak resit bufferovani UARTU v MCU

[Jan Waclawek]

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.

> 
> S tim souvisi jedna nepekna vec, na kterou jsem prisel az kdyz jsem psal 
> obsluhu displeje do programu k meteostanici. Kdyz poslu totiz prikazy do 
> displeje hned po sobe tak o ten druhej prikaz prijdu, protoze v tu 
> chvili zpracovavam 24 bajtovy buffer (4 parametry a 20znaku) a nemuzu 
> cist UART.
> 
> Premyslim jak to lze vyresit - zatim me napadla jen jedina vec - 
> rozsirit buffer na celej zbytek RAM (asi jeste 150B) s tim, ze tohle 
> proste nesmi pretect a implementovat jeste prikaz pro zpracovani 
> bufferu. Nechci totiz pouzit zadnou zpetnou linku z displeje. Je jeste 
> nejake jine reseni? At dumam jak dumam nic me nenapadlo.

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