Seriovy port jeste jednou

[Nesvacil Jiri]

> >To je problem, ktery ovsem nastava. Nejlepe shodit signal RTS drive nez
jsem
> >na konci s bufferem. Kdyz UART v PC ma jiz nejake byty za ukol vyslat,
tak
> >je vysila bez ohledu na signal CTS !!
> >
> Mozna ze to v dane situaci nelze, ale nestalo by za uvahu zpracovavat data
> rychleji, nez staci prichazet? Nebo to v principu neni mozne?

To neni urcite dobre pro vsechny aplikace. Jestlize bych mel problemy s
bufferem, tak ve windows zaskrtnu nepouzivat buffer uartu a budu doufat, ze
to aplikace respektuje. Potom by maximalne co schodim signal RTS mel prijit
pouze jeden byte. Tak jak se vetsinou chovaji vsechna zarizeni.
(Jeste doplnuji jestlize aplikace je v BASICu nutno se vyporadat s bufferem
v BASCu tj. 128 bytu)

V pripade, ze nezabere zaskrtnuti, tak si napisu svuj program pro
komunikaci.

Dale seriova komunikace neni prilis jista a pri narocnejsi komunikaci tj.
ridim stroj ci ctu data ze snimacu, tak se pokusim nad seriovy port dat
nejaky protokol. (Pri pouhem cteni ze snimacu muze stacit precteni 2x a
porovani.)
Protokol muzu vybrat nejaky existuji ci si zavedu svuj. Protokol by mel
prenaset po blokach, pamatovat si cislo bloku treba od resetu zarizeni. U
kazdeho bloku by mel byt kontrolni soucet. Samozrejmosti je opakovane
vyslani bloku pri chybe. Jestlize pisi o blokach, tak to muze klidne byt
blok o velikosti nekolika byte (cislo bloku, prikaz+data prikazu, kontrolni
soucet).

Jestlize jiz mam takovyto protokol, tak se muzu klidne vykaslat na vsechny
ostatni signaly RTS,CTS,DTR,DSR.

JN