Ha már 8051-es oldal, ADuC812-ben van ADC meg DMA, ami 1 utasításra behúzza az ADC adatokat a RAMba (200kHz/12bit), onnan "csak" ki kell vinned a grafikus LCDre. Van a családban ARM magos cucc is. Viszont az érdekelne, hogy tudtok-e olyan AVR-t vagy kisebb ARM-et, ami tud kezelni 4-bites mono LCD-t. Tehát 4-bitenként fogadja a pixeladatokat az X-shiftreg, ha kész, akkor az Y-shiftregiszter lép egyet. Eddig SED1330-al volt hajtva, de amellé kell külső RAM. (van 512x64-es LCD-m pár kiló, valamire csak használni kellene...)

Sziasztok!
Szeretnék megosztani egy kódot, ami úgy gondolom, elég hasznos.
Gombkezelést valósít meg, három gombot figyel egyszerre. 10mS-ként fut le, és három db. 8bites változóba monitorozza a gombok állapotát. Ha a minta úgy néz ki, hogy minimum 40mS-ig le volt nyomva a gomb, majd 30mS-ig fel van engedve, csak akkor értelmezi a függvény valós gombnyomásnak. Ezután beállít egy változót, hogy gombnyomás történt, amit majd egy másik függvénynek kell lekezelnie, feldolgoznia, majd ha megtörtént, akkor annak le is kell nulláznia. Így ha csúszik is kicsit a végrehajtás, amint utoléri magát a proci, azonnal végrehajtja amit kell. Ez amolyan buffer funkció. Szoftveres prellmentesítés is történik, azzal sem kell foglalkozni.
Használata: egyszerűen be kell rakni a main loopba, és ügyelni kell rá, hogy a main pörögjön folyamatosan, ne álljon meg sehol. Ez könnyen megoldható, ha minden függvény ugyanilyen előző és period változókkal ellenőrzi, hogy le kell-e futnia. Én pl. DS18b20-nál is külön választom a két állapotot, az elsőnél lekérdezem a hőmérsékletet, majd 1mp-ig nem piszkálom, fut a főprogram. 1mp után pedig csak lekérdezem a hőmérsékletet.
Ezt a függvényt be lehet rakni interruptba is, ha valakinek úgy jobban tetszik, nálam az interruptnak elsődleges funkciója van, nem késhet, viszont ha a gombnyomást 1-3mS-ma később ellenőrzöm, nem történik semmi.

Változók:

Üdv!

Globális változóimat szeretném egy tömbbe helyezni. Ezt eddig úgy próbáltam kivitelezni, hogy létrehoztam egy tömböt, majd definiáltam a tömb adott byte-jához egy nevet, valahogy így:



Azonban úgy tudom, hogy nagyobb változók(int, long) hozzáadása már problémás.
Ekkor találtam meg az union-t. Böngészgetéssel ezt hoztam össze:



A gubanc nálam ott kezdődött, amikor megpróbáltam a date_time union-ját a g_reg_a[] tömbbe beilleszteni. Ez alatt azt értem, hogy egy meglévő union-t illesztenék egy másikba, valahogy így:



Ha union helyett typedef uniont használok, akkor a fordító elfogadja, de nem kerül bele a g_reg_a[] tömbbe.
Egyáltalán lehetséges amit szeretnék? (Meglévő létező union-t egy másikba rakni.)

Még egy felmerült kérdés.
Lehetséges union-ba 2D-s tömböt rakni?
Erre gondolok:

Na srácok, leírom, mi történt.
Olyan nagyon segítőkészek vagytok, hogy tùlgerjedt a téma, mint egy végfok
Szóval!
Autóvillamosságéknál(!) nagyon sok szenzor +5V referenciafeszültséggel működik.
Egy AVR mikrokontroller akár milliszekundumonként is tud mintavételezni 1 darab analóg bemeneten 10 bites felbontásban 0V és +5V között. Ez nekem nagyon tökéletes!
Így támadt az ötlet egy igazából nem valósidejű tárólós DC szkóp megépítéséhez. És készen vagyunk.
Nem tudom kihasználni a 20 meg 60 MHz-es méréstartományokat, legfeljebb a gyújtásrendszer primer- és szekunderkör vizsgálatánál.

