USB - I2C ( kezdő )

USB-n keresztül szeretnék szenzorokat (hő, pára, légnyomás) kötni egy linuxhoz. Sebesség nem lényeges, de cél lenne, hogy egy futó kábelre több szenzor kerülhessen egymástól távolabb. Úgy néztem, az I2C pont erre való, de egyelőre nem igazodtam még ki a leírásokban.

Elég, ha szerzek egy USB-TTL csatolót, és az abból kijövő RX/TX vezetékekre felfűzhetem sorban az i2c szenzorokat? Vagy valamilyen spéci csatoló kell az USB és a lánc közé?

Linux oldalról elég az i2c-tools? (Már ha megvan a /dev/ttyUSB0 eszközöm.) Vagy kellenek még ehhez is varázslatok? BMP280-as szenzorokat szeretnék használni, de ebben is örülök véleményeknek. (Az 1-wire protokollt már használtam, de azzal csak hőmérsékletet tudtam mérni, és a jelen linux rendszeren nincs támogatása.)

Van még valami érdemi, amire figyelnem kell, jó ha tudom?

Hozzászólások

A TTL szintu TX-RX az az UART (Soros (!))  protokollra vonatkozik. Az I2C egy masik protokoll. Amugy utobbira tenyleg kothetsz tobb slave-et (!), felteve, hogy elter egymastol a cimuk, vagy valami trukkel elered, hogy elterjen. BMP280 eseten tippre egy cim van, de meg kene nezni hozza. Az I2C maximalis tavolsaga is korlatozott, nagyon messzire nem viheted, arra az RS232, RS422, RS485, es tarsai jobbak.

(!): non-PC megnevezes

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

Ja, hardware-t vegul nem ajanlottam. Az Arduino Nano ugy $2 korul van, USB kapcsolattal (USB-soros chipen keresztul, tipikusan CH340, CP21xx vagy hasonlo van rajta). Felteszed hozza az IDE-t, ahhoz a BMP280 libet, az egyik peldaprogramjat atalakitod neked tetszore, es keszen is van. Nagyon gyorsan lehet vele haladni, 1 ora alatt keszen van.

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

Extrem esetben le lehet menni az Atmega328P helyett 168-at vagy 8-ast hasznalo modulig, meg extremebb esetben lehet software-es USB stacket hasznalni. Vagy van egy kicsivel dragabb Atmel, az Atmega32U4-es (ami az Arduino Micro-n van) hardware usb-vel. De a software USB-t nem ajanlom, mert par gepen nem mukodik, utobbi meg dragabbra jon ki.

A fogyasztasa nem durva, ez a 30mA szerintem valami atlagos/maximalis ertek lehet, nalad joreszt varni fog. Ha akkurol hajtod, lejjebb lehet venni az orajelet, vagy pl. interruptrol felkelteni, de tobb macera, mint amennyit szamit.

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

Őszintén szólva eddig I2C-t csak mikrokontrolleren használtam oprendszer nélkül. Van, ahol assemblyben katalóguslapot böngészve megírtam, és van, ahol C-ben kész könyvtári elemeket használva. Szóval nem tudom, viszont meglepne, ha csak master tudna lenni.

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

A slave üzemmódokkal az a probléma, hogy a nem mikrovezérlő CPU-kon nagyon lassú az interrupt kiszolgálás, és a slave szigorú időzítéseit nehéz teljesíteni. (I2C-nél a slave várakoztathat AFAIK, de SPI-nél nem) Pláne, ha a logika userlandben lenne implementálva. Ezek miatt én nem próbálnék meg ilyet csinálni. De ha megcsinálod, akkor nagyon kiváncsi vagyok az eredményeidre :-)

Na jó, de I2C nem csak bitenként történő port mozgatással és olvasással lehetséges, hanem lehet hozzá hardware támogatás akár. Valamint, ahogy mondod, létezik clock stretching is. Azt értem, hogy a szabvány jellemzően 100 kHz-ről meg 400 kHz-ről beszél, de szinkron busznál ez a szigorú időzítés nem igazán lényeges, hiszen szinkron. Aszinkron átvitelnél, mint például az RS232, már valóban kritikus az időzítés.

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

Hú, ez nagyon jónak tűnik, bár forrasztgatni kell hozzá. De találtam egy kapcsolást, és elég egyszerű:

http://vijaysaayi-experimentsandresults.blogspot.com/2017/05/usb-to-ttl-converter-using-mcp2221.html

Már csak az a kérdés, ha a /dev/ttyUSB0 megvab linux oldalról, akkor kell-e még ehhez valamilyen driver, vagy ezzel már el fogom tudni érni az i2c eszközöket?

Nem szabad a zinternetről összeollózni a marhaságokat!

Az eszköznek a linkelt oldalon van egy részletes adatlapja. Azt kell elolvasni és használni.

Ha nem tudsz önállóan kiötleni egy kapcsolási rajzot, akkor mindig ott a gyártó áramköre. Ennek szintén van dokumentációja, amiben ott a kapcsolási rajz. Természetesen nem kell az egészet összerakni, csak amire szükséged van.

Az általad linkelt rajz R-2R-J1 részlete értelmezhetetlen és rossz! Vesd össze az MCP2221 adatlap 1-3, 1-4 és 1-5 ábrájával és csodálkozz!

Hence the USB 2.0 can be used with full speed (upto 480 Mbps).

Írja a cikk szerzője, aki nyilvánvalóan nem szeret olvasni, hiszen az adatlap első három sorában ez áll:

Features:
Universal Serial Bus (USB)
• Supports Full-Speed USB (12 Mb/s)

A /dev/ttyUSB0 helyett lásd: MCP2221 Linux Kernel I2C Bus Driver

Ezen keresztül USB HID protokollal lehet beszélgetni, a soros porttal meg USB CDC alapokon.

