Identifikace ovladače v Debianu

[DolamanAnoha]

Nevím, jestli jsem se dobře strefil do tématu, jestli ne, omlouvám se.
Jde o to, že se potřebuju naučit, jak identifikovat/zjistit, případně otestovat funkci ovladače, konkrétně se jedná o převodník USB<=>Serial CH340/341 a následně jej uzpůsobit ke komunikaci s Modbus RS485 zařízením.
Mým dosavadním největším úspěchcem je instalace ovladače Realtek wifi donglu 8821.
Trochu v tom plavu, protože jsem se blbec nepodíval na lsmod předtím, než jsem zavedl ovladač té wifiny, abych moh po jeho zavedení porovnat, co se změnilo.
Debian identifikoval CH340(přes lsusb), ale jestli zavedl ovladače, to opravdu nevím jak zjistím.
Další hádanka je, jestli stačí funkční ovladač k tomu, aby fungoval protokol Modbus RS485, protože nevím, jestli je potřeba další ovladač, nebo to naopak ošéfuje konkrétní aplikace, v mém případě Home assistant, který má na to konfigurační udělátka.
Navíc se mě do toho plete ještě Python a jakésicosi Pyserial. Tak jsem z toho teď jaksi na rozcestí.
Nainstaloval jsem kvôli tomu na jeden harddisk čistý nový debian pro experimentování, abych se to naučil.

[Reklama]

[DolamanAnoha]

Tak jsem zkusil:

Kód: [Vybrat]

root@HomeAssistant:~# lsmod | grep ch34
ch341                  28672  0
usbserial              61440  1 ch341
usbcore               323584  8 usbserial,xhci_hcd,ehci_pci,usbhid,8821cu,ehci_hcd,xhci_pci,ch341

Ale nevím, co to znamená.

[k3dAR]

prikaz usb-devices ti ukaze co za ovladac dane zarizeni pouziva

prikaz lsmod ti ukaze stejny ovladac za "cislama" na radkach zacinaji nadrazenym ovladacem, v tvem priade je ch341 podrazen ovladacum usbserial a usbcore

EDiT: btw usb-devices kdyz ti ukaze ze je pouzit nejakej-ovladace (tedy v nazvu s pomlckou), tak v lsmod ho najdes jako nejakej_ovladac (tedy v nazvy podtrzitko misto pomlcky)

[_Jenda]

Jde o to, že se potřebuju naučit, jak identifikovat/zjistit, případně otestovat funkci ovladače, konkrétně se jedná o převodník USB<=>Serial CH340/341 a následně jej uzpůsobit ke komunikaci s Modbus RS485 zařízením.

Jak si představuješ, že budeš ten Modbus implementovat, že k tomu budeš upravovat jaderný ovladač CH340? CH340 má nějaké vhodné/speciální Modbus funkce které nejsou v současném ovladači dostupné?

Navíc se mě do toho plete ještě Python a jakésicosi Pyserial.

Python je programovací jazyk a pyserial je knihovna, pomocí které lze ovládat sériové porty (posílat data, nastavovat řídící signály).

Modbus přes čisté CH340 jsem nikdy nedělal, ale asi bych vyčlenil nějakou řídící linku CH340 na ovládání směru komunikace (v pyserial se nastavuje myslím jako můj_port.rts = 0, můj_port.dtr = 1 atd.) a pak doufal, že zařízení bude odpovídat dostatečně pomalu na to, aby to fungovalo i s latencemi USB a ne-realtimovým systémem. Ale myslím že by to fungovat mohlo.

Přečti si https://www.abclinuxu.cz/blog/jenda/2021/9/jak-funguje-modbus-a-rs-485, protože působíš zmateně.

[DolamanAnoha]

Ten modbus budu dělat přes Home Assistanta. Jelikož nejsem programátor, jsem opravdu zmatený.
Home Assistant budu používat na měření FVE, konkrétně chci vyčítat data z FV regulátoru Epever, který dobíjí baterie. Vše se bude pak ukládat do InfluxDB a zobrazovat pomocí Grafany, což funguje v HA moc hezky. Vyčítání dat z měničů mám vyřešeno přes komerční produkt Solar Assistant, který běží na malině a poskytuje je přes MQTT.
Předpokládám, že ta konfigurace modbusu v HA zajistí obsluhu CH340 převodníku - t.j. vytvoří dotaz na Modbus zařízení ve formátu Modbus protokolu a následně přeloží odpověď.
Jsem ve stádiu, kdy mám nainstalován HA na Debianu 11, vyřešil jsem ovladač WIfi donglu, protože ve strojovně FVE nemám drát a teď potřebuju vyřešit CH340/341 pro komunikaci Modbus protokolem.
Mělo by to jít, ovšem všechny informace k tomu jsou staré kolem 2 let a navíc většina je řeší přes ESP32, což by sice bylo řešení, ale v mém případě je to blbost, když mám PC HA v dosahu kabelu od 3ks regulátorů Epever.
Musel bych řešit napájení těch ESP32, ke kterým by stejně vedly kabely z těch Epevrů.