9V-os elemről fogom akkor hajtani az áramkört, köszi a tippet
Köszönök mégegyszer mindent, mint lelkes hobbista! Ezért jó ez a fórum!

Nemsoká' készen áll az 'oszcilloszkóp' alapötletem gyakorlati lenyomata, melynek kimenete végül egy CSV állomány lesz, ha szabad így nevezni. Közzéteszem, amint kész és MÉGEGYSZER köszönöm a linkeket és tanácsokat Mindenkinek!

Addig is:
Lehet volt már téma, neten is sok írást találtam róla, de kifejezetten az én problémámra nem.

Azt a bizonyos elterjedt 4X20 karakteres alfanumerikus kijelzőt I2C soros modullal hajtom AVR-re kötve. A háttérvilágítás így alapból szoftveresen nem állítható fokozatosan. Van egy jumper a modulon, ez mintegy kapocsoló működteti a háttérvilágítás ledjeit 20mA áram mellett.
Jumper le,, majd az AVR egyik PWM lábát rákötöttem a jumper pinek egyikére 220 Ohmos ellenállást is beiktatva. Megvan a fényerő állítás, viszont 5V-ról direktbe nem működik.



Valakinek tapasztalata erről, hogy miért csak PWM jellel működik?
Ha majd nem lesz ötlet, akkor leforrasztom az LCD-ről az I2C modult és majd én vezérlem külön 15-ös lábat (LED+) egy külön digitális pinről.

Azért nem működött direkt +5V-ról a háttérvilágítás, mert lemaradt a pinmód beállítás.

Így gondolom a belső felhúzóellenállás beleszólt az áramkör működésébe. Pf..

Tárgytalan. Már megoldottam.

Elkészült a az alap felállás. A CSV fájlt a Multiecuscan programba importáltam be.
5 ms-os léptékben zajlott a mintavételezés egy fotóellenállás+ellenállás feszültségosztóról.
Szőrös a jel, de lehet a fotoellenállás miatt, lehet a táp miatt, ma már nem próbálom ki mással.

Tiszteletem! Megkérdezném a tisztelt kollégákat, hogy találkoztak már olyan anomáliával, hogy egy prociban(Atmega1284P) amit bootloaderen keresztűl programoztam fel, egy idő után eltűnt vagy 20 sornyi kód. Visszakaptam egy hardvert javításra, mert nem csinált semmit illetve csak a bootloader futott rajta, mert a led villogott rajta, hogy a bootloader várja a programot. Kiolvastam és megvolt a program, de az eleje hiányzott, csak $00-ák voltak benne, de utána folytatódott a program. Létezik ilyen, hogy kitörlődik a program eleje? Köszönöm

Hasonlóval, egyszer, más típusú kontrolleren, a checksum érték nem stimmelt. A hiba forrása ott masszív tápfesz. ingadozás volt.

Köszi! Utánakérdezek!

Olyat már láttam hogy a bootloader "magától" elindult és felírt pár bájtot mert azt hitte, éppen kommunikáció zajlik közte és a PC-s program között. Persze csak figyelni kellene a "data overrun" ill. "frame error" biteket, esetleg valami épeszű keretezést adni az átvitelbe. Ja és egy valamire való bootloader (és PC-n futó párja) csinál verify-t, lehetőleg a teljes tartalom beégetése után.

Helló.
Viccek mókás történetek témából válaszolnék egy hozzászólásra:
Bővebben: Link

