RPi + Arduino UNO + DHT22

Elektronika, Elektromos eszközök

Üdv!
Egy tárgybeli dolgot próbálnám ki (teszt): RPi3 <---> Arduino <---> DHT22
Tehát az RPi küld egy kérést az Arduino felé, ami a DHT22-vel mér és visszaadja az RPi-nek mérés eredményét.

A DHT22 kezelése Arduino-val működik. :)

Az RPi mivel kommunikáljon az Arduino-val? GPIO,SPI,I2C?
Ezeket nézegettem pl.:
RPi I2C (SPI)
Arduino I2C Wire Library
Arduino I2C MasterRead
Arduino I2C MasterWrite

Az elegáns megoldás - a korábbi téma alapján - az I2C lenne?

Vagy ha az egyik GPIO-val az RPi küld egy HIGH-ot az Arduino felé, amit figyelve az Arduino mér a DHT-vel és a GPIO-n küldi vissza az eredményt. Ez nem szép megoldás gondolom.

(upd.: 2016-12-22)

+1

Az az oldal nekem nem tetszik. Nincs kapcsolási rajz részlet, hanem valami sematikus izé, hogy ezt ide kösd, azt meg oda. Mi ez a műszaki igénytelenség? Beszélnek szint illesztésről. Én például nem látok néhány dolgot.

1) Az Arduino mindenképp +5 V-ról jár? Gondolom, az R-Pi GPIO-ja 3.3 V-os.
2) Amennyiben az Arduino +5 V-ról megy, úgy a bemenete TTL kompatibilis, tehát bemeneten 2 V már magas szint?
3) Tegyük fel, hogy igen. Ebben az esetben 3.3 V-ra kell húzni az SCL és SDA vonalakat. Ezt melyik oldal teszi meg? Ha egyik sem, akkor azért csak jó volna két darab ellenállás oda.
4) Bízhatunk-e magunkban, hogy nem követünk el programozási hibát, s az 5 V-os eszköz felől nem hajtjuk meg 5 V-tal a 3.3 V-os bemenetet? Ha nem, akkor tényleg jó volna valamiféle szintillesztés.

Valamiért az az érzésem, hogy ez az eszközök részéről nem hardware-ből támogatott I2C, hanem software-ből rakták össze. Ami nem baj, csak gondolom.

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

Arduinós körökben bevált szokás, hogy Fritzing ábrákban mutatják meg, mit és hova kell kötni. Nyilván nem egy kapcsolási rajz, de egy kezdőnek sokkal érthetőbb.
Arduino-RPi I²C kapcsolatban _mindig_ az RPi-nek kell felhúznia a vonalakat, különben ropogósra sül. És teljesen igazad van, sokkal biztonságosabb egy filléres szintillesztőt, vagy legalább két ellenállást betenni feszültségosztónak, mint közvetlen összekötni. Ettől függetlenül működik, csak hát izé...

Ave, Saabi.

Arduinós körökben bevált szokás, hogy Fritzing ábrákban mutatják meg...
Hát persze. Láttam már olyan kőművest, akinek a nyakában tablet lógott. Színes nagyfelbontású képen oda volt neki rajzolva a tégla, a malter, stb. :-) Ugye milyen marhaság?
Sajnos minden műszaki területnek létezik műszaki rajz szabványa. Ez arra való, hogy egy másik (szak-)ember számára egyértelműen átadhasd a szerkezet tulajdonságait. Ha kizárólag breadboard van egy ábrán, az kb. az emberek 100 százalékának érthetetlen. Pontosan ezért rossz és használhatatlan.

A műszaki rajz is egy absztrakció. Ennek hiányában a kezdő odáig fajulhat, hogy képtelen összerakni egy kapcsolást, ha elfogyott a piros drótja. Ez azért tragédia dalban! ;)

Az megvan, hogy az Arduino oktatási célból készült? Hogy azért olyan, amilyen, hogy laikusok is könnyen használják? Például azért van rajta USB port, mert egy mai, átlagos számítógépen már nagyítóval sem találsz soros portot?
Egy tizenéves gyereket igen hatásosan el tudnál üldözni a mérnöki tudományok mellől a fenti dumával. Persze, létezik kapcsolási rajz, meg minden. De amikor azt próbálod meg megmutatni egy gyerkőcnek, hogy milyen cool ahogy ráköti a LED-et az Arduinóra és megírja hozzá azt az egyszerű programot és ebből hogyan csinálhat forgalomirányító lámpát, akkor nem jössz kapcsolási rajzzal meg Ohm törvénnyel, hanem veszel egy Fritzing ábrát, az alapján összekötöd a breadboardon a cuccokat, ahogy az ábra mutatja és örülsz. Közben reméled, hogy a gyerek is örül.
A Fritzing ábrák beültetési és kábelezési rajzok. Azt a célt szolgálják, hogy egy kezdőnek könnyebben legyen sikerélménye. Nyilván ipari felhasználásra szánt eszközöket nem ilyen módon terveznek meg.

Ave, Saabi.

Oktatási célból, hogy a laikusok is könnyen használják? :-)
Ilyen indokkal hibás szintillesztést publikálni? (Az osztó nem jó ötlet.)
Inkább nem is mondok semmit.

A gyerek meg örül - kicsit dramatizálva.
Egyszer egy profi orosz polgári pilóta családja is a gépen utazott. Az hosszú és unalmas úton a kisfiát beleültette a saját helyére. A gyerek örült. Aztán megmozdította a kormányt, a robotpilóta kikapcsolt, a gép lezuhant. Mindenki meghalt. Utána senki sem örült.
Bár korábban a gyereknek volt sikerélménye.

Igaz, ez egy kicsit offtopic volt egy olyan post-trióban, amikor egy alkalmatlan szenzort sikerül a legbonyolultabban és hibásan illeszteni. Ebből a laikus nem okul semmit. A sikerélmény meg egyénenkén változó. Van aki a hibásan elvégzett munkának is tud örülni.

Szerintem oktatási célból _is_ és laikusoknak _is_ készült. Kb. mint a pi, nyilván a legtöbb feladatra van tőle alkalmasabb uC/SoC, de ez elterjedt, támogatott, és olcsó. Van hozzá rengeteg kész modul, amivel egy amatőr különösebb elektronikai tudás nélkül is össze tud legózni valamit.

De jó hasonlatot találtam, tényleg, mint a legó. Ugye az is mennyire izé már, hogy valaki készen vett és egymáshoz jól illeszkedő legóelemekből épít valamit, amikor az igazi út az lenne, ha maga eszergálná és marná ki az elemeket, netán a munkahelyén egy fröccsöntő gépen csinálná meg magának egyedileg. Valahogy ezt érzem a kommentjeidben (és locsemege kommentjeiben szintén).

Ez nyilván nem mentség a hibás szintillesztésre. (Az osztó csak soros kapcsolatnál lenne jó megoldás, ahol az arduino 5V-os TX lábát egy osztóval lehet a pi-re illeszteni, a pi 3v3 TX szintje elvileg az arduino RX lábán is magasat jelent).

Az otthoni szórakozást pedig ne keverjük már a légiközlekedéssel és egyéb veszélyes üzemekkel.

Egyetértek veled, ideértve a velem kapcsolatos megjegyzésedet is. :) Ez azért van, mert nekem szakmám az elektronika, így természetes dolognak tartom, hogy ha valamire szükségem van, azt megtervezem, megépítem, programot írok rá - „nyilván” assembly-ben. Ezek a ma kapható építőkockák, mint amilyen az Arduino, lényegében az ingerküszöbömet sem érték el, mert jobbnak tartom a konkrét feladathoz tervezett hardware-t, mint valami általános dologból kissé redundánsan összelapátolni valamit.

Tegyük hozzá, ez tényleg azért van így, mert ehhez értek. Ha programozó lennék, s meg szeretnék csinálni egy ilyen projectet, valószínűleg én is a félkész eszközökhöz, modulokhoz fordulnék segítségül. Vigasztalja a programozókat az a tudat, hogy én viszont programozni nem tudok, legalább is magas szinten nem, tehát a hardware-től elvonatkoztatott rétegekben, objektum-orientáltan. Mikrokontrollert assembly-ben viszont bármikor. :)

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

Sajnos ez a hasonlat pocsék. Inkább legóból, fémépítőből és selyempapirból mosógép készítéséhez hasonlítanak ezek a megoldások.
Egy uC nem lesz más akár ráforrasztották valamire, akár nem. Egy szakember ezt látja, az amatőr meg nem. A lényeget tekintve gyakorlatilag külső alkatrész nélkül meg lehet oldani vele a feladatot. Általában bármelyik uC rendelkezik ingyenes fejlesztőrendszerrel.
A kommentjeinkben inkább az érződik, hogy optimálisan meg tudjuk oldani a feladatot. Hidd el, egy amatőrhöz képest számomra sokkal fontosabb, hogy
- olcsó legyen amit fejlesztek
- ki tudjam fejleszteni és ne kelljen fórumozni mert képtelen vagyok megoldani
- természetesen ehhez működő fejlesztőrendszer is kell
- az utóbbi kettőből következően rövid legyen a fejlesztési idő

Persze van hozzá rengeteg kész modul. Itt meg teljesen másról van szó, mivel két különböző rendszert kell illeszteni. Ezt a specifikáció nélkül még a szakember sem tudja megoldani. A piros, kék és zöld drótokból csak azt tudjuk, hogy melyiket kell elvágni. ;)
Oktatási célból sem szerencsés, ha lövésed sincs a modulokról, csak legózol. Helyette inkább a feladatot kellene megfogalmazni.
A feladat:
- adott egy szerkezet, ami egy start bit után 40 biten kitolja az adatokat
- a 0/1 értékeket két különböző impulzushosszal ábrázolja
- a fentieket kell egy olyan rendszerhez illeszteni, aminek a reakcióideje kisebb mint az impulzusok hossza
- ne kelljen kernel drivert írni
- tápfeszültség 3,3V

A lehetséges megoldások:
1. Választok olyan hőmérőt amihez van működő kernel driver. Pl. 1-Wire, vagy i2c extrém alacsony órajellel és árnyékolt kábellel. Nincs járulékos hardver.
2. Letöltöm a kernel drivert és lefordítom. Nincs járulékos hardver.
3. Közbeiktatok egy 6 vagy 8 lábú uC-t, egy ellenállást és egy kondenzátort. Az rpi felé 1 vagy 2 vezetékes kapcsolat, ami időfüggetlen. Az egész kb. 50-60 sor asm. Az áramkör mérete kicsi, így a teszt verzió véglegesíthető. Megemlítem, hogy ehhez sem kell több elektronikai tudás.

Vajon a 3 topic alapján
- sikerült-e a fenti feladatot megfogalmazni
- az elkészülő megoldás hw/sw szintje mennyivel egyszerűbb
- a megoldás mennyiben felel meg a feladatnak
- a fentieket segítették vagy hátráltatták a színes drótok

