Ezzel a módszerrel szeretnék Atmega 8A típusú IC-t programozni:
https://www.arduino.cc/en/Tutorial/ArduinoISP

A nanora már kiírtam a programot, és bár még nem tudom, hogyan kell összekötni az IC-vel, de valahol el kell kezdeni a dolgot
Letöltöttem az AtmelStudio szoftvert, hogy megtanulhassam az AVR programozást.

C-ben, és C++-ban is készítettem már programokat, illetve arduinoval is "játszottam" már. Egy kis induló segítséget szeretnék kérni. Hogyan tudnék írni egy egyszerű LED villogtatót az IC-mre ezzel a módszerrel?

Találtam egy AVR-ekkel és Arduino-val foglalkozó oldalt:

http://avr.gamfrobotics.hu/

Ha valakit érdekelne...

http://www.delamancha.co.uk/basic.htm

Sziasztok, új vagyok és nagyon keresem a Bascom könyv letölthető változatát. A TAVIR honlapon is csak hivatkozás van rá, de letöltés nincs.
Ötlet, hogy honnan?
Köszi

A németet néztem meg mélyebben, tényleg jó, köszönöm a linket.

Goto http://www.avrfreaks.net, vagy telepísd fel a WinAVR legújabb verzióját, abban is vannak példaprogramok. Vagy ha értesz németül, akkor itt van egy jó C-s tutorial: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

Sziasztok!

Egy nagyon egyszerű kimenetet és bemenetet kezelő C-s mintaprogramra volna szükségem ATMEGA16-hoz. Tudna valaki segíteni?

Szia!

Először ne csinálj az OCR2 regiszterrel semmi komolyabb műveletet, maximum értékadást, először a PWM működjön.
A következő képpen:

Az adatlapból kinézheted, hogy mekkora órajelen mekkora a PWM frekvencia.
A programodban az a hiba, hogy a TCCR2 regiszternek mindig új értéket adsz.
Több érték megadásához használd a | karaktert: TCCR2= x; TCCR2 |= y;

Sziasztok! El akartam indítani a ATmega8 PWM modulját és nem tudom miért nem sikerül? a kód:

Segítségeteket előre is köszönöm!

#include <avr/io.h>
#include <util/delay.h>



//-------------------------------------
void delay_10ms(unsigned long valm) {
//-------------------------------------
while(valm--) _delay_ms(10);
}

//-------------------------------------
void delay_10us(unsigned long valu) {
//-------------------------------------
while(valu--) _delay_us(10);
}

//-------------------------------------

//-------------------------------------
// 8-bit Timer/Counter 2 initialization
//-------------------------------------
void InitPWM(void) {

DDRB = (1<<PINB3) | (1<<PINB2); // PB3(OC2) PWM output

//Compare Output Mode, Fast PWM Mode

TCCR2 = (1<<COM21) | (0<<COM20);

//Waveform Generation Mode Bit

TCCR2 = (1<<WGM21) | (1<<WGM20); // Fast PWM

//Clock Select Bit Description

TCCR2 = (0<<CS22) | (1<<CS21) | (0<<CS20); // clkT2S/8

TCNT2 = 0; //countert nullázzuk
OCR2 = 0; //komparálási szintet nullázzuk

}






int main(void)
{
InitPWM();
while(1)
{
PORTB=(1<<PINB2);
delay_10ms(10);
if(OCR2==255) OCR2=0;
OCR2++;
PORTB=(0<<PINB2);
delay_10ms(10);
}
}

Hali !