Az előbbi protokoll 15 elemét az adatlap 3. fejezete részletezi.

Ez egy elég egyszerű kommunikáció: 64 bbyte megy - 64 byte jön. Ha több is érdekel, az usb.org-ról letöltheted az USB 2.0 specifikációt.

Tehát itt nem média konverterről, hanem protokoll konverterről beszélünk.

Szóval nézegess szét az MCP2221 gyártói oldalán!

Nos nem azért, hogy mindenképpen nekem legyen igazam, de ennyi erővel a járt utat is járhatod. Pár hozzászólással lejjebb linkeltem az I2C-Tiny-USB projektet, és egy kész áramkört is, amivel ezt meg lehet oldani. Nálam úgy néz ki, hogy megjelenik egy /dev/i2c-6 nevű eszköz, és ezt tudom az i2cget paranccsal használni. Rákötöttem egy LM75 hőmérséklet szenzort, amin A0...A2 címeket 1-re kötöttem. Ezt a parancsot adtam ki: 'i2cget -y 6 0x4F 0x00 w'. A 6 a /dev/i2c-6 eszköz, a 0x4F az I2C cím, a 0x00 pedig a regiszter címe az LM75-ben, a 'w' pedig, hogy word-ot, azaz 16 bitet olvasson. Eredményként 0xF718-at kaptam, amiben a byteokat megcserélve megkapom az adatlap szerint a hőmérséklet regisztert, és némi bit tologatással kijön, hogy 24.5°C-t mért a szobában. Értelemszerűen, ha több azonos szenzorod van, különböző címeket kell beállítani, és egy-egy i2cget paranccsal végigmenni a címeken.

Egyébként milyen SBC-d van? Mert a sokukon eleve van I2C, és csak rá kell drótozni, majd valószínűleg szintén az i2cget-tel kiolvasni.

Ha nem kell folyamatosan üzemelnie, és tud host-ként üzemelni (OTG), akkor lehet rá esély, hogy jó az I2C-Tiny-USB, de őszintén fogalmam sincs, a szoftveres oldala milyen lenne.

Ha az a gond, hogy ez az egy darab USB kell a töltőnek, akkor valami BT-s vagy Wifi-s megoldást keresnék, például ESP8266.

A telefon tud OTG-t, de megvallom, azt reméltem, hogy egy ilyen usb eszközt össze tudok majd applikálni egy töltővel valahogy. Ehhez először azonban azt kellene tudnom, mit és hogyan fogok tudni használni. Low power irányba mennék, egyébként wifire vagy bluetoothra rátennék minden szenzort, oszt jónapot.

AFAIR, kulon trukkozest igenyel. Van olyan, telefonokhoz valo mikrousb-s hubom, amin van kulon tapcsati, de a telefon toltesere nem tudja hasznalni (csak az eszkozok ellatasara), mert az OTG es a toltes egyszerre nem mehet. (telefon nem tudja, hogy most neki kell kiadnia az 5V-ot, vagy ot toltik)

Type-C-nel mar nincs ilyen gond, ott mukodik.

Szoval mehetsz olyan iranyba, hogy a kulso elektronika neha ratolt a telefonra, amikor mer, akkor meg atvalt OTG modba, megvarja amig minden csatlakozik, mer, aztan vissza.. szerintem kicsit maceras. Vagy szetszedheted a telefont, es valahogy meghackelheted az akku kornyeket. Szamomra egyik sem tunik szep megoldasnak.

Esetleg wireless toltesre nem kepes a kutyu? Akkor mehetne egyszerre.

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

Nem tudtam, hogy vagy OTG vagy tölt. :(

Szerintem szép lenne, amit írsz, hogy két mérés között átvált OTG-ből töltőre, de ehhez egyedi csatlakoztatott hardver kellene, ami azt hiszem túlmutat a képességeimen.

Olyan üzemmódja nincs az USB-nek, hogy kívülről folyamatosan töltődik, de az adatkábeleken azért kommunikál?

Ha nincs, akkor lehet, az egész bukik.

Nem tudom, nezz utana! Elkepzelheto (bar nem valoszinu), hogy csak a kinaiak nem ertettek hozza, es szarul csinaltak meg a hubot. Mindenesetre en ugy emlekszem, hogy a mikro csatinal arra van az a plusz egy pin (4 helyett 5), mert arrol ismeri fel, hogy most OTG vagy tolto modban van-e. Lehet, hogy meg lehet hackelni.

Amugy meg mindig csinalhatsz ESP alapu hardware-t, a telefonod gyujti a mereseidet meg szabalyozza amit kell (futest/keringetest, amit akarsz), az ESP meg csak fordit a szenzoraid meg a telefon kozott.

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

Őszintén szólva nem biztos, hogy ezt a telefonos vonalat erőltetném. Ha jól sejtem, több szenzor adatát szeretnéd valahogy összegyűjteni és kezelni. Én erre egy Raspberry Pi-t vagy valami hasonlót javasolnék. (Nekem például Orange Pi Lite van.) Erre tudsz rendes Linux-ot tenni, eléred ssh-n, scriptekkel megoldhatsz mindent, nem kell Android környezetben szenvedni. Van rajtuk USB, UART, I2C, SPI, GPIO. Otthagyhatod bekapcsolva, lehet webszerver, vagy feltöltheti valaki más számítógépére is az adatokat. Esetleg a szenzorok is feltölthetik közvetlen más gépére az adatokat, ha erre képesek.

A telefonnak van tobb elonye is: a regi telefon kb. ingyen van, mar meglevo hardware-t tudsz ujrahasznositani. Plusz ott egy erintokijelzo, OS, mindenfele szenzorok, akku, es egy rakas egyeb hardware.

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

Nem szenvedek androiddal. Egy teljesen független linux van rajta. Android radir. Minden egyben van. Oled-es érintőképernyőt még raspberry alatt sem találtam sehol. Full linux, és mindezt 200mA átlagos fogyasztással. Látom, hogy az IO műveletben gáz, de a környezet meg nagyon profi amúgy. Tehát számomra nem egyértelmű, hogy rossz út.

Ez esetben sok IO gondodat megoldhatja, ha ESP8266 vagy ESP32 WiFi-s modulokat használsz. A távolságot a térerő határozza meg, és nem kell semminek rádugva lennie a telefonra, lehet folyamatosan töltőn. Az ESP-k programozhatók Arduino környezetből, egy rakás szenzorhoz van példaprogram, nagyjából össze kell csak ollózni a szerver-kliens példákkal :) Van I2C, SPI, UART, 1Wire meg szinte bármilyen interface illetsztő példa is rá :)

