Arduino I2C kijelző helyett mit?

Elektronika, Elektromos eszközök

Sziasztok!

Az Arduinotól (Mega) kb. 3 méterre kellene elhelyeznem egy kijelzőt. Sajnos a megszokott/ismert I2C interfészes 1602 LCD nem használható hosszútávon, összeszedi a zavart és emiatt lefagy az Arduino. Az LiquidCrystal_I2C library segítségével van megoldva a kijelző kezelése, így nem biztos, hogy 0-ról szeretném ezt a részt újból megcsinálni.

Szerintetek mivel lehetne ezt a legkevesebb munkával kiváltani? Ki mit javasol?

Ez a 2x16 karakter elegendő, de használok egyedi karaktereket is. Egyéb elvárás nincs, a mikrokontrolleren van még gazdagon szabad ki és bemenet.

Köszi a segítséget.

  • 4019 megtekintés

( SchTamas | 2019. 09. 06., p – 08:08 )

Nem lehet az arduinot is oda tenni és az egyéb részeket összedrótozni velel messzebbről?

( answ | 2019. 09. 06., p – 08:16 )

Odateszel a kijelző mellé egy kis MCU-t, ami I2C-n kommunikál a kijelzővel, a mostani eszközzel pedig RS485-ön.

Azért linkelhetnéd azt I2C szabványt, ahol ezt olvastad. :-D
Aztán összeszedett zavarról sincsen szó, hacsak a hibás működést nem hívjuk annak.
Ha a felhúzó ellenállás túl nagy, akkor nem tudja időben feltölteni a kábel + a ki- és bemenetek kapacitását. Erre szuperponálódik a tápegység zaja, amitől a H szint olybá tűnhet az avatatlan szemlélő számára, hogy hol H, hol meg nemigen. ;)

Az ellenállás és a sebesség "talán" épp fordítva viselkedik. :)
3 m még abszolút nem téma, használtuk mi ~10 méteren is.
Simán megoldható! Ha tényleg nagy a zavar, akkor árnyékolt kábelt érdemes kell használni. Ha a táp és az adat egy kábelen megy, akkor kevésbé érzékeny, ekkor még egy-egy ferrit gyűrűvel lehet javítani, bár I2C frekvencián sokat nem ér.

Amire figyelni: szoftveresen normálisan kell kezelni! Ehhez az arduino könyvtárak nem biztos hogy a legjobb alapot adják. Van az I2C valóban "deadlock" módja, amikor a két eszköz egymásra vár. Ebből néhány órajel-impulzussal ki lehet hozni.

Ebből néhány órajel-impulzussal ki lehet hozni.

Sajnos ennél sokkal rosszabb a helyzet. A több bájtos parancsoknál a néhány órajel csak az adott bájtot teszi rendbe. Pl. egy vagy több cím bájt esetén (eeprom címzés, modbus) az eszköz nem mindig felejti el a "kályhát". Ilyenkor marad a valódi reset, vagy a sérült protokoll befejezése és eldobása - ami bonyolítja a helyzetet.
A másik eset, amikor az eszköz eleve nem válaszol egy ideig, pl. eeprom írás.

Ezeket ez eseteket elsősorban az adatlapon leírtak pontos megvalósításával lehet megoldani. Az általános szoftveres megoldás nem minden esetben elegendő. Ilyenkor a busz művelet elemeit - akár a szabványtól eltérő módon - egyedileg kell meghatározni.

Jó példa az AM2320. Ez egy i2c + modbus eszköz, de tartalmaz két olyan időzítést, ami nem szerepel a szabványban. Az rpi-re megírt lib alapú driver kiválóan működik. Az rpi más órajelű verzójával meg kiakad. Nyugodtan állíthatjuk, hogy az első eset hibátlan működése csak véletlen volt. ;)

Ja persze, magasabb szinten még ezer dolog romolhat el.
Épp ilyen i2c kijelzőkkel akadt nekem olyan, hogy teljesen leakasztotta a buszt, pedig nem 3 m, hanem csak néhány cm kötötte őket össze.

Ugyanis ha egy slave megfogja az adatvonalat, azzal a master nem sokat tud tenni sajnos. Elvileg az órajellel is megteheti ezt, de ott kevésbé szokott probléma lenni, mert a clock stretching valamikor "véget szokott érni", ha a slave elvégezte a dolgát.

Viszont ha a slave-nél kimarad egy órajel, akkor a master elveszítheti az arbitrációt, erre gondoltam. Nem is kezdeményezhet akkor kommunikációt.

Láttam olyat is, ahol ezt úgy "oldották meg", hogy sw i2c-t írtak, de a clock stretching-et kidobták belőle :D

Bár én pont az ellenkezőjét írom. ;)
A slave megfogja az adatvonalat csak annyit jelenthet, hogy nem olvastad el pontosan az adatlapot.

A clock stretching és az arbitráció kifejezetten multi master opció. Az előbbi esetleg előfordulhat lassú slave esetén, bár manapság elég szegényes az a hardver, amelyikben egy shift regiszter sincsen. Az utóbbi meg nem arbitráció, hanem egyszerű leakadás, mert szarul van megcsinálva.

Az elégséges i2c működéshez ott a szabvány, ahol van Mandatory meg Optional elem is. A clock stretching (avagy szinkronizáció) csak opció, amivel egy hétköznapi (slave) hardvernél nem fogsz találkozni. A slave ack nyújtása inkább előfordulhat, amit elvileg tetszőlegesen lehet nyújtani, mert az i2c 0Hz-től megy felfelé.

Amikor Arduino Arduinoval kommunikál I2C-n, ott van clock stretching.

Elküld 8 bitet az egyik arduino, a másik arduinonak idő feldolgozni, amíg az ack jelet elküldi, addig clock strectching van.

Gondolom az I2C EEPROM írásnál is komolyan elnyújtott órajelek vannak. Szerintem kevés olyan slave van, ami csettintésre megcsinál mindent.

Pontosan erről van szó, ha a master-ben és a slave-ben eltér az órajel (pl. a slave elmaradt, vagy inkább összeszedett +1-et), akkor az adat irányában sem fognak megegyezni, és ezért fog a master arbitrációt veszíteni a slave-el szemben.
Pontosabban: arbitrációs hibát fog érzékelni (nem az van kint, amit ő ad), és ezért fogja "elengedni" a buszt. A slave meg ottmarad a meghúzott adatvonallal.

Ez egy könnyen előforduló hiba, és illik rá felkészülni. Ezen segít az, ha ilyenkor órajel impulzusokat adunk a slave-nek.

BTW ahogy írod, a clock stretching nem (elsősorban) azért kell, mert a biteket nem tudja előállítani a slave, hanem mert esetleg ennél egy komplexebb műveletet kell elvégeznie (pl. AD konverter), és maga az adat nem áll rendelkezésre.
Aki programozott i2c slave-et, az tudja miről beszélek. Pl. PIC18 i2c slave automatikusan clock stretch-el (az ACK-nál), ha olvassák. Ekkor kell beletölteni az adatot a TX bufferbe, ami a slave részéről akármeddig is eltarthat.

Gondolom az I2C EEPROM írásnál is komolyan elnyújtott órajelek vannak. Szerintem kevés olyan slave van, ami csettintésre megcsinál mindent.

Teljes sebességgel lehet írni és olvasni - a hivatkozott M24512 1MHz-es eszköz. Viszont bármilyen flash eszköz írásakor időbe telik az írás, - itt 128B lap írás - konkrétan max. 5ms, amely időtartam alatt nem válaszol. Ez egy nem szabványos busz ciklus: start - cím - nincs válasz, és ez nem azonos a "nincs ack" helyzettel. Tehát a stop helyett loop kell az adatlap szerint. Persze csak akkor, ha tudod, hogy írtál.

Tehát kilépve az ardunio világból, a többi eszköz nem használja az opcionális clock strectching funkciót. Mégpedig azért nem, mert a feladatnak megfelelő hardver áll a protokoll mögött. Pl. a bus collision detektálását is hardver + interrupt végzi, így nem kell pollingolni.

A clock stretching az ack előtt is opcionális. Az Arduino Arduinoval kommunikál olyan eset lehet, amikor a két szerkezet megbeszélte (a lib írója önmagával), hogy így fognak kommunikálni. Normál esetben nincs ilyenre szükség, mert az interrupt és az adat kezelése gyorsan elvégezhető. Ha én írom. ;) Tehát ilyen funkció van egy pic-en is, de külön engedélyezni kell.

Nekem eszembe nem jutna I2C-t flow control nélkül használni.

Ha nincs clock stretching, akkor inkább értelmesebb protokollokat használok. Az I2C azért praktikus, mert képes szabályozásra.

Igazából SPI vonalon 8 MHz-en darálom át DMA-n az adatokat, nem értem minek kellene az I2C clock stretching nélkül? Lassú, macerás, körülményes, rossz zajszűrés, rövid kábel,... Értelmes paraméterei nincsenek. Max annyi, hogy kevesebb kábellel megy. Nofene.

Van valami, ahol a clock stretching nélküli I2C jobb mint egy shift regiszter, vagy RS-485?

Nekem eszembe nem jutna I2C-t flow control nélkül használni.
A gyártók erről sajnos nem tudnak. ;)
A szabvány szerint meg opcionális.
Meg nem is flow controlnak hívják, mert az más.
Lehetne hívni wait state-nek, de hát az sem.

Igazából SPI vonalon 8 MHz-en darálom át DMA-n az adatokat
Ez nyilvánvalóan hasznos lehet egy hőmérőnél. ;)

RS-485 does not define a communication protocol; merely an electrical interface.
Feltételezem, tán egy shift regiszterre sem definiált a kommunikációs protokoll. ;)
Az egyik szinkron, a másik aszinkron.
Az egyik rövid távolságokra való, a másik meg nagy távolságokra.

Aztán, ha az i2c protokollt el akarod vinni nagy távolságra, akkor megteheted akár rs485 interfészen vagy di2c interfészen keresztül is. (stb., stb.)

Nagy zavart érzek az Erőben!

Nem kell zavart érezni az erőben, tök mindegy, hogy mit írnak a gyártók, nem muszáj megvenni a termékeiket.
Flow control nélkül semmi értelme az I2C-nek, mert a többi protokoll sokkal jobb megoldást kínál erre.

Az I2C nagyon sok tekintetben nem optimális, ami tök jó, hogy vissza tud szólni, ha még nem fejezte be a feldolgozást.

AVR alatt megpróbáltam a multimaster-es módot is interrupt kezelésre, de a chip erre alkalmatlan 4-5 hardverhiba miatt. Valszeg azért lett TWI, mert idő hiányában piacra dobtak valami szart I2C helyett.
- egyszerre küldött start jelnél kiakadhat mindkét mester
- néha elveszíti a biteket és kifagy a CLK vonal
- a STOP-ot rosszul kezeli, ha gyorsan küldenek a masterek és a kódod lassú, könnyen NACK jön vissza
- nem tartja be az I2C "bus free time"-ot a specifikációból

Protokoll hibák:
- a felhúzó ellenállások miatt zajra érzékeny
- hosszú kábelnek nagy a kapacitása, miközben egy SPI/UART a HI szintet beleveri 40mA-rel, addig az I2C 5kohm felhúzó esetén 1mA-rel tölt
- őrülten lassú, a 100kHz az semmi, már egy 128x256-os LCD-hez is kevés.

Mivel helyettesítettem idáig az I2C-t?
- SPI a leginkább kézenfekvő, egy 320x200-as színes LCD-hez már 10 MHz-cel DMA-val tolom az adatokat
- WiFi (ESP8266+ESP32 egy I2C-hez képest elképesztő sebességekre képes)
- UART (mehet több résztvevő között is, multiplexinggel)
- CAN busz is lehet, nem véletlenül ezt használják a kocsikban és nem I2C-t

Hőmérőt meg vehetsz SPI-set is, meg OneWire-t is ha szívatni akarod magadat. Én a Microchip-től SPI-s cuccokat szoktam venni, mert az I2C-vel kapcsolatban fenntartásaim vannak.