Edit:
usb-devices našel tohle:

Kód: [Vybrat]

T:  Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=1a86 ProdID=7523 Rev=02.64
S:  Product=USB Serial
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=98mA
I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=02 Driver=ch341


[Reklama]

[_Jenda]

Myslím, že si u té wifi karty možná pleteš ovladač a firmware, pokud to teda nebyl nějaký bizarní USB stick na který sis musel kompilovat out-of-tree modul.

Kolega říkal že na modbus používali něco takového: https://i.stack.imgur.com/iRLrD.png. Tj. RE/DE se nespíná pomocí řídících signálů sériáku, ale start bitem. Zaráží mě že tam není ani kondík, takže to přechází neustále mezi vysíláním a příjmem a jak to vysílá jedničky je mi záhadou (snad ne jenom biasem sběrnice, který je tady navíc nakreslený velmi malý). Ale tady https://electronics.stackexchange.com/questions/576303/problem-with-usb-to-rs485-design-ch340b-linux někdo píše že mu to funguje.

Já kdybych to dělal tak bych asi zkusil v tomto pořadí:
 - to s tím RTS/DTR (otázka je jak tohle integrovat do HA, ale umí to modbus přes TCP, tak si na to můžeš udělat proxy)
 - to spínání přímo vysílaným signálem, případně s RC článkem který podrží vysílač zapnutý i v mezerách
 - vlastní řešení s Arduínem

Pozor že Epever má modbus na 115200 místo na běžnějších 19200, když jsem to zapojoval já, tak jsem se na tom chvilku zasekl.

usb-devices ti prostě ukazuje že máš normálně ten převodník, tam už nic dalšího nevykoumáš a nijak si nepomůžeš. Máš nějakou fixaci na "(kernelové) ovladače", možná z jiných operačních systémů, v Linuxu tohle není skoro nikdy potřeba řešit.

[DolamanAnoha]

Myslím, že si u té wifi karty možná pleteš ovladač a firmware, pokud to teda nebyl nějaký bizarní USB stick na který sis musel kompilovat out-of-tree modul.

Ale tak hledal jsem drivers, našel jsem, zkompiloval, instaloval a wifi se rozjela. Firmware je snad v tom daném zařízení, v tomto případě fleška s anténkou.

Kolega říkal že na modbus používali něco takového: https://i.stack.imgur.com/iRLrD.png. Tj. RE/DE se nespíná pomocí řídících signálů sériáku, ale start bitem. Zaráží mě že tam není ani kondík, takže to přechází neustále mezi vysíláním a příjmem a jak to vysílá jedničky je mi záhadou (snad ne jenom biasem sběrnice, který je tady navíc nakreslený velmi malý). Ale tady https://electronics.stackexchange.com/questions/576303/problem-with-usb-to-rs485-design-ch340b-linux někdo píše že mu to funguje.

Vono to lidem funguje, ale nenašel jsem konkrétně na ten účel, co chci já (Epever), našel jsem jenom jedno video k epevru, kde blikají ledky vevnitř toho USB převodníku, ale chlápek se nepochlubil, jak to udělal.

Já kdybych to dělal tak bych asi zkusil v tomto pořadí:
 - to s tím RTS/DTR (otázka je jak tohle integrovat do HA, ale umí to modbus přes TCP, tak si na to můžeš udělat proxy)
 - to spínání přímo vysílaným signálem, případně s RC článkem který podrží vysílač zapnutý i v mezerách
 - vlastní řešení s Arduínem

Řešení s arduinem by nebyl takový problém, dokonce jsou návody, jak to udělat přes ESP32, v HA je na to integrace, jmenuje se to ESPHome a nakonec to asi budu muset udělat, napájet ESP přes tu +5V linku v kabelu, abych si nezadrátoval celou strojovnu. Mimochodem stepdown DC=>DC z cca +56V na +5V není žádná sranda sehnat, aby to nezarušilo i sousedovic wifinu.