Programoztam már AVR-t jó sokszor jtagicemkII-vel, szóval nagyjából értem mi a dörgés. DE! Otthonra össze aggattam egy soros portra valo programozót: Bővebben: Link
Ponyprog2000 -rel próbáltam programozni 1 ATmega8-at, de nem igazán veszi észre a procit, -24es hibát dob. Annyi a lényeg, hogy a procira csak az ISP lábak vannak bekötve, meg egy ellenállással egy LED. Gyakorlatilag csak egy villogós tesztprogit akarok égeni h lássam megy-e a cucc. De nem. Úgy tudom, és ebben lehet tévedek hogy a procik alapesetben a belső rc oszcira vannak állitva, 1MHz-re.
Miután szenvedtem 1 darabig, bemérgeltem magam és összedobtam az LPT-s 4 ellenállásos "programozót" is. Azzal is ugyanez a helyzet.. nincs ötletem.. valaki ?

(Asszem ma első körben ráaggatok quartzot két db 22pF-el, és kipróbálom hátha..)

Edga'r

Bár a kérdés elég régi. De a problémába gondolom mások is, belefutnak.
Itt részletesen körbejárták a megoldást!: nem programoz az stk200
http://avr.tavir.hu/modules.php?name=Fo ... &start=135
Más témában is ajánlom a fórumot!

Hali mindenkinek.

Most epitettem egy STK200-at, Pony latja, minden szuper.

Kezemben egy ATMEGA8-16PU, ezt csak drotozva is rendesen olvassa, irja.
Masik kezemben egy ATMEGA64L, amire viszont ismeretlen/nem letezo eszkozzel vallat von.

Azon kivul, hogy a 64-es dog, lehet meg ennek valami mas oka?

Elore is THX.

Hello!

A leiras alapjan eleg egyertelmu a dolog. Mit nem ertesz? Az SPI-t magat, vagy az EEPROM mukodeset?

Udv,
Andor

Sziasztok!

Szeretnék AT25160-as SPI eepromot használni mega8-al vagy, de a protocol egy kissé zavaros nekem. Egy kis segítség jól jönne, esetleg példa alkalmazás C nyelven. De bármilyen lehet. Köszi előre is.

nah, beégettem, műxik rendesen. már csak a pure data extern készítéssel vannak gondjaim, de nagyon rajta vagyok. command line ból megy frankón, csak nem szeretek gépelni...

fúúha, nagyon rendes vagy, köszi. erre gondoltam énis egyébként, sajnos egy procit ki is nyírtam, illetve elrontottam az oszci fuse bitjét, de annyit nem ér az egész, hogy külső órajellel tököljek és felélesszem...
tudom h mire való a bootloader, azért köszi az infót. nagyon sokat olvastam az oldalon de ezt a make file os fuse bites dolgot nem tudtam.
még egyszer köszi, szuper rendes vagy!

A uC fuse bitjei jól vannak beállítva? (Oszcillátor típus, boot/normál mód, stb.)
A hex fájlok mellett található makefile-ban az UISP progit használja a betöltésre és ott a fuse bájtokat is megfelelően beprogramozza.
A két hex fájlt össze lehet másolni a hex2bin és bin2hex progikkal.
Mellékelem a fuse beállítást és az összevont hex fájlt:
http://klavi.uw.hu/udmx.zip
A "Config Security Bits" ablakban a megfelelő bepipálgatás után nyomj egy Write-t (a Read-del ki lehet olvasni, hogy mi van benne)

Egyébként a bootloader arra való, hogy a USB-n keresztül tudjál új programot betölteni. Ha arra nincs szükséged, akkor elég Ponyval csak az uDMX.hex-et betölteni és a fuse biteknél a BOOTRST kockát hagyd üresen.