A gyártók nem írnak, hanem gyártják a termékeiket. A zemberek meg megveszik és használják.

Olyan nincs, hogy nem optimális. Legfeljebb valamilyen feladatra nem optimális, de azt inkább tervezési hibának hívom. De lehet más szempont is. Pl. egy termék tervezésénél megnézem, hogy egy alkatrészből i2c vagy spi interfésszel rendelkezőből árulnak-e többet és milyen gyártóktól. Ilyenkor általában nem az spi győz. Ha sokféle eszközt kell alkalmazni egy áramkörben, akkor megint az i2c győz. Ha a feladatra alkalmas valami, akkor tökmindegy, hogy létezik-e valami egészen más, ami akár elképesztő sebességet is tud, bár nincs rá szükség.

A problémádat inkább abban látom, hogy alkalmatlan hardveren, alkalmatlan szoftverrel sikertelen voltál. Ezt még tetézi az 5kOhm-os tévhited, ami könnyel leküzdhető lenne egy adatlap, vagy méretezési példa elolvasásával. A méretezés nem azonos az össze-vissza megvásárolt modulok ötletszerű összedugásával. ;)

Meg az I2C mellőzésével is megoldható a probléma. A Microchip mindegyikből gyárt SPI-t és I2C-t is. Bocs, de jobb szeretem 10MHz-en küldeni az adatokat, mert még az is rohadt lassú.

A 320x200-as színes LCD kijelzőm 192000 bitből áll, 25FPS-hez 4800000 bit kell, ami minimum 5 MHz órajel mellett lehetséges. Küldeném én 36MHz-en is, de a kijelzőknek az már sok.

LCD-ből I2C-t nem szabad venni, mikroprocesszorból meg kizárólag olyat érdemes használni, amelyik képes DMA-zni.

Azért hidd el, durva ahogy LCD-n realtime mutatja az oszcilloszkóp az adatokat, eközben meg USB-n tovább is tudja küldeni 800 kbyte/s mellett. Aztán ugyanúgy 2$ a blue pill is (STM32F103C8T6), mint az Arduino.

Attól még hogy "lassú" az I2C, vagy nem a legalkalmasabb grafikus LCD-khez, még nem lesz rossz interfész.
Most komolyan... 20 éve ennél jóval lassabb kapcsolatokon interneteztünk.
A CAN sem gyosabb, egy kicsit sem, ha a nagyobb protokoll overhead-et beleveszed. [ferdítés on]Elektromosan meg épp azt tudja mint az I2C [ferdítés off]. Ráadásul órajelet sem visz, ott kapásból úgy kezdődne minden node, hogy akassz rá egy kvarcot, vagy horror áron beleintegrálnak egy hőmérsékletkompenzált oszcillátort.

Persze, LCD-hez van millió interfész, legelterjedtebb talán a párhuzamos. Ha viszont van egy I2C-m, arra "akárhány" eszközt felfűzhetek. Dolgoztam olyan helyen, ahol ipari gépek belső kommunikációja I2C-n volt megvalósítva (összetákolva), hosszú, több méter kábelezéssel, leágazásokkal, jelterjedési szempontból egy horror, de mégsem az I2C-vel volt baj, soha.

Hőmérőnek, RTC-nek, EEPROM-nak, lassú AD-knek tökéletes, nem is kell több. Eszembe nem jutna ezeket SPI-al megcsinálni.

( renard | 2019. 09. 06., p – 08:22 )

Ilyen problémák megoldására fejlesztette ki annak idején a Philips az I2C extendert.
https://www.nxp.com/products/no-longer-manufactured/i2c-bus-extender:P8…
http://www.ti.com/lit/ds/symlink/p82b715.pdf
https://sandboxelectronics.com/?product=active-i2c-long-cable-extender-…
https://www.ebay.com/itm/10PCS-I2C-bus-extender-IC-PHILIPS-DIP-8-P82B71…
https://www.ebay.com/itm/10PCS-I2C-bus-extender-IC-PHILIPS-SOP-8-P82B71…

> A linkben a legjobb a "no-longer-manufactured". ;)
Természetesen lehet közvetlenül a gyártótól is vásárolni termékeket, de azért mégis az a gyakoribb, hogy nem tőle, hanem alkatrészforgalmazótól vásárolsz, azok meg még árulnak ilyen tudású IC-t.

> felesleges ilyet használni
Viszont lehet, nem drága (3-4$-ért kapsz 10 darabot), és megoldás a problémára.

Ok, a link az csak trollkodás volt - bár célszerűbb lett volna egy "itt kapható" linket betenni.

Lehet bármit is használni, de akkor sem úszod meg a busz méretezését. Ha meg nekiállsz a számolásnak, akkor kijön, hogy felesleges. Vigyázni kell a kétirányú I2C meghajtókkal, mert a két oldalán eltérő sebesség esetén visszapofázik. És akkor mégsem oldottál meg semmit, viszont mégis számolni kell. ;)

( _Franko_ v | 2019. 09. 06., p – 08:24 )

"összeszedi a zavart és emiatt lefagy az Arduino"

Egyrészt ezt mérted vagy csak saccolod? Másrészt milyen fizikai zavarvédelmet használtál?

--
https://iotguru.live

Szia!

Jórészt saccolom, "sajnos" gépészmérnök vagyok, az elektronbubusgatás csak hobbi. A kijelzőn látszik, hogy elkezdi összeszemetelni a karaktereket, így még megy egy darabig, frissülget, de aztán megáll. Valójában, fórumozgatás alapján valószínűleg nem lefagy, hanem vár valamire és végtelen ciklusba kerül ott, amiből nem tud kilábalni. A kijelzőt kigyomlálva a kódból, napokig tud futni, megállás nélkül.
Egy árnyákolt kb. 15 eres vezetékkel van összekötve, ebben megy +5V, GND mellette, egy ledsornak a DATA lába, illetve 6 egyszerű nyomógomb.

Ilyenkor kellene ráakasztani egy oszcilloszkópot vagy logikai analizátort (én például őket javaslom: https://www.saleae.com/), mert mérés nélkül csak vaktában fogsz próbálkozni, amíg véletlenül jó nem lesz. Egyrészt jelalakot kellene mérni, másrészt a Saleae tud protokollokat is elemezni, mutatja a kommunikációs hibákat.

--
https://iotguru.live

+1

Másrészt viszont ha a kommunikáció hibája miatt le tud fagyni a rendszer, akkor ott a program is hibás. Kommunikációs hiba esetén újra kellene indítani a megfelelő alrendszert, és működő állapotba hozni.

Az más kérdés, hogy ezt jól megcsinálni egy nagyságrenddel nehezebb feladat, mint amit a tipikus Arduino-s könyvtárak megtesznek: épphogy működik, akkor mehet a release és soha többé rá sem nézünk a projektre. Nyilván feladatja válogatja, hogy érdemes-e ezt a plusz munkát beletenni. Nekem is van egy hasonló kijelzős projektem, ami kb egy év működés alatt egyszer lefagyott. Újraindítottam és kész, nem fogom kidebuggolni...

Plusz előfordul, amikor a kliens hardver megy egy hibás belső állapotba és csak HW reset segít rajta. Még az is lehet, hogy nem is az I2C a probléma, hanem pl a túl hosszú kábel miatt instabil a táp. Az ilyen lehetőségek okán sem ártana jól rámérni egy szkóppal a cuccra.

Igen, szép kis gagyi megoldás, ami még hobbista célból is kb használhatatlanná teszi az Arduino I2C alrendszerét. Volt nekem is ilyen I2C-s cuccom, ami időnként lefagyott. A legjobb benne, hogy a tipikus user előítélet jött ettől elő bennem: az I2C szar. Ahelyett, hogy azt vezettem volna le, hogy az Arduino libek szarok.

Meg a hardver is szar.

Arduino alatt van egy mastered, amelyik időnként küldhet üzenetet, amit a slave-ek fogadnak. Ebben a felállásban még működni is szokott, ha két kérés között tartasz némi delay-t.

Delay nélkül az idóta hardver képes a stop és a start jel között arra, hogy 1V-ig beemeli a feszültséget 5V helyett, majd azonnal visszahúzza. Nanosec delayt tart a start és stop között, amit az I2C slave-ek fele nem fog tudni start-ként felismerni.

I2C kérés indul, I2C stop, delay

Ha pedig több mastert szeretnél és arbitrációt, az Arduino-t elfelejtheted. Az csak a PDF dokumentációban van, hogy képes multimaster módban működni, de megbízható adatátvitelt nem fogsz vele elérni. Kifagy, failel, ...

Atmega328P. A normál master slave I2C megy szoftver korrigálással. Az arbitráció sosem fog menni, amikor egyszerre két mester ad, az olyan versenyhelyzeteket eredményezhet, hogy vacak hardveren megoldhatatlan.

Persze a Due más kategória, azon mehet, gondolom az ARM chipek jobbak.

Igazából a doksi TWI-nek hívja, mert gondolom nem teljesíti az I2C szabvány előírásait.

I2C-bus specification and user manual Rev. 6 — 4 April 2014

Megnézheted még a "clock stretching" opciót is. Ezt használva pl. programot flashelek két PIC mcu között, csak úgy "röptében". A slave az I2C ACK-ban adja vissza a blokk írás sikerességét.
Érdekességként itt egy I2C EEPROM. Hogyan valósítod meg a Figure 9. tetején levő csonka buszciklust? (start, address+w, nack -> start ... - azaz nincs stop condition)

A specifikációból kiindulva, a TWI nem tudja a Table 2. szerinti összes funkciót, de az I2C standard sebességeit sem. Ennek ellenére a szabvány ütközés miatt adott más név is igaz, és a működése az esetek többségében kompatibilis.

Az I2C lehetővé teszi, hogy ne legyen master a buszon, hanem mindenki slave. Nincs kitüntetett master, a slave-ek arbitráció útján döntik el, hogy ki fog adni.

Mi van akkor, ha egyszerre ketten akarnak adni?

A hardver észleli, hogy ő 1-et akart küldeni, de a buszon 0 van kinn, tehát másvalaki húzta le a jelet 0-ra. Ez akkor fordul elő, ha mindketten egyszerre adtuk ki a start jelet, mindketten elkezdtünk adni, az ő üzenete még egészséges, az enyém már nem, mert tönkretette azzal, hogy 0-ra húzta a vonalat. Ebben az esetben az arbitrációs logika visszavált slave módba, elvesztettem az arbitrációt, ha viszont engem címzett a másik, slave-ként meg fogom kapni az ő üzenetét, amit velem egyszerre nekem akart küldeni.

Nálam a buszarbitráció az interrupt miatt kellett volna. A slave átveszi az irányítást a buszon és értesíti a mastert, hogy megszakításos esemény történt.

Működött is, de megbízhatatlanul a versenyhelyzetek miatt. Állandó üzenetvesztés, fagyás, belebeszélés,...

Pedig a doksi egyértelmű. Sajnálom, hogy nem sikerült nekik hardver szinten megvalósítani.
I2C-n lehet multi slave, csak mindegyiknek más címet kell adni.

An algorithm must be implemented allowing only one of the masters to complete the transmission. All other masters
should cease transmission when they discover that they have lost the selection process. This selection process is
called arbitration. When a contending master discovers that it has lost the arbitration process, it should immediately
switch to slave mode to check whether it is being addressed by the winning master. The fact that multiple masters
have started transmission at the same time should not be detectable to the slaves, i.e. the data being transferred on
the bus must not be corrupted.

Nem, ha értelmesen csinálták meg a hardvert. Mondjuk Atmega328P-re ne építs.

Amint a master lehúzza alacsonyra a jelet, a slave szintén lehúzza. Tartja a vonalat. Amint feldolgozta, akkor visszaengedi.

Master az órajelet hogy adja:
- CLK HI->LO, DATA beállít (utána CLK LO->HI)

- slave/másik-master a CLK-LO-ra CLK-LO-val válaszol => megfogja az órajelet, nem engedi, hogy a master visszaengedje HI-re

- master küldené a következő bitet, de nem tudja, mert annak ellenére, hogy saját magánál CLK->HI-re váltott, a slave CLK-LO-val fogja a vonalat. A CLK nem megy vissza HI-re.

- slave befejezte, már nincs kedve tetvészkedni, visszaengedi a CLK vonalat LO-ról, nem fogja már senki a vonalat, ezért a felhúzókkal átvált HI-re.

- a master látja, a CLK HI-n van, ezért elkezdi feldolgozni a következő bitet. A slave tetszőleges ideig tetvészkedhet.

Ha átment volna az Atmega328P az I2C szabványon, akkor nem szabadna problémát okoznia. A gond az, hogy nem tartja a szabványt, ezzel mindenbe belezavar.

Itt a probléma az, hogy IT rutinból kell továbbterelni a busz állapotát, különben nem követi a valóságot, viszont a szerző által írt rutin nem elég gyors ahhoz, hogy időben lekezelje az állapotátmenetet. Ha kellően gyors volna az IT rutinja, az megoldás lenne.

16-20MHz csip órajelet feltételezve kb 2000 órajele van lekezelni az interruptot. (Jól számoltam? A busz és a csip órajelének függvénye is ez!) Le is írja a cikkben, hogy nem csak annyi van az IT rutinban, hogy beteszi a kapott bájtot egy pufferbe, hanem konkrétan csinál is vele valamit. Illetve nem tudja a regiszter mentéseket kispórolni az IT rutinból, mert túl sok változót használ, vagy van belül függvény továbbhívása.

Szerintem ezt a problémát meg lehet oldani ASM-ben írt IT rutinnal, vagy "NAKED" ISR rutinnal, ami az állapotátbillentést megcsinálja regiszter mentés nélkül, majd újraengedélyezi az IT-t, és a hosszú idejű feldolgozást már IT engedélyezés mellett hajtja végre. (Vagy csak beteszi az adatot egy round-robin pufferbe, és a fő szálról dolgozza fel, nem IT alól.) Szerk.: Emiatt számomra nem egyértelmű, hogy ezt hardware bugnak kell tekinteni, vehetjük úgy is, hogy egy nagyon szigorú IT sebesség korlátozás.

Ez egy piszkos trükk, hogy az IT rutin kontextusából, de engedélyezett IT mellett dolgozzuk fel a bejövő adatot. Lehetővé teszi az egymásba ágyazott IT-ket, ezért különösen észnél kell lenni az időzítésekkel, nehogy stack overflow legyen a vége, de jól csinálva működik.

Plusz arra is figyelni kell, hogy nem csak ez az egy IT rutin van a rendszerben, és worst case is benne kell maradni az időkeretben. Ez a többi IT rutin, plusz az IT disable blokkok kényszerű lerövidítését is jelenti. És még jó sokat kell számolgatni is. Szóval végsősoron tényleg sokkal jobb lenne, ha a hardver másképpen lenne megvalósítva, ahogy a cikk szerzője javasolja.

Rengeteg bug van hardver szinten, itt két bugról van szó:
- ha nem kezeled le időben a STOP jelet, a chip bennragad és nem fogja elkapni a következő start-ot, NACK-ot küld helyette. A gond az, hogy a STOP-ot nem tudod CLK-LO-val tartani, a chip meg nincs olyan állapotban, hogy új ACK-ot küldhessen ha címzik. Szoftveresen úgy orvosolható, hogy ISR naked, a legelső dolog, amit csinálsz, hogy STOP-nál elengeded a hardvert. Ezzel a bug letudva.

- van egy másik bug is, ami sokkal rosszabb, az a hardware bug

Megtörténik a STOP, CLK HI, DATA HI. Amint a Data magasba megy (2V) a másik master azonnal kiadja a start jelet. Az oszcilloszkópon annyit látsz, hogy a DATA 0V-ról 2V-ra megy, majd 0-ra tér vissza ns időintervallum alatt. Nem tud a DATA vonal rendesen stabilizálódni, nem is éri el a 3.3V vagy 5V jelszinteket. Egy halvány villanás lesz az egész, amit a Slave-ek fele START-nak érzékel, a másik fele semminek. Nézd meg az ábrán, hogy összecsúszik.

Itt a doksi,

https://www.analog.com/en/technical-articles/i2c-timing-definition-and-…

Olvasd el a tBUF részt: "bus free time between a STOP and START condition", 4.7 us.

A probléma, hogy a hardver nem tartja ezt az időt.

https://www.avrfreaks.net/forum/twii2c-bus-free-time

I agreed TWI is free to deviate from the I2C spec, but they have copied the
I2C timing specs to the AVR-TWI timing specs:

tBuf = 4.7uS < 100 kHz
tBuf = 1.3uS > 100 kHz

but this is not the case! so they deviate from their own specs as well. And if we think of our goal it is to have a common communication method. I think their is no doubt.

but I'm just wondering how i can solve this problems...

Ez a 2000 órajel egy sakkprogramra is elég. :-D
Lemértem egy eeprom olvasását - 12MHz-es órajelekben:
előkészítés=281,
restart: 38
read: 40
data read: 186
Ez a teljes interrupt ideje, még a return is benne van.
A csalás csak annyi, hogy ez high priority interrupt, tehát 8 órajelet megspórolok. Van ebben is ugrótábla 12 órajel.
Bár van olyan, aki nem ért velem egyet, de az interrupt alatt illik elvégezni a feldolgozást is. Az elrakom-előveszem általában időigényesebb.
Igaz, ez egy pic18 és asm. Ennek ellenére nem hinném, hogy a C, a más utasításkészlet és hardver tizes szorzót eredményezne. Vagy a bus collision detektálása emésztené fel a különbséget. Ezzel 8% az overhead és 10kB/s az olvasási sebesség, miközben interrupton kívül nem kell mást csinálni. A szerkezet azért kezeli az usb, timer, adc, nyomógomb interruptokat. Az 1kHz-es adc eredményét szorozza (csak 8x8 szorzó van) és számol egy 32 TAP-os FIR filtert is. Végül az eredményt aes256 kódolva az eepromba írja. ;)

