Watcdog

Azt hiszed, erre soha nem lesz szükséged? Csak idő kérdése!

A wotchdog egy remek eszköz a nem túlságosan profi programozóknak. Igaz évek teltek el, mire szükségem lett rá, de elérkezett a pillanat. Sikerült olyan nagy programot írnom, hogy szinte teljesen megtöltötte a rendelkezésre álló flash memóriát, és a rendelkezésre álló RAM területet is. A fordító már figyelmeztető üzenetet küldött, hogy stabilitási problémák adódhatnak. Így is lett. Készítettem egy programot, ami időjárási adatokat mért és gyűjtött. Négy ponton mért hőmérsékletet, légnyomást, páratartalmat, az eredményeket óránként SD kártyára írta, és 7 segmens-es kijelző jelenítette meg az aktuális adatokat, használtam led matrix kijelzőt, LCD kijelzőt és RTC órát is. Nem volt túl bonyolult, csak összetett. Minden modult külön külön is kipróbáltam, nem tapasztaltam velük semmilyen stabilitási problémát, a legelső egyszerűsített verzió (SD kártyára írás nélkül) két évig működött probléma nélkül. Az SD kártya könyvtára alapból több mint 10 Kbyte memóriát foglalt el, így itt lehet valahol a probléma gyökere és oka. Mióta SD kártyára rögzítem az adatokat, néhány naponta lefagy a kütyü. Néha egy nap, néha két hét is eltelik a lefagyások között. A led kijelzőn 2 másodpercenként váltogatom a mért értékeket (páratartalom, légnyomás, pince hőmérséklet stb.), így könnyű volt kiszúrni, amikor lefagyott a rendszer. A kijelzőre “ráfagyott” az utolsó mért adat, nem váltogatta a program az értékeket. Szerintem ekkor már csak a MAX7219 és a 74HC595 IC-k működtek, világítottak a led kijelzők az utoljára regisztereikbe léptetett adattal.

Nézegettem egy darabig a programot, de nem láttam benne hibát (persze van valahol, csak nem láttam). A fiam profi C# programozó, és arról győzködött, hogy “memória szivárgás” lehet, mert az a leggyakoribb probléma. Hogy mi ez, azt csak homályosan értettem meg, és a megoldásra nem láttam lehetőséget. Debuggolni kellet volna a programot, közben figyelni a memória felhasználást és állapotokat. A jelenséget az okozhatja, hogy a program futása közben memória változókat hoznak létre a különböző függvények, majd amikor végeztek, törlik azokat. Néha azonban valamiért nem sikerül a törlés és a foglalt terület felszabadítása, így hosszú idő után elfogy a rendelkezésre álló RAM terület. Ekkor fagy le a rendszer. Lehet, hogy így volt, lehet, hogy nem!

Régi mondás, hogy vannak problémák, amiket könnyebb megkerülni, mint megoldani. Jó kerülő megoldás az ATmega vezérlőkbe beépített watchdog. Ennek lényege, hogy beépítettek egy RC oszcillátort a chip-be. Ez mindentől függetlenül működik, nem kell hozzá külső alkatrész. Ha tápfeszt kap a chip, akkor megy. Ha bekapcsolod a watchdog-ot (házőrző kutya), akkor ez az oszcillátor meghajt egy számlálót, ami ha elér egy értéket, akkor képes resetelni (alaphelyzetbe állítani) a chip-et. Ha ezt a számlálót számlálás közben időnként 0-ra állítod, akkor újrakezdi a számlálást, és esetleg soha nem éri el azt az értéket, ami reseteli az ATmega chip-et. Hát ez szuper! A programban ciklikusan törölni kell a watchdog számlálót, és ha lefagy a program, akkor a törlés elmarad, és a chip egy idő után újraindul. Persze minden adat elveszik, de legalább újra működik. Ha vannak adatok, melyeket jó lenne nem elveszíteni, akkor azokról folyamatosan gondoskodni kell. Pl a programnak az ATmega vezérlőben beépített nem felejtő ram-ba (eeprom) kell beírni, külső SD kártyán kell tárolni, vagy lehet egy külső RAM-ot is használni. Az ATmega eeprom használatának nagy hátránya, hogy kb. 100.000 újraírást enged meg, ezért a programod teljes élettartama alatt nem írhatsz bele többször 100 ezernél többször, különben a chip nem lefagy, hanem tönkremegy. Az SD kártya használat elég macerás, mert fájlokat kell kezelni, de azért nem megoldhatatlan. A külső ram lehet a legjobb megoldás. Van olyan, amit I2C kommunikációval lehet használni, és csak arra kell vigyázni, hogy mindig legyen tápfesze. Pl. szünetmentesen kell táplálni egy elemről. Két ceruzaelemről évekig tudnak működni. Nekem nem kellett ilyen megoldás, mert nem voltak kritikus adataim. Egyszerűen elég volt az újraindítás.

