Attól még nem biztos, hogy jó a 2 x 47pF !.
Az IC. adatlapja sem mond többet 22pF-nél, 16MHz esetén.
2 db fix 22pF-el ki kellene próbálni.

Trimmer??? Mióta?
47pF már "megfogja" a kristályt, nem tud berezegni.
Nézd csak meg jobban az adatlapot, vagy keress rá guglin hogy kell bekötni a 2x22pF kondikat!

Ez csak frissítés kérdése bármely Atmega típusú processzor gyári adatait be lehet írni a műveletet végző jelen esetbe Atmega8 ba , és ettől kezdve tudni fogja azt is.
De egyébként volt rá példa , hogy az említett órajel generátor sem segített , de a fuse bit doktor igen .

Tévedsz.
Támogatja. HVPP fusebit doctor

Sziasztok!
Van egy 128x64-es kijelzőm. Szeretném tárolni a kijelző képet egy Mega16 memóriájában, elméletileg ugye az SRAM pont elég is lenne a célra. Viszont ugye elég nagy probléma, hogy az SRAM végén tárolja a visszatárási címeket. Milyen megoldás lehetséges arra, hogy mégis elérhető legyen a teljes 1024 byte-nyi memória, de mégis lehessen használni is a megszakításokat, szubrutinhívásokat, stb...
Lehetőleg nem szeretnék külső memóriát használni.
A programmemóriát lehet ilyen tárolási célra használni? Tudja írni/olvasni a saját programmemóriáját?
Kiborg

Gondolom nem tükrözni szeretnéd a kijelző képpontjait az SRAM-ba, hanem előre elmentett képeket akarsz kitenni AVR-ről a kijelzőre. Ha az utóbbi igaz, akkor nézz itt körül: Progmem

Az lenne a célom, hogy adott képet megrajzolok gyorsan a memóriában, (pl: sok vonal, kör, stb), majd egyszerre kirajzolom a kijelzőre (tehát tükör lenne) , mivel egy-egy gyorsan megvan, de egy alakzatnak viszont sok pontja vagy, így sok időbe kerül, amíg ki tudom rajzolni. Remélem érthetően fejeztem ki magam.
ui: közben meg rájöttem, hogy ilyenre a program memória nem használható a véges írási ciklusszám miatt, tehát maradna az SRAM, de hát ott meg a verem....

Hát igen, a programmemóriát hamar lerongyolnád.
Ha jól értem, akkor 1024 byte SRAM -od van összesen, és minden byte-ra szükséged lenne, hogy grafikát generálj benne.

Röviden: Lehetetlen.

Hosszabban: Ha a linker scriptet átírod, nem használsz egyáltalán függvényhívásokat, akkor esetleg megoldható. Persze assemblyben kellene megírnod a programod.

Akkor jól gondoltam sajnos.
Assemblyben nyomom, szóval el nem gond. Na de hogy ne használjak függvényhívást, ne legyen szubrutinom, és MEGSZAKÍTÁSOM sem, az már viszont túl sok áldozat
Valami kici occó SPI-s memóriát tudsz ajánlani ?
(úgy néz ki, hogy nincs más megoldás)

Nem érdemes LCD kijelző tartalmat az SRAM-ban tárolni.

Én az SRAM-ban nem a tartalmat tárolom, hanem hogy hogyan kell azt reprodukálni.
Vannak callback függvények, amik egymás után meghívódnak és felépítenek egy 8x8-as cellát.

Ha kiraksz egy sprite-ot/szövegdobozt/keretet valahova, akkor az összes 8x8-as cella, ami érintve van, újra lesz számolva.

Több callback is van: az egyik grafikát rak ki, a másik keretet, a harmadik szöveget,...
Ha érvénytelenítesz egy cellát, akkor az összes callback egyesével meghívódik.

Kb. 0 memóriafogyasztással csináltam ablakozást.

A program memóriára 10.000 írás van garantálva, az EEPROM-ra 100.000. Relatíve gyorsan haza fogod vágni, ha erre használod. És arról még nem is beszéltünk, hogy ez mennyire lassú lenne...

Egyébként a Mega32 pin kompatibilis a Mega16-tal és 2k memóriája van. Elfér benne 128x64 és még 1k marad is.

Szia!
Ez is megoldás, bár sajnos ilyen chipem nincs itthon
Az a gond, hogy a kijelzőn nem egyesével lehet kapcsolni a pontokat, hanem 16-osával. Ergó ha csak egy pontot kapcsolok be (mondjuk a 15.-t a többi meg 0) és be szeretném kapcsolni a 12. pontot, akkor tudnom kell, hogy a 15. is be van kapcsolva, ezt vagy kiolvasom a kijelző memóriájából(ami sok idő) vagy csak memóriában írom át (így megspórolok egy olvasást).
Egyébként egy ST7290-es vezérlővel dolgozom. Nem túl gyors jószág

Ha van olyan része a képnek, ami mindig ugyanaz, akkor azt nem kell letárolnod (logo, üres rész,...). Ezzel nyersz annyit, amennyi a stacknek elég lesz. A globális változókat meg regiszterekben tárold.