Hát, nincs is kitüntetett master. Innentől felfogás kérdése a probléma, én úgy értelmezem a dolgot, hogy mindenki slave és ha valaki master akar lenni, azt arbitráció útján érheti el.

De úgy is fel lehet fogni, hogy mindenki master csak slave-ként kell viselkednie ha más szerezte meg a vonalat.

Szerintem amikor nem adsz, hanem a vonalat hallgatod, akkor te nem master vagy, hanem slave.

( bucko | 2019. 09. 06., p – 08:30 )

A két szerkezetet kösd össze UTP kábellel a következő módon:

1. érpár
SDA
GND

2. érpár
SCL
GND

3. érpár
VCC
GND

4. érpár
VCC
GND

Az I2C adapter VCC és GND csatlakozó lábai közé forrassz 2,2..4,7uF/16V 0805 X7R MLCC kondenzátort.
Az I2C órajelet csökkentheted a 100kHz-es értékről egészen addig, amíg a megjelenítés nem lesz csúnya.

Meg ezt is elolvashatod: I2C Bus Pullup Resistor Calculation

Aminek alapján az SDA és SCL felhúzó ellenállások értékeit csökkentheted akár 1,8kOhm értékig.

+1

Én az órajel csökkentéssel kezdeném. A 2x16 karakterhez nem kell sok órajel, és ha ezt kellően lecsökkentjük, akkor sokkal biztosabb lesz az egész.

Arduino-n hardveres I2Ct használva az órajelet valami regiszterek beállításával kell kezelni. Valószínűleg bele kell nézni a libek kódjába hozzá, vagy akár bele is kell szerkeszteni. Alternatíva lehet, hogy a lib inicializálása utána a saját programból felülvágjuk a megfelelő HW regiszterbe tett értéket.

Szerk: rákerestem, elvileg van rá Arduino API, csak erősen HW függő, hogy milyen értékeket támogat: https://www.arduino.cc/en/Reference/WireSetClock

( Csab | 2019. 09. 06., p – 10:27 )

Az SPI szerintem alapjáraton elmegy 3 méterre.

Két Arduino simán eldumál egymással SPI-n. A közeli Arduino I2C-n vezérli az LCD-t, míg a távoli központtal SPI-n kommunikál.

Az Arduino mikrovezérlő egy kis szar. Akkor tudsz vele értelmes cuccokat készíteni, elfelejted az 1 feladat 1 processzor elvet. Ha nem elég 1 arduino, akkor benyomsz 2-t, azok meg eldumálnak egymással.

( denton | 2019. 09. 06., p – 14:36 )

Ha nem fullhd-s videókat akarsz kitolni realtime-ban, hanem kisebb adatokat, akkor a kijelző mögé betolsz valami kisebb arduinot, pl nano-t, mellébekötsz egy hc-05-ös bluetooth modult, az "anya" arduino mögé szintén és mehet neki bluetooth-on az adat :)

Ugyanez akár rádiójeles modulokon ha a bluetooth nem tetszik.

De persze csak akkor játszik ha nem nagy adatmennyiséget küldenél, és persze meg kell oldani a két eszköz párosítását is.

Ezt úgy mondják nem informatikai nyelvezeten: Ágyúval verébre. ;)

Mindössze arról van szó, hogy
- ott a kábel
- rosszul van illesztve
- legfeljebb 50Ft költséggel megoldható.

A feladat egy 1602 LCD meghajtása, amin 32 betű van. Elég lomha jószág. A vezérlő jeleket is figyelembe véve, legfeljebb 64 betű/másodperc a legnagyobb sávszélesség. De az már elmosódott mozinak látszik ;), szóval ennél lényegesen kevesebb. És az is csak ritkán.

A megoldást pontosan leírtam. Ezen felül minden egyéb felselegesen bonyolítja és drágítja.

Kérdezz nyugodtan, ha valami nem lenne világos!

( KaTT v | 2019. 09. 06., p – 21:42 )

Mint téma iránt érdeklődő, kezdő, csendesen javaslom, hogy mint elméleti megoldás akár, vegyél 2 ilyet, közé UTP kábelt, és kész:

UTP kábel - Rj45 - I2C átalakító :)

https://www.youtube.com/watch?v=Km-XAFcmP6c

SparkFun Differential I2C Breakout - PCA9615 (Qwiic)
https://www.sparkfun.com/products/14589

És ott lent találsz hozzá még átalakítókat, kábeleket, stb, hogy könnyebb legyen összerakni.

Hamarosan tesztelni fogom, nekem szenzor adatok átvitelére kell.

Sakk-matt,
KaTT :)

( tovis v | 2019. 09. 12., cs – 11:01 )

Talán valami ilyesmivel toldanám ki P82B715

* Én egy indián vagyok. Minden indián hazudik.

Én meg először elolvasnám, amit bucko írt. ;)
Rossz esetben a 30-40m-es meghajtó sem oldja meg a hibát, jobb esetben meg pénzkidobás.
A hiba oka az, hogy az i2c modul felhúzóellenállása 20-50cm kábelre van méretezve. Itt a modul a kezemben, látom. A modul szűrése is valószínűleg elégtelen és nem is a kábel végén van. Azaz a modul nem szűrésssel kezdődik, mint ahogyan illene.

( Csab | 2019. 09. 22., v – 06:11 )

Volt beszélgetés az I2C rendszerek problémáiról, a terepasztalon valószínűleg USART-ra fogom cserélni. Maga a terepasztal úgy megy, hogy van egy központi hálózat, az leadja a vonatok jeleit, a sorompó vezérlő, jelző vezérlő, meg miegymás ennek megfelelően állítja a fényeket, sorompókat.

Teljesen elosztott mikrovezérlős rendszer, ahol broadcast üzenetekkel értesülnek az egyes elemek, hogy mi a helyzet. Van egy központi mester, az tolja az üzeneteket.

Az architektúra durván így nézne ki:
https://people.ece.cornell.edu/land/courses/ece4760/PIC32/uart/multiple…