Az említett lefagyós program egy Arduino nano-ban futott. Elővettem hát a legegyszerűbb watchdog mintaprogramot, és rátöltöttem. Ennek a példa programnak a lényege, hogy az Arduino nano beépített led-jét villogtatja végtelen ciklusban. A villogási (világítási) időt viszont minden ciklusban növeli. Egyszer csak hosszabb ideig áll várakozásban a program, mint amennyi idő alatt a watchdog számláló végigszámol, és a chip újraindul. Az újraindulást a program setup részében elhelyezett három gyors felvillanás jelzi. Előre jelzem, a program nem volt működőképes.

#include<avr/wdt.h> //WatchDog header betöltése
int i;

void setup() {
  wdt_enable(WDTO_4S);  //engedélyezük a watcdog-ot 4 sekundum várakozással 
                        //4sec után a chip ujaindítja magát, ha nincs közben
                        // wdt_reset() függvényhívás, ami ujraindítja a timert
  pinMode(13, OUTPUT);  //beépített ledet fogjuk használni
  for (i=0;i<3;i++){    //három gyors villanás
    digitalWrite(13,HIGH);
    delay(100);
    digitalWrite(13,LOW);
    delay(100);
  }
  delay(100);   
}

void loop() {
  for(int i = 0; i<10000; i++)
  {
    wdt_reset(); //alaphelyzetbe állítjuk a a watcdog timer-t
    digitalWrite(13, HIGH);
    delay(250*i); //minden ciklussal növekvő ideíg vílágit a led
                  //4sec-nél hosszabb idő után nem kap resetet
                  //a watchdog, és ujraindítja a chip-et
    digitalWrite(13, LOW);
    delay(250);
  }
}

Szóval az Arduino nano-ban ez a program nem működött. Feltöltés után gyorsan felvillant a led háromszor, tehát a setup rész rendben lefutott. Aztán a led egyre hosszabb ideig világított rövid elalvások között, vagyis a végtelen ciklus is működött. Egyszer csak elérkezett az a pillanat, hogy négy másodpercnél hosszabb ideig világított a led, vagyis nem került sor a watchdog számláló resetelésére. Ekkor bekövetkezett az újraindulás. Viszont nem három gyors felvillanás jött, hanem a beépített led gyors villogásba kezdett végtelenül. Ebből az állapotból csak akkor került ki, ha kihúztam az USB portból, vagyis elvettem tőle a tápfeszültséget. Reset gombra sem reagált. Kipróbáltam mezei telefontöltő táppal is, hátha az a baj, hogy a PC az USB porton keresztül kommunikálni akar. Ez sem segített. Csak a teljes ki és bekapcsolás, de ez is csak egy watchdog “reset”-ig, mindig megjelent a led gyors villogása. Szerencsére programot lehetett rátölteni, az működött, nem kellett kidobni, de csak a ki be kapcsolást követő működési szakaszban, amíg a watchdog egyszer sem indította újra a chip-et!