Az osztó/nem osztó kérdésben az a lényeg, hogy a helyes logikai szinteket kell biztosítani, azaz a zavarérzékenység nem nőhet meg. Az i2c busznál a felhúzó ellenállások a magas szintet passzívan állítják elő, ezért érzékeny a kapacitásokra. (Szemben a TTL vagy CMOS áramkörökkel, ahol a magas szint is aktív, és esetleg a kapacitásának gyors feltöltésére tervezték.) A helyes megoldást itt találod meg, méghozzá az i2c "feltalálójától". Ilyen áramkör kapható a boltban, ebay stb. A bolt is onnan veszi. ;)

Ilyen áramkör kapható

Úgy érted, hogy MOSFET? :) Azon tűnődöm, hogy noha ez a szebb, de akár még bipoláris tranzisztorral is megoldható, ha nagyon muszáj.

Egyébként bevallom, engem cseppet zavar az a dióda nyitófeszültség akkor, amikor az 5 V-os oldalon húzzák a vonalat GND-re. Bár nem kizárt, hogy a MOSFET hátrafelé is képes kinyitni, legfeljebb nem azonos paraméterekkel, mint rendesen. Tehát arról beszélek, amikor a gate 3.3 V-on van, a drain-t GND-re húzzák, a source-t pedig ellenállás cibálja felfelé. Nyilván dióda nyitófeszültségnél ott több nem lehet, de az a kérdés, kinyit-e a csatorna, s így kisebb lesz-e ott a feszültség.

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

Ilyen áramkör kapható. De azért a felvetés nem rossz. :)

Egyszer csak megunod: már megint nem olvasol. A MOSFET úgy működik, hogy ha a Vgs>Vgsth, akkor oda-vissza vezet, méghozzá az Rdson ellenállással. Az egyik irányban ez magától teljesül. A másik irányban a diódán keresztül kerül alacsony szintre a source. De! Ekkor a gate marad magas szinten (Vgs=3,3-1,4=1,7V), így megint csak kinyílik és az Rdson söntöli a diódát. Éppen ezért ide mondjuk egy BSS138 jó, amelynél a Vgsth<1,5V és Rdson néhány Ohm. Sőt, a dióda nyitófeszültsége is kb. 0,8V. Ez azért a (PIC) i2c Vil<=0,3xVdd, míg Vol+Vd=1,4V lehet, azaz nem jó. Bipoláris tranzisztort meg rosseb se használ manapság! A bázisa többet fogyaszt mint az mcu. ;)

Az ilyen áramköröktől kitör a frász. Azért, mert eladják szint illesztőként, de nagyon nem mindegy a konkrét megvalósítás. Például I2C esetében huzalozott VAGY kapcsolat van megvalósítva, bárki lehúzhatja a vonalat, de fel senki, csak az ellenállások. Ugyanakkor más a történet akkor, ha van egy kétirányú, tri-state busz, ahol a küldő irány mindig kis impedanciás, a fogadó mindig nagy, így valahonnan kell egy irány vezérlő jel is az illesztőhöz.

Ez máris két külön áramkör. Az, hogy „szint illesztő 5 V és 3.3 V között”, egy cseppet soványka specifikáció. Aztán, ha a Philips által megálmodott MOSFET-es valami, akkor a felhúzó ellenállások és a kapacitások miatt erősen korlátozott az adatátviteli sebesség. Ezt szintén jó volna tudatni a kedves felhasználóval.

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

Azért ekkora baj nincsen. Az említett fet 25-50pF kapacitású ami kisebb mint a 400pF megengedett kapacitás az i2c buszon, valamint 25ns lehet a kapcsolási ideje. Tehát rövid vezetékek, max. 100/400kHz vígan megy rajta. A Fritzing ábrán úgy is látod a képét! ;) Az 5MHz-es i2c buszt meg úgy sem lehet ezekkel a vacakokkal meghajtani. :)
Világos, a műszaki leírás nem teljesen komplett, de az ilyen kinézetű dolgokat mindig i2c illesztéshez használják.

Ha egy laikusról beszélünk, akit elkezdett érdekelni az egész, annak sokat segít egy színes-szagos ábra, amiben az látszik, hogy mit dugjon és hova. ( igen, más témában is alkalmaznak képeskönyveket oktatásra. Meg rengeteg mozgóképet ;-) )
Nyilván ez nem garantálja, hogy a rajz jó, de ilyet nem is állított senki. De egy kapcsolási rajz értelmezése már több, mint amit egy kezdőtől elvárhatsz.

Ave, Saabi.

"A kommentjeinkben inkább az érződik, hogy optimálisan meg tudjuk oldani a feladatot. Hidd el, egy amatőrhöz képest számomra sokkal fontosabb, hogy..."

Tudom hogy ezt Ti optimálisan meg tudjátok csinálni, és elismerem a tudásotokat.
Azt is tudom, hogy az amatőr pedig nem tudja, de - és most jön a lényeg - nem is akarja. Nem akarja, mert nem tudja és nem is akarja beletenni azt az 5-10-akárhány évet, amit Ti beletettek. Nem érdekli hogy optimális lesz-e, nem érdekli hogy olcsó lesz-e, az se nagyon érdekli hogy mennyi a fejlesztési idő. Ő csak szórakozik, neki az a lényeg hogy csináljon valamit ami működik (értsd jól). A cucc nem fog termelésbe menni, nincs semmiféle gazdasági megfontolás.

És azt is elhiszem, hogy a hozzáértőket zavarja ez a szakmai slendriánság, de evvan, el kell fogadni hogy másoknak mások a szempontjai.

"Persze van hozzá rengeteg kész modul. Itt meg teljesen másról van szó, mivel két különböző rendszert kell illeszteni. Ezt a specifikáció nélkül még a szakember sem tudja megoldani."

A szakember lehet hogy nem, de az amatőr simán. :)
Keres valamilyen 3v3-5V szintillesztőt (valszeg modult) és összerakja ezzel. Aztán jó eséllyel működni is fog, mert azt egy szakember arra tervezte.

"Oktatási célból sem szerencsés, ha lövésed sincs a modulokról, csak legózol. Helyette inkább a feladatot kellene megfogalmazni."

Az oktatási célt ne úgy értsd, hogy apu nekiáll 30 évesen legózni aztán a végén villamosmérnök lesz. Egy fenét, ha odaadnád neki az első féléves matekot vagy a fizikát akkor 10 perc alatt dobná a sarokba. Pedig az az alapja. Nem, felnőttként már max. annyi az oktatási cél, hogy ráragad valami, miközben sikerélménye van.
Fiatal korban más, ott simán meghozhatja a kedvét a sikerélmény, aztán később ebbe az irányba továbbtanulva lehet belőle jó szakember.

Éppen ez a kérdés, csak elfelejtettem konkrétan feltenni.
Ha egyszer oktatási célból és ráragad valami, akkor mi az oktatás tárgya és mi az a valami, ami ráragad??
Mert ha a neki az a lényeg hogy csináljon valamit ami működik (értsd jól) kijelentésedet megpróbálom értelmezni, akkor...
Csinál valamit - ez rendben van. Müködik - ez is rendben van(Példa: bedobok egy követ a szakadékba == repülőgép + sikerélmény.), viszont nem jól, csak azt hiszi.

Kifejtetted a legfontosabbat a feladat megfogalmazását:
Múúkoggy! /Uri Geller/
Viszont hiányzik egy peremfeltétel a topic nyitásánál: Ha értesz hozzá, akkor kuss!

Nézd, nem akarod megérteni amit írok, amit írunk. Nincs ezzel baj, csak így vitatkozni nincs értelme.
Te indulsz a saját kis világodból, ahol az elektronikával csak profik foglalkoznak (kivéve ugye az elődőd, akinek a műveiről már írtál többször), de legalábbis aki nekiáll ezzel foglalkozni az tutira profivá képzi magát.

A valóságban pedig egy fenét. És ez már bőven az arduino és a pi előtt is így volt, lásd ugye kit-ek, egységcsomagok. Pistike megveszi a kész nyákot az alkatrészekkel együtt (ezt ugye valaki hozzáértő megtervezte), otthon összeforrasztja, aztán örül magának. Esetleg utánaolvas és nekiáll módosítani, akár annak mélyebb ismerete nélkül hogy ha azt a kondit nagyobbra vagy kisebbre cseréli, akkor konkrétan milyen fizikai jelenségek is állnak a hatás mögött.

Annyi a különbség, hogy arduoino/pi környezetben a hw az csak része a történetnek, talán a kevésbé jelentős. Az csak egy IO eszköz, a hangsúlyos rész a közé tett sw-ben van. Ahol Pistike a saját igényeire tudja szabni, pl. nem úgy működik az áramkör hogy 40 másodpercig mutatja az időt, 10 másodpercig a dátumot és 10 másodpercig a hőmérsékletet, hanem 8-1-1 másodperc legyen. És nem kell hozzá neki pár év tanulás hozzá, hanem fogja az arduino-t, az i2c kijelzőt és az i2c rtc modult, értelemszerűen összeköti őket és a példaprogram módosításával eléri amit akar.
Vagy épp kihagyja az RTC-t és saját wifi router-éhez szinkronizál, vagy a frankfurti adóhoz vagy egy gps vevőhöz...

És ő ennek örül. Akár tetszik Neked akár nem.

Bizony, ez hivják mellébeszélésnek. Amit leírtál természetesen rendben van, hiszen én sem kezdtem másképp.

Valójában (Amit én nem akarok megérteni. :))) ez a thread ebből indult ki:
Az az oldal nekem nem tetszik. Nincs kapcsolási rajz részlet, hanem valami sematikus izé, hogy ezt ide kösd, azt meg oda. Mi ez a műszaki igénytelenség? Beszélnek szint illesztésről. Én például nem látok néhány dolgot. /locsemege/
Pontosan arról van szó, hogy kilépünk az általad leírt "nemérteksemmihez" álomvilágból. Van ilyen. Ekkor válik szükségessé egy olyan szakember közbeavatkozása - már ha meg akarjuk oldani a problémát - aki ért is valamihez.
A hasonló értetlenségre kicsit lejjeb ezt a választ adtam:
Nem akarod megérteni. Két profi is azt állítja, hogy NEM JÓ, HASZNÁLHATATLAN.
Ezek után miért tételezed fel, hogy az amatőr jobban meg fogja érteni amit a profik sem? Ha valaki ennyire kezdő, akkor egy ilyen ábra legfeljebb fokozza a zűrzavart, miközben nem segíti elő a megbízható reprodukálást.
Konkrétan ebben az esetban ez az ábra elégtelen, nem tartalmazza a szintillesztés korrekt megoldásához elegendő információt. Akár abszolút kezdő vagy, akár vérprofi ez az állítás igaz.
Nyilvánvalóan nem teszi az állítást hamissá a következő:
Arduinós körökben bevált szokás, hogy Fritzing ábrákban mutatják meg...

Sajnos a cikkben (amit már jóval korábban elolvastam, mivel én így szoktam meg :)) van ám egy link:
Effects of Varying I2C Pull-Up Resistors
Ez a cikk szörnyű, csak akadémikusok által értelmezhető információkat tartalmaz! ;)
Ráadásul datasheet-et is emleget! Itt a világ vége!
Vagy egy régi kolléga kijelentését idézve: "Elvtársak! Nincs más hátra, beledőlhetünk a jatagánunkba!"