Half-duplex vonal lenne, a diódák miatt kb. open collectorosan működne, bár működhetne push-pull módon is. Egy dolog hiányzik belőle: az interrupt, amikor egy eszköz jelezni akar, hogy üzenete van. Ezt egy másik open collectoros vezetéken oldanám meg, amikor van üzenet, lehúzza a vonalat, a mester meg körbekérdez mindenkit, hogy mi történt.

Erre az I2C rendszer is jó lenne, akkor mi a baj vele:
- körülményes. Miközben az USART-on kiadom, hogy ezt a puffert DMA-val told át, vagy olvasd be, addig I2C alatt semmi nem megy tapsra. Nem lehet egy rendes DMA-t ráállítani. Ezer dolog történhet az I2C buszon, nem úgy megy, hogy itt egy puffer, küldd át, vagy töltsd fel.
- gyorsabb: még open collectorosan is 2X sebességgel megy (kevesebb szintátmenet), push-pull módban 20X is lehetne
- ha push-pull módban megy, akkor kevésbé zavarérzékeny
- az USART egyszerűbb hardver, sem az Atmel, sem az STM32 nem bug mentes. Lehetnek versenyhelyzetek, néha a chip is kiakad.
- a slave nem tudja jelezni, hogy vége az üzenetnek. Max az lehet, hogy az első bájt az üzenetból elmondja, hogy milyen hosszú lesz.
- az I2C előnye, hogy képes késleltetni a mestert, de ez egyben hátrány is, mert miközben vár, mást is csinálhatna a buszon.

Az I2C rendszereknek semmi problémájuk sincsen, jól érzik magukat. ;)
A probléma inkább az alapismeretek hiányánál kezdődik. Ilyenkor rendszerint a
Texas TTL receptek, 2. javított kiadás, MK. 1978
- 12. Adatátvitel
-- 12.1 Zavarok
...
elolvasását ajánlom. Van abban szó a teljesítményillesztésről is, persze a kábelek lezárásaként.

Az I2C busz az egy protokoll és egy alap buszrendszer, de nem illesztett. Igény esetén át lehet rakni más meghajtókra, akár illesztett vonalra is. Ezek a megoldások drágítják a hardvert, de elég sok irodalmat találsz hozzá. Nagyobb távolságon akkor érdemes használni, ha sok I2C eszköz lóg a buszon.

Az USART avagy az RS232 TTL szintű változata szintén illesztetlen és zavarérzékeny, de az SPI is. Az USART viszont összeköthető RS485 meghajtókon keresztül csavart érpáron, illesztett vonalon. Megfelelő meghajtót választva akár 128 eszközt is ráköthetsz.

Az interrupt meg a dma marha jó, amikor 1us vagy kevesebb idő alatt kell beavatkozni. Egy kisvasútnál fellépő lassú jeleknél meg abszolút felesleges. Hacsak nem akarsz a kisvasút kis állomásán központilag videót vetíteni. ;)

Azért van kommunikáció, durván 1kbyte/s.

Gondolj bele, folyamatosan számolni kell, hogy épp merre lehetnek. Ezért tud 2 vonat egyszerre menni. A gyorsat lassítod, ha kell.

Egy gyorsabb mozdony 600 mm/s-sel is tud menni, a legrövidebb szakasz 230 mm.

Ha valamit félreszámolsz, loggolás nélkül durva lehet kitalálni, mi a baj .

A szabályzási hibáknál a hátsó vonat rángatni fog, ami elég gázul néz ki.

Eközben folyamatosan webről követed az eseményeket.

Nekem a DMA sokkal jobban tetszik, mint a pollozás. Ráadásul ingyen van, csak használni kell.

Az 1 kB/s nem komoly adatforgalom. Különösen egy olyan eszköznek, ami webet ki tud szolgálni.
A poll az az interrupt ellentéte. A DMA meg megkönnyíti a cpu és a program dolgát, de a fenti sebesség mellett csak kényelmi funkció.

Az 1kB/s ~ 10kbaud. Helyette 128kbaud-ot használva 10x gyorsabb lesz a kommunikáció. A half duplex polling helyett lehet ütközéseket is detektálni. Ekkor nem kell külön drót az interruptnak.

> Az USART avagy az RS232 TTL szintű változata szintén illesztetlen és
> zavarérzékeny
Mihez képest? Az RS232 <30m 9600 Baud, azért csak nem 30m kisvasútja van?
Minden esetre én lehet az RS485 választanám - ugyanúgy UART és sok pontos.

* Én egy indián vagyok. Minden indián hazudik.

Ha belegondolsz, szikráznak a kerekek, áram folyik (mágneses hatás), a sín meg egy marhanagy antenna.
Hasonló esetben a két végén földelt vastagfalú vascsőben vezetett vezetett kábel sem túlzás.
Na jó, találkoztam már hasonlóval, csak ott a kisvasút egy néhány kW-os frekvenciaváltó volt. ;)
Zavar miatt tévesztett a 3m 9600baud. Mivel minden adott volt, ezért egy RS232-TCP konverter volt a megoldás. Bár a jelszint kisebb, de csavart érpár és trafó is van benne. A trafó a fellépő közösmódusú zavarok miatt jótékony hatású.
Protokoll lehet MODBUS-szerű, mert abban van CRC is.

Egyik ismeros hasonloan csinalta (kozel 20 eve). UARTnal ugye 1 van alaphelyzetben a vonalon, ezzel hajtotta meg a tapegyseget. Amikor 0 jott, akkor levette a sinrol a tapot, es lefoldelte. Mivel viszonylag ritkan kuldott csak csomagot, ez a rendszer tapellatasat nem befolyasolta. Minden mozdonyban volt 1-1 mikrokontroller (azt hiszem graetz es kondi utan, igy a sin polaritasa sem szamitott), ami dekodolta a kapott jelet (cim+irany+sebesseg), es egy H hidon keresztul PWM-mel meghajtotta a motort. Ez persze csak egy iranyban tudott kommunikalni, de neki eleg volt. A sinhez telepitett mindenfele erzekelok, lampak, ilyesmik kevesbe kritikusak (kevesebbet mozognak, oda lehet vinni a drotot).

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Szerintem amikor az keszult, meg nem nagyon voltak ilyen meretben es arban radios modulok. Egyebkent szerintem mukodne.
Egy graetz hid (vagy 4 dioda) nagyon pici, egy mikrokontroller szinten. A kondi kicsit nagyobb, de nem kell hosszu idot athidalni. A H bridge megint kicsit nagyobb. Ha ezeket ugy erzesre osszeadod, kenyelmesen elfersz egy mozdonyban szabadon hagyott terben. Egy 15-20 evvel ezelotti radios modul mar nehezebb ugy lenne.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Amikor felteszed valahova a mozdonyt, tudnod kell, nagyjabol hova tetted.
Leteznek sinbe epitett erzekelok, ahol ket sindarabkat osszezar a mozdony kereke (lehet, hogy van optikai is). 2 tengely eseten nem csak azt tudod, mikor haladt at, de a sebesseget is (tengelytav osztva az eltelt idovel). Erzekelok kozt meg a mozdonynak kuldott sebessegparancsok eleg jol korrellalnak a sebessegevel, az eltelt idod tudod, ezzel kell korrigani a rendszerben ismert helyet. (kb. mint a Kalman szuro vagy a dead reckoning)

Persze ha lenne visszafele kommunikacio, tehetnel a mozdony kerekebe tavadot, vagy a mozdonyba gyorsulasmerot. Ez sokkal pontosabb lenne.

Kamarov: Stop pissing, Yuri. Give me a stopwatch and a map, and I'll fly the Alps in a plane with no windows.
Yuri (Diving Officer): If the map is accurate enough.
-The Hunt for Red October

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

15 szakaszra van nálam bontva a terepasztal és fogyasztást mérek.

3 diódán 2.1V esik, ez már képes kinyitni egy optocsatolót.

Egy érzékelőhöz 2x3 dióda (mindkét irány), egy ellenállás és egy kétirányú opto kell.

A PWM miatt minden sebességen nyitni fog.

Tudod a szakaszok hosszát, vonat belép kilép megvan a sebesség, utána közelítheted idő alapján a finom helyzetét.

Egész jól mér.

A DCC-hez 10-100 kHz közti négyszög jel kell a speckó szerint, viszont a mozdony motorját 30 és 200 Hz közötti frekvencián hajtja.

Kicsit elhűltem, amikor a 10 kHz-t megláttam, mert a mozdony motorja induktivitás. Folyamatos árama van és nem kimondottan érdekli, hogy PWM-elek-e, vagy sem. Az én DDR-es mozdonyaim 10kHz-nél már teljesen úgy viselkedtek, mintha a jó öreg FZ1-essel vezéreltem volna őket (mint konstans feszültségen).

Ezt ki lehet mérni, hogy 10 kHz-nél már jóformán konstans a motor árama, miközben 100 Hz-nél tényleg PWM van. 100 Hz-nél ha 5%-os tüskéket nyomok a motorra, akkor is megy, csak baromi lassan. Természetesen 0,6V-on meg sem nyikkanna. A kHz-s intervallumban már megszűnik a PWM hatás.

A dekódereknek ezért kell a sínfrekvenciától eltérő frekvenciát használni PWM-re.

Ez érdekes, mert sok helyen direkt 20kHz feletti PWM-et használnak DC motor meghajtásra mivel az nem sípol - mármint nem halljuk. Az ilyen PWM-nek is van szabályozó hatása, csak nem oszcilloszkóppal látható 0-ra visszaesés, hanem egy hullámzó nagyjából állandó feszültésg beáll, ami a PWM kitöltéstől függő érték lesz.

Működni fog vele, de a PWM-ben az a jó, hogy ereje van. Akkor is húz, amikor nincs komoly kitöltési tényező.

Én azt láttam, hogy 10%-os PWM-nél a mozdony odébbtolt egy teli gyufásdobozt. Lassan megy, de van ereje. Persze hangja is van.

20 kHz-nél nem fogja odébbtolni a gyufásdobozt. Nem jut friss impulzusokhoz. Ezt végigpróbáltam, míg a 100 Hz jött ki, mint kívánatos frekvencia. Persze akit a hangja zavar...

Elmagyarázom szívesen.

Legyen egy lassú frekvencia: naponta vált a PWM (1 / nap). 1%-os PWM jelnél 0.24 órát (14 percet) megy a vonat teljes sebességgel, 23 órát és 46 percet meg állni fog.

Hiába 1%-os a PWM, azért azon a 14 percen, amíg kapja a 12V-ot, száguldani fog. Biztosra veheted, hogy helyet fog a vonat változtatni.

Nézzük meg fordítva: 12V-os vonatra 0.12V-ot kapcsolsz. Ugye érzed, hogy a vonat körbe fog röhögni. Arra nem elég 0.12V, hogy a súrlódási erőt legyőzze. Lehet, hogy hangot sem fog adni.

A PWM erre való. A motort helyváltozásra kényszeríted. Friss, 12V-os impulzusokat kap, csak ritkán. Ez elég a súrlódás legyőzésére, a mozdonynak az impulzusok miatt ereje lesz, csak lassan fog menni.

Roppant érdekes magyarázat. :-D
A motor álló helyzetben egy (veszteséges)induktivitás és egy ellenállás soros kapcsolásának felel meg. Az egyszerűség kedvéért hanyagoljuk el a veszteségeket!
Ha feszültséget kapcsolsz rá, akkor az U=L*dI/dt+I*R függvény szerint emelkedik az áram. Ha a t idő elég kicsi, akkor az áram lineárisan nő. Elég hosszú idő alatt az áram határértéke U/R lesz.
Ha a feszültséget kikapcsolod, akkor az áram nem tud 0 idő alatt megszűnni. Ezért kell egy szabadonfutó dióda, amin keresztül az áram lineárisan lecsökkenhet. Ha ilyen nincs, akkor egy nagy feszültségcsúcs fogja elnyelni az induktivitásban felhalmozott energiát.
Ha a motor forog és állandó feszültséget kap, akkor az U=E+IR szerint áll be az egyensúly. Itt az E a forgásból származó ellenelektromotoros feszültség.