Találtam a youtube-on oktató videót a watchdogról. Azon gyakorlatilag ugyanezt a programot mutatták be. Egyetlen különbség az volt, hogy a bemutatón Arduino UNO R3-at használtak. Az ugye kb. ugyanaz, de azért kipróbáltam. És igen, az UNO-n működött. Mi lehet a különbség? Hát a bootloader verziója. Az UNO-n már a kisebb helyfoglalású 512 byte-os bootloader (optiboot) található, míg az általam beszerzett Arduino nano példányok mindegyikén egy 2 kbyte-os bootloader. Ezt honnan tudom? Két gyanús dolgot is felfedeztem. Az egyik nyilvánvaló volt, csak nem tulajdonítottam neki jelentőséget. Az Arduino IDE használatakor, a nano-ra történő program feltöltéskor az alaplap típusa “Arduino nano”, a processzor ATmega328P (old bootloader):

A másik gyanús dologért tenni kelett valamit. Az aruino.cc weboldalon találtam egy “showinfo” nevű programocskát. Ez futás közben kiír jó néhány adatot a chip-ben található dolgokról. Többek között az úgynevezett “fuse” változókról is. Ezek tartalma most nem lényeges, csak annyit kell tudni, hogy a “HIGH FUSE” egyes bitjeivel be lehet állítani a bootloader által lefoglalt memória nagyságát. Íme a high fuse értéke:

Arduion UNO R3 showinfo:
HIGH FUSE     = 0xDE
Arduino nano old bootloader showinfo:
HIGH FUSE     = 0xDA

Igen, itt is látszik, hogy valami más. Persze azt nem tudtam, hogy mi okozhatja a jelenséget, semmilyen más különbséget nem találtam, tekintve, hogy az UNO-ban és a nano-ban is ATmega328 chip található. Így ezen a nyomon indultam el. Nosza töltsünk a nano-ra új bootloadert. Bamba módon csináltam. Feltételeztem, hogy az Arduino IDE által felajánlott bootloader feltöltési lehetőség valami új bootloadert fog a chip-re tölteni. Ehhez persze programozó kell, bootloadert nem lehet USB porton keresztül közvetlenül a nano-ra tölteni. Az UNO-ból csináltam programozót, és azzal töltöttem fel az új bootloadert. Ennek részleteiről itt olvashatsz.

Az akció sikeres volt. Az új bootloaderrel ellátott nano már képes a fenti programot az elvárások szerint futtatni. Az új bootloader rátöltése után újra kiolvastam a “showinfo”-val a high fuse értékét:
HIGH FUSE     = 0xDA
Tehát az új bootloader nem az UNO optiboot verziója, vagy csak a bootloader feltöltsée nem állította be helyesen a high fuse megfelelő bitjeit, és az új bootloader 512 byte-on is elférne, de a fuse bitek állapota 2 kbyte-ot tart fenn számára. Lehet, hogy soha nem fog kiderülni, de legalább a watchdog működik!

Még egy említésre méltó dolog tartozik ide. Mióta a nano-ra feltöltöttem az új bootloadert, már az Arduino IDE alaplap beállításainál nem az “old bootloader”-t kell beállítani. Ezzel a paraméterrel már nem megy a program feltöltés. Sajna a hibaüzenet nem azonnal érkezik, hosszú timeout után a “programozó nem válaszol” hibaüzenetet küld.

Programfeltöltés ATmega mikrovezérlőkre

Egy Arduino UNO R3-at használok programfejlesztésre, de az elkészült programot egy ATmega328 mikrovezérlőbe kellett beégetnem. Régebben nem volt még programozóm amivel egy chip-be betölthettem volna a programot, ezért az Arduino UNO R3-at szerettem volna erre felhasználni. Ennek a műveletsornak a lépéseit rögzítettem az alábbi dokumentációban. A módszer tanulásához a TAVIR weblapon talált leírást olvastam el!

