Megára túl gyorsat nem. Due-re én is elkezdtem, de nem éri meg a fáradtságot. 2MHz-es mintavételezésnél már annyira könnyen felszed minden zajt (elsősorban a műv erősítők pl. 20x-os erősítésnél) . Lehet összetudtam volna hozni megfelelő zajvédelmet, de inkább nem vesződtem tovább vele (normális szoftvert írni erre a feladatra sem kis munka). Mire is elég 2Msps? Talán 500kHz-es jel megnézésére. Inkább vettem egy szkópot, amivel 50Mhz-est is meg tudok nézni.

Itt épp a triggerelést teszteltem rajta. Sima soros buszi kommunikáció.
Bővebben: Link

Kb. erre számíthatsz: Bővebben: Link. Nem valami sok. Még ha nem is rajzolod újra az egész kijelzőt, akkor is sokáig tart a kép frissítése. Itt van az összehasonlító videó: Bővebben: Link. Igazából itt csak az SPI sebessége hasonlítható össze, ami viszont függ a mikrovezérlőtől. Én használtam 4MHz-en kijelzőt, de még az is lassú. A Due 84MHz-en ketyeg, ha ehhez hozzávesszük a 4-es prescalert (ha ez lehetséges), akkor van 21MHz-es SPI-d. Az 10x gyorsabb, mint az alap 2MHZ az UNO-nál, és ez látszik is.

Már nem azért de kb. két sor átkapcsolni az SPI-t 8Mhz-re UNO-n. Nem lesz persze tőle örülten gyors, de azért elmegy. Én pl. 9 analóg jelet frissítek a képernyőjén másodpercenként több mint háromszor, miközben 1280Hz-el mintavételezek és fel is dolgozom az adatokat. A srác valószínűleg nem optimalizálta halálra a kódját, mert ennél azért jóval többre képes.

Elnéztem, tehát az alap a 4MHZ, és 8MHZ a max. Ezzel próbálkoztam egyébként. A Due-nál meg 1-255 között lehet az előosztó. Ezek szerint lehetne 84MHz-es SPI-vel is kommunikálni? Érdekes...
Az autós videóban látható kód tényleg gyatra. Biztosan 4MHZ-en jár az SPI. Ebből azért már ki lehet következtetni, hogy dupla sebességen dupla olyan gyors lesz a frissítés, de még messze vagyunk a 25Hz-es képfrissítéstől

Persze, hogy messze. De ha nagy sebességű mintavételezést szeretnénk és mellette jó kis képernyővezérlést, akkor csapjunk rá egy FPGA-t a nyákra, hadd mintavételezzen, mellé egy ARM SoC-ot, hogy feldolgozza a végterméket és kirajzolja a képernyőre... Viszont ez itt egy Arduino fórum és hát az egy szegény mikrokontroller, ami azért persze jó sok mindenre jó magában is.

Persze örüljünk neki, hogy olcsón van kijelző. Sok mindenre bőven elég is. Ha ennél több kell, ott a Raspberry Pi. Pont most kapott egy upgrade-t, így sokat gyorsult a vasa.

Micsoda kis perpatvar kerekedett!

Köszi az infókat, srécek.
Viszont az Arduino mega az 16MHz-es.
Vagy máshogyan kell nézni a dolgot?
Mellesleg egy 1, esetleg 2 csatornás cucc nekem elég is volna, de 0-16V tartományban tervezném használni, autóelektronikai céllal.
Ezek tudtával sem jó megoldás?

Ne gondold azt, hogy az Arduino ellen vagyok, sőt!

Nem gondolom. Szerintem csak felesleges többet várni tőle mint, amire képes. A képernyők már így is csak bónuszok, annyi minden másra jók így is.

Az UNO is 16MHz-es. Az SPI sebessége a legkisebb prescaler sebességtől függ és az 2. Mega sem gyorsabb.

A Mega annyiban több az Uno-tól, hogy több benne a flash/eeprom/sram. Ezenkívül pedig több GPIO-ja van illetve egyéb perifériája (pl. 4 serial 1 helyett, 8 helyett 16 analog bemenet, stb.).

A 16V nem gond, úgyis egy 1:10-es szkóp szondával érdemes használni (csökkenti a jelre gyakorolt hatást a kialakítása), és akkor még erősíteni is kell rajta. Az ADC sebességéből adódóan pár tíz kHz-es jelet lehet vele figyelni, ennél többre nem érdemes számítani. Busz diagnosztikára és hasonlóra nem lesz jó. Szerintem jobban jársz ha veszel egy usb szkópot kínából, az is jobb lesz mint amit építeni tudsz (ráadásul lehet hasonló is lesz az ára).

Ha mindenáron építeni akarsz, itt egy oldal, ami alapján elindulhatsz. Bővebben: Link

De miért kellene SPI-vel szerencsétlenkedni, amikor van párhuzamos vezérlésű kijelző is, az Arduino Megának meg van jó sok lába, hogy jusson belőle a kijelző vezérlésére? Az viszont tény, hogy nem lesz belőle szélessávó oszcilloszkóp...

Természetesen megán érdemes kihasználni a több lábat. Bit banginggal párhuzamosan gyorsabb kommunikáció elérhető mint a soros SPI buszon. Az SPI buszos panelok akkor jönnek jól, amikor kevés a szabad láb (UNO esetében ugye ez gyakran gond, párhuzamos interfész esetén alig néhány láb marad szabadon), viszont a hardveres SPI támogatás miatt nem kell azért akkora kompromisszumot kötni. Jók még az SPI-os panelok akkor is ha nincs gyakori képernyőfrissítésre szükség, de hasznos, hogy nem kell annyi ér a bekötéshez (olcsóbb kábel).

Raspberry Pivel sokmindent meg lehet csinálni, a nagysebességű mintavételezésen kívül.

A Linux nem real time OS, szóval szerintem semmilyen mintavételezésre nem alkalmas. Indítasz egy liberofiszt, azt lesheted.

Ezért írtam FPGA-t egy pár hozzászólással korábban. Az kezeli az ADC chipet és pufferolja az adatokat, amíg a linuxos (vagy akármilyen) SoC nem jelentkezik érte. Egyébként a hozzászólásod úgy igaz, hogy a linux nem real time alapértelmezett esetben, viszont lehet belőle real time verziót is fordítani.

Uno (328p): Az lenne a kérdésem, hogy I2C busz használata (Wire lib) befolyásolja-e a megszakítások működését? Eléggé fontos, hogy mindig működjön, mert az autó injektorát kell vezérelni és ha kimarad a befecskendezés, akkor baj van.
Köszönöm válaszodat!

Hali!
ECU-t csináltál? Megmutatod a kódot?

Igen, azt építek. Majd publikálom, ha kész, teszteltem is és működik. A kérdésemre tudsz mondani valamit?

Ha megbízhatóság kell, akkor az arduino eleve nem valami jó választás.

Miért nem?

Közben találtam néhány angol fórumot ahol írták, hogy az i2c adatforgalom közben nem futhat interrupt, ki is kapcsolja. Akkor sajnos nem használhatok i2c-t, pedig szerettem volna. Majd implementálom a saját megoldásom.

Sziasztok!
Régebben volt problémám a 433MHz-es adó vevővel, mégpedig hogy a tápfeszültségben levő zavar miatt lecsökkent a hatótávolság nagyon. Kipróbáltam, hogy messzebb vittem 30cm-rel a vevőt a zavar forrástól, nem változott semmi. Eddig digitális lábon olvastam be az adatot, de több helyen is láttam, hogy analóg bemenetet használnak. Most átraktam, és még a lakás legtávolabbi pontjából is jött jel. Nem csökkent az amplitúdója sem. Egyébként 750-es értéket kapok, ami 3,6V-nak felel meg (LM358 kimenete eddig megy fel). Ezt értelmezte eddig a digitális bemenet. Kíváncsi leszek, hogy ez megoldja-e a problémát!

Kicsit nézelődtem. Ha nem megy az adóm, akkor is veszek egy ismétlődő jelsorozatot, ez vagy zavar, vagy valaki más adója lehet. Ilyenkor le vannak kapcsolva a LED-ek, tehát a fő zavarforrás ki van kapcsolva. Próbáltam 250bit/s-ra lelassítani az adatátvitelt, az eddigi 2000 helyett, de szinte rosszabb lett a kapcsolat minősége. Ennek működnie kellene, hiszen rengeteg távirányító 100 méterekről is értékelhető jelet ad, nekem meg csak 15m kellene maximum. Valamit biztosan én csinálok rosszul... Megnéztem a libraryt, és sima digitalRead-del olvassa be az adat lábat, ami működik is, hiszen az Arduino a 3V-nál nagyobb jelet magasnak érzékeli, nekem meg kb. 3.6V-om van.

Sziasztok.

Szükségem volna valamilyen 4 és 6 bites dac-ra. Nézelődtem neten, de nem tudom mit válasszak. Jó volna a cél ic-ket kikerülni. Van még az ellenállás hálós megoldás. Oda viszonylag nagy pontosságú ellenállások kellenek. Illetve van a PWM-es dac. Ott nem tudom mennyire lenne sima a jel. Nem kell nagy sebesség, lényeg hogy stabil legyen. Mit javasoltok?

A tápfeszültség nagyfrekvenciás zavarai ellen nagyon jól működik a ferrit gyűrű. Kapható többféle kivitelben (a jól ismert kábelre szerelhető, de vannak nyákra szerelhető átmenő furatos, illetve smd kivitelben is). Csodákra képes és kiviteltől függően akár pár forintért is kapható.

Hogyan hajtod meg a rádióadódat? Közvetlenül a soros portról vagy használsz valamilyen kódolást?

Ha direktbe az adatokat küldöd, akkor nem csoda ha rossz a jeled. Egy helyes csomagnak így kell kinéznie: folyamatos jel (nem emlékszem, hogy high vagy low, a lényeg, hogy kiszedje szaturációból a cuccot), preamble (mondjuk 10 be/ki a kommunikációs órajel sebességével, ez egyben segít szinkronizálni az órajelet a vevővel), ezután jön a tényleges információ (fejléc majd adat, végén checksum) manchester kódolással (ez biztosítja, hogy mindig van jel váltás, akkor is ha sok nulla vagy egy jön egymás után, hisz ilyenkor szaturációs állapotba menne el az adó, illetve vevő).

A legegyszerűbb megoldás valóban a PWM DAC. Mivel elég lenne neked a 4-6 bit, azt bőven hozza majd.

Javaslom, hogy egy egyszerű RC tagokból álló aluláteresztő szűrővel oldd meg a jelsimítást. Mivel nem szabad 40mA-nél jobban terhelni a uC-t ezért én ennek általában a negyedét veszem (biztos, ami biztos), így legalább 500 Ohmos ellenállást választok (560-as ), ezzel limitálom az áramot max. 10mA-re. Ezután jöhet a C meghatározása ez alapján a képlet alapján f0=1/(2*pi*R*C), ahol az f0 a vágási frekvencia (ez legyen mondjuk a fele [vagy még kevesebb] a PWM-ed frekvenciájának). A jobb minőségű jel érdekében szoktak még egy RC tagot utána biggyeszteni (másodrendű szűrő lesz tőle, R-t meg kell szorozni 10-el, C-t pedig osztani 10-el a második tagban).

Ezután jön a teher kérdése. Ha kis impedanciájú amit meg akarsz hajtani, akkor szükséges lehet még egy egység erősítésű műveleti erősítő is, hogy leválaszd a terhet a szűrő kimenetről (használhatsz műverősítőt az RC szűrő hajtására is, akkor nem terheled a uC-t és gyorsabb reagálású DAC-ot építhetsz).

Hmm, mondjuk annyira kicsi a kondenzátor nagy frekvenciák esetén, hogy lehet kisebb ellenállást is használni... Nagyon rövid idejű lesz a max. terhelés. Azért a 40mA-t ne haladhassa meg (inkább legfeljebb mondjuk 20-at).

Köszi!
Én is erre az RC tagos simításra gondoltam, csak mivel még nem használtam, nem tudtam hogy mennyire számíthatok stabil feszültségre. Gondolom ezzel a másodrendű szűrővel eléggé stabil feszültség érhető el. Műveleti erősítős leválasztás mindenféle képen kell, mert még lehet hogy a jelszintekkel is játszanom kell. De ha nem kellene a jelszintekkel foglalkozni, akkor is raknák.
Ha megépítettem, azért csinálok majd egy két mérést szkóppal. Kíváncsi vagyok mennyire lesz hullámos a jel.

Szia!
Hogy állsz a vezérléssel? Milyen autóba lesz?
A főtengely jelet te hogy dolgozod fel?
Én most jutottam el erre a pontra hogy szükségem lenne rá, de én BASCOM-ban programozom. Nem tudom nálam okozna a e gondot az i2c, de szerintem én csak sorosportot fogok használni.
Atmega328P lesz az ECU, és soroson továbbít adatokat majd egy kijelzőnek amiben szerintem szintén 328 látja majd el az illesztés feladatát. Illetve onnan oldom meg a PC felé a kommunikációt.
Amit használok a rendszerben: map szenzor ami a befecskendezés idejét határozza meg, TPS ami a befecskendezett anyag mennyiségét a hőmérséklet és a lambda segitségével, és a CKP ami pedig azt kellene majd hogy megmondja hova kell befecskendezni.

Az RC szűrőnél a lényeg a kompromisszum. Ha kisebb f0-t választasz, akkor simább lesz a jel, viszont lassabban reagál a változásokra (PWM-et lassabban követi). Ha nagyobbat, akkor többet átenged a PWM harmonikusaiból, ezért kevésbé lesz sima. Mivel azt írtad, hogy nem kell gyorsnak lennie ezért szerintem szép sima jelet is összehozhatsz. Természetesen nem kell megállnod a másodrendű szűrőnél, további RC tagok hozzáadásával (ugyanezzel a tízes módszerrel, R*10, C/10) tovább építheted a szűrődet harmad, negyed és így tovább rendű szűrővé. Nézd meg próbanyákkal, milyen lesz a jeled és ott állj meg ahol elégedett vagy az eredménnyel.

Ha nézed szkóppal, tegyél fel képeket. A többieknek is hasznos lehet.

Volna még egy kérdésem, igaz nem ezzel kapcsolatban. A millis függvény által visszaadott értéket le lehet-e nullázni?

Nem. Az azt tartalmazó változó private és nem elérhető emiatt kívülről (ha csak nem írod át az alapkönyvtárakat persze), gyakorlatilag egy változót növelget egy megszakítással és annak az értékét adja vissza, amikor a millis függvényt hívod. De minek nullázni? Elég ha tárolsz egy nulla pontot (millis értéke a nullázáskor) és kivonod a millis értékéből és máris van egy "nullázott" adatod.