Az áramkör időállandójánál kisebb periódusidejű meghajtásnál beszélhetünk PWM-ről, amikor egy periódus alatt nem áll be a maximális áram. A példádban nagyságrendekkel nagyobb a periódusidő, ezért ezt szakaszos üzemnek hívjuk.

A PWM alkalmazhatóságának a feltétele az, hogy a motorban levő mágnesezhető anyagnak az alkalmazott frekvencián ne legyen túl magas vesztesége, mert ilyenkor a vasmag túlmelegedhet.

A PWM olyan kitöltési tényezőnél indítja meg a motort, amikor az áramerősség az ehhez szükséges értékre tud nőni.

> Az áramkör időállandójánál kisebb periódusidejű meghajtásnál beszélhetünk PWM-ről

A PWM-nek semmi köze az áramkör időállandójához. Pulse width modulation: impulzus szélesség moduláció.
Ahhoz sincs semmi köze, hogy mennyi idő alatt áll be a maximális áram.

A LED dimmer akkor is PWM jelet ad ki, ha történetesen kihúzom a LED-eket alóla és a maximális áram 0A lesz.

Van egy trafód, ami PWM jelet ad ki, te meg bármit csinálhatsz: nem kötsz rá semmit, teaforralót teszel rá, kompresszort hajtasz, motort, LED-et, zenét játszol, vagy ami jólesik.

Nem értem, hogy miért kellene egy 0.001Hz-es PWM jelet másképp nevezni (szakaszos üzem), mint egy 10kHz jelet, amikor a frekvencián kívül az égvilágon semmi nem változik. Ráadásul LED-ek esetén még reaktív rész sincs (meg időállandó sem). Ne keverjük a szezont a fazonnal.

Azért na. Abban igazad van, hogy nagyon elméleti síkról nézve bármilyen frekvencián PWM, de ha teszem aztéletem első 100 évében be van kapcsolva egy lámpa, utána 900 évig ki van kapcsolva, akkor cseppet sem lesz az az érzésem, hogy ez a lámpa 10 %-os kitöltés miatt azt a hatást hozza, mintha a névleges feszültségének 10 %-ával járatnánk. Azt fogom tapasztalni, hogy egész életemben vakító fényerővel világít. Tehát de, van köze a rendszer időállandójához: a PWM által keltett fizikai mennyiségnek nem szabad jelentős mértékben ingadoznia, s ekkor az eredmény olyan lesz, mintha analóg módon szabályoznánk, csak alacsony veszteséggel. Ha izzólámpát PWM-mel vagy fázishasítással szabályozol - szegről-végről az is egyfajta PWM, csak nem lineáris -, akkor az izzószál termikus tehetetlensége adja az időállandót, LED-eknél többnyire a átásunk lassúsága, ha úgy tetszik, a biokémiai időállandó lesz az.

A vonat motorjánál pedig van egy villamos tehetetlenség, ez az L/R időállandó, bár van benne csalás, hiszen az áram viszont U/R, így végül is 1/R-rel arányosdan nő. Ezzel csak azt mondom, hogy ez okozza, hogy R=0-nál hiába végtelen az időállandó, az elvileg végtelen nagy stacioner áram miatt mégis lesz áramingadozás, legfeljebb lineáris.

Aztán ott van a rendszer mechanikai időállandója, amely a tehetetlenségi nyomatékból és ha jól sejtem, a súrlódásokból jön.

Úgyhogy valóban azt nevezném PWM-nek, aminek a hatása közel ekvivalens azzal, mintha a kitöltési tényezővel azonos konstans jellel vezérelnénk analóg módon.

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

Ez is egy megközelítése a problémának.

Nekem azért nem tetszik, mert a feszültségforrást és a terhelést összemossa.

Amikor az IC adatlapját olvastam, ott PWM-nél még visszacsatolásról sincs szó. Nem muszáj egy PWM hálózatban bármiféle szabályzó körnek lennie.

Én úgy gondolom, hogy a PWM egy jelalak, amit akár szabályzásra is használhatsz.

A kerti lámpám letölti a netről, hogy mikor megy le a nap, akkor felkapcsol, 22:00-kor meg lekapcsol. Szerintem ez is PWM, pedig szabályzókör sincs benne.

Az, hogy milyen szót, kifejezést hogyan értelmezünk, rajtunk, embereken múlik. Lesz ennek egy szakmában elfogadott, leggyakoribb értelmezése, meg olykor lesznek, akik mást értenek valamin. Itt vagyok én, aki tudom ugyan, hogy a hivatalos helyesírási szabályok szerint nem kell annyit kötőjelezni, ha úgy tetszik, hibásan írom le azt, hogy router-emmel. Mert nekem így tetszik, mert nem írom le azt, hogy fájljai, hanem azt írom, hogy file-jai. És akkor legyek már következetes a router esetében is.

Szóval ez is ilyen. Értheted, ahogy jólesik, de számíts arra, hogy félre fognak érteni, vagy ki akarnak majd javítani, mert más van a szótáradban az adott fogalomra, mint a többségnek.

A PWM-nek a célja egy alacsony veszteségű teljesítmény vezérlés, ahol kihasználjuk azt, hogy a vezérelendő rendszer a tehetetlensége folytán nem tudja lekövetni a gyors be-ki kapcsolásokat. Ha mégis leköveti, és ez probléma, mesterségesen teszünk bele időállandót, ha úgy tetszik, már a nagyteljesítményű részben alakítjuk analóggá a jelet. Ekkor egy soros induktivitás és egy kapacitás a terheléssel párhuzamosan megteszi, de észben kell tartani, hogy ez egy soros rezgőkör, s ha kihangoljuk valamelyik harmonikusra, abból lehetnek csinos kis villámok.

Érdekességképp mondom, hogy a szabályozásokra én is úgy tekintettem, hogy azért van bennük a negatív visszacsatolás, hogy mindegy, mi a terhelés, a szabályozó méri a hibát a referenciához képest, aztán kiszabályozza, amit kell. Sajnos ez nincs így. A szabályozott rendszerben a végrehajtó szerv, vagy ha úgy tetszik, a szabályozott objektum fizikai tulajdonságait, időállandóit bele kell venni a szabályozó méretezésébe, ellenkező esetben könnyen építhetünk labilis, oszcillációra hajlamos szabályozót. Változó paraméterű terhelésre nagyon nehéz jó szabályozót csinálni, de egyáltalán, bármilyet.

Talán az megvan, hogy a sima analóg tápegységek is oszcillálni kezdenek kellően nagy kapacitív terhelés hatására, mert elfogy a fázistartalékuk. Ezért nem szabad ész nélkül mindenhova uborkásüveg méretű elkót rakni, mondván, így jó stabil lesz, mert ellenkező hatást érhetünk el vele.

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

> nem szabad ész nélkül mindenhova uborkásüveg méretű elkót rakni

Ja, ezt volt szerencsém kipróbálni. Fülhallgató fel, hallgatom a táp zaját egy kapacitáson keresztül. Sajnos van zaj.

1000 uF, 2000 uF, 10000 uF, 22000 uF, a zaj egyáltalán nem csillapodik, sőt növekszik is.

Az elko mellé illik kisebb kondenzátort is rakni, de bevallom nem sikerült a zajt hallható sávon kívül rakni.
Valaki azt javasolta, hogy elko helyett akkumulátort használjak szűrésre, mert az meg tudja fogni a tápot rendesen.

Csökkenteni sikerült ugyan, de így is elég jól hallható volt.

Sőt, az erősítőnek, tranzisztoroknak, ellenállásoknak van zajuk. Az olcsó SMD vastagréteg ellenállások zaja jóval nagyobb, mint a drága - darabonként sok 10, vagy akár sok 100(!) Ft-ba kerülő - vékonyréteg ellenállásoké. Tudom, mert ezzel eszik az életemet a munkahelyemen, műszereknél nagyon nem mindegy, mennyire zajos egy erősítő... :)

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

+1
Gratulálok, igazad van!
És ezzel ki is döntötted magad alatt a fát. :-D

A PWM tényleg egy moduláció fajta, és első fokon semmi köze a meghajtáshoz.
Másrészt meg az állandó vagy változó kitöltésű, fix vagy változó frekvenciájú meghajtás népszerű neve.

Amiről én beszéltam, az meg egy induktív terhelés meghajtása négyszögjellel.
Ekkor a következő üzemmódokat különböztetjük meg:
- Tertósan kikapcsolt állapot: Az áram = 0, az idő sokkal nagyobb, mint a meghajtott terhelés időállandója.
- bekapcsolt állapot: Az áram = maximum, az idő sokkal nagyobb, mint a meghajtott terhelés időállandója.
(Ez a szakaszos üzem.)
- discontinous mód (DCM): A meghajtó frekvencia és kitöltési tényező összemérhető az áramkör időállandójával. Az áram (közel) háromszög alakban nő és nullára csökken. A következő áram emelkedésig az áram értéke 0.
- continous mód (CM): A meghajtó frekvencia és kitöltési tényező összemérhető az áramkör időállandójával. Az áram (közel) háromszög alakban nő és csökken, de értéke nem lesz 0.

A gyakorlatban létezik még számtalan mintázat, de azok leírhatók a fenti definíciókkal.
A legjobb példa erre a túlterhelt, zárlatos vagy nem optimálisan méretezett kapcsolóüzemű tápegység: Egy vagy több impulzusból álló sorozat után hosszabb szünet.

Értelmezésed szerint az is DC mód, ha egy 1ms hosszú impulzus után egy év múlva jön a következő. Bár ennek a gyakorlatban semmi értelme sincsen.

Csavart érpáron mehet az RS232 is. A trafó az már más kérdés, akkor az már inkább RS422 lenne.
Az i2c semmiképpen nem tűnik jó megoldásnak. Ha pedig szereti az aszinkron soros kommunikációt akkor még mindig a legköltséghatékonyabb az RS485.
Az RS232-TCP megoldás alatt azt érted, hogy RS232 hajtották ki amit aztán egy átalakítóval tulajdonképp ethernet -en (mondjuk UTP kábelen) vittek tovább? Igencsak drága megoldás, és legalább 2 érpár kell hozzá.

* Én egy indián vagyok. Minden indián hazudik.

Csavart érpáron még a sör is elmegy, csak az a kérdés, hogy szimmetrikus-e a jel. Az RS232 meg nem.

Az RS232-TCP ilyen. Normál UTP-vel kötöttem össze. A cég meg elbírta, a néhány száz misis forgalom mellett. ;)
A vételi oldalon meg virtuális COM port vette, vagyis az eredeti soros portot kezelő programot lehetett használni.

Nézted, hogy mit linkeltél? :)

A képek egy részén látható NYÁK csak arra való, hogy fogadja azt a modult, ami a lényeget tartalmazza. Az utolsó két képen pedig azok a "termékek" láthatók, amiket valójában meg is lehet rendelni (kb. 230Ft-ért) ennél az eladónál.

Inkább valami ilyesmit vehettél:
https://www.ebay.com/itm/HLK-RM04-Embedded-UART-ETH-WIFI-wireless-Route…

Ez az a modul, ami az átalakítás érdemi részét végzi, ezen van az okosság:
https://www.ebay.com/itm/1-pcs-HLK-RM04-Uart-Serial-Port-to-Ethernet-WI…

Ez nekem jobban tetszik, annak ellenére, hogy nem tud wifit:
https://www.ebay.com/itm/RS232-to-TCP-IP-Server-Module-Serial-USR-TCP23…



> Csavart érpáron még a sör is elmegy, csak az a kérdés, hogy szimmetrikus-e a jel. Az RS232 meg nem.

Az I2C sem, pedig arra ajánlottad:
https://hup.hu/node/165661?comments_per_page=9999#comment-2384169
Lehet, hogy tovis ilyesmire gondolt, amikor RS232-re javasolta a csavart érpárat.

Hát szakadjak meg, tényleg nem ezt akartam linkelni! ;)
De egyiket sem találtad el, mert ezt.
Itt a képe is.
Jackdugós (!) TTL interfészre kötöttem a valamilyen Conrad adatgyűjtő szerkezeten.

