( TCH | 2018. 12. 13., cs – 12:49 )

> Ezt úgy képzelem, hogy küldesz valamilyen AT parancsot, ezt ő nyugtázza, utána küldheted a következőt.

Én is így képzeltem, de nagyon nem így működik. Ha az OK-ra (vagy ami a response, arra) várok, akkor egy idő után nem mennek ki a parancsok a soros buszon...

> Az más kérdés, hogy a GSM interface-en mikor lesz belőle valami, mit és hogyan bufferel a modem. Szerintem különféle státuszok lekérdezésére is vannak megfelelő AT parancsok.

Vannak, de olyan nincs köztük, hogy "küldhetek-e már adatot". Mondjuk szép is lenne, hiszen ahhoz, hogy lekérdezzem, hogy küldhetek-e adatot, ahhoz adadot kéne küldenem. :P

> A flow kontroll kell, mert úgy korrekt, de elég valószínű, hogy nem tudod annyi adattal elárasztani, amit ne tudna benyelni legalább a bufferébe, ha nem is azonnal dolgozza azt fel.

256 byte a parancssorbuffer és 300 ms a minimum válaszidő (annál gyorsabban egy parancs sem reagál). Ezt még 9600 bauddal is el lehetne "árasztani", de én nem is küldök azonnal, megvártam, amíg visszajön a response, de ennek ellenére nem megy, ha nem várok egy csomó időt.

> Mint ahogyan te is jelezheted az RTS vonalon, hogy a másik oldal csihadjon kicsit, mert nem tudsz mit kezdeni a sok adattal. Viszont ez alsó rétegre vonatkozik, a flow kontroll akár üzenet közben várakoztat, ha megtelt a buffer.

Ez egy Orange Pi, 4 vezetékesre konfigurált soros porttal, az RTS/CTS kezelése be van építve, elméletileg nekem nem kell figyelnem CTS-t, a rendszer magától megvárja, hogy clear legyen, amíg beönti a buffert a buszra. Vagy szerinted pont itt a baj, hogy pont hogy nem?