USB UART latency

Kis hasznos az /etc/udev/rules.d/ konyvtarba, ha valaki sok FTDI USB UART-tal dolgozik:

SUBSYSTEM=="tty", ACTION=="add", RUN+="/bin/bash -c 'f=/sys/bus/usb-serial/devices/%k/latency_timer; test -f $f && echo 1 > $f'"

Kicsit gyanus volt hogy 921k6 baudon az oda-vissza tranzakciok ~12kB/sec-cel mentek... :)

( Nyosigomboc v | 2022. 12. 30., p – 13:29 )

Ugy emlekszem, a LinuxCNC-s csapat az USB-t a hardware-es latency limitje miatt nem ajanlja. Egyebkent is, ha real-time, vagy idoziteskritikus feladatod van, mikrokontrollerrel egyszerubb megoldani, a PC-n csak a kommunikacio es a magasabb szintu dolgok menjenek!

A strange game. The only winning move is not to play. How about a nice game of chess?

( uid_6201 v | 2022. 12. 30., p – 15:02 )

Szerkesztve: 2022. 12. 30., p – 15:04

Köszi, nekem nagyon hasznos ez.

Egy kérdés: hosszútávon (hónapokig üzemeltetve) van esetleg tapasztalatod FTDI USB-Serial cuccal? Én PL-2303 chipessel jártam sok éve úgy, hogy 2..3 hétig tuti jó volt, aztán vmi reset (villámtól, bámitől), újrakapcsolódás és mivel a szoftver fogta a /dev/ttyUSB0-t, ezért /dev/ttyUSB1-ként jelent meg. Automatizált állomásnál ez innentől problémát okozott, ethernet-rs232 átalakítóra tértünk ott át, ez okés volt. Azóta pedig megfelelő számú hw soros portos miniPC-kre.

Nekem az Odroid C2 - Aeotec z-stick jatszotta el ugyanezt.

Mar erosen gondolkodtam, hogy scriptet irok ra, amely kiloke/betolti a kernel modult es ujrainditja a Domoticz szervert.

Egyebkent nincs valami ertelmes megoldas, ami az eszkoz egyedi ID-je (van ilyen egyaltalan?) nevezi el az /dev-ben az USB eszkozt?

--szerk--

Udev szabalyokkal megoldhato, hog ykapjon egy fix nevet.

Egyebkent nincs valami ertelmes megoldas, ami az eszkoz egyedi ID-je (van ilyen egyaltalan?) nevezi el az /dev-ben az USB eszkozt?

Az /etc/udev/rules.d/ az pont erre jo. Vagyis temagad irhatsz hozza kicsi szkripteket, ami mondjuk tok hasonlo mint a fenti pelda. Nalam pl van ilyen is:

SUBSYSTEM=="tty", ACTION=="add", ATTRS{product}=="*TavIR*", RUN+="/bin/bash -c 'for (( i=0; i<16; i++)); do if ! test -L /dev/ttyAVR${i}; then ln -s %k /dev/ttyAVR${i}; break; fi; done'"
SUBSYSTEM=="tty", ACTION=="remove", RUN+="/bin/bash -c 'for (( i=0; i<16; i++)); do test -c /dev/ttyAVR${i} || rm -f /dev/ttyAVR${i}; done'"

Elegge primko, biztos lehetne elegansabban is :) De ha ~10 eve mukodik hibatlananul, sok-sok egymas utani debian alatt, valtozatlanul, akkor nem javitom meg inkabb... :) 

Egy kérdés: hosszútávon (hónapokig üzemeltetve) van esetleg tapasztalatod FTDI USB-Serial cuccal?

Igenigen, egeszen hatarozottan megbizhatoak. Nem mondom hogy az eletemet is rabiznam, de pont az ilyen random egyeb UART bridge-kkel ellentetben azoknal messzemenoen stabilabbak. Avagy inkabb forditva mondanam: ezutobbiakkal van eleg rossz tapasztatom, es most mar (az ara es/vagy a beszerzesi nehezsegek ellenere) csak FTDI bridgekkel tervezgetek dolgokat. Nyilvan eles/kritikus rendszerben kerulni kell az USB-t, ott marad az Ethernet. De ha csak ilyen alkalmi, barmikor kihuzhato-visszadughato vagy tavolrol/automatikusan is reszetelheto a dolog akkor jok ezek is az USB-s cuccok is.  De ezekre is inkabb FTDI ;)

Nyilvan eles/kritikus rendszerben kerulni kell az USB-t

Miért? Azért kérdem, mert mi műszeren belül a 32 bites mikrokontrollerrel felépített mérőrendszer és az előfeldolgozott adatok feldolgozását és a GUI-t biztosító PC között USB CDC-t használunk és szokott működni. Aggódnom kellene kicsit?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azt szoktam, hogy a kezeloprogramom VID:PID alapjan megtalalja a megfelelo eszkozt. Ha egy darab van csak, vagy a regi eltunt, siman eldontheto, hogy melyiket kell megnyitnod. Akkor is, ha az eszkoz csatlakozaskor kuld valami azonositot (+ esetleg verziot).

A strange game. The only winning move is not to play. How about a nice game of chess?

( locsemege v | 2022. 12. 31., szo – 14:51 )

A működéséről mondj néhány szót! :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A doksiban (FT2232H) lattam hogy van ez, rakerestem hogy linuxon lehet-e ezt a parametert hangolni es akkor ugy lett meg hogy van ez a `/sys/bus/usb-serial/devices/ttyUSB*/latency_timer` file. Kiprobaltam, mukodott. De ami a furcsa hogy papiron a ftdi_sio.ko-nak is van egy ndi_latency_timer parametere, de azt sajnos egy `rmmod ...` / `modprobe ... ndi_latency_timer=1` modon nem tudtam beallitani. De lenyegeben igy, udev-en keresztul mukodik, teljesen jo ez. Szoval erdekes, hogy noha ez egy driver featura, az FT2232H-s ic doksija (26. oldal) is elegge jol leirja. Az modnjuk jo kerdes hogy egy mezei FT232R is tud-e ilyet. Ez most epp nincs keznel, a doksi sem utal ra, de majd megnezem valamikor.

[...]

Es most lattam igy hogy akarmeg 0-ra is allithato ez az ertek, akkor meg egy kicsit gyorsabb :) 

( martonmiklos v | 2023. 01. 04., sze – 11:28 )

Ó ha ezt hamarabb látom...

Múlt héten dumpoltam egy EFM8-at a bootloaderben lévő CRC check segítségével (minden byte-ot végigpróbálsz 0-255-ig, hogy az az a checksumja és ha igen akkor megvan a tartalom).

Műhelyben elkezdtem valami CH341-es hokival kb. 3 óra alatt meglett a fele. Hazajövök itthon van egy FT4232H alapú cuccom rárakom, egy éjszaka alatt nem ért véget. Nem értettem a dolgot, de vszeg ez lesz a megoldás...