Érzékelem a problémádat, de hidd el, nem éri meg ilyen keményen érvelni, ettől még nem fog megváltozni a világ. Engedd ezt el. Tudjuk, hogy amit sokan csinálnak legózva, nem üti meg azt a műszaki színvonalat, hogy az biztonságosan, stabilan működjön. Egy aknamező, mert épp a hozzánemértés okán egy rakás dologra nem gondolnak, amelyre szakember viszont igen. Például inicializálásnál az adatot lehet, érdemes előbb írni, mint az irányt meghatározó regisztert, nehogy egy kellemetlen tranziens legyen ott. Vagy a GND-k összekötése. Egy másik topikban úgy kötöttek be digitális potenciométert, mint a valódi mechanikust, mintha az valami galvanikusan leválasztott dolog volna, s mintha a lábai közötti feszültségre, valamint a lábak, a GND és a tápfeszültség viszonyára semmilyen megkötés sem lenne.

Az is lehet, hogy valaki a Clamp-diódán nagyobb áramot folyat el a megengedettnél, de sohasem veszi ezt észre, mert mázlija van, s a parazita tirisztor nem gyújt be. Aztán lehet, hogy egyszer mégis, és csak azt tapasztalja, hogy nem működik az egész, tűz forró az IC, nem alakul ki rendesen a tápfeszültség... Megállapítja majd nagy bölcsességében, hogy biztos öreg volt az IC, kicseréli, és soha sem fog odáig eljutni, hogy ez tervezési hiba, működhetett volna az akár évtizedekig.

Nem állhat minden amatőr mellett egy szakember. Segíthetünk, ha kérdeznek, de minden rossz mozdulatuknál nem szólhatunk rájuk. Olyan ez, mint amikor valaki az otthonában mindent szigszalaggal javít meg. Ereszt a tömítés? Tekerjük be egy rakás szigszalaggal! Jó ugyan nem lesz, de már nem fog folyni, csak csöpögni, azt meg ki lehet bírni... :)

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

biztos öreg volt az IC
Erre mondják bearanyoztad a napomat! ;)
Emlegetett elődöm repertoárjában láttam: 3m árnyékolt kábel egyik végén aktív kimenetű optocsatoló (talán 300 Ohm előírt felhúzó ellenállással), a másik végén PIC, de direktbe. Pedig akkor már majdnem 30 éve olvastam az ESD-ről, miszerint először csak átüt a gate, majd utána "korhad", végül tönkremegy. Igaz itt nem is ESD volt csak visszaverődés. Az optocsatoló fordulatot érzékelt, s ahogy telt az idő, egyre többször jelent meg felesleges impulzus. A végén úgy elkorhadt, hogy használhatatlan lett. Hát ez az az eset, amikor a clamping nem fogja meg a megengedettnél nagyobb áramot. Vagy nem elég gyorsan.

Néztem a digitális potenciométert. Az egy szokásos 0..100%, két diódás 555-ös kapcsolás. A pwm feszültség >=12V, amiből egy marhanagy áramgenerátor+zener állítja elő az 555 tápfeszültségét. Van esély rá, hogy ez >5V. Vajon merre folyhat az áram a potméteren? Ez a frappáns megoldás tipikusan a "legózás halála". Ehhez sem értek, ahhoz sem értek, osztán még bele is nyúlok. De a lényeg: raspályon mennyen pörlben!
Először azt néztem volna meg, hogy a motor milyen frekvenciát bír el. Utána meghívnám a taxis barátomat a CB rádiójával. ;) Szóval néhéz finoman hozzáállni ezekhez a dolgokhoz. A főnökömnek is elmagyaráztam a 200A/100kHz pwm árnyékoló dobozba szerelésének okát : Hogy le ne tartóztassanak! :-)
(A jellemző lengési frekvencia 21MHz körül, sajnos precízen számítható az alkatrészek paramétereiből!)

Az egész jelenség felfogható mint a Dunning–Kruger hatás eredménye. Ráadásul nem is a saját tudás túlbecsüléséről van szó, hanem inkább a minimális ismeret befogadásának dacos taszításáról. A taszítóerő a tanácsadó szakképzettségével exponenciális arányban nő. ;) Ez aztán megérett egy újabb kutatásra!

<sarcasm>
Hát igen, én is minden elektronikai alkatrész megvásárlását minimum villamosmérnöki BSc-hez de inkább MSc-hez kötném, és igazaból azt sem értem hogy a viharba lehet billentyűzet közelébe engedni bárkit mérnök-informatikus végzettseég nélkül. Még a végén önképzéssel elsajátítja jó részét annak amiért mások éveket gürcöltek valami állami műintézményben, és oda a méregdrága elefántcsonttorony.
</sarcasm>

Érti ugyan az ember a szarkazmust, de azt is látni kell, hogy hajmeresztő az, amit egyesek elkövetnek elektronikákkal kapcsolatban, szinte fáj látni. Épp, mint a részeg ember. Ha mázlija van, nem üti el semmi, nem töri el semmijét, noha erre többször is minden esélye, lehetősége megvolt, majdnem be is következett, aztán ha nem lett baj, még visszaigazolva is látja, hogy lám-lám, lehet így is csinálni, nem veszélyes ez, mert hiszen látjátok, semmi bajom sem lett.

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

<való világ>
Sajnos nekem csak egy általános gépész üzemmérnöki diplomám van (1983). :(
Első állásom a Videoton Fejlesztési Intézet volt, ahol (villamos) hardverfejlesztőként dolgoztam.
Állandóan cseszegettek a szakirányú végzettség hiánya miatt, igy csakazértis (gépész) gyártmánytervezőként voltam állományban.
Többek között részt vettem a Videoton lézernyomtató első és második verziójának fejlesztésében. Rossz nyelvek szerint a második verziót jelentő továbbfejlesztés >90%-át én végeztem. (Analóg és digitális hardver és mikroprogramozás, de az optikai részhez tartozó elektronika nem a mi asztalunk volt.)
Itt az utolsó munkám az egyetlen magyar fejlesztésű CDROM vezérlő volt - a nagyfrekvenciás dekóder kivételével én terveztem és programoztam.
(Az, hogy ezekből miért nem lett soha gyártmány más lapra tartozik.)
Jelenleg egy kis cégnél motordiagnosztikai műszereket fejlesztek, de szigorúan csak az elektronikai részt tervezem és programozom.
Beszélgetés a főnökömmel:
- Mondd már hogy működik a négyütemű motor?
- Ezt most hogy érted?
:)
</való világ>

Szóval mit értettél félre?
Vagy nem értek semmihez?
Gondolkozom: Talán a Dunának megyek. :(

Legalább annyit érdemes lenne észreveni, hogy egy kész, valóban működő áramkört utánépíteni nem ugyanaz, mint meglévő, egymással sokszor nem kompatibilis modulokból valamit összerakni minimális elektronikai alpaismeretek nélkül. Az első esetben lehet sikeres egy teljesen amatőr is, ha mindent pontosan úgy csinál, ahogy a leírásban van. A probléma ott kezdődik, ha azt hiszi, hogy az elektronika csak ennyiből áll. Ezt ide, azt oda, beletöltök egy kis szoftvert, adok neki villanyt, és már megy is.

Ha valaki éveket gürcöl egy állami műintézményben, ahogy írod, az azzal is jár (nem mindig, ez igaz), hogy ott valamit megtanul. Legalább az alapokat. Legalább azt, hogy hogyan kell hatékonyan tanulni. Innen kezdve egy teljesen új dolgot is viszonylag könnyen meg tud tanulni a szakterületén, mert megvannak hozzá az alapjai. Természetesen mást is meg tud tanulni, olyant is, amivel eddig nem foglalkozott, ha úgy áll hozzá, hogy előbb ott is elsajátítja az alapokat.

Ha valaki hobbiból csinál valamit, előbb-utóbb rájön, hogy akkor lesz több öröme benne, ha folyamatosan tanulja azt a szakmát, amit ő hobbiból űz. Ha valaki érdeklődő, ha valakit zavar, hogy nem tudja, hogy mit csinál, miközben épít valamit, hogy mi miért történik pl. egy áramkörben, akkor úgyis utána fog olvasni a dolgoknak. Először csak a "mit kössek, hova kössek" jellegű dolgokat, majd később egyre mélyebbre fog ásni. Ha valaki nem tudja ezen a területen, hogy mit csinál a didóda, a tranzisztor, a FET, a műveleti erősítő, ha nem néz utána a digitális áramköröknek, a mikroprocesszoroknak, a mikrovezérlőknek, ha nem tudja, mi az a totem pole kimenet és társai, akkor folyamatosan akadályokba fog ütközni.

Ha valaki önképzéssel elsajátítja azt, amit más valamilyen állami műintézményben tanult, az nem baj. Teljesen mindegy, hogy hol és mikor tanulsz, csak tanulj. Akár elektronikát, akár programozást, akár mindkettőt. Ettől függetlenül egy diplomát nem feltétlenül kell lenézni, főleg, ha tudás is társul hozzá :)

Azt azért megfigyeltem, hogy könnyebben jutnak eredményre a mikrovezérlőkkel azok, akik villamos- vagy gépészmérnök végzettséggel vágtak bele a programozásba, mint azok, akik programozóként végeztek.

Az utolsó mondatodra nagyon egyszerű a válasz. A szoftver annyira elvonatkoztatott valami, hogy akik a működést, mozgást és kritikus feladatokat kedvelik inkább foglalkoznak hardverrel - vagy lesznek taxisofőrök. ;) Egy adatbázis nem tud túlmelegedni, füstölni, eltörni.
Az is elég lényeges, hogy néha egy iparban dolgozó mérnöktől 5 perc alatt többet lehet tanulni, mint 5 év egyetem alatt.

Tán azért írtam mondatot, mert nem kérdés volt? ;) A válasz meg költői válasz!
Rosszul fejeztem ki magam, helyesen: "erre nagyon egyszerű a magyarázat...".
Természetesen írhatod, hogy a rosseb se kért magyarázatot... :D
Tán csak azért írtam, mert a +1 nem elég precíz megfogalmazása az egyetértésnek.
Megannyi rejtély! :)

+1 Én sajnos nem értek eleget az elektronikához, de szeretném képezni magam (hobbiból). Arduino-val 1-2 dolgot csináltam már, és annak ellenére, hogy nem értem még rendesen az elektronikát, nekem is fáj néha, hogy milyen példákat tesznek fel (pl szervo tápellátása az Arduino tápjáról, ami számszakilag egyértelműen nem ad elegendő áramot). És nagyon hiányzanak a szakmailag szabatos példák, amikből lehetne tanulni, de nem nagyon találom őket.

Ha programozós példákat nézek, azokról magam is el tudom dönteni, hogy gagyi-e vagy nem - mivel értek hozzá. De az elektronikáról nem, és ezért meg kellene becsülnünk azt, aki ért is hozzá, és a fáradtságot is veszi, hogy rámutasson, hogy mik a problémák.