Szia.
Pedig a programban volt a hiba. Nem ellenőrizted az adat helyességét, minimum egy ellenőrző összeg kellett volna. FF-et sosem használunk, sehol. Ha a kábel szakadt, vagy zárlatos mondjuk a tápfeszültséghez, akkor csak FF-et tudsz kiolvasni. 8db egyes a lehető legrosszabb eset. EEPROM-ba pedig én úgy mentek, hogy 3 különböző részt kiválasztok, mindháromra mentek. Visszaolvasásnál mindhármat kiolvasom, és összehasonlítom, hogy ugyanazok-e. Ha az egyik különböző, akkor a másik kettőből még ki tudom következtetni az eredeti adatot, de itt már jelezni kell, hogy gond van. Minden programoz úgy kell megírni, hogy minden egyes hibalehetőség le legyen kezelve. Az EEPROM már engem is szivatott meg. Ha elmegy a tápfesz, mikor írsz, akkor más lesz lementve, mint amire szükséges van. Ezért még pluszban ellenőrizni is kell, hogy egy változó értéke az érvényes tartományon belüle van-e. Pl. ha csak 0-100-ig mehet, akkor 100 fölötti érték esetén észre kell venni, hogy hiba van, és cselekedni. Valószínűleg a program nincs felkészülve a 100-nál nagyobb értékre, és könnyen hibára futhat.
Érdekes dolog, pl. ha készít az ember egy órát, vagy csak simán számolja a mS-kat (pl. Arduino millis() függvény), hogy mi történik, ha az unsigned long változó túlcsordul? Pont a napokban teszteltem egy órám. Kb. 47-50 naponta csordulna túl a változó, viszont könnyen előfordulhat, hogy ennyi idő alatt nem történik áramtalanítás, és folyamatosan működik az óra. A változóm kezdőértékét beállítottam 2^32-4000 -re, így hagytam 4mp-et a túlcsordulásig, és figyeltem. Megállt az óra, semmire sem reagált, hiszen a feltételek sosem lettek igazak. Be kellett raknom egy plusz függvényt, ami elindítja a watchdog timer-t, és reseteli a kontrollert. Lehetett volna nullázni is minden változót, de abból túl sok van, és ha egy kimarad, az elég nagy gondot okozna.

Szia!
Kissé félrement a hozzászólásom. A PIC kezdőknek rovatba szántam.
A programról csak annyit, hogy valóban elmulasztottam leellenőrízni, mit olvasott ki az EEPROM-ból, de az biztos, hogy hibás az az egy byte. Ugyanis 75 byteot mentek az EEPROM-ba, és a kérdéses byte a 36. volt a sorban. Sajna komolyabb ellenőrzéseket nem áll módomban végezni adatküldéskor, mert még így a felgyorsított 1-wire-vel is necces a futási idő. Legrosszabb esetben 1,5 msec alatt fordulnia kell a programnak.

Nem annyira ment félre, mint gondoltad.

A Chipcad-nél láttam egy Atmel procit a kirakatban és meg is kérdeztem, hogy ezentúl Atmel chipeket is fognak árulni? Mert hát a Microchip felvásárolta őket...

Azt mondták, hogy év végére már lesz az is raktáron.

Az árazásuk lesz a bónusz meglepetés rövidesen. Microchip-től szeretettel

Sziasztok!

Mitől van az, hogy a kódomban az 1,5mp időzítés kb ezzel egyenlő: _delay_ms(150); A kvarc 16MHz-es. Az avr studióban a projektbe be van állítva a 16MHz ill. a kódom is tartalmazza a a legelején #define F_CPU 16000000UL -t, mégis érezhetően lomhán fut a kód.

A 8-as CPU órajel osztást kikapcsoltad a FUSE bitek között?

Köszönöm, megoldódott. Hibás fuse bit volt beállítva.

De ezzel az időalapba is tettél egy plusz hibát.( minimum a reset idejét késni fogja.) Gondolkodtam a millis() függvénnyel hogyan lehetne korrektül megoldani, de nem igazán jöttem még rá.Talán úgy lehetne, egy másik ugyan ilyen típusú változó értékét mindig 1000 (1s) el növelve hasonlítani a millis eredményét, ha több akkor eltelt egy másodperc lehet az órát léptetni. Ha túlcsordul, ott van némi gond mert a relációt egy ciklus idejére meg kell fordítani. ott átmeneti ideig 1s -t téveszteni fog ( szerintem).
Ha pontos óra kellene inkább valamiféle külső óra ic-t választanék.(az ezekhez gyártott kvarcok stabilabbak)