Az I2C sem szimmetrikus és tényleg csak rutinból írtam. Megindoklom.
Az RS232 szintén nem szimmetrikus és nincs illesztve. A max. slew rate 30V/us. Ha a TTL szinteket nézed, akkor is hasonló érték jön ki. Az I2C slew rate 100kHz esetén min. 3V/us. Ezeket az értékeket áramra fordítva kijön az alap I2C 3mA maximális árama, míg az RS232 nagyobb áramokkal működik.

A javaslathoz órajel csökkentést is írtam, amihez további slew rate csökkentés is párosulhat. A felfutás sebességét az RC tag méretezésével lehet beállítani. A C adott = kábel + ki- és bemenetek kapacitása, és ehhez számolod ki a kívánt felfutáshoz az R értékét. A lefutó élnél meg a meghajtó FET durván kisüti a kondenzátort, de ez nem így van. A max 3mA azt jelenti, hogy nem bír több áramot biztosítani a kisütéshez. Ezen kívül általában további slew rate csökkentő áramkört is be lehet kapcsolni, van glitch és zavar szűrés és órajel. Az RS232 nem multipoint, durván hajtja a vonalat, bár a zavartávolsága kétszerese az I2C-hez képest. Mindkét interfész állapotgéppel az órajel (vagy az órajel vélt helye) után olvassa az adatvonalat.

A fentiek alapján az I2C győz, mert egy slew rate korlátozott átviteli vonal mindig biztonságosabb. A csavart érpár csak a gyártó javaslatának kiterjesztése a hosszabb kábelre. Akkor még nem tudtam, hogy eleve árnyékolt vezetéken megy.

És a legfontosabb indok az, hogy a topic egy kijelzőről és 3m távolságról beszél. Ez a thread meg kisvasútról, ami jóval zajosabb környezet.

RS485 lesz nálam szerintem, de azért illene észrevenni, hogy I2C-n a sebesség csökkentése messze van az optimális megoldástól.

Gondolj bele, egy STM32F103C8T6 64 kb-os (fizikailag 128 kbyte és ezt ki is használom).

A vezérlőprogram frissítése I2C-n: 128k * 8 bit / 100kHz = 10.24s. (A képletben az ACK jel, az address, a start/stop jel nincs is benne).

10s egy vacak kis program átküldése. Hova lehetne még csökkenteni tovább az I2C sebességét?

Minthogy nem fogok a terepasztalomon a chipek között kotorászni, WiFi-n kell áttolni a programot. Már a 100 kHz is az alkalmazhatóság határán mozog.

Te pedig türelmes, ha mindenegyes elrontott változat után 20 percig töltögeted a programokat.

Sajnos a munkahelyemen is vannak programok, amit csak így lehet kipróbálni. Nem is tud az ember napi 10 tesztelt sornál többet megírni, de ezért fizetnek ugye. Nekem bőven elég a munkahelyen tetvészkedni, otthon jobban szeretek kiegyensúlyozott körülmények között fejleszteni.

Megírom a programot, feltöltöm weben és kipróbálom. Így megy a fejlesztés: emulátor helyett valós hardveren. A teljes elektronika egy panelen van, a vonat, perifériák viselkedését meg emulálom, mintha ténylegesen menne. Egy hálózaton ugye bárki tud más nevében üzengetni, akár kamu üzeneteket is.

:)

Röhögni fogsz, de a monitoromon fejlesztek. Bedugok egy USB-s vackot (Nodemcu, Arduino, Atmega328P förmedvény), után szarok az egészre, mert a fejlesztés Angular-ral történik, weben keresztül.

Valamelyik USB-s csatlakozóból kilóg valami vacak valahol. Az a jó, hogy még csak látnom sem kell az egészet, anélkül is megy a buli.

Nem hinném, hogy a 10 tesztelt sor 128k lenne.
Hacsak nem spagetti kódot írsz, bizonyára fel lehet osztani a programot funkcionális blokkokra.
A megváltozott blokkot a másodperc töredéke alatt ki lehet írni.
Sokkal gyorsabban, mint amennyi idő alatt weben megérkezik egy egérkattintás. ;)

Keretrendszere válogatja. Egy Arduino program ESP8266-ra 250-300 kBájt, ESP32-re meg 800-900 kBájt. Akkor is ennyi, ha átírsz egy karaktert és senki nem szórakozik azzal, hogy a régi és az új bináris közötti különbségeket küldje át, átküldi az egészet egyben.

--
https://iotguru.live

"Hiába, fejlődik a világ. Mindenki elfogadja, ha egy IDE legalább 16GB memóriában fut."

Aham, onnan indultunk, hogy vannak bőven olcsóbbnál-olcsóbb eszközök, ahol a bináris bőven több, mint 128 kBájt, szóval be lehet fejezni a nagyotmondást és nyünnyöggést, hogy 'bezzeg az én időmben'.

--
https://iotguru.live

Meg egy boot logo :-)

C-ben írva csak egy fordítási opció (AVR esetén az Arduino ezzel fordít), és csak az kerül bele, ami kell bele. A gond az, ha a függőségek nincsenek kitisztázva, akkor akaratlanul is berántunk óriási kódtengereket. Érdemes a könyvtári függyvényeket nézegetni, hogy mi mennyi: a printf és a lebegőpontos libek rémlenek, hogy nagyon sokat zabáltak. Ha ezeket nem használjuk, akkor jelentősen csökken a program mérete. A MAP fájlt kell nézegetni, hogy mi van benne, és azok közül miktől lehetne megszabadulni.

Viszont így könnyebb dolgozni vele. És ez csak játék. Aztán az a vége, (mint a másik topicban) hogy 600MHz-es "mcu" kell egy autó vezérléséhez. - Ami olyan bonyolult lesz, hogy a hardver és a kód biztonságosságát fokozni kell. És a játék folytatódik...
Tudom, tán túl szkeptikus vagyok, meg Murphy, stb. De az ilyen fejlett technológiák mellett miért zuhan le egy repülőgép a szoftver miatt!

Nos a világ változik. Régen elég volt, ha kiírtad egy weboldalon, hogy a vonat az 1. vágány 340mm-én van. Ma nem elég.

SVG-ben kirajzolod a terepasztalt, kirajzolod a vonatot és animálod, ahogy mozog. Azért, mert így szép.
Megírod a grafikát Angular-ban, a mikrozezérlő csak ennyit küld JSON-ban: 1. vágány, 340 mm, te meg már rajzolsz is.

Minimális kommunikáció, realtime látvány, de ennek sajnos ára van. Egy Angular app sajnos nem fér el 12 kbyte-ban.

Nálam 180 kbyte gzip-pel tömörítve, amit az ESP8266-ra feltöltök. A böngésző cache-elése úgy van beállítva, hogy 1 napig érvényes a letöltött adat.

Tehát: amikor rámész böngészővel az ESP-re, azonnal betöltődik a cache-ből a 180 k, elindul egy JSON kérés, arra JSON válasz jön.

Az a vicces, hogy realtime megy az egész és gyorsabb is, mint az Arduinon összetákolt 12k-s webszerverek.

Az utóbbira van is egy tipikus példám:
Pici router webes felülete borzasztó lassú volt. Ok, kis router, kis webszerver, nem ez a dolga...
Aztán egyszer véletlenül nem volt kéznél más, csak egy fapados brózer. A router meg villant! A webes megjelenítés 10x lassabb volt a fejlett brózerek miatt. Egyszer próbáld ki!

"Nekem most is 12k a programom! ;)"

Nagyszerű. És? Ha 40 dollár az óradíjad és 1-2 percnél többet kell ezért dolgoznod egy egyedi fejlesztésen, hogy csak 12k legyen a program mérete, akkor már nem éri meg téged alkalmazni. Durván több százezres szériáknál számít talán az, hogy mekkora a program, kevéssé hiszem, hogy egy házi építésű terepasztalnál ez számít. Azért meg ne veregesd a vállad, mert a múltban ragadtál...

--
https://iotguru.live

Bizony, ez egy befektetés.
Az eggyel nagyobb mcu minimum +1000Ft meg az egyéb elemek.
Ugyanaz a "core" megy több termékben, néhány 100..1000 sorozatnagyságban. Csak egyszer kellett megírni és évekig lehet használni.
Ezzel szemben a korszerű eszközökkel dolgozó szoftveresünk képtelen megbízhatóan működő programot írni. Ezért sajnos nem a vállamat veregetem, hanem elkezdtem újraíratni a szoftver interfész részét. Aztán jön a többi. Ez sok hónapos munka, biztosan megéri. Most éppen 3 termék áll. A firmware kész, a szoftver adatot veszít, hibákat dob.

A házi készítésű terepasztalnál számít, de ezt a problémát nem én vetettem fel. És ez az I2C hibája! :)

"Az eggyel nagyobb mcu minimum +1000Ft meg az egyéb elemek."

Egy ESP32 bruttó 950 forint, ha csak egyet veszel belőle. Ha több is kell, akkor olcsóbb.

"Ezzel szemben a korszerű eszközökkel dolgozó szoftveresünk képtelen megbízhatóan működő programot írni."

Így van, mindenki balfasz, csak te vagy helikopter.

--
https://iotguru.live

Egyedi fejlesztésű rendszerekbe bele kell tenni a vasat.

Tisztára szétszivattam magam a legolcsóbb Atmega48-asokkal. Akkortájt 600 Ft volt, az Atmega328P meg 1400 Ft. Tudnék belőlük egy marékkal adni, mert mind parkolópályán végezte.

A probléma nem az, hogy a 48-asban kevés a Flash (4k), hanem a RAM is baromira kevés (512 byte), igazából semmire sem használható.

Jó sok időt elfecséreltem vele, meg egy kis C64 effektus: kis memóriába szar kódot írtam,...

Szóval IC ment a polcra, kicseréltem jobbra és újraírtam mindent normálisan. Nálam ez a 800 Ft-os spórolás legalább +3 hét munkával párosult időben. Bődületesen megérte.

Nem. Én a rénszarvi vagyok! ;)
Vajon ennek mi köze ahhoz, ha más szarul dolgozik?
Persze bármit mondhatsz, mert egy terméknél a disztribútorok és a vevők döntik el, hogy megfelel-e.

Az ESP32 jó ötlet, de a konkrét termékekben 1500-2000Ft drágulást eredményezne. Talán az rpi... ;)

A különböző termékekben felhasznált szenzorok (nyomásmérők, árammérők) mind 5V-osak. Ha ebből mást választok, akkor csak lényegesen drágább vagy nemlétező :) típust választhatok.
Tehát kell még egy feszültség és illeszteni kell a 3,3V-os ESP32-höz, amiben nincs USB.
Aztán kell valamilyen USB képes hardver, kvarc, stb.
Ekkor nő a nyákméret és nagyobb doboz kell - és több kiöntő gyanta, vagy 4 rétegű nyák.

Az egyszeri költségeket, mint a a nyák újratervezése, vagy a programok újraírása nem számoltam.

A megrendelő 1 darabot szeretne, vagy 100 milliót?

Mert ugye ha csak egy kellene neki az otthon automatizálásához, akkor a hardver költsége elenyésző a munkadíjhoz képest.

Kis ajándék a vevőnek, hogy az eggyel nagyobb változatot rakod be. A vevő boldog és csak 2000 Ft-ot vesztettél, ami az 500.000-es munkadíj mellett viccesnek mondható.

Dolgoztál valaha ESP32-n és ESP8266-on?

Az egyik dual core, a másik nem, az egyik dupla órajellel fut, a másik nem, az egyikben 50k RAM van, a másikban 500k, az egyik tele van perifériákkal, a másikon egy csomó mindent emulálsz.

Ugye nem gondolod a kérdést komolyan?

Miközben az egyik CPU kiszolgálja a vevő wifi kéréseit, a másik dolgozik és a vevő érezni fogja hogy húz. Neked meg fele annyi idő megírni, mert nem kell semmit emulálni és szarakodni a kevés RAM-mal, meg az emiatti fagyásokkal.