További probléma a messze elvitt I2C vezetékekkel a zavarérzékenység, amit lejjebb is emlegettek már: Ipari környezetben egészen meglepő mértékű zavarjeleket mértünk szkópon. Egy-egy közeli relé, mágneskapcsoló kapcsolásakor több 10V-os csúcsfeszültségű zajokat láttunk. Nem is volt túl megbízható... Ha néhány cm-re viszed, onnan meg megoldja WiFi, netán valami erre kitalált vezetékes megoldás (mint az RS485, amit javasoltak is), sok fejfájástól megkímélheted magad. Arról nem is beszélve, ha a telefon egyszer tönkremegy, nehéz helyettesíteni.

No meg attól még, hogy az RPi az adatgyűjtőd, a telefon még lehet a kijelző ;)

Raspberry PI-n és hasonlókon van hardveres I2C AFAIK. Ha a 3V jelszint megfelelő, akkor arra közvetlenül is rá lehet kötni I2C slave(már elnézést a kifejezésért :-)-eket. Ha eltér a jelszint, akkor lehet jelszint-illesztő modult is tenni közé.

Arduino-ra is lehet kötni I2C-ket, a PC-re pedig USB-vel rádugni. Akkor csak egy egyszerű protokoll transzformátor program kell csak az Arduino-ra, és mehet.

Szükséged lesz valami olyan eszközre, amely a PC USB portja és az I2C közt fordít. Erre talán egyik legcélszerűbb ez: https://github.com/harbaum/I2C-Tiny-USB

Van hozzá kernel modul, könnyen használható, bár a kiolvasott adatot neked kell értelmes formába önteni.

Megveheted készen is, és akkor már erdemes egy ilyent: https://www.tindie.com/products/820labs/i2c-tiny-usb/

Egyébként ez az első github-os linken is megtalálható. Tud 3.3V-on és 5V-on is kommunikálni. Bizonyos szenzorok csak 3.3V-al működnek.

A raspberry pi-n valoban van I2C kivezetes, amit mar kozvetlenul a gyari modullal is tudsz hasznalni, es nagyon jo linuxos toolok vannak hozza az `i2c-tools` csomag formajaban. A "bedugod es mukodik" kategoriaban jelenleg (szerintem) ez a legegyszerubben elerheto dolog. Illetve amit vbalint kollega mond feljebb, azt a kis hardvert is erdemes megnezned!

Az I2C sajnos mind digitalis logikaban, mind hardveres illesztesben elegge kulonbozik az UART-tol (ld. USB-TTL csatolo) illletve az SPI-tol is, szoval az biztos hogy egy dedikalt, kimondottan I2C periferiara kihegyezett hardverre van szukseged. Illetve az I2C-nek szamos uzemmodja van, es kerdes hogy a sajat kis hardvered mit tamogat, mire van szukseged. Szenzorok olvasasahoz eleg csak az MT es az MR (master transmitter es master receiver) uzemmodokat ismerned, ezt a raspberry pi beepitett modulja tudja. Az I2C protokoll kimondottan az open collector-os illesztesre van kitalalva, igy hardveresen sem UART-hoz, sem SPI-hoz nem lehet hozzakotni, bar logikaban van azert valami minimalis koze az SPI-hoz.

Ezutobbi tulajdonsaga alapjan az FT2232-es meghajtohoz is hozza lehet illeszteni: https://www.ftdichip.com/Support/Documents/AppNotes/AN_113_FTDI_Hi_Spee…. Ezt meg nem probaltam ki, de lehet hogy majd egy szep napon megnezzuk :) Mindettol fuggetlenul ez inkabb bitbang-nak tunik elso olvasatra. 

Köszönöm. Én az FT232RL-t találtam, mint könnyen beszerezhető, és erre alkalmasnak tűnő eszközt, bár nem tudom, mennyire nehézkes ennek a programozása, mennyire vannak hozzá eszközök. És igazán azt sem, mi az érdemi különbség az FT232 és FT2232 valamint az FT232H csatlakozók között, nekem bármelyik jó, vagy csak a drágább változatok?

Csak egy 2-es kulonbseg van a tipusszamban, de azert elegge nagy a kulonbseg a ket FTDI chip kozott :)

  • az FT232R csalad az klasszikus USB - soros (TTL) konverter, ahol par bitnyi bitbang-re is van lehetoseged - de ezutobbit inkabb csak transmission controlra (pl RS485) vagy flow controlra (RTS/CTS) szokas hasznalni. Persze kezzel allitgatva tetszoleges mas I/O-t is meg tudsz vele csinalni csakhat az nem igazan lesz hatekony...
  • az FT2232, FT4232 csalad pedig egy un. U(S)ART + MPSSE, azaz multi-purpose synchronous serial engine-t tartalmaz. Alapertelemben ez is mezei UART-kent jon fel, de relative egyszeruen at tudod konfiguralni szinkron soros protokollokra (USART, SPI, ISP, SWDIO, JTAG, I2C, ...). Az "MPSSE" az pont arra utal hogy ebbol a feltucat szinkron soros buszbol egyik sem az "alapertelmezett", hanem neked kell kivansagodnak megfeleloen beallitani hogy hogy is kommunikalsz. Plusz az MPSSE-n kivul van meg partucat GPIO-kent is hasznalhato bited. Mindez 2 vagy 4 csatornara elosztva. 