Pozor že Epever má modbus na 115200 místo na běžnějších 19200, když jsem to zapojoval já, tak jsem se na tom chvilku zasekl.

Tys zapojoval epevra?!

usb-devices ti prostě ukazuje že máš normálně ten převodník, tam už nic dalšího nevykoumáš a nijak si nepomůžeš. Máš nějakou fixaci na "(kernelové) ovladače", možná z jiných operačních systémů, v Linuxu tohle není skoro nikdy potřeba řešit.

Takže říkáš, že ovladač je nainstalován automaticky a nic dalšího není třeba shánět, jestli dobře rozumím.

No ale teď mám jiný a větší problém, všechno jsem zkoušel na nečisto na starém 60GB SSD Intel ze šuplíku. A pak jsem chtěl vrátit původní "ostrou" instalaci HomeAssistanta, kterou mám na 250GB Apaceru a PC i3 nenaběhlo, prej se něco přepsalo v biosu, je to UEFI. V sekci, kde se nastavuje BOOT priority onehdá vznikl jakoby disk s názvem "debian" a s touto volbou naběhne jenom ta zkušební verze na Intelu, ale ta původní na Apaceru ne. Jde to nějak opravit? Mám tam už spoustu práce udělanou a dělá se mi špatně, když to budu muset dělat nanovo.

[_Jenda]

Myslím, že si u té wifi karty možná pleteš ovladač a firmware, pokud to teda nebyl nějaký bizarní USB stick na který sis musel kompilovat out-of-tree modul.

Ale tak hledal jsem drivers, našel jsem, zkompiloval, instaloval a wifi se rozjela. Firmware je snad v tom daném zařízení, v tomto případě fleška s anténkou.

Aha, tak to fakt byl driver, fascinující, příště zkus buď kernel z backports jestli už nebude driver přímo v tom, a pokud to ani pak nepojede, tak kupovat wifi karty s nějakým normálním chipsetem

Firmware právě ve wifi kartách posledních 10 let skoro nikdy nebývá, výrobci tam nedávají flash/rom, ale jenom ram a po každém spuštění se tam musí nahrát z počítače.

Pozor že Epever má modbus na 115200 místo na běžnějších 19200, když jsem to zapojoval já, tak jsem se na tom chvilku zasekl.

Tys zapojoval epevra?!

Ano, provozujeme solární systém na napájení radiolokátoru.

Nepoužívám HA, napsal jsem si podle dokumentace epeveru skript co vyčítá jeho registry (napětí, celkem dodaná a odebraná energie, teplota), loguje to do .csv souboru a kreslí to opět vlastním skriptem v Pythonu - Matplotlib do grafu. Normální lidi by tohle asi dělali Grafanou, ale obě instalace Grafany od dvou lidí co jsem viděl byly příšerně špatně nastavené (což nemusí být problém Grafany ale těch lidí), tak jsem to zase zbastlil takhle.

usb-devices ti prostě ukazuje že máš normálně ten převodník, tam už nic dalšího nevykoumáš a nijak si nepomůžeš. Máš nějakou fixaci na "(kernelové) ovladače", možná z jiných operačních systémů, v Linuxu tohle není skoro nikdy potřeba řešit.

Takže říkáš, že ovladač je nainstalován automaticky a nic dalšího není třeba shánět, jestli dobře rozumím.

Ano, ovladač (myšleno jaderný ovladač toho převodníku) je v jádře už dlouho a to je to, co ti vytvořilo zařízení /dev/ttyUSBx. To je ale jenom ten sériový port, teď potřebuješ ještě „ovladač“/aplikaci co přes to bude komunikovat - a v případě modbusu bude nějak řešit RE/DE signály, pokud to nebude řešit něco za tím převodníkem samo.

[DolamanAnoha]

Ještě mě napadlo, zdali nebude potřeba za ten ch340 zařadit rs485 to ttl převodník?

[_Jenda]

Samozřejmě, jak jinak sis představoval že to propojíš?

[František Ryšánek]