Ha már van affinitásod két szám összeszorzásához, akkor jó úton haladsz! ;)
Az elektronika tanulását alapfokon az Ohm, Kirchhoff törványei és R-C-L tagokkal kapcsolatos számításokkal lehet elkezdeni. A következő fejezet az alapkapcsolások ismerete. A rutin pont olyan, mint amikor egy programozó ránézésre felismeri a for ciklust. A jól megrajzolt(!) kapcsolási rajzot könnyedén lehet olvasni. A dilettáns munka általában az értelmetlenül szétdobált részletekből látható. Pl. amikor nyomtatott áramkört terveztetek 8-10 szempont szerint egyeztetett "tolvajnyelven rajzolok". A végeredmény szinte kivétel nélkül tökéletes, mert aki tervezi villamosmérnök (bár aszongya már nem ért hozzá :), de az amatőrök által figyelembe se vett nagyfrekvenciás/nagyáramú/zavar/hidegítési/árnyékolási tulajdonságok szempontjából is minden a helyén van.

Digitális áramkörökhöz vagy adatátvitel vonalhoz a Texas TTL receptek (MK 1978) a tökéletes mű. Annak ellenére, hogy ma már nem is használnak TTL áramköröket meg wire-wrap kötéseket.

Alapirodalmat pl. a Texas-tól szoktam letölteni. A gyártók az egyes alkatrészekhez általában kiadnak Application Note vagy Reference Design típusú anyagokat részletes számításokkal. Általában érdemes tisztában lenne az alapáramkörökkel. Ha érdekel mondjuk egy teljes analóg kézikönyv akkor előkerítem. (Ezek mind online anyagok.)

A legfontosabb egy alkatrész alkalmazásakor az adatlap. Abban is megtalálható egy-egy áramkör alapbeállítása és méretezése. No, meg a bemenetek pontos kialakítása, határértékek, tápellátás, hidegítés stb. Ha idáig eljutsz, vigyorogni és hüledezni fogsz, hogy mitől működnek a breadboardon kialakított áramkörök! A másik rossz hír: a jobb alkatrészek java része csak felületszerelt kivitelben kapható. Persze nem kell mindent sajátkezűleg szerelni, de pl. egy modul vásárlása ebay-ről már sokkal jobban fog menni ránézésre is. Hiszen látod mi van rajta.

Néhány példa.
Ebben a topicban is szereplő i2c busz tulajdonságait (bár a thread tetején linkelt cikkben is van egy részletes magyarázatra mutató link) a legegyszerűbben úgy ismerheted meg, hogy a gyártótól (NXP==Philips) letöltöd az i2c specifikációt. Részletesen leírja a max/min felhúzóellenállás méretezését (van hozzá két grafikon is) és a megengedhető maximális kapacitást ill. az időzítéseket. Tehát nem kell az egészet megtanulni, hanem a kívánt információt kiszedni belőle.
Volt egy topic az usb kábel maximális hosszáról. Az usb szabvány leírja és elmagyarázza, de a QA-ban is szerepel. Az ehhez szükséges ismereteket a TTL receptekben is megtalálod, bár az usb jó 20 évvel később keletkezett. De egy vezeték régen is vezeték volt, a villany ugyanúgy közlekedik rajta: fénysebességgel.

No, remélem jól összezavartalak. ;)

a villany ugyanúgy közlekedik rajta: fénysebességgel.

Noha igaz, amit írtál, de a könnyű félreérthetőség miatt mondom, ez nem vákuumbeli fénysebesség, nem az a közel 3e8 m/s, hanem épp az adott közegre jellemző, mert a vonal permittivitása és permeabilitása - elsősorban az első - nem azonos a vákuuméval. Tehát jellemzően a vákuumbeli fénysebességnél lassabban, az adott közegre jellemző fénysebességgel.

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

Helyesbítek: a post-trió cserélendő topic-trióra! Így már több értelme van.
Eltekintve az orosz pilótától úgy érzem a megfutamodás rövid útját választottad. ;)
Ha ez neked hülyeség, akkor légyszíves válaszoljál a következő post utolsó előtti bekezdésében feltett kérdésekre. Nem kell a választ ideírnod, csak úgy magadnak.

Azért egy dologban igazuk van. Amikor valaki nem ért az elektronikához, keres olyan platformot, amelyen járni tanítják, ahol nagy a közösségi támogatás, ahol megdicsérik akkor is, amikor szakmai szemmel nézve félelmetes hülyeséget csinál. Mert tudjuk, vannak olyan esetek, hogy valami rossz, nagyon rossz, de épp működik. Legfeljebb egy hét múlva dobja fel a talpát, vagy zavarérzékeny, vagy bármi.

Könnyű neked vagy nekem, mert olyan áramkört tervezünk, amelyre szükségünk van. Pont olyat, nem redundánsat, de a feladatot tökéletesen ellátót.

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

Nem mondtam, hogy nincs igazuk, csak nem jó amit csinálnak. ;)
Talán szuperérzékeny vagyok erre a kérdéskörre. A főnököm szerint bármit csinálok az
- bonyi!
- nem kell a világ legpontosabb műszerét elkészíteni!
- minek hitelesíteni?
Persze a pontatlan áramkört is meg kell tervezni, tehát nem nyernék semmit.
Nem olyan régen a 8 éve gyártott szerkezetből összeraktak 20 darabot és mindegyik rosszul működött. A tűrés fölső határát súroló 78L05 sorozatot sikerült beépíteni. (Főnök: Nem is gondoltam, hogy ennyi mindent figyelembe kell venni!) Én a Dunába ugranék, ha ilyen dolog kerülne ki a kezem közül. Még akkor is, ha csak én tudok róla.

Nem is olyan könnyű. :(

off

Fentebb keresd meg egy hozzászólásodat, amelyben elszúrtál egy linket. Direkt nem válaszoltam rá, hogy ki tudd javítani. Az a hiba, hogy sehova sem mutat a link. Csak ennyi:

<a>Ilyen áramkör kapható.</a>

Ez a hozzászólás:

http://hup.hu/node/151163&comments_per_page=9999#comment-2051742

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

A hülyeséget a pilótás történetre értettem.
A többi meg a Fritzing ábrára szólt, nem a hiányzó feszültségszint-illesztőre. Arra én is azt mondtam, hogy tegyen be egyet.
De azt fenntartom, hogy aki ismerkedik az elektronikával, hamarabb él át sikerélményt, ha egy Fritzing ábra alapján összetákol egy áramkört, mintha kapna egy kapcsolási rajzot és egy öt kilós fóliánst benne a magyarázattal.

Ave, Saabi.

Ötkilós fóliáns? Ezzel úgy jártál, mint Tudor a Hófehérkében: Nem tudom mi az, de ellenzem!
Megkockáztatom, hogy a Fritzing ábrán még hatékonyan ábrázolható kapcsolások esetén a kapcsolási rajz roppant egyszerű. Egy mérnök meg nem azért készít kapcsolási rajzot, hogy kicsesszen a másikkal! :) A cél az egyszerűség és a közérthetőség. Ha egy ilyen rajzot kap a műszerész, sokkal hatákonyabban tudja elkészíteni vagy ellenőrizni az áramkört. Annak ellenére, hogy nem tudja mi az az áramkör, sem megtervezni, sem bemérérni nem fogja. Persze egy ilyen áramkör részletes magyarázata nem haladja meg az 1. oldalt.
Rájöttem min vitatkozunk. Ha ezt az "elektronikával ismerkedésnek" tartod, akkor én is fogok egyet hazudni. Ha beülök az autóba vagy csak megnézem messziről, akkor motortervezéssel ismerkedek! ;) Ellenvetés?

Ellenvetes:

Te professzionalisan, azon belul is igen maximalistakent tekinted a temat, mikozben valojaban a fritzing abra, arduino, esp8266, es hasonlo ordogtol valo dolgok nem annyira rosszak mint hiszed.
Szerintem ez inkabb azert faj neked, mert a kevesbe "szakerto" ember is osszetud pakolni orak alatt egy idojarasallomast, egyeb huncutsagot, ami amugy hosszu napok tervezese lenne szamodra, sok-sok buktatoval.
Ezeket a buktatokat masok mar leharcoltak helyetted, es kepzeld el, marha jol mukodnek mindenfele komoly hozzaertes nelkul.
En mindenfele elektronikai szakertes nelkul osszeraktam egy szinerzekelot, kesobb egy relative bonyolult robotot is...

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Igazad van, de nem jól látod a kérdést. Természetesen professzionálisan állok a dologhoz, hiszen ez a profession-öm. ;) Igaz, maximalista vagyok egy kicsit, de ez sem teljesen igaz. Nézd meg a "lelki problémámat". Elismerem, hogy egy laikus, a ma kapható cuccokból minimális ismeretekkel össze tud rakni valamit, ami ráadásul működni fog. Aztán jönnek a problémák és a fórumok és mindenki hülye, aki azt állitja, hogy nem jól csinálta. Mert neki működik! Azt is állíthatnád, hogy két pont között a közlekedés szabályainak ismerete nélkül is, gyorshajtva is el lehet jutni. Hiszen most se csípett el a rendőr! És igazad van ez egyszer! Vagy akár többször is.

Tehát amit én több napos erőfeszítéssel megtervezek, miközben a hobbista órák alatt végez vele, majd hetekig fórumozik... Azt állítod hogy irigykedek?! :-) Ha Te mondod!
Az erőfeszítést inkább az idő hiánya jelenti. Sokszor úgy kell megtervezenem egy áramkört, hogy nincs idő deszkamodellt vagy prototípust építeni. A tervezés után azonnal adom le nyomtatott áramkör tervezésre, ami alatt beszerzem az anyagokat. Utána azonnal megy a gyártás (5-10db), és az lesz a prototípus. A kezdeti méricskélés és programozás után indul a több darabos gyártás. 30 éve ehhez képest igan lazán mentek a dolgok.

A sok-sok buktatót sem tudom értelmezni. Hobbistaként vagy 40 éve tervezek áramköröket. Hivatásszerűen - mikrogépeket is - csak 33 éve. Egy új áramkör számomra csak egy feladat, amit meg kell oldani. Ehhez meg rendelkezem elegendő szaktudással, gyakorlattal és azzal a képességgel, hogy megszerezzem a hiányzó ismereteket.