Az r2-r15-ig lehet regisztereket használni változónak, r2-től indulj felfelé.

Univerzálisat szeretnék, amit csak egyszer kell jól megírni, a teljes területet lefedi.
ASM-ben programozok, mindent regiszterekben tárolok
Tudsz esetleg valami jó kis RAM-ot, ami kici occó 5V-os és SPI-s.
Elég kritérium

Most univerzális, vagy egyedi megoldást akarsz?

Ha univerzálisat, akkor felejtsd el az Atmega16-ot. Ha egyedit, akkor meg Atmega16-ra optimalizáld szét az egészet, hogy 1k-ba beférjen 1k + stack.

Atmega16 (DIP-16Mhz) - 1225 Ft
Atmega32 (DIP-16Mhz) - 1525 Ft

A teljes különbség DIP esetén árban 300Ft, más tokozásnál még ennél is kevesebb!
Ha már vásárolni kell, akkor az Atmega32 legyen RAM helyett, legalábbis szerintem.

Mitől lehet, hogy winavr-rel az alábbi hiba üzenetet kapom, úgy hogy minden h fájl be van includolva?

main.c: In function 'main':
main.c:10: error: 'DDRA' undeclared (first use in this function)
main.c:10: error: (Each undeclared identifier is reported only once
main.c:10: error: for each function it appears in.)
main.c:11: error: 'PORTA' undeclared (first use in this function)
make.exe: *** [main.o] Error 1

Process Exit Code: 2

Rossz MCU define van valahol, valszeg a makefileban. Emiatt nincsen DDRA, mivel olyan ioxxx.h filet includeolt a precompiler, amiben nincsen DDRA.

Az mcu jól van beállítva, olyan mintha egyáltalán nem látna h fájlokat.

Sziasztok!

Adott egy attiny2313 ami felprogramozásra került, és a fusebit-ek úgy lettek beállítva, hogy külső kvarcról kapjon órajelet.

Ez azt jelenti, hogy kvarc nélkül nem tudom újraprogramozni, sem pedig a "chip id"-jét kiolvasni a programozómmal?

(A régi kapcsolás, panel már nincs meg, szeretném másra használni a uC-t.)

Igen, azt jelenti.

És ha sejtelmem sincs, hogy mekkora kvarc volt eredetileg, akkor mekkorát tehetek oda biztonsággal?

Legegyszerűbb ha betartod amit az adatlap mond.
Szerintem 1Hz -től 16MHz -ig mehet minden.

Köszönöm a segítséget, működésre bírtam! (5Mhz kvarc/10p kondikkal)

Akkor valami elérési gond lesz.
PATH meg lett adva helyesen?
Szóköz van a WINAVR telepítési útvonalában?

Hali,
írtam egy olyan programot amiben egy atmega 168 3 pwm csatornáját szabályozom, és kiírom egy 3310-es kijelzőre. Proteusz szimulátorban tökéletesen működik, de a megépített hardverben nem csinál semmit. A hardver tuti működik, ha kitörlöm a progiból a másik 2 csatorna szabályozását akkor jó. Mi lehet a hiba?

Igen az elérési út volt a gond. Köszönöm a segítséget.

Az E-bay kínálatában figyeltem fel a Meduino Nano Enhancement kártyára, amely dugaszolós próbapanelhez ideális. Van ATMega 168 és 328-as változata is (természetesen benne van a bootloader).

Jellemzői közül kiemelésre érdemes, hogy 3,3 V és 5 V között átkapcsolható. Van az alján egy FTDI USB-UART protokol konverter is, amellyel a programletöltés egy kattintással végezhető (az #RTS kimenet egy 100 nF-os kondival rá van kötve a RESET lábra, így nem kell nyomkodni a RESET gombot.) A PWR, RX, TX ledek mellett a D13-as lábra is csatlakozik egy negyedik LED. Kezdéshez szerintem kitünő (és viszonylag olcsó) eszköz. Arduino IDE beállításánál "Arduino Nano" nevet kell kiválasztani a Tools/Board menüben.

Egy avr-gcc kérdésem lenne:

Logikai jelanalizátoron dolgozom és minden órajelciklus számít. Minél gyorsabban fut le az interrupt, annál gyorsabb jelváltozásokat is észlelni tudok. A jelenlegi interrupt 32 ciklus alatt lefut, amiből 7 ciklus az interrupt meghívása.

4 ciklus az interrupt hívás, amit egy 3 ciklusos JMP követ (atmega328P) az interrupt táblában. Ha ez JMP helyett RJMP lenne, akkor nyernék egy órajelet. A kérdés, hogy el lehet-e érni, hogy a fordító az interrupt táblában RJMP-t használjon JMP helyett?

ahova a jmp megy, oda tégy rjmp-t, és utána egy nop-ot.

Az elvet én is tudom, csak ezt az avr-gcc-nek eddig nem sikerült elmagyaráznom.



Ha bővebben ki tudod fejteni, hogy az interrupt vektor tábla allokálását hogyan vehetem át a C-től, jó lenne.