Virtuális soros port 0x0D --> 0x0A konverzió (Linux <=> CDC-ACM)

 ( VaZso | 2019. szeptember 18., szerda - 10:25 )

Sziasztok!

Egy STM32 mikrokontrollerrel szeretnék virtuális soros porton kommunikálni - tehát USB CDC-ACM eszközzel, alapvetően Linux alól.
A ttyACM eszközök létrejönnek, működik is, de belefutottam egy dologba, ami nem tetszik.

Úgy néz ki, hogy alapértelmezetten a rendszer átalakítja a kontroller által küldött adatsorok végén lévő 0x0D0A (\r\n) adatot 0x0A0A (\n\n) formátumúvá.
A termios-ban létezik egy "ICRNL" bit, amit "1"-be állítva ez az átalakítás megszűnik, vagyis nem bántja a 0x0D0A adatsort.
pl. screen-t elindítom az eszközre, akkor a jelenség megszűnik.

Legfőbb problémám, hogy, ha menteni szeretném a szöveges tartalmat, akkor cat, ill. dd bemeneteként is megtörténik a fenti konverzió - én viszont szeretném ugyanazt az adatsort látni, mint, amit a kontrolleren küldésre összeállítok.

Létezik valami megoldás, amivel még a mikrokontroller oldalán meg tudom mondani, hogy nem akarom, hogy módosítsa a rendszer az adatokat?

Szeretném az adatsort tty-ként látni úgy, hogy Windowson is elérhető legyen és akár bináris adatsort átküldeni, ha úgy adódik (bár lehet, erre nem ttyACM interfészt lenne ildomos használni?) - mindenesetre nem tetszik, hogy alapértelmezetten módosul az adat, amit küldök.

Esetleg tudom úgy konfigurálni az USB descriptorokat, hogy ne akarjon automatikusan belenyúlni a rendszer?
Nem úgy tűnt, hogy a bInterfaceProtocol változtatásával el tudnék érni valamit - jelenleg 0x01, amire a rendszer "AT-commands (v.25ter)" szöveget ír, de próbáltam más értékeket is és a konverzió mindegyik esetben megtörtént.

Szerintetek mit lehet ezzel kezdeni azon kívül, hogy a rendszeren módosítok?
Én ülnék fordítva a lovon?

Minden véleményt előre is köszönök.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

stty-al tedd raw módba!

MCU oldalon esetleg szimulálhatsz egy dedikált USB serial chipet (aminek saját drivere van) vagy vehetsz is fillérekért egyet. Persze AT parancskészletet is implementálhatod és akkor működhetsz úgy mint egy modem.

Vagy kb 5 perces munka:
minden speciális karaktert escapelsz vagy base64-ben küldöd MCU oldalon és másik oldalon pedig visszaalakítod

Köszönöm a válaszod.

Kicsit más probléma, de dedikált USB chip emulációjára van valami bevált megoldás (library)?
Nem tudom, mennyire vannak erre jól használható megoldások.

A dedikált USB-UART nem igazán játszik, mert egyrészt a hardver már kész, másrészt egyéb funkciót is szeretnék csinálni rajt USB-n - momentán pl. Mass Storage eszközként is megjelenik.

Habár a másik oldal jobban érdekelne - a kontrolleren USB Host üzemmódban kezelni FTDI / PL232, esetleg más USB-UART eszközöket.
Ismer esetleg valaki olyan megoldást erre, ami viszonylag egyszerűen föléleszthető?

Escape-elgetni nem akarok, nem ez lenne a probléma lényege - ha saját szoftver fut a túloldalon, akkor az elvégzi a megfelelő konfigurációt, vagyis RAW üzemmódba teszi az eszközt. Ez is programfüggő, de Windows szereti a \r\n jelölést az új soroknál, Linux esetén viszont a \n szükséges csak, de a \r-t is értelmezi, vagyis megcsinálja a "line feed" és "carrier return" műveletet is.
Ennek eredménye, hogy \r\n-re megjelenik Windows esetén az új sor, Linux esetén ugyanez történik, de az alapértelmezetten átalakított \n\n hatására minden sor között megjelenik egy üres sor is, amíg nem teszi az ember RAW módba, ill. kapcsolja be ezt az "ICRNL" bitet.
Kicsit "megrökönyödtem" ezen a viselkedésen, mert azt vártam, hogy a rendszer azt olvassa be (különösen dd-vel), ami az eszköztől jön, és nem valami mást - ergo elkezdtem a saját kódomat túrni, hogy mit rontok el.

...és szemem előtt van, hogy el fogom követni valamikor azt a hibát még, hogy nyers adatot szeretnék átküldeni ttyACM eszközön a rendszernek, de az minduntalan korrumpálja nekem az adatot 0x0D0A byte-sorozatoknál 0x0A0A-ra.

Bár a modemmanager a másik, ami szereti szívatni az embert alapértelmezésben, az legalább egy külső program és nem mélyebb szintű furcsaság.
Úgy tűnik, sikerült belefutni az egyik "történelmileg így működik" viselkedésbe.

Nem tudok ilyen libről, de nem is biztos hogy publikusan érdemes lenne megosztani jogi és technikai oldal miatt. (lásd az FTDI botrányt)

"Szerintetek mit lehet ezzel kezdeni azon kívül, hogy a rendszeren módosítok?"
Nem hiszem. Ha lenne is erre szabványos protokoll, tuti, hogy a Linuxos és Windowsos verzió nem kompatibilis, vagy nem ugyan azt a szabványt implementálták, vagy alapból nincs telepítve. Konfiguráld fel a Linux -ot megfelelően és kész. Ezt érdekes lehet elolvasnod: https://stackoverflow.com/questions/39491856/transmitting-binary-data-throught-ttyacm

Köszi - úgy látom, a lényeg az, hogy "ez ilyen", maximum a saját operációs rendszerén konfigurál az ember...

Ha nagyon muszáj akkor írhatsz egy új drivert. (A problémát az okozhatja, hogy eredetileg a tty NEM bináris kommunikációra lett kitalálva)

* Én egy indián vagyok. Minden indián hazudik.

Igen, ezt értem.

Nyilván az új drivert Linuxhoz és Windowshoz is meg kellene írni.

Nem értelek. Ez a hagyományos UNIX módja a soros port kezelésnek. Ezek után miből gondolod, hogy a túloldalon csinálhatsz bármit, amitől az ezen a végén ülő Linux másként fogja csinálni? Ezt a Linuxon tudod állítani, pont a fenti bit piszkálásával. man stty, ha az egyszerű, parancssori módja érdekel.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"Ez a hagyományos UNIX módja a soros port kezelésnek.""

Értem, csak nem örülök neki.

Azért gondoltam, mert virtuális soros kommunikációként indultam neki, az meg önmagában nem igazán van ilyen téren korlátozva.

Az más kérdés, hogy - ahogy a fenti hozzászólásban is írtam -, ez afféle történelmi viselkedés lesz...

Nem a parancssori állításának módja volt a problémám (azt megtaláltam), csak a jelenség lepett meg és érdekelt, van-e általános módja a viselkedés kikerülésének (pl. olyan eszközazonosító, ami soros terminál, de "mem UNIX" működéssel).
Ezen felül nem rémlik, hogy a ttyUSB eszközöknél megcsinálná ezt a konverziót - bár ezt most már ellenőriznem kellene -, lehetséges, hogy ott más az alapértelmezés.