Ugyanakkor az osszes FT[24]232-re jellemzo hogy egy ic-labacska az vagy input, vagy push-pull output. Az I2C labakkal (SDA, SCL) meg az a baj hogy az egy open collector output + input egyszerre. Hardveresen baromi egyszeru mert egy push-pull outputbol es egy inputbol egy darab ellenallassal es egy (logikai inverzio nelkul pedig ket) tranzisztorral mar meg tudod csinalni az open collector output + input kombinaciot. De ez nem azt jeleti hogy az adott I/O lab az ilyenertelemben "multifunkcios" lenne...  

HA már FTDI, akkor van közvetlen USB-I2C átalakítójuk: FT201X, illetve ehhez jkét fejlesztői modul létezik, ami már minden kötítést tartalmaz: UMFT201XA és UMFT201XB talán ezeket is érdemes megnézni. Én még nem használtam őket, nem tudom milyen a támogatottságuk. 

Az i2c egy külön protokol, cél hardver szokta kezelni. USB átalakító lehet mondjuk egy AVR, vagy valami hasonló MCU. Amúgy PC alaplapon is elképzelhető, hogy van valahol kivezetve.

+1. Ezert is kerdezi meg az `i2cdetect`, az `i2cget` meg `i2cset` hogy ugye biztos tudod mit csinalsz amikor ezeket a parancsokat kiadod. Mondjuk nekem mar elegge raall a kezem a -y kapcsolojukra :) 

Ettol fuggetlenul a beagyazott alaplapokon/gepeken (rpi, pcengines, ...) mar jol lehet tudni hogy milyen i2c slave eszkozok vannak - ott mar sokkal biztonsagosabban tudunk jatszani! 

Itt egy példa. :)

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

Valóban ijesztően néz ez így ki, de jellemzően nem. Az USB 90 Ω hullámimpedanciával lezárt szimmetrikus érpár, így a soros ellenállás és a zener által a párhuzamos kapacitás sem jó. Ellenben valóban szoktak villámhárítót beleépíteni, például ilyen az USBLC6-2SC6 nevű szerkezet, valamint vezetett zavar ellen azonos menetiránnyal csatolt induktivitásokat, amelynek szimmetrikusan nagyon kicsi az impedanciája, közös módusban meg viszonylag nagy. Induktivitásra típus: DLP11SN900SL2.

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

Én meg terveztem USB interface-t, és meg is szívtam elsőre, amíg a topológiával nem biztosítottam a nyákon a szükséges hullámimpedanciát. GPIO-val high speedet szerintem esélytelen. A low speed reális, a full speed is sok mér, de az még talán.

Tehát nyilván lassú jeleknél nem érdekes, de USB 2.0-nál már mindenképp.

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

cél lenne, hogy egy futó kábelre több szenzor kerülhessen egymástól távolabb

Mennyi az a távolabb? Az I2C-t nem erőltetném, ha sok méterről van szó, arra inkább az RS485 való.

Ahhoz már csak olcsó rs485 szenzorok kellenek. ;)

A probléma megoldásáról van már néhány topic pár ezer hozzászólással. Bizony, így megy ez, ha a topicnyitó csak szoftver oldalról árul el néhány morzsát az igényeiből. A megoldás lehet:

usb -> mcu -> i2c -> driver ---drót --- ( driver -> szenzor )

usb -> mcu -> rs485 -> driver --- drót --- ( driver -> mcu -> szenzor )

Mindkét esetben a zárójeles részt lehet többszörözni a kábel mentén.

Mindkét esetben a kezdő "usb -> mcu ->" elhagyható, ha a host rendelkezik az adott interfésszel.

Az rs485 driver olcsó, de az i2c szenzorhoz kell egy protokoll konverzió.

Az i2c driver drága, viszont nem kell hozzá más.

Köztes megoldás:

usb -> mcu -> i2c -> (rs485/di2c) driver --- drót --- ((rs485/di2c) driver -> i2c -> szenzor)

A "drót" mindegyik esetben csavart érpár.

Persze ezt lehet a végtelenségig variálni, találsz hozzá több könyvet is.

Aztán ne feledjük el, hogy az i2c legkisebb frekvenciája 0 Hz, ami számít a távolság kalkulálásában.

A topicnyitó azt is jelezte, hogy nem túl járatos a témában, így tán azt sem tudja, mit kellene pontosan jeleznie. Azt remélte, ha van egy szabvány USB felülete, akkor a hardver nem lényeges, hisz az USB az USB mindenütt. Akkor már csak azt kell kitalálni, mit dugjon az USB lukba, és azt majd hogyan olvassa a linux alól.

RS485-tel nem találkoztam eddig, míg 1-wire, i2c, és társaival meg már sokszor. Ahogy nézem, a linuxban van rs485 driver, de a szenzorok jóval drágábbak. Azért utánanézek ennek is.

Ahhoz már csak olcsó rs485 szenzorok kellenek. ;)

Nem kellenek. Megfelelő mikrovezérlők kellenek, amik olcsók. Sok gyártó nagyon sok típusa szóba jöhet, csak el kell dönteni, hogy milyen érzékelőket akar az ember használni, azokat milyen "buszon" kell illeszteni  (I2C, SPI, 1-wire, akármi). Az RS485-höz hardveresen szintén nem kell drága dolog, a lényeg a szoftveres megvalósításban van.