A főprogramban ellenőrzöm az unsigned long változó értékét, tehát csak akkor visz be hibát, amikor resetel. De megjegyzem, a 16MHz-es kvarccal sosem fogsz tudni atomórát építeni, sőt. Még RTC-vel sem tudtam elérni megfelelő pontosságot, csak ha hosszabb időn keresztül figyelem, hogy pontosan mennyit siet/késik az óra, és beépítem a programba ennek a korrigálását. Általában DS1307-tel dolgozok, de ahány kvarccal próbáltam, annyiféle irányú, értékű hibát találtam. Esetleg az az IC, amiben benne van a kvarc, és gyárilag trimmelt, talán az adna megfelelő pontosságot, de az az IC meg böhöm nagy (ha tudod melyikre gondolok). Ebay-en lehet venni pár $-ért komplett nyákot, elemtartóval, mindennel.

Nem vagyok a téma szakija, de már foglalkoztam ilyesmivel, PIC - AVR frekvenciamérő. Ott is fontos a pontosság, és jellemzően a kvarc pontossága- trimmelhetősége. Szóval a kérdés az, hogy óra építés esetén használsz -e trimmerkondenzátort a frekvencia beállítására? Igaz, hogy a hőfokfüggés még megmarad, de erre is van megoldás, csak több alkatrész, és kísérlet kell hozzá, ha egyedit tervezel és nem valami járt utat használsz fel. Vagy jó megoldás, külső tokozott kvarcoszcillátort használni. Vagy leméred pontos frekvenciamérővel, hogy az üzemi hőfokok tartományában mennyi frekvenciaingadozás, és átlagot számítva ezt adod meg a program alapértékének f_osc ... Ebből matekozik a program. Ha minimális alkatrészmegoldást szeretnél.

Régen építettem intel 8048-al saját kvaccal, azután piccel saját kvarccal, utána óra ic-vel órakvarccal, majd egy szerintem általad is javasolt modulkával, az utóbbi volt a legpontosabb .óra állítástól állításig talán még egy perc tévedés sem. Amit egy karóra kapcsán állapítottam meg, akkor hajszál pontos volt ha fele időben kézen fele időben a polcon volt. Folyamatos polc esetén már havi 3-5 s tévedést is összehozott. tehát a hőmérséklet stabilitás nagyon fontos, az összes többi korrigálható de azt csak jó minőségű alkatrészekkel lehet biztosítani. (bár úgy látom ebben már több tapasztalatod van, és te sem támasztasz irreális várakozást a millis()-hez.)

Nem nagyok akarok beszállni a vtába, de ha pontos óra kell, inkább központi vezérlésű jellel kell dolgozni (DCF77 [itthon bizonytalan], GPS, NTP stb.).

Szia ! Az R2025S ic-t próbáltad már?

Nem használtam még. Ahova a DS1307 is be van építve, ott is elég nagy a hőingás, szobahőmérséklettől indul, és 10-15fokC-szal is simán lehet az IC. Tehát már ez a hőingadozás is befolyásolja a pontosságot.

ATMEGA 32 chip-et szeretnék irni , kinai programozóval. Viszont a gond az, hogy az eeprom irása nem megy, felprogramozza, de viszont ellenörzéskor hibát jelez. Probáltam Khazama-val, illetve Extreme burner-el is. Mi lehet a gond ?

Bár nem írtad milyen programozóval próbáltad, az usbasp szoftverét régebben frissíteni kellett használat előtt. Én az avrdudest szoktam használni.
Amit még elkövettem, megesett, hogy a kódvédelmet, vagy valamely egyéb konfigbitet rosszul állítottam be, aztán csodálkoztam miért nem fogad szót többet. ( az égetés sikerült, talán túl jól is)

ilyesmi programozót használok :
Bővebben: Link

persze ilyet rendeltem, de kicsit másmilyet küldtek .
Amúgy ezt a frissitést hogy értsem ?

Ez volt az, bár mintha programozni sem lehetett volna vele frissítés nélkül, vagy csak bizonyos beállításokat nem szeretett erre már nem emlékszem. A programozásához mintha másik programozó kellett volna.