Ne keverjük össze a Fritzing ábrát az Arduino-val. Elgondoltam, hogy egy áramkör gyártásánál egy Fritzing ábra szerű izével adnám meg a teendőket. Biztosan kardélre hánynának. :(

Ezeket a buktatokat masok mar leharcoltak helyetted, es kepzeld el, marha jol mukodnek mindenfele komoly hozzaertes nelkul.
Fussunk még egy kört! Azért találtam néhány olyan cuccot ami termék azaz gyártják és megveheted, ráadásul open source. A szakember pontos számításokat, oszcilloszkóp felvételt közöl. Apró kis szépséghibája a dolognak, hogy a felvételen látszik amint az igen gondosan tervezett tápegység kimenő feszültsége túllépi a megengedett értéket. A felhasználók java része szerencsésnek mondható, mert az egyes áramkörök néha bámulatosan "túlteljesítenek". A többiek meg valamilyen véletlennek tulajdonítják a dolgot. Pedig a tervezési leírás olyan szakszerűnek tűnik, hogy minden bizonnyal gyorsan lapoznál. ;)
Ezek azok a dolgok, amiket a hobbisták megtehetnek. Nyilvánvalóan soha sem kerül sor komolyabb reklamációra. Ugyanakkor az amatőr szerkezetet (ez egy PIC programzó) termelésben ritkán fogják használni, tehát senkinek sem tűnik fel.
Az amatőrnél akár 10 esetből 10x működik valami és ez nagyon jó eredmény!
Ha egy termékről beszélünk, akkor nem jó dolog az olyan véletlen, amikor 100 esetből véletlenül csak 10 példány működik és 90 nem működik. Szóval a véleményed ellenére nem érzem magam bűnösnek, amikor próbálok információt átadni az utóbbi eset megelőzésére. Még akkor sem, ha ez sokak számára feleslegesnek tűnik.

Sok mindenben igazad van, egy dolog felett siklasz at:

Ez egy hobbi :)
Es jellemzoen az embereknek az idobol van a legkevesebb.
Ha mindent 0-rol kellene osszerakni(mint regebben), szerintem ezredannyi embert sem erdekelne ez az egesz.
Es ezert az arduinonak es rpinek, es tarsainak hatalmas josaga van, hogy normal halando emberek is nekiallnak butykolni a szabad 10 percukben.
Ha ezek nem lennenek, joval kevesebb ember foglalkozna, probalgatna, es fejlodne az egesz.
Mert szerintem minel szelesebb korben jut el valami, annal gyorsabban fejlodik.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Ha mindent 0-rol kellene osszerakni
Egy mcu-n nincs mit összerakni. Régen bizony sok-sok áramkörrel sem lehetet volna ugyanazt elérni.

Tényleg elsiklottam valami felett! Nem gondoltam volna, hogy a hobbi==nem értek hozzá. (Eddig aszittem szabadidős elfoglaltság.)
Szóval hivatásos sofőrként balesetmentesen kell vezetni, míg az amatőr nekimegy minden fának. A hobbikertésznek kipusztul minden növénye az össze-vissza elültetett ágyásokban. A hobbiszakács nyers, égett, szarízű ételeket készít. Stb. Ez így jó, mert hobbi.

Ok, értem. Csak nem látom be, hogy ebből miként alakul ki a fejlődés.

Valójában egy olyan jelenségről van szó, mint amit "A Facebook elhülyíti az emberiséget" című cikkben olvashatsz. Alkalmazva a jelenséget erre a témára
- természetesen nem mindenki hülye,
- a hibás információ gyorsabban terjed és jobban rögzül,
- a tévhír bevonul a köztudatba és kitörölhetetlen marad.

Ellenvetés?

Ne keverjük össze a Fritzing ábrát az Arduino-val. Elgondoltam, hogy egy áramkör gyártásánál egy Fritzing ábra szerű izével adnám meg a teendőket. Biztosan kardélre hánynának. :(

Én itt feladom. Ha valaki nem akarja megérteni, hogy a Fritzing ábra nem a profiknak szól, akkor mondhatok bármit, csak a hasonló hülyeségeket fogja előhozni ellenvetésként.

Ave, Saabi.

Röviden: Nem akarod megérteni. Két profi is azt állítja, hogy NEM JÓ, HASZNÁLHATATLAN.
Ezek után miért tételezed fel, hogy az amatőr jobban meg fogja érteni amit a profik sem? Ha valaki ennyire kezdő, akkor egy ilyen ábra legfeljebb fokozza a zűrzavart, miközben nem segíti elő a megbízható reprodukálást.

És most ki akartam találni egy példát, de nem kellett. Élőben láttam! Képzeld el, ha programot kell írni és minden for/while/switch stb. tilos! Pont egy ilyen programot mutattak nekem ami egy banknál(!!) futott. Volt vagy 100 oldalas, és programozáshoz nem értőknek kellett módosítgatni. Minden hencegés nélkül max 5 oldalban leírható lett volna a probléma, ha nem dilettáns készíti. No ez jutott eszembe a Fritzing ábrával kapcsolatban.

Nézd, a fritzing ábra nem használhatatlan. Az kb. egy nyák beültetési rajznak fogható fel, csak nem nyákon hanem breadboard-on dolgozik.

Programozás témában én is láttam már szörnyűségeket, pl. ilyen pascal kódot: 


if i=88 then writeln('1988');
if i=89 then writeln('1989');
...

Na, ezt egy tanár írta...

( locsemege v | 2016. 12. 20., k – 22:57 )

Az utolsó ötletedet felejtsd el! Az milyen gány már? Jó, amúgy lehet csinálni, de akkor kell visszafelé egy acknowledge, s így csináltál egy handshaking párhuzamos átvitelt. Aztán minek az a sok drót? Szóval I2C vagy SPI inkább. Én az előbbivel csinálnám.

Lehet úgy is, hogy a mikrokontroller aszinkron mér bizonyos időközönként, nem törődik az R-Pi vel. Amikor az R-Pi kérdezi, átadja neki a mindenkori legutolsó eredményét bufferből. De csinálhatod azt is, hogy amikor az R-Pi kérdezi, hogy akármi, akkor gyorsan mérsz egyet, s a friss eredményt adod az R-Pi-nek. A slave egyébként meg tudja fogni az I2C buszt - nézz utána clock stretching kifejezésnek - így nem vagy nagyon időkényszerben. Kérdés, mennyi ideig illik ezt megtenni. Felületesen nézve talán 35 ms-on belül el kell engedni a buszt.

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

( hzsolt94 v | 2016. 12. 20., k – 23:57 )

USB-n :-)

(Újabb téma ugyanarra a projektre?)

Hol itt az ágyú?
https://oscarliang.com/connect-raspberry-pi-and-arduino-usb-cable/
http://www.instructables.com/id/Raspberry-Pi-Arduino-Serial-Communicati…
Összesen egy egyszerű kábel kell hozzá.
Egy hátránya lehet, hogy elhasznál egy USB portot a Málnán, de a 3-as változaton pl. van bőven.

Ott, hogy az USB szabvány 621 oldal. Eléggé összetett a folyamat onnantól, hogy a host érzékeli, hogy bedugták valamelyik hubba az eszközt, az eszköz elmeséli magáról, hogy tulajdonképpen ki ő és mit akar, egészen addig, hogy a 4 féle üzemmód közül valamiféle kommunikáció kialakul. Nem egy súlycsoport az I2C-vel.

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

Arra gondolsz, hogy van kész library? Nem tudom, én valahogy ezekben nem nagyon bízom mikrokontrolleres környezetben. Nagy gépen sem igazán, de ott nincs más reális lehetőség. :) Csak így hirtelen: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.8.15

Szerk.: Különben azért irtózom az ilyen félkész, előre megrágott megoldásoktól, mert ha ebben valami nem megy, akkor ott vagyok, hogy ez bizony akkor most rossz. Ezzel szemben, ha mindent magam csinálok az első assembly utasítástól az utolsóig, akkor egészen biztos, hogy a hibát is magamban kell keresni, kézben tartom az egészet az utolsó bitig, s meg is fogom találni a hibát.

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

O.K., de ez működik. Ha veszek két USB/RS232 átalakítót, ezeket bedugom egy-egy olyan PC-be, amiken Linux fut (azért Linux, mert ott még nem találkoztam olyan adapterrel, amit a kernel ne kezelt volna kapásból), mindkét gépen lesz egy /dev/ttyUSB0. Innen kezdve, mivel van két soros portom, nyert ügyem van. Kb. ez van a Málna és az Arduino USB-s összekötésekor.

Működni fog - ezért népszerű az arduino.

De végülis javasolhatjuk a témanyitónak azt hogy ha ilyesmit szeretne, végezzen el egy 4 éves BSc mérnökinfót(?), majd szakosodjon FPGA-kra, tervezzen egy saját architektúrájú mikrokontrollert a feladatra optimalizált utasításkészlettel, ehhez készítsen egy megfelelő kapcsolási rajzot, majd nyákot, gyártassa le, szerezzen rá FCC/CE matricát is a rend kedvéért, dobjon össze gyorsan egy assemblert az architektúrához, majd az ennek megfelelő assemblyben írja meg a szenzor kiolvasását, amit lehetőleg DMA-val töltsön be a RPi memóriájának megfelelő részébe.

Vaaaagy, csak bedugja az USB kábelt, és elhiszi hogy valaki ezt már megoldotta. :-)

a) USB, összedugja, ott a /dev/ttyUSB0, és működik.
b) Kihozza a TX/RX-et az USB-Serial adapter előtti pinekről, beköti az RPi megfelelő portjaira közvetlenül. Így kimarad a felesleges USB, cserébe reszelgethet RPi kernelt mire feljön a /dev/ttyAMA0

( Remélem a b variáció már csak gépfegyvernek minősül. ;-) )

Na ja, csak míg az I2C-t minden nehézség nélkül implementálom egy mikrokontrollerre, addig az USB-t - előbb elolvasok 621 oldal szöveget angolul, fejben tartok néhány tíz oldalt, kódolok néhány ezer sort. Én biztosan I2C-vel csinálnám, debugolni is könnyebb, akár azt is megtehetem, hogy másodpercenként egy bitet viszek át, hogy lássam multiméterrel, ha valami nem megy, s nincs oszcilloszkóp otthon. Tegyük hozzá, a feladat egyszerűbb annál, mintsem idáig fajulnának a dolgok, ez csak példa.

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

Itt nem kell 621 oldalt elolvasni, az USB port kezelése mindkét eszközben megoldott, ehhez már nem kell nyúlni, csak a kész kapcsolaton kell átküldeni az adatokat, ami már nem lehet kihívás senki számára. Ha I2C-t használsz, akkor kicsit többet kell programozni - nem is beszélve arról a szintillesztési problémáról, ami bizonyos esetekben okozhatna gondot, amiről pont írtál is (az adott felhasználási módnál nem okoz, ha nem követ el programozási hibát, viszont ha elnéz valamit, akkor baj lehet).

Valóban benéztem a dolgot annyiban, hogy én mindig saját fejlesztésű, egyedi hardware-ben gondolkodom, míg az Arduino egy népszerű, elterjedt játékszer, kész nyák, kész hardware, s gondolom, van már hozzá egy rakás library, amelyek egy része bizonyos, vélhetően nem részletezett körülmények között olykor még működhet is, a fene tudja, milyen megbízhatósággal. De nem baj, mert talán ebben a CPU-ban is van watchdog. ;)

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

Nem olvasol el egy sort sem. Használod az arduinon már rajta levő, előre bekötött FTDI chipet, amit az arduino lib és a raspbian is tökéletesen kezel, a kisujjad megmozdítása nélkül. Nemhogy az USB de még a soros port működését sem kell értened:

Amit a /dev/ttyUSB0-ba beleírsz, az kijön a Serial.read()-ból, amit Serial.write()-ba beírsz, az kijön /dev/ttyUSB0-ból. "Varázslat :-)"

Hm... és ez akkor is így van, ha 40 µs-onként próbálok IT-t kérni tőle? Vagy akkor, ha megoldom, hogy egyes IT rutinokba mások becsaphassanak, mert épp erre van ingerenciám? Érted, mi a bajom? Nem tudom, hogyan működnek, mit bírnak ki ezek a libek, milyen peremfeltételek mellet üzemeltethetem, de ha tudom is, akkor sem biztos, hogy az nekem megfelel. Jut eszembe, mennyi idő alatt fut le? És milyen esetben? Mi a worst case?

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

Itt nincs worst case (pontosabban nem érdemes róla beszélni), van két "erőmű" ahhoz képest, ami volt '82-ben, amikor kijött a PC a soros porttal. A két gép között simán megy az adatátvitel, nem kell hozzá semmi fakszni. Régen nagyon fontos volt, hogy jól válasszam meg az adatátviteli sebességet, nem véletlen, hogy még a stop bitek számát is lehetett piszkálni (1 - 1,5 - 2). Kellett a handshake is, ma meg azt látom, hogy a berendezések zöméhez nem kell más, csak GND, RxD és TxD. Egy Cisco routert is simán kezelek háromeres kábellel, ha úgy alakul (van rendes kábelem, nem arról van szó, de a Huawei cuccokhoz leginkább 3 erest adnak, néha az akad a kezembe).

Csak a pontosság kedvéért.
A PC 81-ben jött ki.
Nem is volt benne semmi, csak egy soros adapter, amivel akár 10km távolságra is lehetett kommunikálni. Tényleg változott a világ, mert ezt az apróságot már évtizedek óta nem tudják a gépek. Persze ott a hálózat, de ahhoz dróton kívül még sok-sok dolog kell.
A régi 25 vagy 9 pólusú csatlakozók jobbára a modemek miatt maradtak életbe. A soros átvitelhez mindig elég a 2 aktív vezeték, ha van szoftver handshake.
És ami a legfontosabb: Az adatátviteli vonalat marhára nem érdekli, hogy erőmű van e mögötte, vagy sem. A villany buta, nem ért az rpi-hez, csak a dróttal áll kapcsolatban.

Értem én, csak leszarom :-)

Senki nem akar 40us-onként IT-t kérni tőle, nem is tudsz igazán arduino féle C-ben interruptot definiálni, tetű lassú lesz, és a worst-case az természetesen az hogy beszarik. De ez itt mind érdektelen. Egy darab nyamvadt hobbi-célú DHT22-ről van szó. Ha nem működik akkor majd valaki belerúg amíg működni nem kezd, aztán jólvan. Különben meg annyira egyszerű a felhasználás a hardverhez képest, hogy neked is komolyan meg kellene erőltetned magad ha direkt el akarnád rontani.

Meghajlok az érveitek előtt. Az én olvasatomban így néz ki a történet: ha nem foglalkozunk az architektúrával, picikét eltávolodunk a fizikai rétegtől(*), továbbá erre az egy, esetleg még néhány szenzorra fókuszálunk, akkor használhatunk kész libeket, amelyekről nem kell azt tudnunk, hogyan működnek, s fog működni. Jó, legyen hát USB.

Viszont nagyon komolyan van egy aggodalmam. Amennyiben ennek az USB libnek egy része IT-ben van implementálva - tegyük hozzá, nem tudom -, úgy átvittük a döglött lovat a szomszéd utcába. Tudniillik az R-Pi és a szenzor közé épp azért került egy mikrokontroller, mert az R-Pi valós idejű folyamatokat nem tud kezelni, a mikrokontroller meg igen. Persze kellő elszántsággal ezen képességétől ügyesen meg tudjuk fosztani, s akkor visszakapjuk az eredeti problémát, de még egy nyák van a szerkezetben. Kissé a Legényanya című filmre emlékeztet, amikor is újabb gödröt ástak, amelybe az előző gödörből kitermelt földet rakhatták. :)

*: Egykori infós évfolyamtársam mélységesen fel volt háborodva, hogy a kondenzátorokat, induktivitásokat leíró differenciálegyenleteket, meg úgy általában lineáris villamos hálózatokat is tanulnia kell. Valamiképpen a villamosmérnöki karon infósként ezt a személye elleni merényletként élte meg. :D

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

Nem állítom, hogy USB felületen kell velük kommunikálni, valamint nem ismerem (nem is igazán akarom) az Arduino világot, de a szál elején FTDI chip került említésre.
Ergo a fentiek alapján a kontroller szintjén nincs USB lib és nem kell IT-okkal bajlódni, szimplán az egyik UART-jára van kötve egy FT232-es IC.

Szerintem késő / korán van már. :)

Ezeknél a kis sebességű IC-knél nem is lehetne szoftverből kezelni az USB-t. Amikben van USB, ott is egy segédmodul van, ami bufferrrel dolgozik (és ha kéred akkor küld IT-t buffer állapotáról).

Ilyen szempontból az ESP32-es WiFi modulok alattomosak nagyon, azok az általad kezelt CPU-n eszik a WiFi kezeléséhez szükséges időt.

Most néztem egy kapcsolási rajzot, ezen van két mkrokontroller, az egyiknek van USB interface-e. Ezek szerint ebben fix program van, míg a másik, soros porton ezzel az USB-ssel kommunikáló kontroller a szabad préda, azzal azt csinál az ember, amit akar. Így már világos, hogy nincs gond, mert önálló hardware intézi az USB-t, annak legfelsőbb rétege, a nettó adat jelenik meg az UART-on.

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

Véletlenül ismerem ezeknek a libeknek a kódját*, úgyhogy csak érdekességként megadom neked a vágyott információkat:

Az USB kezelését egy dedikált FTDI chip intézi, ezért nem releváns. A mikrokontrollerre TTL sorosportként érkezik, a library interruptot használ a 2 byteos buffer ürítésére amikor megtelt. 1-wire hardweres interface nincsen, az tisztán szoftverből megy. Konklúzió: amíg nem küld rá 1 bytenál többet az arduinora hőmérséklet letöltés közben, addig garantáltan menni fog. Ha ráküld, akkor vagy igen vagy nem, de azért jó eséllyel igen, mert elég rövid az IT.

A valós idejű problémakezeléshez annyit tennék hozzá, hogy az arduinonál a futó főprogam kódod egy újra és újra meghívott függvény, amivel rendszeresen vissza kell térned. Ez a függvény lényegében egy nagy while loopban van, ami a bejár egy csomó egyéb függvényt is, amit az includeolt libek definiálhatnak. Vagyis fogalmad sincs róla mikor kapod vissza a függvényed elejére a vezérlést, de ha nem tér vissza a függvényed elég gyakran akkor megmakkannak a libjeid. Kellemesen frusztráló ugye? De! Jelen projektnél ez sem fog gondot okozni, a hőmérő olvasása közben úgysem tudod kiengedni a függvényből.

(*Csak nem debugolnom kellett őket mert nem fértem bele az elvárt időzítéseimbe? XD)

Ez marha jó. :-/ Persze így működnek a programok, de akkor itt-ott van egy rakás pollingolás, amiről senki semmit nem tud, ha szerencsém van, akkor jó nekem, semmiről senki nem marad le, nem lesz overrun, s így tovább. Legjobb. Tehát van valamim, amellyel valami történik, s ha azt tapasztalom, hogy működik, akkor sem tudom, hogy miért. ;)

Visszatérve a soros port kezeléséhez. IT-t lehet tiltani a szenzor fizikai kezelésének idejére, utána meg felengedni, hadd éljen! :) Ha előtte át lett véve az adat, annyi idő alatt úgy sem tud bejönni egy karakter, amíg mérünk, bár ez nyilván függ a baudrate-től is.

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

off

Nem igazán értek ezzel egyet. Egyfelől a villamosmérnöki karon végzett. Szerintem elég ciki lenne, ha lövése sem lenne arról, mi az a kondenzátor. A másik dolog, hogy a programozó az iparban fizikai folyamatokat implementál, pontosabban ez így képzavar, szóval fizikai folyamatokhoz implementál például szabályozást, s nem túl nagy baj, ha van annyi műszaki ismerete, hogy legalább megérti, mi is a feladat. Különösen úgy, hogy sokszor a specifikáció hiányos. Vagy azért, mert a megrendlő úgy gondolja, hogy valami evidencia, eszébe nem jut, hogy a programozónak nem az, vagy azért, mert a megrendelő is hülye hozzá, s azt akarja, hogy legyen valami csodálatosan csillogó-villogó, füttyögő bizgeréje azonnal és olcsón. Arról meg neki sincs sok fogalma, hogy az hogyan fog összeállni.

Különben dolgoztam programozó matematikus közelében, és vicces volt, hogy a dolgok fizikájához mákszemnyi tudása nem volt, miközben bármit megírt, ha valaki megmondta, hogy mi legyen az. Bár: ez valóban vicces?

Mondjuk azon tudtuk jókat derülni, hogy már a szavakat sem értette olykor. :)

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

Nem azért végzett villanykaron, mert ott akart végezni, hanem mert ott volt az infószak. Ha egy közgáz karon lenne akkor gondolom könyvelést és marketing-statégiát kellene tanulnia, ha pedig egy orvosi karon akkor oltani, vért venni, műtenie kellene...

Amúgy a villanykari infó villanykar része messze nem azon a szinten van, hogy tudja-e mi a kondenzátor. Azzal még nem is lenne semmi baj, ha ilyen "betekintés a mérnöki tudományokba" jelleggel lenne egy kis felületes villanyos (gépész, vegyész, akármi) okítás.

Az viszont már baj, ha egy infó szakon a tárgyak 50-70%-a simán csak át lett hozva a villanyász szak(ok)ról, amire a hallgatók 95%-ának soha az életben nem lesz szüksége. Ráadásul sokszor úgy, hogy ezeknek a villanykari alapozótárgyai nem, vagy csak alig jöttek át infó szakra, szóval az egész csak lóg a levegőben. Ja, és persze masszív szórótárgyakról beszélünk...

És már bocsánat: egy normális világban nincs olyan, hogy az üfféltől csak úgy odakerül a munka a programozó elé, aki ugye képzett villanymérnök is félig (3/4-ig), ezért átlátja ha fasságot kér a megrendelő, és persze röptében javítja a speckót is, mert a cégnél nyilván nincs project mgr, nincs hozzáértő villanyász, nincs senki, csak a főnök, a programozó, a portás meg a takarítónő...

Nyilván nem az ideális világra készülünk, de az azért nem normális hogy egy programozónak képzett villanyásznak kell lennie, mert rajta kívül mindenki hülye: a megrendelő is és a kollegái is. Mindezt persze úgy, hogy a villanyász tudást fele annyi óraszámban kell összeszednie mint egy villanymérnöknek, mert papíron mégiscsak infó szakra jár...
Gondolom az autóipari sw fejlesztők félig gépészek, akik pedig erőművek vezérlését sw-eit írják azoknak minimum phd-ja van magfizikából...

