[Megoldva] FTDI chip programozás (Win vs Linux)

 ( BlinTux | 2018. szeptember 2., vasárnap - 12:25 )

Sziasztok!

Adott egy ilyen kis FTDI eszköz.

Ehhez szeretnék írni egy progit C-ben.
Kezdeti lépésnek csak egy egyszerű adatküldést valósítottam meg egy minta kód alapján.
Forráskód

Ezt a kis progit Windows 10 alatt szeretném használni. Viszont ha lefuttatom, akkor azt írja:
unable to open ftdi device: -4 (usb_open() failed)

Viszont! Szintén ezen a gépen lévő VirtualBoxban futó Ubuntun lefordítva és futtatva ugyanezt a kódot, tökéletesen működik a dolog.
Tud vele kommunikálni és a küldött adat is megjön.

Google nem nagyon barát, mert minden amit találok az Linux-os kérdés a témával kapcsolatban, nekem viszont ott semmi gond vele :)

Van esetleg ötletetek mi lehet a nyűg Win alatt?

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ő.

Magát az eszközt a Windows 10 felismeri? Létrejön egy soros port,ha bedugod a kütyüt? Valamilyen terminálszoftverrel (pl. TeraTerm) tesztelted?

A linkelt oldalon ez a szöveg egy kicsit gyanús:
> Note: This chip is not orignal, do not have EEPROM, can not invert the signals.

Igen, ha bedugom akkor van egyCOM8-as portom.
Sőt, ha csak erre a portra akarok adat küldeni, akkor az is működik C-ből, Windows alatt is.
De régebben ezzel a kütyüvel még mindenféle eszközöket is flasheltem, szintén Windowsból.

A gond az, hogy nekem nem elég csak az RX/TX lábakat használnom, kellene még az RTS, CTS is. Azt pedig csak a fenti kérdésben szereplő kóddal tudnám vezérelni :S

Az RTS/CTS-t a TIOCMGET/TIOCMSET-es ioctl()-lel is tudod vezerelni, legalabbis linux alol. Vsz a win-es kornyezetben is lehet, mert ez egy sima UART-specifikus dolog (ld: modem lines), nem kimondottan csak FTDI tudja hanem minden jolnevelt UART-vezerlo. Cygwin alatt pl tuti hogy van ilyen ioctl, legalabbis egy altalam, linuxra irt uart-libraryt a kollega le tudott forditani cygwin alatt es ebben a library-ban is van RTS-CTS kezeles. Valahogy igy:

...
ioctl(handle,TIOCMGET,&w);
if ( w & TIOCM_CTS ) 
 { ...
 }
if ( ... ) w |= TIOCM_RTS;
else       w &= ~TIOCM_RTS;
ioctl(handle,TIOCMSET,&w);
...

Hmm, ez nem rossz, de az is gond még, hogy a bitmódot át kell állítanom bitbang-ra.
Ez megint olyan dolog, amit a driver tud, ezt megkerülni már nem tudom hogy lehetne :)

De lehet nem tökölök akkor ezzel, nem ér annyit az egész. Megírom a progit linuxra, és max bebootolom hozzá az Ubit VirtualBox-on :)

Persze ha a WSL kezelné az USB-t, akkor még egyszerűbb lenne... :S

A DTR-DSRt is tudod hasznalni igy, bitbang uzemben, az RX-TX helyett. Csak at kell drotozni a kapcsolast egy kicsit :)

Érdemes lenne tesztelni az eszközt pl. a TeraTermmel (vagy valami hasonlóval; van elég). Kell néhány rövidzár (TxD-RxD, RTS-CTS, DTR-DSR), és már mehet is a gépelés. Hardware handshake bekapcsolt és local echo kikapcsolt állapota mellett vissza kellene jönnie a képernyőre annak, amit írsz. Ha ez működik, akkor az eszköz jó Windows 10 alatt is.

https://ttssh2.osdn.jp/index.html.en
https://realterm.sourceforge.io/
https://sites.google.com/site/terminalbpp/

Nem jön így vissza adat :(
Akkor ez valóban bukta.
No mindegy, majd veszik másik FTDI panelt, addig dolgozok vele Linuxból :)

Linuxon megy, mert ott nincs ellenőrzés, hogy hamisított-e a chip.
A kínai olcsó ezekből, pedig hamísított. Az FTDI újabb driverében benne van az, hogy a hamis kínai ne működjön.
Alapból, csak a chip, ennek az árnak a többszöröse.
Cserélhetsz IC-t, vagy drivert, lehet IC-t könnyebb, ha WIN10 driver uralmát vesszük alapul. Lehet nincs is régi driver ami vinné.

Az előttem hozzászóló leírta a lényeget: a gyártó régebbi chipjét elkezdték klónozni a kínaiak, mire a gyártó azt csinálta, hogy frissítette a chipet (máshogy kell kezelni, nem kompatibilis a régivel), majd a régi típusúnak a támogatását kikúrta a picsába a driveréből. Így sem a klónozott, sem az eredeti (de régi típusú) gyári chipekkel már nem megy a driver. A Linuxban ott az opensource driver, viszi az összes chipmodellt - nyilván ott nincs lehetősége a gyártónak ugyanezt a játékot eljátszani.
A történet amúgy olyan régi, hogy kb. amikor a Win8 megjelent, akkor mondta azt a gyártó, hogy jó, akkor a Win8-ra már csak ilyen drivert fogok kiadni. Tehát WinXP/7-re még van a régi gyári driverből, ami viszi a régi típusú chipet, de 8+-ra már nincs.

Ha a régi típusú chippel találkozol, az 99.999%, hogy klónozott - ezért is olcsó. A új típusú chip jóval drágább (mondjuk 5-10x), abba véletlenségből nem lehet belefutni.

Megoldások:
- elfelejted a Win10-et (ideális esetben az egész Windowst),
- próbálsz szórakozni a Win7 driverrel, hátha ráhekkelhető valahogy az újabb Winre,
- keresel egy nem gyártói drivert, vagy magad megírod (mivel ott az opensource linuxos, így simán írhat bárki),
- veszel eredeti FTDI chipes cuccot (ez ugye már az új típusú chip lesz),
- nézel másik gyártó terméke után, aki nem baszakszik hasonlóan.

Veszek inkább egy eredetit, akor legalább mindenhol tudom használni majd.
Addig marad a Linuxban kódolás rá. A kódot úgy is bármikor át tudom majd fordítani windows binárissá.

//OFF
Nemrég azt mondtad a Win inkább desktop, mint a Linux. Hm.

Nem is olyan dolgot akarok művelni, amihez desktop rendszer kell :)
Sőt, még csak grafikus felület sem ahhoz a progihoz amit írok.
Meg amúgy is ez programozás, amihez a Linux jobb alap mint a Win.

Nem azért a két fillérért, de ha jól látom a kódodat akkor libftdi-t használ és úgy emlékszem, hogy ez a libusb-n keresztül piszkálja a HW-t. Tehát a gyári FTDI-os driverekkel szerintem nem fog menni Windowson.

Eme leírás megerősíti ilyen jellegű emlékeimet:
http://embedded-funk.net/running-libftdi-under-windows/

Noh, te vagy akkor a nap hőse, jár a bumerli! :)

Lecseréltem a driver lubusbk-ra és máris nem panaszkodik a kis progi, egyből mennek át az adatok! :)

Pedig már egyszer használtam is ezt a Zadig progit, mert amikor flasheltem egy kütyüt ezzel az FTDI-vel, akkor is mokolni kellet a driverekkel.

Örök hála, küszi a tippet! :)