Ha a kollega kezdo, akkor nem ezt a linux <-> usb <-> valami mcu <-> illeszto <-> rs485 <-> illeszto <-> masik mcu <-> i2c <-> szenzor vonalat csinalnam/javallanam elso blikkre hanem a linux <-> (usb) <-> i2c <-> szenzor sorrendet. Ahol az (usb)-t azert irtam zarojelbe mert vannak olyan linuxos hardverek amik nativan tamogatjak az i2c-t, es egy `modprobe i2c-dev` utan maris van /dev/i2c-0, es egy i2cget paranccsal maris olvashatja ki a homersekletet, paratartalmat. A sikerelmeny hamar meglesz, asztalon hamar mukodik, es kb azonnal el tud kezden ilyenekkel is kiserletezni a kollega hogy "na, ez hany meter kabelt is bir ki" :) Ha nem birja ki a hosszabb kabelt, akkor fokozatosan vennem le a SCL frekvenciat (100kHz => 30kHz => 10kHz => nehany kHz). Egy-ket soros ellenallas vagy par nf-es kondi is segithet szurni a jelet, plusz itt is lehet mar sodrott erparokat alkalmazni annak ellenere hogy nem differencialis a jel. 

A masodik lepesben a leheto legegyszerubb usb <-> i2c bridge-t probalnam ki, ami meg a fentebbi felsorolasban a vbalint-fele I2C-Tiny-USB c. dolog tunik annak (es ezuton is koszonet neki a tippert, rendeltem is par peldanyt, erdekel a dolog).

Ha a sok kabel tenyleg problemas akkor ezt az "i2c differencialis erparon" jellegu megoldasokkal mennek tovabb: mert ott csak illesztoket kell kozbeszurni, nincs semmi "media konverter", plane mikrokontroller, sajat firmware-rel, stbstb. 

Es akkor negyedik lepes lenne az egyedi mikrokontroller, es azt is valami olyasmi breakout boarddal kezdenem amiben van beepitett usb <-> serial bridge es i2c kivezetes is egyszerre. Pl egy arduino asszem ilyen. 

Ha ezek is mennek, akkor mar lehet folytatni a jatekot mikrokontrolleres multi-drop rendszerekkel (RS485, CAN, ...). Abban igazatok van hogy ez a legrobosztusabb, strapabirobb, vezetekelhetobb megoldas (lasd: CAN + autoipar, Modbus, ...), de cserebe elegge melyviz is ;)

Valahogy el kell kezdeni a tanulást, lehet pl. úgy is, hogy soros porton (vagy "igazi" RS232 szintekkel, vagy TTL szintekkel) illeszt egy mikrovezérlőt a Linuxot futtató valamilyéhez, utána hozzáköt egy akármilyen érzékelőt a mikrokontrollerhez, azt is megtanulja kezelni, utána jöhet másfajta érzékelő másfajta megoldással stb. Amikor ezek mennek, elkezdhet agyalni azon, hogyan illeszt több mikrovezérlőt a központi kütyüjéhez. Ez elég komplex feladat, amit apró részekre bontva lehet felépíteni. A határ a csillagos ég...

Ha nincs jó barátságban a hardverelemekkel, akkor kaphat készen modulokat, kismillió család van már ezekből, tanulásra bármelyik jó, a legolcsóbb is.

Nem biztos, hogy az egészet egy Samsung Galaxy S III köré kellene kezdeni építeni, még akkor sem, ha az ingyen van, ugyanis hiába adott hozzá látszólag sok dolog (pl. az érintőképernyő), már a tápellátásához barkácsolni kell, ha OTG kábelt csatlakoztat hozzá - ami nem biztos, hogy egyszerűen megy annak, aki kezdő.

Erre is (meg a feljebb leírtakra is) megfelel az MCP2221. Rádugható USB-re, van benne soros, i2c, gpio, sőt több - szinte egy kis rpi. ;)

"Minden" rendszerhez van driver, rajz, dokumentáció, amit a gyártó ad és nem a githubos amatőrök.

Nem állítom, hogy egy gyártó mindenben tökéletes, de a githubos projektekben azért jóval több a hiba.

Ha valaki kezdő, az ne jelentse automatikusan azt, hogy lusta olvasni. A sok-sok "nekem működik" amatőr megoldásból általában nem lehet tanulni. 

Arra, amit ő szeretne, ez is jó, meg számtalan más is, viszont ő még nem tudja, hogy nem ezt kellene akarnia :)

Ő 10 m-re akarja elvinni az I2C buszt, ami nem szerencsés. Pontosan tudom, hogy mit írtál erről korábban (máshol), tehát itt nem fog egyezni a véleményünk.

Azok a meghajtók, amiket csavart érpárak meghajtására használnak (pl. X.21/V.11, G.703, RS422/RS485 esetén), és a hozzájuk való vevők már nagyon sok éve bizonyítanak, probléma nélkül használhatók, ott a 100 m vagy akár az 1 km is simán elérhető.

10 m-re simán jó a 1-wire is, de akár használhat valami/frekvencia átalakítót is az érzékelőknél, azzal is könnyebben tudja megoldani a problémát, és akkor nem kell szenvednie az I2C-vel, de még az RS485 erősen szoftverigényes megvalósítását is megússza.

Zajos ipari környezetben 50-60 m-ről is stabilan jönnek pl. a hőmérséklet-frekvencia jeladók jelei, semmi baj sincs velük, és egyszerű a megvalósítás is, a feldolgozás is. Sok lehetőség van még, pl. a szokásos 4-20 mA-es áramhurok.

 