na, megcsinaltam ezt az uDMX cuccot, de valamiért nem akar működni. azt írja a windóz, hogy az usb eszközt nem lehet felismerni, stb, szokásos szövegbuborék. tuti hogy jó az áramkör végigsípoltam mindent, a szoftvert is sikeresen beégettem, ponyprog verify is okét mondott rá. mi lehet a baj?
ja igen, még valami. 2 db hex file om van. ahol találtam ezt a kapcsit azt írják, hogy mind a kettőt be kell égetni. az egyik a bootloader, a másik maga a szoftver. ponyprogban sehol sem találtam olyan beállítást, hogy hagyja békén az előző beégetett cuccot, mindenképp kitörli az egész chipet új égetésnél... ezt hogy lehetne kiküszöbölni? (próbálkoztam a program móddal is, direkt nem pipáltam be az erase-t de akkor is kitörli...

Szerk: sehogysem akar ez működni...
Hol lehet kapni dip tokos atmega8 at? az smc ben csak so tok volt, lehet h az a baj.. mindenesetre kipróbálnám dip-el is.

Szerk2: rámértem az usb adatvonalakra szkóppal. kb 1-1.5 másodpercig próbálkozik miután rádugtam, ezek után csend, és kiírja a win, hogy az usb eszközt nem lehet felismerni.. olyan 2.7-2.8 voltos jelek futkosnak a gnd hez képest a pozitív adatvonalon.

Egy problémával találkoztam. mega162-t használok, abban is a T0 és T1 számlálókat. Ezeket célszerű okokból szinkronizálva kell használnom, vagyis hogy az egyik (T0) ck/64-ról, a másik (T1) ck/1024-ről megy és pontosan ugyanabban az órajelben vált értéket a T1, amikor a T0 felső 4 bitje. Ez könnyen megoldható, ha szinkronban vannak nullázva, amikor a ck/1024-es órajelet kap.

De erre találták ki a "prescaler reset" biteket, viszont ez nekem sem szimulátorban, sem hw-ben nem működik. Hiába olvastam végig a róla szóló részeket a doksiban, egyszerűen nincs hatással a prescaler-re a reset jel. Egyáltalán.

Most sw-ből csinálom, ez így tök jól működik, de tudja valaki, hogy miért nem tudom én ezt a "prescaler reset" dolgot használni, ha már benne van?

valóban megvannak a hex fileok. akkor végülis beégethetem a bootloadert is, utána meg erase nélkül a programot. így firm cserénél nem kell tökölni az égetővel. köszi a helpet.

Nem volt kerek számomra, de belenéztem, amit te nézegetsz, az a bootloader forráskódja. Így már értem miről írsz.
Úgy nézem kihagyhatod belőle a bootloadert, ráadásul megtaláltam a hex fájlokat, nem kell fordítanod semmit. Ott vannak a binaries mappában.

ó, köszi. a második kérdésem nem is igen lényeges.

Leírom még egyszer, hátha..
Tehát, nézegettem a c programot és arra jutottam, hogy amikor elindul a proci, megnézi, hogy milyen címről induljon el. ez egy protr egyik lábára van kivezetve, és egy jumper állásától függően vagy a bootloader indul, vagy a szoftver, ami benne van. (a bootloader az utolsó 2 k -t használja)
A kérdésem az volt, hogy baj e, ha én a bootloadert nem töltöm fel, csak a progit? Szerintem nem.

A progi WinAVR alá íródott, ezzel tudod fordítani. Stk200-at pl. a Ponyprog kezeli. Mindkettő free és fenn a neten.
A második kérdésed nem egészen értem.

ő. megvan a firm is. egy c file. mivel tudok ebből hex et csinálni, és milyen programot használjak az stk200 hoz? (win xp)
a c programot nézegetve azt látom, hogy egy jumper állásának függvényében indul vagy a bootloader címéről, vagy a szoftver címéről.
ha nem töltök rá bootloadert, csak a szofot, nem okozhat bajt ugye? (persze a jumpert nem fogom cseszegetni...

Megépíted, majd a bootloadert beégeted a uC-be. Utána lehet csak működésre bírni.
AVR programozó van a neten vagonnal, talán legegyszerűbb az STK200, keress rá.
Mega8L-t az msc árul legolcsóbban.

Sziasztok!

Szeretnék építeni egy ilyet: http://www.anyma.ch/research/udmx/

Sajnos egyáltalán nem értek az AVRekhez, picekkel már szórakoztam, de járatosnak azért nem mondanám magam a témában.
Az lenne a lérdésem, hogy ezeknél a mikrokontrollereknél hogy működik a felprogramozás? A letölthető cuccok közt találtam az oldalon usb bootloader file-t.. Ha jól sejtem akkor ez a sorrend:
Megépítem a hardvert, felrakom a windowsos drivert, bedugom, bootloader, majd a firmware filet indítom. mind2 exe. ez így ok? Ja igen még egy kérdés, budapesten hol tudok venni ilyen procit? ATMEGA8L-BPU http://lutz.in.hagen.de/cms/images/stories/uDMX/uDMXOben.jpg

Előre is köszi.


Szerk:
Gondoltam belinkelem azt is, hogy mihez kellene ez nekem, így talán tudtok esetleg alternatív megoldásokat is ajánlani.
A lényeg, hogy RGB vagy akármilyen ledeket (vagy bármit) szeretnék vezérelni dmx protokol segítségével, pc ről. 2 programot találtam amit alkalmasnak tartok erre az egyik a MAX/MSP Jitter, a másik egy nagyon hasonló, de freeware program, a neve: Puredata.
http://www.response-box.com/rgblights/index.shtml
Ezen a linken találtam RGB pixel meghajtót, pic procival, ebből építettem is, kipróbáltam DMX fénypultal, hibátlanul működik. Egyetlen szépséghibája, hogy a pixel cím kiosztásához bele kell túrni az asm file-ba és újra buildelni, majd az így kapott hex filet beégetni a picbe, de ez nem okoz különösebb problémát, csak macerás. Jó lenne egy 9DIP kapcsolóval beállítani a címet, de igazából ez nem fontos.
Ami a lényeg tehát, hogy olyan hardver kell nekem, amihez van extern a programokhoz, és teljes doksi van hozzá, az utánépíthetőség miatt. (lehet usb, vagy soros port is..)

Hali!
Munkalehetőség (akit érdekel)

AVR hardver közeli programozót keresünk, elsősorban C nyelvben járatosat.
(AVR GCC) egy távfelügyeleti rendszert fejlesztünk, elég sok mindent magába foglal a dolog (RS-485,RS-232, tápellátás, hőmérséklet-mérés, infra távvezérlés, UPS monitoring, SPI buszos eszközök, stb.)
Hardveres ismeret előny.

jelentkezni a t.cseh(kukac)watt22.hu címen lehet önéletrajzzal.

Üdv:
Ros-Co.

Aham, hát ez szomorú.. Sok éve van valahol egy jtag doksim, de még nem néztem bele. Azt gondoltam eleve azért jó, mert támogatnia "kell" a lácbakötést, de ezek szerint nem.
Nekem sem ártana ilyen lehetőség, bár sorosan programozva csak kapcsolókkal lehetséges. (Mellesleg a két kontrollerem más potenciálon dolgozik, így most nem is merült fel a kérdés )

Hello!

Jtagen lehet progrmozni őket ezt én is tudom. Az érdekelt volna, hogy láncba lehet-e őket kötni, de azóta már megnéztem s nem lehet, mint például a Xilinx eszközöket sajnos.

Hát az adatlapokban benne van, hogy "programming flash,EEPROM etc. through the JTAG interface", szóval kéne tudniuk. Amelyiknek a lapja nem ír róla, az nyilván nem. Bizonyára kell hozzá megfelelő JTAG-kábel vagy efféle. Nézd meg, hátha van valamiféle "application note" az atmel honlapján erről, elég hasznos dolgok vannak ott. (Én épp a "szoftveres USB"-t fogom használni a futó projektemben egy ottani megoldás alapján.)

Hello!

Szerintetek az Atmeleket lehet láncba kötni, s úgy programozni. Tehát mint az FPGAknál, hogy ki lehet választani a JTAG láncban, hogy mely eszközök vannak a rendszerben. Bár az AVR Studioban se nagyon látom, hogy lehetne ilyet csinálni. Csak elgondolkoztam hátha.

Muszáj, mert a kód zöme erősen időkritikus, nem beszélve arról, hogy a C min. 2x akkora kódot állít elő és akkor még méretre optimalizáltan fordítok, a sebesség meg sehol... Én igyekszem kihasználni a kontroller minden utasításának előnyét, amit úgy tűnik sikerül is. (A C-ből fordult kód mindig kicsit "puritánnak" tűnt nekem)

Amúgy semmi bajom a C-vel meg C++-szal, hiszen ez a munkám is. x86-ra muszáj, de oda elég könnyű jó fordítót találni. Egyébként pár CPU-igényes résznél még előjön itt is az assembly lehetősége, mert pl. az SSE-t én jobban tudom használni, mint a fordító (amitől nem is várható el, hogy okosabb legyen nálunk ).

Visszatérve, a mostani AVR-projektem is olyan, hogy úgy használok megszakítást, hogy abból sosem térek vissza (nincs "reti"). C-ben ez kicsit nehéz.
Maradok tehát a szívásnál... egyszer csak kijön egy jó verzió, vagy ha annyira rá fogok érni, írok egy sajátot. (286-ra már írtam anno házi feladat gyanánt )

Én assembly-t utoljára c64 -en használtam, meg egy picit pic-en. Most a winavr-t nyomom, és semmi gondom vele. Nem bánnád meg hosszútávon, ha c-ben programoznál. Vagy ha ragaszkodsz az assemblyhez, a winavr-ben is van assembler és a c kódba is beszúrhtsz inline assemby-t,nem olyan bugos gondolom. Ne szívasd magad, ha nem muszáj.

Egy (már régi) AVR-es észrevétel: aki AVR assemblert használ, mint én, bizonyára nem kevés bugba ütközött.. Folyton javítódik, de "jó" még sosem volt, pedig nem bonyolult, a fordítót még én is megírnám egy hét alatt - talán hibátlanra. :/

A Simulator-ja is elég vacak, az egyes típusok perifériáit itt-ott igen hibásan kezeli. Inkább kerülne valamennyibe és lenne jó, mint ilyen. Na mindegy.. (ver. 4.08-ra vonatkoznak az elmondottak)

Egyedül vagyok, aki folyton emiatt szív?

<példa>
'wait' makrót csinálok, precíz időzítésű kódhoz:
.MACRO wait
.if @0 == 1
nop
.elif @0 == 2
rjmp PC+1
.elif
....
.endif
.ENDM

Ez lefordul, a következőt csinálja:

"wait 1" =
nop

"wait 2" =
nop
rjmp +0

és így tovább. Ami elég gáz... Muszáj voltam végig if-endif-elni, hogy működjön. Elég durva hiba szerintem, hogy a feltételes fordításban ilyenek fordulnak elő. (Nem értettem miért telt meg gyorsan a prg.memóriám és mitől olyan lassú a futás... gyakran használtam wait 8-10-eket, ami igencsak "odacsinált" egyetlen "rcall" helyett)
</példa>

SPI debugolás alatt azt értem, hogy In-System sorosan programozom az AVR-eket (tehát a céláramkörben vannak), ezekhez a SCLK, MISO, MOSI (és persze RESET) lábak kellenek. Úgy debugolok általában, hogy indulás után a kontrollerben ellenőrzöm valameyik lábat (pl. MOSI), és ennek megfelelően vagy rendesen vagy úgy indítom, hogy ezeken a lábakon keresztül beszélgetek a PC-vel, ha úgy van kedvem, ill. parancsokat várok tőle. Ezt a beépített SPI-vel szoktam legújabban (soros master-slave cucc), mert már szinte mindegyikben van és ugyanazok a lábak kellenek hozzá. Írtam hozzá pár rutint, ezeket használom az AVR progijában, a PC oldali programot meg mindig elkészítem, mert ez mindig speciális (az AVR-programozó részt már lib-be tettem, így azt nem kell újraírni).
Szóval nem olyan debug, hogy breakpoint meg ilyesmi.. De nekem bőven megteszi.. a kritikus dolgokat meg szimulátorban ellenőrzöm mielőtt élesben futna.

Az 1541-meghajtó emulátorhoz volt (van) elég jó debug-progim, ott is parancsokkal léptettem előre az emulált 6502 procit, közben az emulált regisztereket, memóriát stb. kijelezte nekem.

A hardware, software az meg az, ami, szóval hogy mit hogy érdemes és mire kell figyelni, ha építesz valamit, hogyan kösd be stb. Ha valami nem világos és én már találkoztam a problémával, akkor szívesen segítek

NickE: a gyári programozó ugye nem áramkörbe ültetve programozza az AVR-eket (tehát nem ISP)? Ha igen, milyen kábel/csatlakozója van (Xilinx-hez van egy ilyenem, 2x5-ös DIL anya csatlakozóval, ilyen a sajátom is egyébként)?

A fuse bitekről annyit, hogy azok nem "fordítottak", ez így normális, hogy 1 az alap és 0 a programozott, mert ez is flash memória (ha jól sejtem), ami így működik. Ettől még az adatlapban szereplő 1-ek és 0-kat úgy kell értelmezni, ahogy azokat a checkbox jelzi (x=1, üres=0).

Nekem erre gyári programozó van, amit BIOS-okhoz vettem, de ismeri az AVR-eket is. Gyanítom, hogy párhuzamosan égeti, de ez nem biztos. Ebben is fordítva vannak a fuse bitek, de értelmesebb, mint a Pony. Így néz ki, Checkboxot ezzel jelölöm [x]
[x] BODEN=0
[x] CKSEL3=0
[x] CKSEL2=0
...

Erről az spi debugolásról írjál légyszi 1-2 szót, milyen sw, hw, stb.?

Sziasztok!

Én AVR-fan vagyok, eddig kizárólag ilyen kontrollerrel dolgoztam. SW,HW ügyben tudok segíteni, ha felmerül valami. In-System programozok LPT portról, saját programozó programmal . Amikor jön egy új kontroller, új módok, parancsok stb., leprogramozom az adatlapja szerint. Így nincs mindent programozó készülékem, de szinte ingyen van programozóm (csak egy buffer-áramkör), amihez kell. Debugolásra is használom az SPI lábakat.
(USB-s saját programozót tervezek, de csak hogy nagy sebességgel tudjak beszélgetni a kontrollerrel futás közben (az SPI-jén keresztül, már amelyiknek van)).

GCC-t egyszer használtam, mert azt hittem elég egyszerű a feladat, hogy elférjen 2kb-ba, de nem fért, akárhogy optimalizáltam. Végül maradtam a jó öreg assembly-nél, fele akkora lett, így új feature-öket is beleraktam a projektbe.
ASM-kérdésekkel is lehet fordulni hozzám.

Volt több projektem:
-2 db PS/2 billentyűzet "eggyé alakítása" + gombok átmap-olása (multiplayer játékokhoz előnyös )
-Fényjátékok (dísz, ajándék)
-Zenélő, képet-éredekes-módon-megjelenítő doboz
-Komplett digitális óra (idő felolvasás az én hangommal, 3 ébresztő zene (real-tone, nem csipogós), naptár, szüli-/névnap előrejelzés)
-Időzítős távkioldó fk.géphez (astro-fotózáshoz)
-Sebesség/távolság/idő-mérő biciklire
-1541 lemezegység-emulátor (realtime) C64-hez, az újabb, még jobb verzió fejlesztés alatt van
-Jelenleg vezetőtávcsőhöz készítek CCD-vezérlést (astro-fotózáshoz) AVR-ekkel
(+ egy rakás félbehagyott projekt )

Ha van időm, segítek bárkinek, de inkább csak szóban itt, mert túl sok extra időm nincs.. :/

Az minden flash memóriánál úgy van, hogy törölt állapotban 1, és írott állapotban nulla. Csak valahogy logikusabb, hogy ha ott a pipa, akkor az azt jelentse, hogy az a bit 1 lesz.

A fuse biteket külön kell programozni. Zavaró a fordított logika, nem a ponyprog a hibás, az adatlap szerint is 1 az alap és 0-ba égeted.
Nekem is kellet már külső oscit gyártani . Némelyik avr-en a reset lehet portláb is. ha átállítod portlábra, akkor sincs programozás, csak jtag-en.

Ezt nem tudom, de vannak ettől szebb dolgok is. Pl. a Ponyprog-ban a fuse bitek invertálva vannak. Ha be van pipálva a checkbox, akkor van az adott bit nullán. Sosem értettem, ebben mi a logika

Azt ugye tudod, hogyha átállítod véletlen külső oszcillátorra, és valójában az nincs, akkor lőttek a programozásnak, adhatsz neki valahonnan órajelet (mondjuk ez nálad biztos nem gond, gondolom van egy pic a közelben, amiről lehet lopni órajelet).

Bocs a nagyon kezdő kérdésért: ha jól emlékszem, az AVR-ek hex fájlja nem tartalmazza a fuse biteket? Nem igazán értek az AVR-ekhez, csak most kellene egyet égetnem.

Bocs, de ezek digitek és nem karakterek, esetleg helyiértékek.

üdv! proli007

Én is gondoltam rá Szerinted annyi elég? Csakhogy fölöslegesen minek dolgozzon a proci a hiányzó karakterek 0-jávalm, deha elég, akkor nem variálok vele.

kihagyod a HW-bol a folosleges karaktereke?

Közben erre én is rájöttem. Meg arra is, hogy ez így 10Hz-es felbontású, namost nekem bőven elég lenne 1KHz, tehát nekem csak 5 digit kell, csak mivel programoláshoz nem értek nem tudom melyik részét kellene ennek megfelelően elhagyni/módosítani.

A kod elejen a

reszt atirni ertelemszeruen a kristaly frekire.

Es a

reszbe es bele kell turni. Csak ehez mar nincs kedvem gondolkodni

A Microsyl MegaLoad bootloader nekem jól bevált. A kontroller C forráskódja hozzáférhető. A cpu freki, meg a soros baudrate beállítása után lefordítva már használható is, Windows programmal megy a betöltés.
Az eredeti ICC fordítóhoz van írva, a www.mikrocontroller.net oldalon megtalálható a AVRGCC-re átírt változat is. Ez utóbbival 512 bájtnál kisebb boot kódot lehet generálni, így egészen kis kontrollernél (pl. ATmega8) is van értelme használni.
Reset után a bootloader szólítja meg a PC-s betöltőprogramot, így indul a programbetöltés. Ha nincs válasz, akkor rögtön a főprogram indul, vagyis max. 100ms késéssel indul a főprogram.

Bocs, de ebben a kérdésben nem foglalnék állást, mert AVR-ben nem vagyok büfé, de a kollegák biztos fognak rá válaszolni.

Persze nem egész számmal, úgy is lehet számolni, hogy néhányszor 15-el számolsz, néhányszor meg 16-al és amilyen arányban számolsz, annyi lesz az átlag. Tehát, ha 50%-ban, akkor az 15,5-re jön ki. (Nem biztos, hogy használható, de lehet egy tipp ez is.)

szerk:
A sebesség növelésére (a jel lassítására), esetleg lehet előosztót is betenni. A kijelzés láthatósága miatt, meg nem szükséges 1msec-onként mérni. Közben lehet ide-oda számolgatni, átlagolni, kivonni, vagy amit kell

üdv! proli007

Igen erre gondoltam! A problémám az, hogy 15,36MHz-es kavicsom nincs, van 10,12,14,15,16-os. Ezek valamelyikéhez hogy kéne módosítani kódot? Illetve ahhoz, hogy a legkisebb helyiérték KHz legyen?
Előre is köszi!