A probléma megoldására a mai napig (2020) háromféle módszert használtam:

  1. Próbapanelon összerakott környezettel és az Arduino IDE ArduinoISP példaprogramjával.
  2. Egy 2019-ban Aliexpres-en vásárolt AVR ISP shield panel felhasználásával. Ez lényegileg ugyanaz mint az előző megoldás, csak kényelmesebbé vált a feltöltés során az „égetendő” chip mechanikai kezelése, dugdosása.
  3. STK500 programozó használata.

Az első két esetben két fő lépésből áll a műveletsor:

  1. Feltöltjük a programfeltöltésre szolgáló programot az Arduino UNO R3-ra. Ezzel elkészül a „programozó” készülékünk
  2. A mikrokontrollerbe töltendő programot „programozóval” töltjük be a chip-be. Ekkor az Arduino Uno R3 lesz a programozó, ami lényegileg 3 vezetékkel lesz összekötve az ATmega328P chip megfelelő lábaival. Nyilván chip-nek tápot kell adni, és kell minimum egy kvarcz kristály és két kondi az órajel előállításhoz.

Az STK500 programozó esetén az első lépés kimarad, hiszen Arduino UNO-ra nincs is szükség, azt a programozó helyettesíti. A leírás végén erről is olvashatsz, de legelőször nézzük meg azt az esetet, amikor nincs programozónk, de van kéznél Arduino Uno.

  1. A programozó szoftver feltöltése Arduino-ra

Első lépés az égető szoftver feltöltése az Arduino UNO R3-ra.

Elsőként csatlakoztattam az USB portra az Arduino UNO R3-at, és beállítottam az eszközök /alappanel menüben az Arduino Uno alappanelt, hiszen most magára az R3-ra szeretnék programot rátölteni, mégpedig az ArduinoISP programot, amitől programozó lesz belőle.

Ezt követi a programozó megadása az eszközök/programozó menüpontban. Én az AVR ISP-t állítottam be. Mindig is ezt használtam ha az Arduino UNO R3-ra akartam programot rátölteni:

Most jön a program kiválasztása. A file/minták menüből választottam ArduinoISP menüpontot. Ez a program kifejezetten erre a feladatra lett készítve:

Ezután jött a program égetése az R3-ra. Praktikusan rákattintottam a feltöltés ikonra:

Nálam minden rendben volt, villognak kicsit a ledek az Arduino UNO R3-on, és el is készült programozó.

  1. A program feltöltése „Arduino as ISP” programozóval

Ekkor összeraktam az ATmega328P-t egy próbapanelon, mert kellett hozzá néhány alkatrészt. Itt a kapcsolási rajz:

Ezen a kapcsolási rajzon szerepel egy led a soros áramkorlátozó ellenállással. Nyilván ezt nem raktam be, csak nem találtam pont olyan rajzot a neten, ami nekem kellett.

Sokat segített az összerakásnál a mikrovezérlő lábkiosztása, ezért segítségül itt van ez is:

Az én panelem így nézett ki:

Elismerem, hogy kicsit áttekinthetetlen, de működőképes. A kvarc-ot közvetlenül a mikrovezérlő lábaihoz dugtam be, a kondenzátorokat pedig a panel egyik végén kialakított „GND csomópontba”. Így a kondik teljes lábhosszúságára szükség volt. A reset láb felhúzó ellenállása látható még a képen a panel bal alsó sarkában.

Ekkor következett az R3 programozó és az ATmega328 összevezetékezése. Itt az Arduino weblapon található rajz, ez teljesen áttekinthető és egyértelmű:

Mindez nálam kicsit csúnyábban fest:

Amikor elkészült a „kábelezés” beállítottam a programozót az eszközök/programozó menüpontban. Itt az ArduinoISP-t választottam, tekintve, hogy az Arduino UNO R3 ettől a perctől kezdve egy külső programozó készülék:

Egyébként ha nem akarjuk folyton az Arduino R3-at használni programozásra, meglehetősen olcsón kapható az Aliexpres-en a már említett STK500 programozó. Az STK500 nevet kell a keresőbe beírni, és bőségesen válogathatunk az olcsóbbnál olcsóbb eszközök között. 1000Ft alatt már lehet kapni, ami kb. így néz ki:
Olvastam a neten fórumokban, hogy a kínai cuccok szarok. Ez biztosan így is van. Az én amatőr körülményeimben azonban tökéletesen megfeleltek. A képen látható cucc valójában ugyanaz, mint amit az Arduino UNO és a hozzá vezetékezett dugdosós panelen összeraktam. Egy kisebb ATmega vezérlő van rajta, és egy USB soros illesztő IC, Nomeg a kábelek, amik megkönnyítik a dugdosást.

Most jön az alaplap kiválasztása. Persze itt nem alaplapról van szó, hanem egy chip-ről. Bár a felsorolt alaplapok között nem fogunk ATmega328P nevűt találni alapból, ne essünk kétségbe. Mivel akkoriban (2015-ben) én sem találtam, elkezdtem próbálkozni. Láss csodát, az Arduino UNO alaplappal pont működött a dolog. Nyilván más menüpontokkal is ment volna, de azt, hogy ezek miben különböznek, azt nem tudom, talán nem is érdekes:

…és ezzel minden előkészület megtörtént! Megkezdődhetett a program beégetése. Tanulás képen a blink alapprogramot égettem be, ezt könnyű volt kipróbálni égetés után. Tehát a file/példák/basic/blink programot nyitjuk meg:

És következhet a pont az i-re. Be kell égetni a programot a chip-be. Ehhez a vázlat/feltöltés programozót használva menüpontot kell választani:

A képernyőn csak egy halovány felirat jelent meg a program alsó üzeneteket megjelenítő részén arról, hogy folyik az égetés (elfelejtettem kifotózni). Az R3 ledjei vadul villogtak pár másodpercig. Aztán „égetés kész” felirat jelent meg, és tényleg készen lehetett.

Valóságban nem ezzel kezdtem, hanem a bootloader égetéssel. Ráadásul a vásárolt chip-ben már volt bootloader az ismertető szerint, de ez úgy tűnik nem igazán probléma. Ehhez az eszközök menü/bootloader beégetése menüpontot kellett kiválasztani. Ezt a lépést a továbbiakban már soha nem csináltam, nyilván nem is kell. Azonban én mindig olyan chip-et vásároltam a későbbiekben, ami már gyárilag tartalmazta a bootloadert!

Természetesen az elkészült chip-et le is ellenőriztem. Lehúzogattam a programozó vezetékeket, csak a tápfeszt hagytam rajta. Rádugtam a 28-as lábra egy ledet (az Arduino 13-as digitális ki/bemenete egyben a beépített led, ami az ATmega328P chip-en a 28-as számú kivezetés), ami szépen villogott!!

Program feltöltés AVR ISP Schield használatával

Teltek múltak a hónapok, és chip égetésére nem is volt szükségem, de egy újabb munkához megint csak kellett. Közben az előző módszer leírásában említett próbapanelen vezetékezett környezet megsemmisült. Az Aliexpres-en megláttam egy Arduino UNO R3-ra rádugható panelt, amin már kész a környezet, az ATmega328P chip könnyedén bedugható a nyitható-zárható foglalatba. Így néz ki:

Ez szuper! Tulajdonképpen semmi nem változott, ez csak egy kész vezetékezés a kvarcz kristállyal, két kondenzátorral. Található meég rajta 3 led, ami a feltöltés állapotáról tájékoztat. Égetés közben a ledeken vagy egy kicsike tűzijáték, amit próbáltam értelmezni. Ha minden rendben, akkor a zöld led látványosan pulzál. Piros, ha valami nincs rendben. Egy kis hangszóró is van rajta, ami hangosan tülköl hiba esetén. Beállítani úgy kell mindent, amit a fentebb lévő leírásban olvasható.

Azonban sokat szívtam vele, mert előkerült egy ATmega8 chip. Nem vettem észre, hogy nem ATmega328P van a kezemben, és csodálkoztam, hogy nem működik. Több órás próbálkozás után végre rászántam magam és értelmeztem a hibaüzenetet. Előkerült egy nagyító, és megbizonyosodhattam róla, hogy az ATmega328 tényleg nem ugyanaz mint az ATmega8.
Olyan nyúlfarknyi programot kelett feltöltenem, ami az ATmega8-ban is elfért. Keresni kelett tehát egy olyan alaplapot, ami megfelel az ATmega8-nak!
Már előzőleg is említettem, hogy a feltöltéskor az alaplap választásakor bizonytalan voltam, mert nem találni ATmega328P alaplapot, csak Arduino UNO alaplapot, amivel szerencsére sikerült a feltöltés. Az ATmega8-nak viszont semmit nem találtam.Mindent kipróbáltam, semmivel nem működött. Így nem volt mit tenni el kellett kezdenem böngészni a netet, hátha van megoldás. Persze, hogy van! Találtam valahol egy cikket, ami pont erről szólt. Az alábbiakat kell tenni:

Meg kell keresni az Arduino IDE-ben a file/beállítások menüt, és a “további Alaplap-kezelő URL-ek:” sorba be kell írnia következőt: https://mcudude.github.io/MiniCore/package_MCUdude_MiniCore_index.json

Most el kell kezdeni az alaplap kiválasztást és rögtön a legfelső “Alaplap kezelő” menüpontot kiválasztani:

A megjelenő keresőbe írjuk be “minicore”, és válasszuk ki az egyetlen megjelenő alaplapot, és telepítsük:

…és igen, megtörtént a csoda. Van már az alaplapok között ATmega chip-ből mindenféle:

Túl hosszú volt az alaplap felsorolások listája, ezért inkább két képet csináltam. Viszont érdemes megfigyelni, hogy ez első képen kiválasztott ATmega8 alaplap alatt megjelent egy csomó új menüpont, amikre eddig nem kellett odafigyelni. A minicore alaplap kezelő leírásban erről rengeteg részletet találunk. A minicore kiválasztásakor a telepítés nyomógomb megnyomása előtt (keressük meg újra) kattintsunk a “More info” linkre, és szemezgessünk a rengeteg infóból.
Engem ezek közül az órajel frekvenciáról szóló rész hozott izgalomba. Egy alkalommal szerettem volna kvarcz kristály nélkül egyetlen led-et vezérelni. Pontosabban egy RGB led-ből akartam változtatható színű hangulatfényt építeni csupán virtusból. Remek lett volna, ha semmi nem kell a vezérlőn kívül. Olvasgattam is a vezérlő adatlapját, amiben megtaláltam a belső RC oszcillátorról szóló leírást. De azt már a szerény angol tudásom birtokában nem tudtam megfejteni, hogy ezt miképpen kellene beállítani. Feltettem hát a kérdést az egyik fórumon, hogy valaki segítsen. Nem az volt a válasz, hogy ezt meg ezt kell csinálni, hanem arról érdeklődtek, minek ez nekem, miért akarok filléreket spórolni a kvarcz kristályon és hasonlók. Elég lett volna nekem egy “Nem tudom!” vagy “Nem akarom megmondani!” is. Ez volt az a a pillanat, amikor rájöttem, sokan nem is akarnak segíteni.
Ezeknek a plusz menüpontoknak a működéséről az STK500 programozónál még némi információ. Ha tovább olvasod a leírást, haarosan odaérsz.