A githubos amatőrök dolgairól nem tudok nyilatkozni, nem szeretek más által barkácsolt megoldásokkal foglalkozni, legfeljebb megtekintés szintjén, az embernek általában úgysem pont ugyanarra van szüksége, és egyébként is obban jár, ha saját maga találja ki, hogy mit akar csinálni, azt mivel tudja megoldani, a sok-sok év alatt mindenkinek kialakul a saját eszközkészlete, amihez fokozatosan jönnek hozzá az új dolgok.

A kezdő, mivel kezdő, nem rendelkezik tapasztalattal, ezért az indulásnál sokat számít, hogy milyen tanácsokat kap, sokszor az a legjobb tanács, ha az eredeti ötlet buktatóit megmutatják neki, és egy járhatóbb útra terelik. Kezdetben nem kell nagy dolgokat csinálni, jobb lépésekben haladni, úgy nagyobb az esély a sikerélményre. A sikereken felbuzdulva, az egyre nagyobb tudás, egyre több tapasztalat birtokában lehet magasabb hegyeket is megmászni.

Hááát, a műszaki paraméterek nem vélemény vagy ízlés függőek, hanem adottak az adatlapokon. Így aztán amit én mondok, az legfeljebb szerinted nem fog egyezni a gyártók specifikációjával. Vagy hogy is van ez? ;)

Ő 10 m-re akarja elvinni az I2C buszt, ami nem szerencsés.

Én meg 5m távolságra vittem el, extrém zajos környezetben, 100kHz órajellel. Mellékes tervezési szempont volt, hogy akkor is működjön, amikor egy autó rááll a flexibilis kábelre, illetve tetszőleges potenciálkülöbség se zavarja. Nekem működött, csak meg kellet találni a megfelelő anyagokat és alkatrészeket. Ilyen projekt nincs a githubon. ;)

Azok a meghajtók, amiket csavart érpárak...probléma nélkül használhatók, ott a 100 m vagy akár az 1 km is simán elérhető.

Én meg láttam TI reference design-t lyen (nagy sebességű) meghajtásra. No, az nem amatőr munka! Az áramhurok tényleg jó, akár 2km távolságra, de nem nagy sebességre.

Ebben a topicban semmi lyen problematika nincsen. Az alap i2c meghajtás (max. 400pF, ~2mA) csak rövid távokra elegendő. A 10m kábel összehozhat >1nF kapacitást. Ennek a kapacitásnak kívánt sebességű feltöltéséhez nagyobb áram kell, azaz olyan meghajtó, ami ezt tudja. Ilyen meg van a boltban és nem is drága. De majdnem erre sincs szükség, ha a sebességet kisebre veszed. Ugyanis az előbbiek az adott i2c módban megengedett maximális sebességre vonatkoztak.

Az i2c szenzorok általában smbus protokollal működnek, ott meg van van crc (PEC), amivel ellenőrizheted az adatok helyességét, szükség esetén ismételheted a kiolvasást. Egyszerűbb esetekben erre általában jut idő.

sokszor az a legjobb tanács, ha az eredeti ötlet buktatóit megmutatják neki, és egy járhatóbb útra terelik.

Bizony, a járható út: használj rpi-t, esp-t, atmega - de legalább 32 bites legyen! ;)

Miért i2c? Ugyan nem egy tudományos statisztika: Rákerestem a Mousernél

- rs485 sensor: 63 - ezek inkább development toolok

- 1-wire sensor: 226

- i2c sensor: 3852

- spi sensor: 2065 - bár ezek jó része i2c is

Ezzel az egyik kérdés eldőlt.

Az i2c legegyszerűbb kivitele, ha a drótra kötsz mindent.  Hosszú kábelnél meghajtók kellenek, magas zavarszintnél meg differenciálisak.

Ennél valószínűleg csak bonyolultabb megoldás létezik.

Buktatók vannak, de a legfőbb buktató, ha amatőrökre hallgatsz. ;)

Megismételted nagyjából azt, amiket ezzel kapcsolatban már írtál a HUP-on, pedig jeleztem, hogy azt már ismerem :)

A Mousernél talált darabszámok alapján szerinted eldőlt a kérdés, pedig még mindig XP-t használsz, ugyanakkor statisztikai adatok szerint már régóta Windows 10-zel kellene dolgoznod (CentOS helyett meg pl. Ubuntuval) :)

Sehol nem írtam, hogy RPi vagy ESP kellene a megoldáshoz, habár feldolgozásra pl. egy RPi teljesen jó lenne, az ATMEGA sem került szóba nálam, holott azokat kedvelem, főleg a 8 biteseket :)

Ach! Minő szájkarate, ami nem szól semmiről! :-D

A Mouser, Farnell, stb. árul ipari szenzorokat, a barkácsboltok meg nem. Sőt a Tesco sem lenne mérvadó. ;) Szintén rossz döntés lenne pl. az ebay találatait vizsgálni. Azt az mcu-t, amit használok már 5 éve (akkor még elég új volt), 7x kevesebben árulják, mint a 2002-től gyártott elődjét. A legújabb termékek a Mousernél megtalálhatók, de az ebay-re néha soha nem jutnak el. Így aztán az ebay sok szempontból az amatőrök világa.

Aztán miért kellene Windows 10 az assembler fordító futtatásához? Az rs485 meg jóval régebbi, mint az i2c, de mindenki hülye, aki nem Fisher Space Pennel ír - mint én is. Pedig az régebbi, mint az i2c. :-D

Sehol nem írtam, hogy RPi vagy ESP kellene a megoldáshoz...

Én sem állítottam, hogy írtad. Csak feltételeztem, hogy olvastad ezt a topicot (vagy másikat), ahol hemzsegnek az ilyen jótanácsok. Pedig a feladat csak annyi, hogy 10m dróton jelet kell továbbiítani.

És itt a probléma gyökere! A drót az összes fent említett entitásnál régebbi és mindezeknél sokkal többen használják a világon!