Szerintem Bucko PIC-et hasznal, szoval a kerdes arrol szol, hogy miben jobb egy ESP32-es eszkoz, mint egy PIC-es. A fejlesztonek eg es fold, a felhasznalonak idealis esetben teljesen mindegy, ha mindketto ellatja a feladatat.
Most te tudod milyen mikrokontroller van a mikrosutodben, mosogepedben, hutodben, elektromos kazanodban, autodban? Amig mukodik, es nem kapod szet, mindegy.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

miben jobb egy ESP32-es eszkoz, mint egy PIC-es
Eleve nem sok értelme van összehasonlítani egy 3,3V-os wifi eszközt egy 5V-os usb eszközzel - mikor nekem pont az utóbbi tulajdonságokra van szükségem. Ezen kívül 2kB ram, 16k flash, i2c, 28 láb - meg néhány std. PIC perifériára van szükségem. Ilyen az 1923 PIC/AVR típus közül 6db van. Ebből 4 elavult és drága, másikban 24k flash van, ha kinőném a kisebbet. ;)
Erre a típusra lehet építeni, mert biztosan sokáig fogják gyártani.

Otthonra nekem az Atmega328P is kevés (Arduino).

Az ember elkényelmesedik. Vagy ESP32, ESP8266, STM103, vagy semmi.

Nem fogok programozóval szaladgálni, max annyi, hogy megnyomok egy elrejtett gombot, bekapcsol a WiFi és úgy tolom fel az új verziót. Még talán az is elfogadható, hogy bedugom az USB-t és feltöltöm.

32 bites chipeket már lehet kulturáltan programozni, olvasható kódot írni. Egyszer fogytam ki a 64k-ból STM alatt, mert túl sok virtuális függvényt csináltam. Annyi megkötés van rajtuk C++-ban, hogy a virtuális osztályokat és függvényeket nem kell túlzásba vinni.

Atmega328P alatt nem a virtuális függvényekkel szokott elsősorban probléma lenni, mert jóval előbb orra buksz, ha normális, olvasható kódot kezdesz rajtuk írni.

"Eleve nem sok értelme van összehasonlítani egy 3,3V-os wifi eszközt egy 5V-os usb eszközzel - mikor nekem pont az utóbbi tulajdonságokra van szükségem."

Te is összehasonlítottad. És ugye lehet, hogy nekünk a Wifi és a 3,3 volt fontosabb, szóval hosszan indokoltál semmit.

--
https://iotguru.live

Nem mondtam, hogy nem csinálod jól. Mindenre van megoldás, például lecseréled az I2C-t USART-ra, vagy TCP/IP-re, vagy SPI-re, vagy másra.

Foglaljuk össze tömören: 2 chip között az optimális összeköttetést a TCP/IP adja. Az összes többi protokoll igazából egy rossz vicc. A jelenlegi chipek zöme viszont nem tud megbírkózni az ethernettel, ezért egyszerűbb megoldásokat rakunk be.

Amennyiben a pi zero eléri az 1000 Ft-os kategóriát, a többi protokoll is menni fog a levesbe és végre minden a helyére kerül.

Sokáig I2C-t használtam, a javítások javításának javítása után eljött az idő arra, hogy mást is kipróbáljak, hátha több szerencsém lesz.

Ember!
Két CHIP között?
Az alapfogalmakkal kéne előbb tisztába kerülni!
:(

Vegyünk elő mondjuk egy PC alaplapot...
Hány CHIP van rajta?
És azok milyen módon vannak egymáshoz kapcsolva?

Persze tiéd a jövő... Biztos elő fogsz állni olyan alaplappal, ahol a CHIPek wifin kapcsolódnak egymáshoz...

Két _chip_ között (két IC között)?
Általában I2C vagy SPI egyébként.

Két _rendszer_ között már más kérdés (pl. RS485, RS232, CAN, USB, Ethernet, egyéb.)

Ha már PC, egy Latitude E6530-ra kötött I2C eszközök címei:
- bus 2: 0x28, 0x50
- bus 6: 0x08, 0x29, 0x2B, 0x30, 0x32, 0x44, 0x50, 0x52, 0x61
- bus 11: 0x37, 0x3A, 0x50

Nem tudom, ezek milyen eszközök (pl. hőmérséklet információ), de ezeket látja a rendszer.

Mi a bajod a TCP/IP-vel?

Ha van 5 darab 700 Mhz-es pi zero-d azt milyen protokollal kötnéd össze? I2C-vel?

Még egyszer megerősítem: hatalmas balfaszság TCP/IP helyett mást használni pi zero-n kommunikációra.

Jelenleg azért használsz más protokollt, mert a mikrovezérlőd képességeiben meg sem közelíti a pi zerot. De ez változhat.

Nem a TCP/IP-vel van gondja szerintem, hanem azzal, hogy két chip között szeretnéd (feltételezem, nem szándékosan írtad ezt, de a fenti kérdés is erre vonatkozott).

Két rendszer között (pl. két Pi között) a legkézenfekvőbb valóban az Ethernet / TCP/IP protokoll, de egyéb szenzorokkal, IC-vel nyilván nem Ethernet fölött kommunikálunk.

Van, hogy az ember nem jól fejezi ki magát vagy elír valamit - ha jelzed, hogy ez történt, akkor már nincs meg az a gumicsont, nincs min rágódni.
Amíg olyan információt lát az ember, amivel nagyon nem ért egyet és nincs korrekció, addig helyesbítés is lesz előbb-utóbb.

Modul sokféle lehet, bizonyos esetekben jogos a TCP/IP, más esetekben meg szükségtelen bonyolítás - konkrét esettől függ.

Az élet nem mindig az egyszerűség felé tart. A PS2-es szabvány egérre, billentyűzetre egyszerű volt. Arduino is lekezelte, akár Attiny85-tel is.

Bejött helyette az USB, azt még STM32F103, ESP8266, ESP32 sem képes lekezelni. A host oldali USB-re olyan követelmények vannak, hogy a chipek összecsinálják magukat.

Komolyabb hardver kell egy USB hosthoz, mint TCP/IP-hez.

USB-n lehet lassú eszközt csinálni, Atmega328P bitbang is megy, de lassú host-ot nem. Ott mindent meg kell érteni. :)

Egy szenzort (ADC, gyorsulásmérő, giroszkóp, magnetométer, barométer, páratartalom, hőmérséklet, stb) nem bonyolult interfészeken csatlakoztatnak.
Kijelző sem Etherneten megy.

Az USB bejött, mint (felhasználó szempontjából) egyszerű "Plug and Play" típusú eszköz.
Valóban nem egyszerű, sőt... STM32F103-nak van egyébként device üzemmódja, de host-ként valóban nem tud működni, ez Mass Storage eszközre STM32F407 procival működik, talán az F2 sorozattól van host mód.

Az Ethernet használatához van olyan proci, ahol a MAC integrálva van, de PHY jellemzően még kell a lapra (USB-nél nem feltétlen), ill. vagy külön "trafó", vagy olyan aljzat, amibe a "trafó" integrálva van. Az Ethernet fogyasztása "nem kifejezetten alacsony" a többi lehetőséghez képest, ill. a protokollt ott is implementálni kell (LwIP egy lehetőség rá)...

Az a bajom, hogy már nem fér el az asztalomon a 2400 baudos modem, amin a SLIP protokollt megvalósítom. Abban egyetértek, hogy a TCP/IP a király. ;)

Nem ártana valami tankönyvet szerezni, elolvasni, megérteni, majd egy kicsit gondolkozni, mielőtt megszólalsz. Rendbe kéne rakni a fejedben a hardver, a protokoll, a fizikai réteg, stb. fogalmakat. Akkor aztán majd jól tudsz beszélgetni róluk.
Persze az sem ártana, ha olvasgatnál még egy kicsit. Aztán azt is megértenéd, hogy mit miért mire használnak.

Ha úgy tetszik, az alapfogalmakon kívül még létezik rengeteg tervezési szempont is. Mert ha nem így lenne, akkor két pont között a legrövidebb út a tengeralattjáró. :-D

"Ebből meg levonod, hogy én nem csinálom jól."

Bocsánat, de te vontad le a következtetést, hogy mindenki balfasz, akinek 128 kB a binárisa.

Erre bátorkodtam írni, hogy többek között egy ESP32 bináris majdnem 1 MB. Innen jött az, hogy de az sokba kerül, aztán amikor kiderült, hogy nem kerül sokba, akkor jöttél azzal, hogy neked már kész PCB és perifériák vannak, ahhoz kellene illeszteni, pedig a kutya nem beszélt arról, hogy neked kellene cserélni, hanem arról volt szó, hogy egyszerűen vannak olyan feladatok, amire az ESP32 sokkal jobb, cserébe 1MB a bináris.

De azt már régről tudjuk, hogy szerinted rajtad kívül mindenki balfasz.

--
https://iotguru.live

Bocsánat, de te vontad le a következtetést, hogy mindenki balfasz, akinek 128 kB a binárisa.

1. A balfasz nem az én szóhasználatom.
2. Semmi ilyen következtetést nem vontam le. Figyeld csak, miket állíottam!
- Termelékeny szoftveres lehetsz, ha naponta 128k friss programot írsz! :-D
No ezt nem értette senki. :-)
Elmagyaráztam:
- Nem hinném, hogy a 10 tesztelt sor 128k lenne.
Hacsak nem spagetti kódot írsz, bizonyára fel lehet osztani a programot funkcionális blokkokra.
A megváltozott blokkot a másodperc töredéke alatt ki lehet írni.
Sokkal gyorsabban, mint amennyi idő alatt weben megérkezik egy egérkattintás. ;)
3. Értő olvasással kevésbé tűnne fel az érelem nélküli aggresszivitásod.

Akkor is ennyi, ha átírsz egy karaktert és senki nem szórakozik azzal, hogy a régi és az új bináris közötti különbségeket küldje át, átküldi az egészet egyben.
Ezek szerint ez nem fontos. Akkor meg így jártunk, de nem kell nyafizni, meg nem is az i2c hibája. Ehhez meg már gondolkozni is kéne.

Ettől még sok dologra jó az ESP32, sok dologra meg nem.
Aham, onnan indultunk, hogy vannak bőven olcsóbbnál-olcsóbb eszközök, ahol a bináris bőven több, mint 128 kBájt
Ez sem az én problémám és nem az i2c sara. Borzasztó drága ipari eszközökben van i2c, az olcsó cuccokban meg nincs. Tán még összefüggés sincs. :-)

A 8 bites procikon egy utasítás hossza 1-4 byte lehet általában. A 32 bites procikon egy utasítás hossza 4-8 byte lehet.

A programod ESP8266-on 2x annyi, mint Atmega328P-n, de tök mindegy, mert a memóriád meg 20x annyi legalább (1MB vs 32k).

Egyedül a frissítésnél lehet gond, hogy I2C-n nem győzöd kivárni a végét. Mondjuk Nodemcu-n az UART-ot fel is szokta tolni a nép 921600 baudra.

RS-485 esetén ez 500m maximális kábelhosszt jelent.

:)

Látom, már megint sikerül téves félinformációkkal osztani az észt. :)

A 8 bites procikon egy utasítás hossza 1-4 byte lehet általában.
Tényleg, a 80-as években igy is volt.
Manapság meg jobbára 16 bites az opcode a 8 biteseken. Legalábbis az Atmega328P ilyen.
Ebből az utasításszóból tartozik 1-2-3 db egy utasításhoz, de tipikusan 1.

Mellékesen a PIC platformon léteznek ennél kisebbek is. Ezeknél az opcode 10-12-14-16 bites lehet. A legnagyobb típusválaszték és a legfrissebb fejlesztések 14 bitesek. Itt a beépített speciális perifériák milyensége és darabszáma a döntő. Ezeket a perifériákat néhány utasítással üzembe lehet helyezni, összekapcsolni és kezelni. A hardver meg teszi a dolgát.

