Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: DolamanAnoha 17. 06. 2022, 16:41:51
-
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.
-
Tak jsem zkusil:
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á.
-
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)
-
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ě.
-
Ten modbus budu dělat přes Home Assistanta (https://www.home-assistant.io/integrations/modbus/). 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:
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
-
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.
-
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.
-
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.
-
Ještě mě napadlo, zdali nebude potřeba za ten ch340 zařadit rs485 to ttl převodník?
-
Samozřejmě, jak jinak sis představoval že to propojíš?
-
...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 (https://www.tme.eu/cz/details/usb-rs485-pcba/moduly-usb/ftdi/) druhý (https://www.tme.eu/cz/details/usb-com485-pl-1/moduly-usb/ftdi/usb-com485-plus1/) třetí (https://www.gme.cz/modul-prevodniku-usb-rs-485) čtvrtý (https://papouch.com/sb485-prevodnik-usb-na-rs485-422-p4618/).
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 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/serial/Kconfig) 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 (http://support.fccps.cz/download/adv/frr/modbus/linuxmodbus.html), 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.
-
@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 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)
-
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 (http://www.wch-ic.com/downloads/CH341DS1_PDF.html) (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).
-
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é).
-
@Jenda naprostý souhlas. Bohužel musím říct, že dokud jsem neměl skop, tak jsem neměl představu, co je na té sběrnici blbě *tentokrát*. A je poněkud nefér, že mně můj skop koupil před lety zaměstnavatel, takže to nešlo z mé kapsy. Ale v dnešní době bych si snad nějaký koupil i ze svého, na takové to domácí kutění... nějaký ten OWON/Rigol/Hantec... Dvoukanál a čím víc GSps tím líp. Pak ještě chvíli trvá, než si člověk uvědomí, na co to vlastně kouká, a na co by koukat měl, kam zakousnout krokodýla pro referenční zem atd. To je ale na tom celém hezké - člověk se učí s novou hračkou a trochu se při tom dovzdělá...
Pokud se týče RS485, je osciloskop důležitým nástrojem v konkrétním bodě "diagnostického postupu". Připadám si, že bez něj jenom akademicky teoretizuju. A pak připojím sondu a prostě vidím.
A taky, USB/485 dongly není od věci mít dva-tři. Aby mohl být jeden na komunikaci a druhý na odposlech, nebo na duplexní odposlech RS422 (čtyřdrátu), nebo na porovnání dvou kusů, jestli jeden nemá drbnutý transceiver.
-
Dvoukanál a čím víc GSps tím líp.
Já bych si dvoukanál koupil jenom v nouzi takový ten "arduino scope" (vevnitř je STM32 s integrovaným ADC a nějaký displej, stojí to litr a jsou rádi když to dá megahertz)
Jinak je super čtyřkanál, používám pravidelně, dva mi nestačí, a stojí to 12k, tak pokud na to tazatel má, tak bych doporučil: Rigol DS1054Z
YMMV
A pak je zásadní mít analyzér se streamováním do počítače, konkrétně klon Saleae za 10 USD: https://sigrok.org/wiki/MCU123_Saleae_Logic_clone
Pro odposlech sběrnice používám https://www.gme.cz/modul-sbernice-rs-485 a právě ten logický analyzér
-
@Jenda : uvědomil jsem si, že jsem dal do placu nějaké svoje doporučení jako dogma, přitom to souvisí s mými specifickými potřebami, převážně v práci. Vaše potřeby jsou nejspíš jiné.
Když hledám důvod nějakého divného chování něčeho v servisu, málokdy využiju dva kanály, ale potřebuju šířku pásma. Koukám na přechodové děje, "když někdo cvakne vypínačem". Nebo třeba hledám nějaké rušení, a využiju, pokud skop umí ukázat FFT. Taky mám generátor krátkých ostrých pulzů, který ve spojení se skopem používám jako reflektometr (TDR) při hledání vaklů v koaxových konektorech. Obecně jsem mírně cáklej rádiem. Na RS485 nebo porovnání dvou hran 1PPS mi přesně stačí dva kanály proti společné zemi, v krajním případě plus externí trigger (vlastně třetí vstup).
Soudě podle Vaší volby : čtyřkanál, "pouhých" 50 MHz analogově, ale 1GSps, a zřejmě 6 nebo 12M bodů na kanál, plus ty odposlechové sondy co zmiňujete... řekl bych, že si hrajete s MCUčky, sběrničkami, GPIO a tak :-) a prostě volíte přístroj podle svých potřeb.
Koukám, že konkrétně Vámi zmíněný Rigol DS1054Z je ten slavný levný model, co se dá "softwarově upgradovat" o jednotlivé fičurky. Šířka pásma až 100 MHz, analýza sériové komunikace...
Ze sortimentu levných skopů mám takový pocit, že se ceny nehýbou už asi 10 let. Dvoukanály s 2 GSps končí kolem 20-30 kKč. Vývoj jakoby se zastavil - u velké čínské trojky, a třeba i u slovenského ETC, od kterého mám v práci M595. Chvíli jsem si potěžkal v ruce OWON SDS8202V (jeho zajímavostí je za příplatek bateriové napájení) takže mám trochu srovnání. Pravda je, že konkrétně u OWONu vidím novou řadu XDS4000, která končí čtyřkanálem 5 GSps / 500 MHz v ceně asi 5000 USD. Tzn. inovace probíhá, šířka pásma roste, ale cena jde nahoru - směrem ke značkovým západním strojům. Pozoruji vývoj i v související součástkové základně (křemík - rychlé ADC a analogové zesilovače). Bohužel i tady to spíš vypadá, že vývoj pomalu brzdí. Mooreův zákon se zadýchal - novější součástky jsou rychlejší jenom za cenu nižšího rozkmitu zpracovaných úrovní napětí, mají nižší napájecí napětí. "Ospalou atmosféru" v sortimentu osciloskopů si vysvětluji taky tak, že na těch gigahertzích už dávno nefungují klasické sondy se "zemním krokodýlem na vodítku" a je vůbec problém, navázat skop do měřeného zařízení, aniž by člověk narušil funkci pozorovaného obvodu, rozměrově je to všecko mrňavé apod. Prostě tyhle frekvence už jsou pro zatvrzelé feinschmeckery, kteří vědí co dělají, bez přístroje této kategorie se neobejdou a nemají problém, utratit 1000 EURO za aktivní sondu, vyrábět si na míru speciální sondy / vazebné přípravky apod. (např. kartu do PCI-e slotu s impedančně a konektorově přizpůsobeným výstupem pro osciloskop). Pro klasické rádio v těchto pásmech je beztak už hodnotnějším vybavením čistokrevný spektrální analyzátor, nebo FDR, nebo vektorový analyzátor sítě - přesný průběh vlny v časové doméně nikoho moc nezajímá.
-
Mockrát děkuji za podnětnou diskuzi, vš jsem si přečetl a v budoucnu využiju pro upgrade. Nicméně mezitím jsem problém vyřešil jinak. Použil jsem wifi zázrak, zvaný Esp8266 v podobě NodeMCU. Na něj jsem připojil rs485/UART převodník. Za pomoci EspHome integrace v Home Assistantu jsem oživil starší pokusy, které nevedly k žádanému výsledku ale tentokrát, poučen z tohoto vlákna jsem usp%el. Nyní už vyčítávám data ze všech tří Epevrů. Dokonce je umím apgrejdovat přes wifi pomocí OTA. Jedniý zádrhel byl a pro krátkost času stále je, že flešnutí přes USB není možné, dokud neodpojím RS485/UART převodník od pinů RX/TX NodeMcu. Flešer vyhlásí nekomunikaci, pokud to neudělám. Což je ale jen otravná, ale řešitelná potíž. Jiné piny na NodeMCU pro komunikaci s převodníkem jaksi neměl dost času hledat.
Ještě jednou děkuji.
-
Byl bys ochotný se podělit o ESPHome YAML ke komunikaci s Epever? Řeším stejný problém, ale nedaří se mi to zprovoznit.