Dotaz: Nastavenie FIFO pri seriovom porte

[Gabo]

Prosim Vas, ako sa da nastavit vstupny bufer na seriovom porte s radicom 16550A na inu hodnotu ? Potrebujem aby sa prerusenie generovalo skor ako sa zaplni. Napriklad uz pri 8 bajtoch. Setserial to neumoznuje. Dakujem Gabo.

Odpovědi

[rastos]

Uplne 'tvrde' riesenie: pozeral som sa do zdrojakov jadra a vidim tam pouzitu strukturu serial_uart_config (definovanu v linux/serial.h), ktora ma clen dfl_xmit_fifo_size. Tato struktura je naplnena v drivers/char/serial.c a pre 16550A je fifo nastavene na 16. Vyzera to, ze by to slo prepisat na 8 a hotovo. To je, ale fakt nestandardne riesenie.

Potom, ale vidim ze linux/generic_serial.h definuje funkcie gs_getserial() a gs_setserial(), ktorym sa posiela pointer na serial_struct co je struktura definovana v linux/serial.h a tiez obsahuje clen xmit_fifo_size. Snad najak pomocou toho.

[rastos]

Ok. Ten prvy odstavec plati. Namiesto toho druheho mam toto:

  #include <linux/serial.h>
  #include <sys/ioctl.h>
  ...
  struct serial_struct sp;

  fd=open("/dev/ttyS1",O_RDWR);
  ioctl(fd,TIOCGSERIAL,&sp);
  sp.xmit_fifo_size=8
  ioctl(fd,TIOCSSERIAL,&sp);

Hm?

[Gabo]

Super, dakujem, za pomoc. Hned to vyskusam.

[Gabo]

Trochu som s tym polaboroval, ale ziadny vysledok. xmit bufer je vysielaci, co neriesi problem. Skusam nastavit rx_trigger priamym pristupom na port. Uvidim co to spravi. Ako inak riesit tento problem ? Dokumentovany je ako serial overrun .

[rastos]

Domnieval som sa, ze serial overrun moze nastat len na velmi pomalych strojoch neschopnych spracovavat prichadzajuce data dostatocne rychlo. Navyse mam pocit, ze takuto situaciu ma riesit flow control. Mozno sa viac docitas v Serial Howto

Aj tak celkom nerozumiem poziadavke. Na co je dobry mensi buffer? Data z portu mozes precitat aj bez zaplnenia buffra. Mimochodom, ako by si ten problem riesil, keby to nebol Linux ale nieco ine?

[Dejv]

Ja vam neporadim, jak nastavit mensi Rx FiFo, ale mam za to, ze preruseni se generuje pri prijmu bytu, ne az pri zaplneni FiFo. Nebude ten zakopany pes nekde jinde?

Dejv.

[Gabo]

Mozno som sa trochu zamotal. Problem je v tom, ze stracam pri prijme znaky. Myslel som, ze zmensenie FIFO to vyriesi. Po prestudovani zdrojakov so zistil, ze skutocne sa prerusenie generuje pri prvom znaku. A to je potencialne problem. Generuje sa vela preruseni a zahlti to CPU-386. Riesenim by malo byt nastavenie rx_trigger. Generovalo by sa menej preruseni. To som zatial nezvladol. Uz mi hrozi dalsi problem a to je 16550 nema plne hardverove riadenie a spolieha sa na cpu. Riesenie sa crta s obvodom 16554 alebo 16654.

[Dejv]

Pokud ztracis znaky, co takhle snizit rychlost? Vim, ze to nemusi byt mozne, ale aspon napad...

Dejv.

[Gabo]

Znizenie rychlosti bude problem. Uz teraz idem na 9600. Problem je, ze mam 4 x 16550. Niekde som sa docital, ze 16654 a 16554 maju skutocne hardwerove riadenie toku dat. Uz som si zohnal aj taku kartu. Teraz mam 16554 co su 4xRS232 na jednom cipe. Problem je, ze v standartnom mode sa sprava ako 16550. To riadenie toku treba dako zapnut. Inac povedane zhanam driver. V kerneli je daka podpora pre 16654 ale nepodarilo sa mi to pouzit. Mate s tym dakto skusenosti ? Dakujem.

[Dejv]

Jeste jeden napad. Jak (kolika draty) mas propojen pocitac se zarizenim? Pouzivas 3-dratove propojeni (jen RxD, TxD a GND), nebo tam mas vic signalu (datove i ridici)?

Dejv.

[Stanislav Brabec]

V původním dotazu jste se ptal na 16550A, ale teď píšete o 16550. Tyto modely se, pokud si dobře pamatuji, liší právě tím 16bajtovým bufferem (model A ho má). Obávám se, že zmenšením bufferu u 16550A to zhoršíte. Zředěním přerušení to můžete možná zlepšit.

Řešením by také mohl být preepmtivní (2.6) nebo RT kernel, nebo low latency patch.