cteni ze serioveho portu, nekdy jo a nekdy blbe

[Jaroslav Honsa]

> On Tue, 6 Apr 1999, Zdenek Pizl, Czech Agriculture University, Prague wrote:
> > 
> > > > !!! ALE nekdy se stane ze retezec dlouhy treba 25 znaku mi to nacte
> > > > nadvakrat, jakoby tam bylo uprostred '\n' nebo neco podobnyho.
> 
Dobry den,

omlouvam se, predevcirem jsem tady trochu nedokonale tlachal a potom jsem
byl pryc. Ale zatim jsem si celou problematiku trochu osvezil.

Jak je veliky buffer v UART 16550 (16450) nas v podstate nemusi zajimat,
to zajima kernel/driver serioveho portu. Jakmile se tento buffer naplni,
dostane kernel interupt aby jej vycetl a ten obsah zapise do nejakeho
bufferu v pameti. Protoze obsah je dlouhy maximalne 16 bitu, musi driver z
techto kousku skladat byty. Ted se ceka na aplikaci az si obsah bude chtit
cist. Podle toho jak si aplikace nastavi parametry pro seriovou komunikaci
(termios) dostane funkce read() odpoved. Pokud neni open() v rezimu
O_NONBLOCK, read dostane odpoved podle toho, jak jsou nastaveny parametry
c_lflag (ICANON) nebo c_cc (VMIN a VTIME). V kanonickem rezimu read()
dostane odpoved az prijde znak novy radek ("\n"), v "raw" modu -
nekanonickem se ceka az prijde VMIN bytu nebo uplyne VTIME desetin vteriny
od zacatku cteni po tom, co prisel aspon jeden znak (ale pritom musi byt
VMIN aspon 1).

Ve vasem pripade bych vypnul kanonicky mod (-ICANON) - zmizi i ten "\n"
na konci, co vam vadil a zkusil nastavit VMIN na 1024 (a nejaky VTIME
timeout). Pak by to podle meho nazoru melo cist po vetsich kusech. Jo, a
jeste nepouzit O_NONBLOCK pri open().
Ale mozna, ze uz jste to uspesne rozchodil.

Zdravi Jaroslav Honsa.