A kutya sem térne át fejlettebb processzorra, ha a extra tudása a szélesebb adatbusz, nagyobb kezelhető memória és a kicsit nagyobb sebességben kimerülne. Már a 16 bites eszközök is jóval fejlettebb utasításkészlettel rendelkeznek. Előfordulhat, hogy 3-4 utasítással jó néhány oldal 8 bites programot lehet helyettesíteni. Ha van cryptoengine, akkor csak használni kell, míg az aes256 8 biten 2,5kB kódot fogyaszt. Tehát egy magasabb bitszámú processzor általában rövidebb kódot eredményez.

Egy ESP-nek meg nagyobb a kódja, mert magasszintű nyelven programozod, tcp és wifi is van benne, no meg a framework is nagy méretű. Ráadásul nincs is kigyomlálva - ahogy írta valaki.

Az i2c meg csak egy kérdést vet fel: Miközben arról írtam, hogy egyszerű periféria és hosszú vezeték esetén érdemes csökkenteni a sebességet - ki a rosseb mondta, hogy ezen keresztül programozd? Már, ha türelmetlen vagy. ;)

És melyik az egy bájtos utasítás? ;)
A 2 vagy 4 bájt az megállja a helyét.

De ez mindegy, mert a több bites processzoron általában rövidebb a kód. Azért általában, mert pl a NOP az nem. :)
A kód méretének a növekedését pont azok a tényezők okozzák, amit leírtam.
Vagyis tévedtél.

A 8 bites procikon egy utasítás hossza 1-4 byte lehet általában. A 32 bites procikon egy utasítás hossza 4-8 byte lehet.
A programod ESP8266-on 2x annyi, mint Atmega328P-n...
Aha, akkor ez itt Z80, csak rosszul olvastam. ;)
Pedig programoztam már Z80-at több mint 30 éve. Akkor is fejlesztőmérnök voltam, meg most is az vagyok. Éppen ezért először az adatlapot olvasom el, és nem városi legendákat terjesztek a tévhiteimről. Az adatlapok egész pontosan definiálnak egy-egy eszközt, bárki elolvashatja. Még Te is. A műszaki világ már csak ilyen.

> ki a rosseb mondta, hogy ezen keresztül programozd?

Ez a gondom az I2C-vel:
- mindenre jó, csak felprogramozásra nem
- mindenre jó, csak 2m-nél hosszabb kábelre nem
- mindenre jó, csak a terepasztal zajos környezetére nem
- mindenre jó, csak multimesterre nem (legalábbis legtöbb esetben a hardver nem működik)
- mindenre jó, de a legjobb, ha alacsony sebességen használod

Tudod, én szado-mazo vagyok és inkább 921600 baudos RS-485-ös rendszerre váltok, árnyékolt UTP kábelekkel. Szeretek szenvedni.

Az I2C alapvetően nem nagy távolságokra lett kitalálva.
Normális körülmények között nem bontható, NYÁK-on belüli kapcsolatra ideális, ha nincs szükség nagy átviteli sebességre.

Távolságok áthidalására, két rendszer közötti kapcsolatra vannak sokkal jobb megoldások.

Arra kell használni, amire való. :)

És nem nagy sebességre. A topik elvileg arról szólt, hogy egy 40x2-es LCD-hez lehet-e hosszú kábelt alkalmazni I2C-hez.

A 40x2-es LCD az a kategória, ami még simán megy I2C-vel, de alapjáraton az LCD-ket SPI-n, vagy párhuzamosan érdemes tolni.

I2C: 128x64 monochrome LCD (25 kHz órajel kell 25 fps-hez)
SPI: 320x200 24 bites színes LCD (5 MHz órajel kell 25 fps-hez)
felette párhuzamos átvitel kell.

Első tévedés: az i2c mindenre jó
Az i2c busz eredetileg ajálott hossza 10cm. (azaz 0,1m)
Az i2c alapvetően egy protokoll. Ha kábelt kell meghajtani, azt tetszőleges hardverrel teheted. (Persze az elektronika szabályai szerint. Így pl. egy ventillátor nem tud meghajtani i2c protokollal egy kábelt.;))
Két méternél hosszabb kábelre ugyan nem jó, ezért itt egy 3m-es, 1MHz-es i2c meghajtó, amit pl. HDMI kábelekhez ajánlanak. Ha középről hajtod, akkor az már 6m. ;) Ilyennel terveztem a kisvasútnál jóval nagyobb zajú környezetre 5m-es meghajtót. Igaz, azt 400kHz fölött nem ajánlanám.
A multmasterhez hardver támogatás kell. Megoldhatod szoftverrel is, de az önhibádon kívül téveszthet.
A sebessége tényleg nem lehet túl nagy. De már ebben is tévedtél egyet, szóval úgy sem értenéd. ;) Van sokkal gyorsab és szintén illesztetlen soros busz, az usb. Haonlóan az i2c-hez, ott is korlátozott a maximális kábelhossz. (5m - USB 2.0) Növelheted a hosszt, de akkor a sebességet kell csökkentened. Ilyen a lezáratlan kábel.
Az i2c-t átviheted rs485 hardveren, és akkor nőhet a hossz, mert az egy illesztett meghajtás.
Ha nem értesz hozzá, akkor nem barátod. ;)

Mindenképpen jó, ha van hardver támogatás a multimasterhez.

Kb. két hetem ment el Atmega328P alatt multimasterrel, míg beláttam, hogy a hardver támogatás csak elméleti.

Nem voltam képes terhelt buszon 10.000 tranzakciót sem átnyomni, mert folyamatosan elhasalt (annyi volt a kód, hogy random küldenek egymásnak). Kb. 4 különféle hardverhibát találtam meg, azokat megpróbáltam orvosolni, de a 5.-nél feladtam.

A hardver támogatás pusztán elméleti Atmega alatt. A neten programot sem találsz, amelyik használná, gondolom nem véletlenül. Azt írják, hogy STM32 alatt is vannak bugok, a PIC-eket nem használom, azokat nem ismerem.

Ebben abszolút igazad van: Az i2c bonyolult (lehet) és bizony korlátozott a sebessége.
A legtöbb gyártó meg az "alap" protokollt valósítja meg, de a szabvány szerint opcionális dolgokat meg nem. Ez tökéletesen elég arra, hogy a single master szenzorokat olvasgasson, kijelzőt írjon. Még az rpi i2c sem sem tud mindent, vagy csak nem írták meg.
Szerencsére a PIC szinte tökéletes implementációval rendelkezik. Van hardver a bus collision detektálására külön interrupttal. A busz műveleteknél is konfigurálhatod, hogy egy egy bájt, vagy a busz tranzakció egyes elemeihez rendeled az interruptot. Az előbbi az az egyszerű megvalósítás, az utóbbival meg bármit meg lehet tenni. Erre PIC18-tól már van magas prioritású interrupt is. Ekkor az apró szeletekben programozott protokoll minimális futásidőt fogyaszt.
Sajnos vannak bugos verziók, de azt 90%-ban el lehet olvasni.

A fő bajom az I2C-vel, hogy nehéz pufferelni. Minden egyes átküldött bájt esetén külön nézni kell, hogy mi az ábra.

USART-hoz még interrupt sem kell. Körkörös DMA pufferbe töltöm az adatokat, amikor meg épp ráérek feldolgozom.

Írtam STM32-es oszcilloszkópot:
- ADC-vel DMA-val mintavételez
- eközben USB-vel max. 800 kbyte/s-cel nyomtam át mintavételeket
- eközben kirajzolom LCD-re, hogy mennyi bájtot toltam át DMA-val
- a proci meg jóformán semmit sem csinál

Azért képes az egész így működni, mert nem kell minden egyes átküldött bájtot végig kísérni. Ott a hardver DMA, az megcsinálja. Te csak felprogramozod a regisztereket, minden megy magától.

Nálam nagyon nem jön be, amikor minden egyes idióta bájtnál azt bámulod, hogy épp sikerült-e, vagy sem. Baromi erőforrás igényes. I2C esetén nem tehetsz mást. Ilyen a protokoll.

Így igaz, az i2c nyugtáz és azt teheti bonyolult módon is, amit el kell olvasnod. Az egyszerű "két drótos" usart meg semmi ilyet nem tud, ezért lehet rá dma-t kötni. Ez nem hiány, hanem egyszerűen más a tipikus felhasználása.

Az oszcilloszkóp gyönyörű példája annak, amit a szoftveresek soha nem fognak megérteni. ;)
Beállítod a hardvert, ami utána teszi a dolgát. Na erre írjál unit tesztet!

Az i2c-hez nem kell különösebb erőforrás, ha assemblerben programozod. :-D
Kellett már néhány fajta eszközt programoznom. Különösen a szabványtól kicsit eltérő kínai csodák jelentettek kihívást. ;) Ezért nem lib-et hoztam létre.
Az adatlapból kigyűjtöm az egyes funkciókat, majd "tokenizálom". Egy eszköz egy művelete - pl. egy eeprom blokk írás - egy token sorozat. Ebben pl. van olyan token, ami visszalép az előzőre, miközben csökkenti a blokk számlálóját. A pointerek megadásával meghívom a token sorozat start condition elemét, és a többit intézi az interrupt. Az elején beáll az i2c_active, és törlődik, ha elfogytak a tokenek. Persze kell hozzá egy ugrótábla is.
Ezzel a módszerrel villámgyorsan össze lehet rakni bármit, még a nem std műveleteket is.

Elképesztő, hogy ez az ártalmatlan bejegyzés mekkora hullámokat vetett.
Tény, hogy a mai számítástechnikai kapacitásokkal, nagy megbízhatósággal lehet szimulálni/emulálni szinte bármilyen folyamatot. Azonban mégis vannak repülőgép katasztrófák amit a hibás szoftver számlájára írtak (ezzel mindig az a bajom, hogy túl egyszerű a szoftverre fogni mindent, de ez messzire vezet).
A lényeg hogy szeretjük a kisvasutakat.

Amiről még alig esett szó az a "Power Line Communication" - azaz pl a síneken is lehet kommunikálni, csak MODEM kell hozzá (pl. a régi telefon/FAX modem kártyákon lévő Conexant csipekkel/kártyákkal olcsón megoldható és helyből védett akár 50V -ig, illetve egy érpár és duplex, mindezt úgy hogy az illesztés megint csak aszinkron soros 8250 szerű).

A legjobb elgondolásnak mégis a szakaszolás + áram mérést tekintem. Hasonló lehet még a HALL elem, vagy optocsatoló alkalmazása is, de ezek sokkal kevésbé zavar tűrők.

* Én egy indián vagyok. Minden indián hazudik.

( Csab | 2019. 10. 05., szo – 19:39 )

Egy kis Arduino:

Szóval beraktam az Atmega328P-t a hűtőszekrénybe, hogy nézze, hogy rendesen hűt-e.

OLED LCD, DHT22 szenzor, Atmega328P és 4 óra hűtőszekrény 7 és 9 fok között mért.
Páratartalom: 98%

A cucc működött is, mindaddig amíg ki nem vettem. Utána kifagyott és nem indult el többé.
Annyira nem indult el, hogy újra föl kellett tölteni a programot, csak utána ment újra.

A chipnek elvileg -40 fokot is bírnia kellene. Hogyan felejthette el a programot, ha igazából csak hűtőszekrényezés volt?

És belemászik a pára a flash-be és felülírja. Bocs, de nem általános iskolai tananyag. Mi köze a párának a flash-hez?

A cucc 2 db 1.2V-os elemről működik, amit felpumpálok 5V-ra (DC-DC konverter).

Az interneten olyasmit írnak, hogy túlfeszültségtől alakulhat ki memóriavesztés, amit valószínűleg a DC-DC konverterre kicsapódó pára okozhatott. Kicsit megpumpálta a tápfeszt, amitől az IC amnéziát kapott. Jelenleg ezt gondolom.

A pára okozta. Valószínűleg a táp visszacsatolásában mászott el a feszültségosztó osztási aránya, aztán specifikáción kívüli tápfeszültsége lett, csoda, hogy túlélte. Ha nem on chip RC-oszcillátort használsz, az órajel is leállhat ugyanezen oknál fogva.

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