...dovolím si poznamenat, že než se peklovat ručně s nějakým přepínáním RX+TX, je citelně jednodušší, pořídit si modul, kde UART přímo řídí half-duplexní transceiver interním flagem "TSRE" resp. "TEMT". Tzn. pokud má UART neprázdný výstupní shift registr, tak je transceiver ve stavu "TX", jinak je ve stavu "RX" (budič přepnutý do stavu vysoké impedance a přijímač naslouchá). Z hlediska programátorského opracování, prostě pošlete znak nebo řetězec znaků a o víc se nestaráte. Co jste předal do kaskády bufferů (která končí v UARTu FIFO a posuvným registrem) to se přesně odvysílá.

Zrovna značku WinChipHead nemám úplně rád, kdysi mě naštvali nepovedeným konvertorem USB/LPT.

Na USB bych si dovolil doporučit něco od FTDI, lépe originál, ale jsou k vidění i čínské pajcy - které ovšem nemusí fungovat s originálními ovladači od FTDI pro Windows, ale open-source ovladač v Linuxu by je měl vzít bez problému.
jeden druhý třetí čtvrtý.

Ve směru RX mají moderní UARTy veliké FIFO, klidně 64-128 B, a následuje driver obsluhující interrupt... tam se data taky neztratí.

V user space prostě pošlete dotaz a pověsíte se na otevřený "deskriptor" a čekáte co přijde jako odpověď. Nějaké časování znaků není potřeba řešit.

USB serial nemá USB třídu - vlastně má, CDC ACM (modem), ale tu většina USB/serial donglů nepoužívá. Většina USB/serial donglů (UARTů) má na USB proprietární rozhraní. Linux k tomu přistoupil tak, že má cosi co vypadá navenek jako "class-based ovladač pro USB serial". Asi to tak nemají všechna distra, ale ovladač usbserial jsem vídal zkompilovaný jako modul, ovšem s monoliticky zakompilovanými ovladači pro běžné modely/značky USB/serial čipů. Takže jsem býval zvyklý loadnout "usbserial" a bylo vyřešeno. Skutečně populárních je asi 5 značek USB/serial čipů.

A dál záleží, v čem je napsaný ten Modbus. Provozovat ho v Pythonu... no asi proč ne :-) Rozhodně může Modbus žít v user space, sám jsem kdysi na to napsal v Céčku rozvlákněnou knihovnu, bohužel jsem nedostal svolení ji vystavit k volnému downloadu...

BTW tyjo, RTL8821 má USB variantu? Já ho znám jako poměrně solidní a úspornou ACčkovou wifinu na (Mini)PCI-e.

[DolamanAnoha]

@jenda Nejsem na tyhle hračičky odborník, ale u toho bazmeku co mám píšou, že je přímo RS485 a i vývody má označený jako A, B a ne RX, TX.

@František Ryšánek
Tohle rozhodně stojí za zamyšlení.
Díky. Zkusím.

[_Jenda]

@jenda Nejsem na tyhle hračičky odborník, ale u toho bazmeku co mám píšou, že je přímo RS485 a i vývody má označený jako A, B a ne RX, TX.

Tak v tom případě se nejedná (jen) o "převodník USB<=>Serial CH340/341", ale je za tím ještě něco zapojeno, plus je nějak řešeno to přepínání RX/TX o kterém se tu celou dobu bavíme, a měl jsi to OMG říct, a zjistit, jak je to přepínání řešeno (dokumentace, nebo otevřít a prostě se podívat na desku co tam je za integráče a jak jsou zapojeny)

[František Ryšánek]

u toho bazmeku co mám píšou, že je přímo RS485 a i vývody má označený jako A, B a ne RX, TX.

Já bych řekl, že Váš USB/485 dongle má automatické HW přepínání RX/TX vyřešeno = vytaženo z UARTu.
Schéma plošáku donglu bude zřejmě velmi podobné referenčnímu, viz str.16 v datasheetu (kapitola 7.6.). Vaší pozornosti doporučuji výstup CH341 zvaný TNOW. Tenhle výstup je odhadem trvale přítomen a aktivní = netřeba ho explicitně konfigurovat v registrech UARTu (nebo řešit v ovladači, nebo mít uložený v I2C EEPROM).

[_Jenda]

V tom případě nic nebrání to prostě zapnout a vyzkoušet. Jednak to může prostě zkusit (vyčíst přes MODBUS nějaký registr) a když to nebude fungovat tak buď píchat logickým analyzérem dovnitř, nebo si koupit MAX485 a odposlouchávat sběrnici, nebo koukat na sběrnici přímo osciloskopem (to je dneska asi to normální řešení, já pocházím ještě z doby, kdy osciloskopy byly obtížně dostupné).