Így aztán egy kezdőt először a drót helyes használatára kell megtanítani! Ha ez a tudás elegendő a probléma megoldására, akkor készen is vagyunk. Bizonyára csak ismétlem magam, és már ismered, de nem sokat tanultál belőle.

habár feldolgozásra pl. egy RPi teljesen jó lenne

Íme, itt is egy jótanács. Ott a telefon, többmagos processzor, linux - az miért nem jó a feldolgozásra? Tudom, Windows XP. :(

Így aztán egy kezdőt először a drót helyes használatára kell megtanítani!

Érdekesen hangzik, de egyetértek vele.  Amit én csinálnék ekkora távon: egy-egy MCU és illesztés a drót két végére, valami hullámimpedanciával lezáró meghajtó, ami vagy half duplex, vagy full duplex kb. úgy mint a telefon, tehát a dróton mindkét oldali adás szuperpozíciója van, de a saját adásunkat levonjuk belőle, így akkor is halljuk a másik oldal beszédét, ha közben mi is beszélünk. Ez szimmetrikus érpáron menő aszinkron kommunikáció lenne. Az MCU-k a „belső” oldalon, azaz ott, ahol a szenzor van, s csak néhány cm a távolság, mert például a szenzor és az MCU azonos nyákon vannak, ott meg sima I2C felhúzó ellenállásokkal, aszimmetrikus, szinkron kommunikáció, és készen is vagyunk.

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

A hullámimpedanciát a zemberek egyszerűen impedanciának hívják. Esetleg megadhatod a mérőfrekvenciát.

Két i2c eszközt 10m távolságra modulált telefon hibriddel (azt meg úgy hívják) összekötni roppant ravasz ötlet. :-D

De legalább újabb protokoll bevezetése nélkül nem is működne.

Itt egy roppant egyszerű leírás: An Introduction To I2C Over Long Wires, amit még egy mérnök is megérthet, ha figyel. Bemutatja az i2c működését a rövid, hosszú és hosszú illesztett vezetékeken. Sőt >>10m távolságon. Az alján további néhány AN is van, ha a részletekre is kíváncsi vagy. Van benne pl. 350kHz-es órajelű mérés 50m távolságon, nem illesztett vonalon. Nem én készítettem, hanem az NXP.

Viszonylag drágák a buszmeghajtók, de ha kisebb frekvenciát használsz, talán nem is kellenek.

hullámimpedanciát a zemberek egyszerűen impedanciának hívják

Rosszul teszik, mert nem ugyanaz a kettő. A végtelen sok elemi induktivitás és köztük végtelen sok elemi kapacitás reaktanciáinak végtelen összegzéséből - hadd ne mondjam, integráljából - képes kijönni egy valós mennyiség, ami ráadásul gyakorlatilag nem is igazán frekvenciafüggő. A kábel geometriájától, a felhasznált anyagoktól - permeabilitás, permittivitás - függ, és ezzel a hullámimpedanciával illik lezárni a kábelt, ha nem szeretnél reflexiókat, állóhullámot a kábelen.

legalább újabb protokoll bevezetése nélkül nem is működne

Amit ajánlottál doksit, az sem az eredeti Philips féle I2C implementáció, akkor meg már nem mindegy? Amit én javasoltam, abban egyetlen érpár is elég lenne, igaz, a nagytávolságú szakaszon semmi köze sem lenne az I2C-hez. De számít ez valamit, ha az a cél, hogy az adat "A"-ból "B"-be eljusson és viszont?

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

Látszik, hogy ott voltál az elosztott paraméterű hálózatok órán. ;)

Ennek ellenére a hullámimpedancia fogalmat többnyire csak nagyfrekvenciás kábeleknél használják. Márpedig a <1MHz, az nem is frekvencia. (A TI után szabadon. ;))

ezzel a hullámimpedanciával illik lezárni a kábelt

Helyesen: A hullámimpedanciának megfelelő impedanciával illik lezárni a kábelt. (A tankönyv szerint - mint József Attila.)

A Philips kis neve ma: NXP. A P82B96 és PCA9600 éppen annyira nem i2c eszköz, mint ahogy az 72LS244 nem TTL áramkör - elvégre nem a normál 10 fan out terhelést képes meghajtani, mint egy tisztességes TTL áramkör. ;) Ráadásul amikor a TTL sorozat keletkezett, még nem is implementálták ezt az áramkört, tehát szinte nem is létezik. Szerinted.

Folytatás alant.

A Mouser, Farnell, stb. árul ipari szenzorokat, a barkácsboltok meg nem. Sőt a Tesco sem lenne mérvadó. ;) Szintén rossz döntés lenne pl. az ebay találatait vizsgálni. Azt az mcu-t, amit használok már 5 éve (akkor még elég új volt), 7x kevesebben árulják, mint a 2002-től gyártott elődjét. A legújabb termékek a Mousernél megtalálhatók, de az ebay-re néha soha nem jutnak el. Így aztán az ebay sok szempontból az amatőrök világa.

Sajnos olyan magas lovon ülsz, hogy észre sem veszed, hogy néha megbotlik :)

Arra szerettem volna rávilágítani az "XP-zéssel", hogy nem mindig helyesek a következtetéseid. Én is használok XP-ket a mai napig virtuális környezetben, nekem azzal nincs is bajom (persze azért annyira buta vagyok, és semmiből nem tudok tanulni, hogy arra azért nem vagyok képes, hogy az legyen a fő operációs rendszerem).

Azt sem mondtam, hogy RPi kellene a Galaxy helyett, az én 3 mondatomat titulálod szájkaraténak, holott te írsz Tesco-ról, ebay-ről tök' feleslegesen, de az rendben van, mert onnan fentről ez így látszik. Legyen. Igazad van. 10 m-en csak az I2C a jó, a többi ötlet mind amatőr, megvalósíthatatlan, feleslegesen bonyolult és egyebek.