Program feltöltés STK500 programozóval

A programozó használatához minimális odafigyelésre van szükség. Ugyanis az Arduino nano áramkörére betervezték ugyan az ICISP csatlakozót, de a programozóval történő csatlakoztatás nem teljesen egyértelmű. Az Arduino nano “pinout” ábráján külön kirajzolták a csatlakozót:

Azonban itt nem szerepel semmi arról, hogy melyik az “1”-es csatlakozó pont, amit a nyákon feltüntettek. Persze könnyű kitalálni, hiszen ez az ábra is felülnézetben ábrázolja a csatlakozót. A programozó picike kis nyáklemezén, ami csatlakozót tartalmazza, szerepel az egyes kivezetések neve, így könnyű kitalálni, hogy a MISO lábat a csatlakozó jobb felső pontjához kell irányítani! Miután csatlakoztattuk a programozót az Arduino nano-hoz és bedugjuk a programozót az USB portba, a nano-n a megszokott tápfesz jelző piros led világit. Megnyugodhatunk, nem rontottuk el.
A programozó bedugásakor a Windows 10 USBasp nevű drivert próbált telepíteni, de a Windows eszköz kezelőjében látható volt, hogy a driver nem elérhető:

Nyilván az a baj, hogy az eszköznek driverre van szüksége. Kis kutakodás után a neten (Google usbasp szóra sok találatot ad fel). Két helyen is találtam drivert. Az egyik a következő elérési utvonalról tölthető le: https://protostack.com.au/download/USBasp-win-driver-x86-x64-v3.0.7.zip
Az itt található állományt ki kell bontani, és elindítani az installdriver.exe programot. Megnyomni a szokásos next-next gombokat, és kész is. A másik lehetőség a fórumokon a Zadig (https://zadig.akeo.ie/) weboldal. Innen a le kell tölteni a driver telepítő programot , és futtatni.

Az a lényeg, hogy a Windows eszközkezelőben megjelenjen egy USBasp nevű eszköz és rendben működjön. Ezzel az eszközzel azonban nem keletkezik COM port, így az Arduino IDE programban az eszközök menüben a “Port” menüpont szürke marad. Ez azonban nem baj. Alaplapnak válasszuk ki az éppen aktuális alaplapot (pl. Arduino nano, vagy Arduino UNO stb.). Programozónak válasszuk az USBasp nevű programozót. Ne felejtsük el, hogy a programot ekkor nem a szokásos módon a feltöltés ikonnal lehet elvégezni, hanem a vázlat menüpontban a “Feltöltés programozót használva Ctrl + Shift + U” menüpontot kell használni. Azon se lepődjünk meg, hogy a program feltöltés figyelmeztető üzenetet (Warning) eredményez.

Ezt nyugodtan figyelmen kívül hagyhatjuk, a feltöltés rendben megtörtént. Ha bootloadert égetünk, ugyanezt fogjuk tapasztalni. Elméletben a bootloader feltöltése a képen látható figyelmeztető üzeneteket eredményezte, így látszólag felkerült a chip-re, de valójában nem történt meg. Nem jöttem rá, hogy mi a hiba, de kísérletezgetéssel sikerült mégis a bootloader feltöltés. Abból indultam mi, hogy a bootloadert nem egy Arduino nano-ra akarom feltölteni, hanem egy ATmega328 chip-re. Azonban az Arduino IDE kiválasztható alaplapjai között nem szerepel ez a mikrovezérlő. Azonban kicsivel ez előtt leírtam, hogyan lehet letölteni a minicore alaplap kezelő könyvtárat. Ebben már van ATmega328. Így ezt választottam ki:

Ezt követően már lényegesen több beállítási lehetőség jelent meg, amiből semmit nem állítottam át, csak rákattintottam a bootloader égetése menüpontra.:

Ekkor már lényegesen több információ jelent meg a feltöltésről, és sikeres is volt. A feltöltés infóiból egy részlet:

Az Arduino piros led-je másodpercenként két gyors felvillanást produkált a feltöltését követően. Az eredeti program törlődött.
Azt figyeltem még meg, hogy az új bootloader-es nano bekapcsoláskor másként villogtatja a led-et. Amikor bedugom az usb portba és tápfeszt kap, az új bootloader hét alkalommal dupla felvillanással jelez. A régi bootloader csak szimpla felvillanásokat produkál:

Fuse bitek módosítása

Amikor megtaláltam a mincore alaplap kezelőt, kikísérletezgetni kezdtem. Elővettem az ATmega8 chip-et, összehuzaloztam egy led villogtató kacsolást a kvarcz kristállyal, két kondenzátorral. Ekkor már volt STK500-as programozóm, azt is belehuzaloztam a kapcsolásba. Be kellett kötni a GND, VCC, reset, Miso, Mosi és Sck vezetékeket. Amint a programozót bedugtam az USB portba, máris feszültséget kapott az ATmega8 chip. Ha lett volna rajta program, minden bizonnyal villog is a led azonnal. Töltöttem is rá egy blink példa programot, és a led villogott. Most jött a kísérletezgetés. Sorban kiválasztottam az esetemben lehetséges órajeleket. Nyilván az 1Mhz és 8Mhz belső órajel, és 16Mhz külső jöhet szóba. Rátöltöttem először az 1Mhz belső órajel beállítással egy bootloadert a chip-re:

A bootloader rátöltése törli a programot, ezért miután megláttam a bootloader betöltését nyugtázó OK üzenetet alul, a “Feltöltés programozót használva” menüponttal rátöltöttem újra a chip-re a blink programot. És a led villog. Gyorsan lekapkodtam a kvartz kristályt a kapcsolásról, adtam neki külön 5V tápfeszt, és a led tovább villog. Kipróbáltam a 8Mhz beállítást is (kvarcz-ot nem kell visszatenni), és azzal is működött. Aztán vissza akartam állni a kvarcz kristályos 16Mhz külső órajelre. Na ez már nem sikerült, csak ha a bootloader égetés előtt visszaraktam a kvarcz kristályt és a két kondit a helyére.
A bootloader égetése közben a képernyő alján rengeteg információ jelenik meg. Ezekből kiszemezgettem, hogy mit is csinál a folyamat, és milyen fuse biteket állít be:

 Bootloader-elBootloader nélkül
1Mhz belső órajelLfuse:10100001 Hfuse:11010100Lfuse:10100001 Hfuse:11010101
8Mhz belső órajelLfuse:10100100 Hfuse:11010100Lfuse:10100100 Hfuse:11010101
16Mhz külső órajelLfuse:10111111 Hfuse:11000100Lfuse:10111111 Hfuse:11000101

Még esetleg a BOD beállítás lehet hasznos a megjelenő menüpontok közül. ez a BOD paraméter azt a feszültséget határozza meg a vezérlőnek, ami alatt leáll a működés. Pl. ha elemről tápláljuk a vezérlőt és az elem feszültsége a beállított 2,7V alá csökken, akkor a vezérlő leállítja magát. Ez jobb, mintha bizonytalan működést idéz elő az elégtelen tápfeszültség, mivel egyes részei még működnek a vezérlőnek, míg mások nem.
Találtam táblázatot, hogy egyes vezérlőknél milyen feszültség értékeket lehet beállítani:

atmega328ATmega168atmega88ATmega48ATmega8
4.3V4.3V4.3V4.3V4.0V
2.7V2.7V2.7V2.7V2.7V
1.8V1.8V1.8V1.8V
TiltvaTiltvaTiltvaTiltvaTiltva

Viszont erre még nem volt szükségem, így kísérleteket nem végeztem a BOD feszültség tárgyában!