OldComp.cz

Opět si hraju s RS232 (kvůli SIFTermu), opět jsem v něm opravil pár drobností a jednu větší chybu - měl jsem tam špatně nastavení softwarového řízení toku dat. Zkorigoval jsem podle datasheetu a teď se zdá, že to na straně 16C650 v ZX Spectru funguje správně.

Ale Linux na Xon/Xoff nechce reagovat. Co dělám špatně?

Sériák na Linuxu nastavuju takto:Tzn. pomocí -crtscts vypnu hardwarové řízení toku pomocí signálů CTS a RTS, přesto PC CTS směrem ven nastavuje, ale na RTS do PC nereaguje, vysílá bez ohledu na stav, potud asi ok. Pomocí ixon zapínám řízení toku dat řídícími znaky a pomocí ixoff zapínám posílání xoff/xon znaků, když se zaplní buffer na straně PC (někde mezi 4 - 5kB, zkoušel jsem dřív).

Cituji z manuáluS pomlčkou se parametr vypíná, bez pomlčky zapíná, proto mi kombinace -crtscts ixon ixoff připadá správná. Na osciloskopu vidím, že z 16C650 v ZX do PC přichází znak 0x13 (CTRL+S) , když pozastavím příjem a zaplní se FIFO v UARTu. A naopak, když opět začnu na ZX data přijímat a FIFO se vyprázdní, tak pošle 0x11 (CTRL+Q), to by mělo být dle Wikipedie správně https://en.wikipedia.org/wiki/Software_flow_control Stejně to funguje v linuxovém terminálu, CTRL+S odpovídá klávese Scroll Lock.

Viz obrázek z osciloskopu - žlutá jsou data ze ZXS/16C650, purpurová z Linuxu, znak 0x13 je vyslán, ale PC nereaguje a vysílá dál (a mnohem déle než je na screenshotu).

V PC mám RS232 kartu do PCI s čipem Moschip MCS9835CV.
Zkusil jsem i USB redukci s čipem PL2303. (dvě různé od různých výrobců)
Zkusil jsem i USB redukci s čipem ch341.
Zkusil jsem notebook Dell D630 s interní RS232 - hlásí se jako 8250/16550 bez dalších detailů.

Ani na jednom počítači to nefunguje. Teoreticky na tom notebooku mám kromě Debianu 10 i WXP a mohl bych to zkusit pro zajímavost i tam.

Co dělám špatně?
Nastavuju špatně sériák pomocí stty?
Přehlídnul jsem důležitý parametr?
Používám špatné řídící znaky?
Je potřeba ty znaky Linuxu explicitně určit, jako je zapisuju do registrů 16C650?

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS

Našel jsem https://hackaday.io/project/16097-efort ... ng-xonxoff

Druhý odkaz z Hackaday je zajímavý https://github.com/neundorf/CuteCom/issues/22 a hlavně zmiňovaný parametr icanonTo už nějaké řízení toku provádí, ale obávám se, že to bude použitelné jen pro přenos textu, ne k přenosu binárních dat (escapovat?).
Pro zajímavost jsem to zkusil i bez parametru icanon a bez parametru raw.A i to se chová stejně, jako s parametrem icanon místo raw (raw je k icanon v protikladu, raw parametr icanon vypíná).

Další problém je, že na přijetí Xoff PC nereaguje hned, tj. nejbližší další vysílaný znak. Po přijetí Xoff pošle při rychlosti 9600bps dalších 6 - 7 znaků (PCI karta Moschip). Přijímač proto musí být připraven a mít v bufferu dost místa.

Pro vyšší rychlosti to není použitelné, nad 19200bps stihne PC vyslat víc znaků (10 a víc), než se vejde do bufferu UARTu, resp. do zbývajícího volného místa a tu a tam se nějaký znak ztratí. Asi by to šlo ošetřit a znaky z bufferu stíhat číst, ale znamená to, že na straně ZX Spectra nelze se sériákem zacházet tak bezstarostně jako s hardwarovým řízením toku dat. A nakonec cat /dev/ttyS1 sice přijímá, ale přijaté znaky nevypisuje do konzole. Proč?

Zkoušel jsem 38400bps i 57600bps a zdá se, že těch znaků se neztrácí o moc víc než 19200bps, ale ztrácejí se samozřejmě taky.

Závěr? Zásadně používat řízení toku dat pomocí CTS RTS, softwarové řízení toku je jen hromada problémů.

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS