Ez igy elegge tag. Pl. ezt szoktak ilyenre hasznalni.

Raspberry Pi

Hát igen ez azért eléggé nem lowcost
Képfeldolgozás alatt arra gondoltam, hogy elég ha mondjuk 0,3 másodpercenként kiértékel egy képet. Mivel még ilyet nem csináétam nem tudom hogy pl. egy ARM11 elég-e erre a feladatra? pl ez: http://www.arm9board.net/sel/prddetail.aspx?id=348&pid=200

Nekem már van Pi-m, de még a fiókban van. Csak megnézés fázison esett át. Ez nagyon off...

Hat attol fugg, mit szeretnel kiertekelni. Egy jobb kepfelismero program (rendszam es auto pozicijanak erzekelese) egy kozepes Pentium 3 konfigon fut el. Az Atmel termekei kozul a SAM9-es ARM-ok viszik a linuxot. Viszi az AT32AP is, viszont ez a termekvonal megszunik, mert csak a sajat ARM-jaiknak csinalt konkurenciat.
Esetleg ha jobban erdekel az FPGA, akkor vehetsz Spartan6-os fejlesztopanelt. Egy XC6SLX45-os FPGA-ba belefer egy softcore proci (LEON3), amin fut a linux es meg szabadon marad az FPGA fele. Egy ilyen panel kb. 180 euro+tapegyseg.

FPGA-t annyira nem szeretem, tudom gyorsabb meg rengeteg előnye van, csak egész egyszerűen nekem nem szimpatikus, illetve nincs is akkora tapasztalatom benne, hogy nyugodtan neki merjek vágni.
A szavaidból azt veszem ki, hogy az általam linkelt konfiguráció már tökéletesen elég arra a célra amire nekem szükségem van, árban is korrektebbnek tűnik.
Még sosem használtam LINUX-ot futtató magot, szóval ezért is tettem fel a kérdést. De mivel tudom, jól, hogy ebben van a jövő, szeretném odahaza kisebb feladatokra is használni.
Első körben egy egyszerű valamilyen szenzor parkot telepítek a szobába és annak a kiértékelt eredményeit küldeném egy webes felületre mondjuk. A lényeg hogy ezzel foglalkozzak kicsit. Későbbiekben az lenne a cél, hogy képfeldolgozásra kiértékelésre használjam.

Hát, nekem az AVR fordító csinál érdekes dolgokat.

uint8_t portbit=2;
PORTB |= _BV(portbit);

hivatkozást ahogy láttam 16 biten fordította. Pedig sem a PORTB sem a portbit nem 16 bites.

Esetleg megprobalhatsz kinabol rendelni valami olcso cortex a8/9/10/11 alapu SoC-cal felszerelt androidos modult. Vagy a vegen marad a raspberry, ha van fel eved varni a megerkezesre

Az AVR utasításkészlete (azaz 1 elemi utasítás) 16 bites(2 bájt). Mi is itt a kérdés?
Ja igen: ha változót definiálsz, azt az SRAM-ba teszi, pontosabban a STACK-re.
Ez 2 vagy 3 utasítás. Ha közvetlen utána írod a PORTB-re, 1 utasításba belefér(optimalizál).

AVR-libc FAQ:

Why does the compiler compile an 8-bit operation that uses bitwise operators into a 16-bit operation in assembly?

Bitwise operations in Standard C will automatically promote their operands to an int, which is (by default) 16 bits in avr-gcc.

To work around this use typecasts on the operands, including literals, to declare that the values are to be 8 bit operands.

This may be especially important when clearing a bit:

var &= ~mask; /* wrong way! */

The bitwise "not" operator (~) will also promote the value in mask to an int. To keep it an 8-bit value, typecast before the "not" operator:

var &= (unsigned char)~mask;

Ha a -mint8 kapcsolot megadod az avr-gcc-nek, akkor 8 bit az alapertelmezett.

Hát, ezt kihagynám. Az intnek azért legyen rendes mérete. Inkább kasztolgatok.

Mondjuk ez nekem 8 bitesnek fordul le. Siman sbi 0x18,2 lesz a produkalt kod. (-O2 mellett)

> sbi 0x18,2

Hát, akkor valamit nagyon elírtál. Próbáld a kettőt változóba rakni, úgy hogy véletlenül se optimalizálja ki.

for(i=0; i< 7; i++)
PORTB |= _BV(i);

Én -Os-t használok, 4.3 vagy 4.4 alól. Állítólag a 4.7-től már a hiba javítva van. Mindenesetre nekem mindig 16 bites, a kasztolás sem segített.

És ha ezt tennéd ki?

Valtozoba raktam, es ugy csinalta. Nem irtam el rajta semmit. -Os es -O2 is ugyan ezt az eredmenyt adja. A verzio 4.7.0, de minek hasznalna az ember regit, ha az hibas...

Ha változó lett volna, nem pedig konstans, akkor nem sbi 0x18,2-t fordított volna.

Mondom, hogy valtozoban volt, raadasul a main fuggvenyen kivul deklaralva. Egyszeruen kioptimalizalta. Vedd figyelembe, hogy masodik alkalommal kicsit mas kodot irtal le.

Megneztem a for ciklussal is. Ott is optimalizalta, egyedul egy movw maradt benne a kezdoertek betolteskor, de az aritmetikai muveleteket, stb. mar 8 biten vegzi. A movw es a mov ugyan ugy 1 orajel alatt lemegy...

Oké, pongyola voltam. A nem jel (hullám) nem jött át megfelelően, azt javítsátok.



A remekmű fordítás után:

Fura. Nalam ez:

Igy fordul le:


Szerintem terjel at a 4.7.0-ra.

Hello!

Azt szeretném megtudni, hogy az ADC mintavételezési sebességébe bele kell-e kalkulálna azt, hogy 13 ciklust vesz igénybe egy konverzió?
Ha a mikrovezérlő 8MHz órajellel működik és az ADPS biteket úgy állítottam be, hogy 64-el ossza el, akkor az ADC mintavételezés frekvenciája 125kHz. Ezt még el kell osztanom 13-mal vagy nem?

Az a 125kHz az ADC orajele es nem a mintavetelezes frekvenciaja. Az ADC-nek 13 ADC orajelbe kerul, mig csinal egy konverziot. Azaz el kell osztani 13-mal.

Köszönöm!

Free running módhoz tudtok jó leírást?
Egy FFT algoritmushoz szeretnék megtölteni egy N hosszúságú tömböt mintákkal.
Jelenleg így csinálom:



Úgy gondolom hatékonyabb lenne ha csak akkor vételezne újabb N számú mintát ha már az előzőn lefutott az FFT.

Szerintem inkabb hasznaljak ket puffert, es amig az egyiket az ADC megszakitasaval toltod, addig a masikat tudod szamolni. Csak arra kell ugyelni, hogy ne gyujtsel gyorsabban adatot, mint feldolgozod vagy szemaforokkal szinkronizald a ket muveletet. Nem tudom milyen mennyisegu adatot szeretnel igy feldolgozni, de igazabol erre mar inkabb az AVR32 valo, mert rendelkezik DSP utasitasokkal es peldaul a szorzas+akkumulacio egy utasitassal megvan.

Interruptot rendelsz hozzá ami letárolja a mért értéket, majd újra elindítja a konverziót.
A hardveres free-running lényegében annyi hogy az ADC kiolvasásakor új ciklust indít, semmi komoly.
Ezt Te magad is megoldhatod, így nem kell free-running módba kapcsolni.
Ha így teszel akkor interruptból le is állíthatod: "ha X minta van, nem indít új konverziót"

Nem kell feltétlenül interruptot használni, ha a mintavételezés alatt nem csinál mást a cucc.

Mintavételezés: 20ksps-nél NE állíts be nagyobb mintavételi frekit mert hibás lesz az eredmény!
Tehát 8MHz esetében az előosztó minimum 8000000/13/20000~=30 (tehát 32).
Ha 2 csatornát felváltva használsz...
1: arányosan csökkenteni kell a mintavételi frekit: max. 10ksps 2 csatornánál, 6.6ksps 3 csatornánál...
2: az ADMUX beállítása és új konverzió indítása között legalább 300us-nek el kell telnie!

Az eredmeny mindig hibas, csak kerdes, hogy mekkora merteku a hiba Nyilvan az ADC orajel csokkentesevel csokken a hiba.

Köszönöm a válaszokat.

ATmega2560-ason írom, egy csatornát használok.
Jelenleg így néz ki. Gombnyomásra indul és áll le a folyamat azért van megszakítás.
Elméletileg nem csinál semmit mintavételezés közben, akkor ez azt jelentené, hogy nem szükséges az ADC megszakításokkal való kezelése?



A problémám az, hogy az FFT algoritmus helyes spektrumot ad ha olyan tömbökön futtatom le amiket én töltöttem fel szinusz/négyszög/háromszög hullámoknak megfelelő értékekkel, viszont ha egy függvénygenerátort kötök rá és valós jeleket adok az algoritmusnak, helytelen spektrumot kapok.
Azt tudom, hogy a mintavételezési frekvenciának legalább duplájának kell lennie a mérni kívánt jel frekvenciájánál. A mérést ennek megfelelően végeztem, számításba vettem azt is, hogy az ADC órajelét el kell osztanom 13-mal de így sem jó.
Nem tudom mi lehet a gond.

A megszakitas akkor celszeru, hogyha a konverzio alatt is szeretnel muveletet vegezni. Ha nem, akkor az "ADC Noise Reduction Sleep" hasznalata a celszeru, mert pontosabb lesz a mintavetelezett jel erteke.

Kulso jelforrasnal eloszor szerintem ne az FFT-t probald, hanem rajzold ki a memoriaban levo jel alakjat, igy lathatod, hogy a mintavetelezessel minden rendben van-e.
Az analog bemenetre mindenkeppen tegyel egy alulatereszto szurot, aminek a vagasi frekvenciaja a mintavetelezesi frekvencia fele. Altalaban ez szokott hibat okozni. Ezen felul a kvantalasi zaj miatt mindig lesz valamennyi hiba, de ez eleg kicsi es elvileg egyenletes eloszlassal jelentkezik a teljes spektrumban.

Ablak függvény alkalmazására is gondoltam de azt nem nagyon tudom, hogy kéne megvalósítani.