Nem mintha én nagy kedvelője lennék az oktatási rendszernek, de itt konkrétan a "Mérnök informatikus" szakról beszélünk. Itt ilyesmiket tanítanak mint "beágyazott rendszerek tervezése", FPGA-k, és más hardver-közeli informatika. Ezekhez igenis szükség van komoly villamosmérnöki tudásra. Ha valakit a "tiszta" programozás érdekel, annak inkább "programozó matematikus" jellegű szakot kell választani.

Gondolom az autóipari sw fejlesztők félig gépészek, akik pedig erőművek vezérlését sw-eit írják azoknak minimum phd-ja van magfizikából...

Képzeld, aki motorvezérlőt programoz, attól elvárják hogy gépész, sőt némi vegyész ismeretei legyenek, akit pedig egyáltalán a közelébe engednek atomerőmű vezérlésnek, azoktól nagyon komoly atomfizikai végzettség elvárt. Őszintén örülök neki hogy így van.

A programozás egy csomó területen csak egy eszköz, amit tudni kell használni az adott területen releváns szaktudással! Villanyszerelőnek sem lehet senki szaktudás nélkül aki a megfelelő színű drótokat helyesen be tudja kötni egy csavarhúzóval, pedig a munkája jelentős részében ezt fogja csinálni.

(Utóirat: személyes véleményem szerint a jelenlegi magyar egyetemi oktatási rendszer úgy egyébként katasztrófálisan rosszul működik, de pont nem a túl sok jó minőségű tananyag probléma.)

Az a helyzet, hogy a progmat matek szak, annak minden előnyével és hátrányával együtt.

A mérnök-infó meg infó meg a fene tudja mi, mindenesetre simán vannak olyan szakirányok (link) amiknek nem sok köze van a villanyászathoz. És akik a villanyosabb szakirányokon végeznek, hát szerintem kb. 90%-ban ők is csak simán elfelejtik azt amit villanyászatból tanultak az alatt a pár év alatt, mert soha nem fogják használni.

A hw közeli dolgokat pedig leginkább villamosmérnök programozzák szerintem, legalábbis szerintem ez a helyzet jellemzően.

Amúgy abban valóban igazad van, hogy a _motorvezérlés_ programozásához kell gépészeti tudás, de én egy jóval nagyobb kategóriáról beszéltem. Az autóknak van szórakoztató rendszere, van navigáció, központi zár, kulcs nélküli nyitás, stb. Nem csak motorvezérlésből áll a világ.

Az atomerőműnél pedig hülyeséget írtam, nyilván nem kérdés hogy a reaktorok vezérlését nem akárkik csinálják.

Tény, hogy az oktatási rendszerből hiányzik egy komplett szakma, akik a kis terhelés, kis rendelkezésre állás, jó felhasználói felület jellegű munkára specializálódnának. (Például egy entertainment centert összerakni.) Az egy érdekes vita tárgya lenne hogy ez egyetemi szintű tudást igényel-e, de az biztos hogy sem a mérnökinfó sem a progmat nem erre van kitalálva.

A progmatot had védjem meg annyiban, hogy a programozás azért alapvetően nagyon erősen épít a matematikára, különösen akkor ha teljesítmény, rendelkezésre állás, vagy algoritmizálás elkezd hangsúlyt kapni. A komoly algoritmizálási háttér persze nem feltétlenül szükséges, de valahányszor ok nélkül kegyetlenül belassul egy GUI-s program, vagy JavaScript-kupac, gondolj arra hogy bizony ezt is kellő matematikai háttér nélkül csinálták.

Nem kell megvédeni a programot, azt írtam h matek szak annak minden előnyével és hátrányával együtt. Nyilván vannak az erős mateknak előnyei, és van ahol ez nélkülözhetetlen. De ott is úgy gondolom, hogy akik ott végeztek ezt a matek részt többnyire nem használják. Mondjuk úgy 90% kb.

Kicsit ellentmondok, hogy egyetértsek. ;)
Olvastam egy érdekes cikket arról, hogy milyen régóta készít az ember tökéletes PID szabályzást. Méghozzá matematikai ismeretek nélkül. Egy biztos: Akár villanyszerelő akár elméleti fizikus az ember, a józan paraszti ész nem mindig tanítható.
Sokat dolgozok olyan kollégákkal akik a GUI és a Java mesterei. A grafikus felületnél is felmerül a paraszt, de csak a vakítással kapcsolatban. :) Az ilyen programozók egyértelműen pontatlanok, nem elég alaposak, sok esetben nem is gondolkodnak. Hiszen néhány sor után már ott csillog-villog a kész mű! Sok esetben a guglizok java, MSDN stb. dolgokat - bár semmi közöm hozzájuk. Nézd csak, ha ennek az ojjektumnak a propertijéeit :) két szinttel mélyebben is megnézed, és ott, igen ott azt a fleget is jól beállítod, akkor már jól is fog működni! :(
Visszatérve az elejére, nekem is éppen olyan ember kéne aki ugyan nem ért a PID-hez, viszont el tudja olvasni a legfrissebb kutatásokat. Mert ezt a témakört bizony a mai napig kutatják, és ezeket az anyagokat már csak keményvonalas matematikusok tudják elolvasni. Ha valaki elmagyarázná mi van odaírva, akkor még én is tudnám programozni.
Az egészet kifodítva azért lehet szükség több területen jártas szakemberre, mert esetleg az egyes szakterületek művelői sem értenek annyira a szakmájukhoz, hogy a másik szakterület számára specifikációt készítsenek. Ezért marad a könnyebb út: néha mindenhez kell érteni. Ilyen módon azért elkészülnek a dolgok, de nem a legjobb módon. Magyarán a piac sebessége sok esetben felülírja a feladat maradéktalan megoldását. Ennek eredménye a számtalan üzletileg sikeres fércmű.

( locsemege v | 2016. 12. 22., cs – 20:11 )

Írod, hogy működik Arduinoval. Végül is hogyan illesztetted az R-Pi-hez?

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

Az RPi-hez még nem, csak az Arduino+DHT22 teszt sikeres volt:

//
// Arduino DHT22 test code.
//
// http://playground.arduino.cc/Main/DHTLib
//

#include

// dht variable
int dataPin = 8;
dht DHT;

// *****
// SETUP
// *****
void setup() {
// put your setup code here, to run once:

// Serial setup
Serial.begin(9600);

}

// *********
// MAIN LOOP
// *********
void loop() {
// put your main code here, to run repeatedly:

// DHT22 read and output via serial port
int readData = DHT.read22(dataPin);
float t = DHT.temperature;
float h = DHT.humidity;
// print to serial port
Serial.print("Temperature = ");
Serial.print(t);
Serial.print("°C");
Serial.print(", Humidity = ");
Serial.print(h);
Serial.println("%");
delay(2000);
}

:)

Azt látom, hogy a kontroller soros porton írja az eredményt, csak arra lettem volna kíváncsi, ezt követően mi lett az adattal. Van ugye a másik kontroller, azon keresztül mehetett USB-n, de mehetett akár RS232 interface-en keresztül valahova.

Azért érdekelt, mert volt szó arról, hogy mi legyen az Arduino és az R-Pi közötti illesztés. Aztán kiderült - amit én korábban nem tudtam -, hogy az USB és az UART között lévő másik kontroller készen, tálcán szállítja a megoldást. Akkor ezek szerint ez lett.

Szerk.: Egyébként, ha jól látom, teljesen indokolatlan ennek a két sornak nem egy sorban lenni:

Serial.print("°C");
Serial.print(", Humidity = ");

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

Jogos, de a mintakódból vettem (teszt volt). :)

A lényeg, hogy az Arduino és a DHT22 működését teszteltem, ami működött. Az eredményt csak simán a soros porta küldtem.
A fejlesztői környezetben a soros port monitorban figyeltem az adatokat. Ez működött.
Az RPi és Arduino I2C illesztése és kommunikációja ezután jön. :)

( makgab v | 2016. 12. 23., p – 10:20 )

A wiringPi-vel mit kellene küldeni az Arduino/DHT22 felé I2C-n, hogy lekérje a mérési adatokat?

//
// test code
//
#include < iostream >
#include < errno.h >
#include < wiringPiI2C.h >

using namespace std;

int main()
{
int fd, result;

fd = wiringPiI2CSetup(0x00); // Arduino address

cout << "Init result: "<< fd << endl;

result = wiringPiI2CWriteReg(fd, 0x00); // send data: 0x00

if(result == -1)
{
cout << "Error. Errno is: " << errno << endl;
}

// get the response from Arduino:
read(fd, resp_data);
}

Az Arduino+DHT22 tesztkódja pl.:

// I2C, DHT
#include < Wire.h >
#include < dht.h >

// ***************************************************
// dht, variables
//

int dataPin = 8;
dht DHT;
int I2C_ADDR = 0; // as slave

// ***************************************************

// *****
// SETUP
// *****
void setup() {
// put your setup code here, to run once:

// I2C init
Wire.begin(I2C_ADDR);
Wire.onRequest(requestEvent);
}

// *********
// MAIN LOOP
// *********
void loop() {
// put your main code here, to run repeatedly:

// delay
delay(100);
}

// *************
// receive event
// *************
void requestEvent( char data ) {
// DHT22 read
int readData = DHT.read22(dataPin);
float t = DHT.temperature;
float h = DHT.humidity;
// I2C/wire result send: t, h
Wire.print( data );
Wire.print(": ");
Wire.print(t);
Wire.print("C,"); // separator
Wire.print(h);
Wire.print("%");
}

Jó fele megyek? A requestEvent( char data ) le tudom kérni, hogy a Pi mit küldött?
Ill. az Arduino válasza a read()-el kapható vissza?

off

Például nekem ez a bajom a félkész dolgokkal. Újabb megfejtendő fejtörést okoznak. Saját implementáció esetén nem kérdés a formátum, mert én találom ki, nem kérdés, milyen függvényt hívjak, mert azt is épp akkor találom ki, nem kérdés a paraméterezése, mert épp úgy találom ki, hogy kényelmes legyen.

Annak tükrében, amit a többiek írtak, lehet, hogy mégis az USB átvitel lenne a jobb, bár a megbízhatóság tekintetében ebben sem vagyok biztos. Azért mondom, mire is gondolok.

Az R-Pi-t táplálod 5 V-ról, a CPU-ja jár talán 3.3 V-ról. Az Arduino-nak vélhetően ugyanaz lenne a tápja. Ezt vagy az R-Pi megfelelő lábairól oldod meg, vagy USB-n keresztül táplálod. Ez utóbbi esetben viszont megúszol egy szintillesztést is. Szóval azt akarom mondani, hogy USB-s kommunikáció készen van azzal, hogy egy USB kábellel összekötöd a két eszközt. Az Arduino-ban soros portot kell kezelned, mert az USB réteg egy másik kontrollerben került megvalósításra.