Most megyek, veszek valamit az ebay-en, az való nekem, ezek után a Mousert, RS-t, Farnellt, TME-t mind messzire elkerülöm...

Dehogy ülök magas lovon! Még megharapna. ;)

Viszont amit leírogatok, az nem "következtetés", ti. hivatásszerűen csinálom, ebből élek.

Kénytelen vagyok a legjobb, legolcsóbb és beszerezhető megoldásokat alkalmazni, különben nincs sorozatgyártás, nincs termék.

Ha nem ismerném az alapokat, alkatrészeket, a választékot, beszerezhetőséget, akkor nem tudnám elvégezni a munkámat. Egyes esetekben túl drága lenne, amit gyártunk, vagy nem működne és ezért nem lehetne eladni.

Én kérek bocsánatot, ha a megszerzett tapasztalataimat próbálom ráerőltetni másra! Sőt, meghajlok az előtt is, ha 1m drót helyett 3db rpi a könnyebb út. (Már megint másra gondoltam, ne vedd magadra!) Azért is bocsánatot kérek, ha szerintem egy ilyen megoldás nem helyes és még ki is fejtem.

Az "XP-zés" egyáltalán zavar, mert nem tudod milyen az enyém. Biztosan semmi köze sincs ahhoz, amit virtuális gépen futtatsz. Ez egy elég egyszerű döntés volt: Szerettem volna zökkenőmentesen dolgozni. Ehhez tizenéve kialakítottam egy olyan rendszert, amihez azóta se kellett érdemben hozzányúlni. (És kb. 40% maradt a gyári XP-ből.) A "fő operációs rendszernek" az én esetemben vajmi kevés értelme van. Inkább egy ibmes kolléga örökérvényű szavai írják le a helyzetet: A vindóz nagyon jó, mert sok putty ablakot lehet rajta nyitni.

Annak idején pedig az "ifjú szakemberek" szerint a szakember havonta újrahúzza a rendszert. Mivel az AIX nálam megelőzte a Windows-t, ezt elképzelni sem tudtam, hiszen az AIX felkerül a gépre, aztán 15 év múlva kidobjuk, persze néha upgrade, de az nem újrahúzás. A vége az lett, hogy soha nem kellett megállnom az új rendszer nem várt fícsörei miatt. ;) Úgy érzem, ezzel csak nyertem. Ha mégis tökölni kellett valamivel, az általában nem az XP miatt volt, de semmiképpen nem rabolt több időt, mint más (Windows) rendszeren.

Igazad van. 10 m-en csak az I2C a jó, a többi ötlet mind amatőr, megvalósíthatatlan, feleslegesen bonyolult és egyebek.

Hát ugye. ;)

usb - i2c ---- Mi legyen itt? ---- i2c

Ahogy a vasorrú bába mondaná: olajoshal. :-D

Primitív eszemmel gondoltam csak drótra.

A mikrovezérlő (vagy akármi, amivel kezeled az I2C buszos eszközöket) szempontjából semmilyen változás nem lesz, a szoftver oldaláról ez továbbra is I2C, csak kell hozzá legalább 2 db illesztő IC, ami miatt útközben valóban nem I2C lesz a dolog, hanem differenciális I2C. A szokásos logikai analizátorokat így nem tudod mindenhol használni, hacsak eléjük is nem teszel egy ilyen illesztőt (persze ez sem komoly probléma, hacsak nincs kiöntve az érzékelő, mert akkor nem férsz hozzá az SDA és SCL jelekhez).

Az adatlap szerint ez is csak akkor jó 10 m-re, ha lejjebb mész a sebességgel.

Jó, de akkor az, amit javasoltam, hogy I2C, MCU, duplex aszinkron átvitel, MCU, I2C, szóval akkor ez is I2C, bár igaz, hogy a kettő között teljesen más.

Az I2C egy szabvány. Meg lehet hekkelni igény szerint, és ez jó, csak akkor már nem I2C.

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

Jó, de akkor az, amit javasoltam, hogy I2C, MCU, duplex aszinkron átvitel, MCU, I2C, szóval akkor ez is I2C, bár igaz, hogy a kettő között teljesen más.

Úgy érted, hogy az I2C---MCU---(valamilyen_illesztő)----(hosszú_kábel)----(valamilyen_illesztő)---MCU---I2C résznél a két MCU-val emulálod a sor végén lévő I2C-s eszközt?

Igen, az dI2C. (Figyeled? Ott az I2C.)

Értem én, hogy szerinted az sem i2c, pedig csak egy buszmeghajtó, miközben a protokoll i2c.

Éppen ezért hivatkoztam az AN10658-ra, amiben a P82B96 buszmeghajtót használják, méghozzá 400kHz órajelen 50m távolságra.

A fenti áramkör nem differenciális, így a dokumentumban szereplő oszcilloszkóp ábrákon a normál i2c-nek megfelelő jeleket láthatod.

A Figure 10. szerinti - telefon- vagy szalagkábelen keresztül - a Table 1. első érték 250m kábelhossz. Az már majdnem 10m! :-D

Ennek alapján a 100kHz, lapos kábelen, két eszköz buffer nélkül is leküzdheti a 10m távot.

Persze ilyet nem csinál az ember a zavarok miatt, ezért kell a csavart érpár. Pl. SCL+Vcc és az SDA+GND mehet egy-egy érpáron. Ezzel jócskán megnő a kapacitás, meg talán több eszközt is a kábelre kell rakni, tehát nem lehet kikerülni a buszmeghajtót.

És ugye a SCL+Vcc az nem differenciális adatvezeték. ;)

De hol van az irónia?