Még nagyobb off. Hogy Neked mennyi időd van? Lassan ki kellene takarítanom a lakást, mert az a hír járja, hogy hamarosan karácsony, vagy valami ilyesmi. Nem a karácsony miatt kell takarítani, hanem azért, mert már nagyon megérett erre a helyzet. :)

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

Arra figyelj, nehogy az R-Pi GPIO-jára az Arduino 5 V-os jelszintet küldjön, mert az R-Pi beadja a kulcsot. Szóval valamit tégy szintillesztés ügyében. Meg ne felejtsd el az SDA és SCL vonalakat 3.3 V-ra felhúzni ellenállásokkal. Ha engem kérdezel, például 2.2 kΩ jó is lesz.

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

Ahogy olvasom, az R-Pi-ben ezen a két lábon van egy-egy 1.8 kΩ-os ellenállás a 3.3 V felé. Tehát valóban csak össze kell kötni a GND-ket, SDA-kat, SCL-eket, s mivel gondolom, ugyanaz lesz a tápegység, így a +5 V-okat.

Az enyhe aggodalmam az, hogy ha egy programhiba miatt az Arduinoban az SDA vagy SCL vonalak valamelyikét kifelé forgatod, s oda logikai magas szintet küldesz, akkor a kontroller oda kiteszi az 5 V-ot. Két dolgot reméljünk: aki a libet írta, körültekintően járt el. A másik pedig az, hogy nem lesz olyan programhiba, ami ekkora felfordulást okoz. Azért ennek kicsi a valószínűsége, hiszen több dolognak kell balul elsülnie.

Körültekintés alatt azt értem, hogy ebben az esetben hamarabb kell az adatregiszterbe írni, mintsem az irányt meghatározóba. Ezeket az MCU-kat nem ismerem, de a PIC-eket igen, ezzel kapcsolatban mondok egy érdekes lehetőséget a szívásra. Ez pedig a read-modify-write típusú utasítások használata, tehát leegyszerűsítve szinte minden, például a porton egy meghatározott bit törlése. Ezt az MCU úgy csinálja, hogy beolvassa a portot, az adott bitet törli, majd az eredményt visszaírja a kimeneti latch-be. Mi ebben a kockázat? Több is van.

Mondjuk van a porton egy bemeneti és egy kimeneti lábad. Tegyük fel, a bemenetin épp I2C-t kezelsz software-esen, a kimenetin pedig egy LED hajtasz meg. Tök' jó. Az I2C miatt a bemeneti port adat bitjét 0-ba írtad, így ha ezt a vonalat alacsony szinten akarod hajtani, csak kimenetre állítod ezt a bitet, s mivel az adat 0, alacsony szintre húzza a vonalat a kontroller. Ha meg magas szintet szeretnél, befelé forgatod a portbitet, nagy impedanciás lesz, az ellenállás tápra húzza a vonalat, illetve visszaolvasva meg tudod nézni, valaki más lehúzza-e, vagy el van engedve a vonal. Hurrá, eddig minden jó.

Tegyük fel, ez a vonalad bemenet és magas szintű, akár azért, mert még a start bit előtt vagyunk. A mellete lévő biten lévő alacsony szintre aktív LED-et meg kigyújtod, mert olyan kedved van, tehát végrehajtatod azt az utasítást, hogy a LED bitje legyen alacsony szintű, egy bitet törölsz a porton.

Hogyan is hajtódik ez végre? Beolvassa az MCU a portot, tehát a bemenetként kapcsolt I2C vonaladon bejön a magas logikai szintnek megfelelő 1-es. A LED-nél is, de ez most kevésbé érdekes. A LED bitjét törli az MCU, majd visszaírja a regisztert. A LED kigyullad, az I2C-hez tartozó adat pedig 1 - hiszen ezt olvasta be, s nem nyúl hozzá. Még nincs baj, hiszen az a vonal még bemenet. Aztán hajtanád a vonalat alacsony szinttel, így kiforgatod a portbitedet. S mi történt? Kis impedanciával hajtasz magas szintet!

Ez nagy baj, mert egyfelől nem fog működni, másfelől zárlatba kerül a meghajtásod egy korrekt meghajtóval, aki kis impedancián húz alacsony szintre. Tehát fizikailag is sérülhet az eszköz. Nem mellesleg sok sikert a debugoláshoz, ha nincs benne elég rutinod. :)

A másik dolog, amire a read-modify-write típusú utasításoknál figyelni kell, hogy az írás az utolsó órajelben, míg az olvasás az elsőben történik, így ha gyorsan van hajtva az MCU, netán néhány pF terheli a vonalat, még nem változott meg annyi ideje a vonal állapota, hogy azt stabilan, helyes adattal vissza lehessen olvasni a következő utasítással, nem tartod be setup time nevű paramétert, így az MCU téveszteni fog. Hacsak nem figyelsz erre, s hajtatsz végre egy porttól független utasítást, vagy jobb ötlet hiányában egy NOP-ot a következő portot piszkáló utasítást megelőzően.

Amúgy ezen dolgok miatt is jobban szeretek assembly-ben programozni. Itt már lényegében a CPU flip-flopjaira, kombinációs hálózataira, regisztereire írja az ember a programot, néha látni kell az áramköri megvalósítást is, olvasni a mikrokontroller időzítéseire előírt paramétereket, hol hány ns időt kell mindenképpen biztosítani. Azokat a paramétereket nem azért adja meg a gyártó, hogy soha meg se nézzük, meg biztos minden magától teljesül, s így tovább.

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

Az említett linken levő videoban egy RPi kommunikál I2C-n egy Arduino UNO-val, egy python app villogtat ledeket.
Én nem látok ott ellenállásokat, csak közvetlen összekötötte a lábakat. Ez akkor hiba volt?

A cikkben szerepel két további I2C cikk:
Tutorial: Arduino and the I2C bus
I2C and SPI

A másodikban van egy kép a konfigurációról: I2C configuration
Tehát egy-egy 1.5 kΩ-os ellenállást mutat a Vcc és SDA, valamint a Vcc és az SCL közé.

Illetve:

"If you are only using one I2C device, the pull-up resistors are (normally) not required, as the ATmega328 microcontroller in our Arduino has them built-in. However if you are running a string of devices, use two 10 kilo ohm resistors. "

Működik, csak veszélyes. Én is kötöttem már össze RPi-t Arduinóval I²C-n közvetlenül, hogy WS2812-es multicolor LED-eket hajtsak meg - mert erre akkor még nem volt alkalmas az RPi, később készült rá lib, ami megcsinálta - de tudtam, hogy van veszélye. Ha az 5V valamiképp átkerül az Arduinóról az RPi-re, akkor az meghal.
Alternatív megoldás lehet egy 3V3-as Arduino board beszerzése a meglévő UNO helyett. Én például egy NodeMCU boardot használok erre a célra, ami egyrészt 3V3-as, másrészt WiFi-n küldi az adatokat. :-) Itt nincs veszélye a másik készülék megsütésének. :-D
Szintén alternatív megoldás lehet a DHT22-t közvetlen az RPi-re kötni. Erre is találhatsz sok példát.

Ave, Saabi.

Mennie kell a fenti peldanak, en evekkel ezelott priman beuzemeltem hasonloan, oda kell figyelni mit hova kotsz es vezerelsz kodbol aztan :)
De ha ovatosabb tipus vagy egy ilyet szerezz be, itthon is tuti kapni: https://www.sparkfun.com/products/12009

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Nem néztem meg a kódot, de ha valóban így van, az egy újabb ok, hogy semmiben se bízzak meg, amit nem én írtam. Ha valamit IT-nek kell triggerelnie, de sokáig tart, azt úgy szoktam kezelni, hogy a hardware vonatkozású részét - timer kezelése, valaminek a nyugtázása - megírom IT-ben, majd egy software-es flagben jelzem, hogy esemény volt. A fő végrehajtó ciklusban pollingolom, s ha elkészültem, visszatörlöm ezt a flaget. Így az IT rutin is tudja, ha az előző esemény még nem került feldolgozásra, ne rontsa el a buffereket, illetve az alap szinten sem kezd újra feldolgozásba, ha nincs mit. Tehát nincs overrun illetve underrun. Pontosabban szólva lehet, de azok kellemetlen következményeitől távol tartja magát az ember, mert megfelelő módon kezeli azt.

Persze van olyan, hogy alapszintről mielőbb törlöm a flag-et, nehogy lemaradjak egy következő eseményről. Ez mindig a konkrét esettől függ.

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

( veresh | 2016. 12. 23., p – 20:06 )

Érdekel a téma, ezért feliratkozok.

( makgab v | 2016. 12. 25., v – 23:13 )

Már kezd alakulni a dolog a fejemben. :)
A folyamat:
* RPi küld egy 0-t:

result = wiringPiI2CWrite( fd, 0 );

* Majd várja a választ:

result = wiringPiI2CRead( fd );

Egy dolog nem érhető már csak, hogy az Arduino hőmérséklet válasza pontosan hogy ér az RPi-re, mikor csak egy int értéket kaphat vissza a fv.
Tehát az Arduino küldi pl. a 22.3 értéket, ezt hogy kapja meg a wiringPiI2CRead() fv, ha ez csak egy int érték lehet.

Arduino reqestEvent pl.:

void requestEvent() {
// temp_str: "22.3"
Wire.write( temp_str );
}

...és csak a read()-el fogom tudni olvasni.

Szerintem pl. 22.3 értékből valami egészet kell csinálni. Ezért volt hasonló értéke korábban egy-két szenzornak. :)

Pl. ilyesmire gondolok:

22.3 --> 002230
24 --> 002400
21.36 --> 002136

azaz mindig mondjuk 6 karaktert küldök át, amiból az utolsó kettő a tizedesek, a többi az egész rész.

Arduino-val a DHT22-t a DHTLib-el kezelem, ami double/float értéket ad már vissza, lsd. korábban:

void loop() {
int readData = DHT.read22( dataPin ); // dataPin = 8
float t = DHT.temperature;
float h = DHT.humidity;
// serial
Serial.print( "Temperature: " );
Serial.print( t );
// ...stb.
}

Akkor ezt elvileg egy integerben vissza tudom adni. :)
Majd meg kell néznem mekkora pontossággal dolgozik (asszem 1 tizedes). Pl.:

respond_temp = float_temp * 10 ---> 226 = 22.6 * 10 (22.6degC)
respond_humi = float_humi * 10 ---> 397 = 39.7 * 10 (39.7%)
vagy pl.
respond_temp = float_temp * 10 ---> 220 = 22 * 10 (22degC)
respond_humi = float_humi * 10 ---> 390 = 39 * 10 (39%)

( secretx v | 2016. 12. 29., cs – 12:53 )

En is belevagok egy hasonlo projectbe, nalam az alap nodemcu+dht22 shield lesz, es az rpi gyujtogeti a helysegek adatait :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( secretx v | 2017. 01. 03., k – 22:35 )

Aktualis helyzet nalam: http://hup.hu/node/151389
:)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"