Fusebity

W tekście będę posługiwał się określeniem „fusebity” ponieważ jest bardzo rozpowszechnione na polskich stronach internetowych.
Polecenia AVRDUDE i ustawienia fusebitów były wypróbowane przeze mnie na kontrolerach: ATtiny2313, ATmega8, ATmega16, ATmega32 i ATmega48 w rzeczywistych układach.
Jeśli lubisz stosować inny program to i tak niektóre z podanych informacji mogą być dla Ciebie przydatne.

• Bity konfiguracyjne (Fusebity) 
  • Źródła sygnału zegarowego
    • ATmega8, ATmega16, ATmega32
  • Interpretacja wartości fusebitów i ustalanie pożądanej konfiguracji
    • Przykład na fusebitach dla programatora USBASP
    • Przykład na fusebitach dla ATtiny2313
• Odczytywanie  fusebitów przy pomocy AVRDUDE
  • Odczytywanie przy użyciu programatora USBASP
  • Odczytywanie przy użyciu STK200 i BSD
    • Przykład Linux
    • Przykład Windows
• Zapis fusebitów przy pomocy AVRDUDE
  • Zapisanie fusebitów przy użyciu USBASP
  • Zapisanie fusebitów przy użyciu STK200 i BSD
• Użycie Burn-O-Mat

Fusebity ATtiny2313
Fusebity ATmega8
Fusebity ATmega16 i ATmega32
Fusebity ATmega48, ATmega88, ATmega168

Bity konfiguracyjne (Fusebity)

Są to bity konfigurujące mikrokontroler. W dokumentacji Atmela zwane  „Fuse Bits”.
Są zorganizowane w bajty – „Fuse Low Byte”, Fuse High Byte” i czasami jeszcze  „Fuse Extended Byte”.
Wiele osób ma obawy przed zmianą konfiguracji mikrokontrolera, jako że na forach można znaleźć wiele pytań od osób, które straciły łączność ze swoim mikrokontrolerem po zmianie fusebitów. W istocie niebezpieczeństwo nie jest duże jeśli nie podejdziemy do sprawy z nonszalancją, a zachowamy należytą uwagę.
W większości przypadków tak zwanego „zablokowania” mikrokontrolera jest łatwo przywrócić stan poprzedni. Potrzebny będzie jednak jakiś generator impulsów prostokątnych. Dlatego dobrze jest mieć w szufladzie zasłużony układ NE555 lub jego odpowiednik.
W dokumentacji Atmela są opisane w rozdziale „Memory programing” => Fuse Bits”.
Pod adresem http://palmavr.sourceforge.net/cgi-bin/fc.cgi można znaleźć miły kalkulator fusebitów.

Źródła sygnału zegarowego

ATtiny2313

1. Generator RC z wewnętrznymi elementami RC o częstotliwości 4 lub 8 MHz (Calibrated Internal RC Oscillator).
2. Generator RC jak wyżej ale jego częstotliwość jest podzielona przez 8.
3. Generator zegara dla „Watch-dog” o częstotliwości 128 kHz.
4. Kwarc lub rezonator ceramiczny przyłączony do nóżek XTAL1, XTAL2 (External Crystal/Ceramic Resonator):
1. O częstotliwości od 0,4 MHz do 8 MHz
2. O częstotliwości powyżej 8 MHz
5. Generator RC, który wymaga podłączenia zewnętrznego kondensatora i rezystora o wartościach wyliczonych na podstawie podanej przez Atmela formuły na stronie 27 dokumentacji dla ATmega8 i podłączonych według rysunku 12 na tejże stronie (External RC Oscillator).
6. Zewnętrzne źródło sygnału zegarowego, np. sygnał z zewnętrznego generatora kwarcowego lub z innego procesora dla zapewnienia synchronizacji (External Clock).

ATmega8, ATmega16, ATmega32

1. Generator RC z wewnętrznymi elementami RC o częstotliwości 1 lub 2 lub 4 lub 8 MHz (Calibrated Internal RC Oscillator).
2. Kwarc lub rezonator ceramiczny przyłączony do nóżek XTAL1, XTAL2 (External Crystal/Ceramic Resonator):
1. O częstotliwości od 0,4 MHz do 8 MHz
2. O częstotliwości powyżej 8 MHz.
3. Generator RC, który wymaga podłączenia zewnętrznego kondensatora i rezystora o wartościach wyliczonych na podstawie podanej przez Atmela formuły. Podobnie jak dla ATmega8.
4. Kwarc o bardzo małej częstotliwości (np. zegarkowy 32,768kHz) .
5. Zewnętrzne źródło sygnału zegarowego, np. sygnał z zewnętrznego generatora kwarcowego lub z innego procesora dla zapewnienia synchronizacji (External Clock).

Interpretacja wartości fusebitów i ustalanie pożądanej konfiguracji

Często zdarza się, że dla wykonania urządzenia którego dokumentację znaleźliśmy w Sieci należy ustawić fusebity, które podane są w postaci szesnastkowej.
Fusebity zapisane w ten sposób można łatwo przekształcić do postaci dwójkowej. Tak samo w drugą stronę.
Do tego wystarczy jakikolwiek kalkulator zarówno pod Linuksem jak i pod Windows.

Przykład na fusebitach dla programatora USBASP

Żeby użyć realnego przykładu weźmiemy fusebity zalecane dla kontrolera pracującego w programatorze USBASP ze strony http://www.fischl.de/usbasp/ z opisu w pliku Readme.txt (http://www.fischl.de/usbasp/Readme.txt)
„… # TARGET=atmega8 HFUSE=0xc9 LFUSE=0xef …”
Co oznaczają te wartości dla ATmega8 ?
Weźmy na tapetę „hfuse”.
0x oznacza że zapis jest w systemie szesnastkowym. C9 to liczba zapisana w tym systemie.
Ustawiamy kalkulator na system szesnastkowy (Hex) i wpisujemy z klawiatury C9
Przełączamy kalkulator na system dwójkowy (Bin) i odczytujemy wartość 11001001.
Teraz przypiszmy opisy bitów do ich wartości:

hfuse
Szesnastkowo (0x)	C				9
Zapis w stylu PonyProg’a
Wartość bitu	1	1	0	0	1	0	0	1
Opis bitu	RSTDISBL	WDTON	SPIEN	CKOPT	EESAVE	BOOTSZ1	BOOTSZ0	BOOTRST

Ponieważ fabryczne ustawienia są 11011001 (patrz tutaj) więc widać, że zmianie uległa tylko wartość bitu CKOPT (zaznaczonego kolorem fioletowym w powyższej tabelce). Czyli:
Generator zegarowy pracuje ze zwiększonym napięciem, co umożliwia stabilną pracę z kwarcem o częstotliwości powyżej 8MHz.
A teraz „lfuse”.
Ustawiamy kalkulator na liczby szesnastkowe (Hex) i wpisujemy z klawiatury EF
Przełączamy kalkulator na system dwójkowy (Bin) i odczytujemy wartość 11101111.
Teraz przypiszmy opisy bitów do ich wartości

lfuse
Szesnastkowo (0x)	E				F
Zapis w stylu PonyProg’a
Wartość bitu	1	1	1	0	1	1	1	1
Opis bitu	BODLEVEL	BODEN	SUT1	SUT0	CKSEL3	CKSEL2	CKSEL1	CKSEL0

Fabryczne ustawienia są 11100001 (patrz tutaj). Zmianie uległy bity CKSEL zaznaczone  kolorem fioletowym w powyższej tabelce.
Wszystkie cztery bity CKSEL mają wartość 1. Zgodnie z tabelą 2 dokumentacji oznacza to przełączenie generatora na pracę z rezonatorem kwarcowym.
Czyli:
Kontroler może teraz pracować stabilnie z kwarcem  powyżej 8MHz.
Jak wiadomo, w przedmiotowym programatorze pracuje kwarc 12MHz.

Przykład na fusebitach dla ATtiny2313

Wybierzemy taktowanie częstotliwością 128kHz. Dzielnik częstotliwości generatora przez 8 nie będzie potrzebny.
W układzie ATtiny2313 częstotliwość 128kHz można uzyskać z generatora układu WATCHDOG.
Aby wykorzystać generator 128kHz bity CKSEL3..0 bajtu „lfuse” powinny mieć wartość 0110, bity SUT1..0 wartość 10 (zobacz tutaj), a rezygnacja z dzielenia częstotliwości generatora przez osiem oznacza, że bit CKDIV8 powinien być niezaprogramowany czyli 1.
Innych zmian nie potrzeba. Teraz „lfuse” wygląda następująco:

lfuse
Szesnastkowo (0x)	A				6
Zapis w stylu PonyProg’a
Wartość bitu	1	1	1	0	0	1	1	0
Opis bitu	CKDIV8	BODEN	SUT1	SUT0	CKSEL3	CKSEL2	CKSEL1	CKSEL0

Jeszcze raz porównamy z oryginalną wartością 01100100 bajtu „lfuse” i możemy zaznaczyć różnice kolorem fioletowym.
Odczytywanie  fusebitów przy pomocy AVRDUDE

Operacje  na fusebitach przy użyciu programu AVRDUDE są możliwe w trybie poleceń i w trybie interaktywnym.
Ja preferuję odczytywanie i zapis w trybie poleceń i takie też będą następne przykłady.

Odczytywanie przy użyciu programatora USBASP

Przed zaprogramowaniem kostki najpierw odczytałem oryginalne ustawienia:
voytek@tay:~$ avrdude -p attiny2313 -c usbasp  -U lfuse:r:-:h -U lfuse:r:-:b -U hfuse:r:-:h -U hfuse:r:-:b
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e910a
avrdude: reading lfuse memory:
Reading | ################################################## | 100% 0.01s
avrdude: writing output file "<stdout>"
0x64                      lfuse szesnastkowo
avrdude: reading lfuse memory:
Reading | ################################################## | 100% 0.01s
avrdude: writing output file "<stdout>"
0b1100100                 lfuse dwójkowo
avrdude: reading hfuse memory:
Reading | ################################################## | 100% 0.01s
avrdude: writing output file "<stdout>"
0xdf                      hfuse szesnastkowo
avrdude: reading hfuse memory:
Reading | ################################################## | 100% 0.01s
avrdude: writing output file "<stdout>"
0b11011111                hfuse dwójkowo
avrdude: safemode: Fuses OK
avrdude done.  Thank you.
Jak można zauważyć, otrzymaliśmy wartości fusebitów w zapisie dwójkowym i szesnastkowym.
O poleceniu:
Jeśli używamy programatora USBASP, to polecenie wygląda tak samo dla Linuksa i dla Windows.
avrdude -p attiny2313 -c usbasp  -U lfuse:r:-:h -U lfuse:r:-:b -U hfuse:r:-:h -U hfuse:r:-:b
avrdude –  wywołanie programu
-p attiny2313 – rodzaj mikrokontrolera. Można również podać -p t2313
-c usbasp – rodzaj programatora
-U lfuse:r:-:h
-U operacja na dalej podanej części pamięci,
lfuse  „Fuse Low Byte” część pamięci której dotyczy operacja,
: separator,
r  operacja czytaj (read) wcześniej podaną część pamięci,
: następny separator,
- wyślij wynik na standardowe wyjście (stdout) czyli ekran
: następny separator,
h -zapis szesnastkowy (hexadecimal)
-U lfuse:r:-:b – tak samo jak wyżej z wyjątkiem ostatniej litery. Zamiast h jest b (binary) dlatego wartość bajtu jest podana w zapisie dwójkowym.
Powyższe polecenie kazało programowi AVRDUDE odczytać z mikrokontrolera ATtiny2313, przy użyciu programatora USBASP, dolny bajt fusebitów (dwukrotnie, raz  szesnastkowo i drugi raz dwójkowo), a następnie górny bajt fusebitów (również dwukrotnie) z każdorazowym wysłaniem wyniku na wyjście standardowe.
Używając AVRDUDE można otrzymać wartości fusebitów w systemach: dwójkowym, ósemkowym, dziesiętnym i szesnastkowym.
Jeśli chcesz się przekonać wydaj następujące polecenie:
avrdude -p attiny2313 -c usbasp  -U lfuse:r:-:b -U lfuse:r:-:o -U lfuse:r:-:d -U lfuse:r:-:h
Odczytane fusebity bajtu „lfuse” będą przedstawione kolejno w systemach: dwójkowym, ósemkowym, dziesiętnym i szesnastkowym.

Odczytywanie przy użyciu STK200 i BSD

Polecenie jest prawie takie samo. Różnica jest tylko w typie programatora. Zamiast usbasp wpisujemy odpowiednio stk200 lub bsd zależnie od podłączonego programatora.

Przykład Linux

avrdude -p attiny2313 -c stk200  -P /dev/parport0  -U lfuse:r:-:b  -U lfuse:r:-:h  -U hfuse:r:-:b -U hfuse:r:-:h
avrdude -p attiny2313 -c bsd  -P /dev/parport0  -U lfuse:r:-:b  -U lfuse:r:-:h  -U hfuse:r:-:b -U hfuse:r:-:h
Jak widać w poleceniu dodana jest opcja -P z wartością /dev/parport0. Jednak polecenie powinno działać i bez tego ponieważ w AVRDUDE domyślnym portem jest pierwszy port równoległy czyli właśnie /dev/parport0.
Powyżej podane polecenia każą AVRDUDE odczytać z ATtiny2313, przy użyciu odpowiednio STK200 lub BSD, przyłączonego do pierwszego portu równoległego „lfuse” w postaci dwójkowej, a następnie szesnastkowej i potem „hfuse” w ten sam sposób.

Przykład Windows

avrdude -p attiny2313 -c stk200  -P lpt1  -U lfuse:r:-:b  -U lfuse:r:-:h  -U hfuse:r:-:b -U hfuse:r:-:h
avrdude -p attiny2313 -c bsd  -P lpt1  -U lfuse:r:-:b  -U lfuse:r:-:h  -U hfuse:r:-:b -U hfuse:r:-:h
Jedyną różnicą w stosunku do polecenia pod Linuksem jest nazwa portu lpt1 zamiast /dev/parport0.
Ogólny wzór polecenia do odczytywania fusebitów przy użyciu AVRDUDE wygląda następująco:
avrdude -p KONTROLER -c PROGRAMATOR -P PORT-U lfuse:r:-:b  -U hfuse:r:-:b  -U efuse:r:-:b
W miejsce KONTROLER wpisujemy symbol mikrokontrolera. Aby zobaczyć listę symboli obsługiwanych kontrolerów napisz w terminalu polecenie:
avrdude -p ?
W miejsce PROGRAMATOR wpisz symbol programatora którym dysponujesz. Aby zobaczyć listę symboli obsługiwanych programatorów napisz w terminalu polecenie:
avrdude -c ?
W miejsce PORT wpisujemy nazwę portu do którego jest podłączony programator. Domyślnie jest to pierwszy port równoległy i wtedy nie ma potrzeby wpisywania go.

Zapis fusebitów przy pomocy AVRDUDE

Jeżeli robisz jakieś zmiany w fusebitach, zawsze zapisuj wartość którą wprowadzasz do mikrokontrolera. W razie kłopotów będzie łatwiej zdiagnozować przyczynę i ponownie nawiązać nić porozumienia z mikrokontrolerem.
Jeśli nie chce Ci się pisać to wciśnij ALT+PrintScreen i zapisz aktywne okno (to z fusebitami, które chcesz zapisać) do schowka. Być może dzięki temu zaoszczędzisz dużo czasu.

Zapisanie fusebitów przy użyciu USBASP

Jeśli mamy już pożądaną konfigurację mikrokontrolera należy ją przedstawić w postaci wartości szesnastkowej fusebitów i sformułować polecenie dla AVRDUDE. Jako wartość fusebitu wykorzystam to co było wcześniej opisane.
Polecenie zapisu fusebitów ma bardzo podobną postać do polecenia odczytu.
Piszemy:
voytek@tay:~$ avrdude -p attiny2313 -c usbasp  -U lfuse:w:0xA6:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e910a
avrdude: reading input file "0xA6"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xA6:
avrdude: load data lfuse data from input file 0xA6:
avrdude: input file 0xA6 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.01s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: safemode: Fuses OK
avrdude done.  Thank you.
Ponieważ potem chcę pokazać działanie polecenia dla STK200 więc przywrócę fabryczne ustawienia.
 voytek@tay:~$ avrdude -p attiny2313 -c usbasp  -U lfuse:w:0x64:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e910a
avrdude: reading input file "0x64"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.03s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x64:
avrdude: load data lfuse data from input file 0x64:
avrdude: input file 0x64 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.01s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: safemode: Fuses OK
avrdude done.  Thank you.
Jak widać posługiwanie się AVRDUDE w trybie tekstowym jest bardzo proste.

Zapisanie fusebitów przy użyciu STK200 i BSD

Teraz powtórzę powyższe czynności ale przy podłączonym STK200.
voytek@tay:~$ avrdude -p attiny2313 -c stk200 -P /dev/parport0 -U lfuse:w:0xA6:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.06s
avrdude: Device signature = 0x1e910a
avrdude: reading input file "0xA6"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xA6:
avrdude: load data lfuse data from input file 0xA6:
avrdude: input file 0xA6 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: safemode: Fuses OK
avrdude done.  Thank you.
Podobnie jak przy czytaniu fusebitów, różnica między poleceniem dla USBASP i STK200 sprowadza się do zmiany nazwy programatora i podania nazwy portu do którego jest on podłączony.
Teraz przywrócę fabryczne ustawienia:
voytek@tay:~$ avrdude -p attiny2313 -c stk200 -P /dev/parport0  -U lfuse:w:0x64:m
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done.  Thank you.
Nie udało się.
Powtórzę to polecenie z małą zmianą. Zmianę wytłuszczę.
voytek@tay:~$ avrdude -p attiny2313 -c stk200 -P /dev/parport0 -i 100 -U lfuse:w:0x64:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.05s
avrdude: Device signature = 0x1e910a
avrdude: reading input file "0x64"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.07s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x64:
avrdude: load data lfuse data from input file 0x64:
avrdude: input file 0x64 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: safemode: Fuses OK
avrdude done.  Thank you.
Teraz wszystko się udało.
Polecenie różni się od poprzedniego nie tylko wartością „lfuse” (to raczej oczywiste, bo chodziło o zmianę) ale i dodaną opcją „-i” z wartością 100.
Opcja „-i” oznacza opóznienie (wydłużenie) impulsów SCK o podaną ilość (w tym przypadku 100) mikrosekund.
Jest to związane z tym, że częstotliwość impulsów SCK z programatora musi być co najmniej cztery razy mniejsza od prędkości zegara mikrokontrolera.
W powyższym przykładzie najpierw zmniejszyłem prędkość zegara do 128kHz. Jedna czwarta tego to 32kHz. Wydłużenie impulsów SCK o 100µs gwarantuje, że częstotliwość SCK z programatora będzie mniejsza niż 10kHz. To spełnia wspomniany warunek z nadmiarem.
Ogólny wzór polecenia zapisu fusebitów
avrdude -p KONTROLER -c PROGRAMATOR -P PORT -i DELAY -U lfuse:w:0xXX:m -U hfuse:w:0xYY:m -U efuse:w:0xZZ:m
O poleceniu:
KONTROLER, PROGRAMATOR, PORT były omówione wyżej.
-i DELAY jest opcjonalne (dla niskich częstotliwości zegara mikrokontrolera) i nie ma sensu przy stosowaniu USBASP, który ma przełącznik spowalniający SCK do 8kHz.
w oznacza operację zapisu
0xXX, 0xYY, 0xZZ to odpowiednio wartości szesnastkowe fusebitów w bajtach LOW, HIGH i EXTENDED.
m każe pobrać wartości (0xXX, 0xYY, 0xZZ) ze standardowego wejścia. Czyli z wydanego przez nas polecenia.
Jeszcze jeden przykład. Programowanie pilota do Canona wraz ze zmianą fusebitów
voytek@tay:~/Dokumenty/Canon/USB_Remote$ avrdude -v -p t2313 -c stk200 -P /dev/parport0 -i 100 -U flash:w:"canon_remote.hex" -U lfuse:w:0xA6:m
avrdude: Version 5.4, compiled on May 21 2007 at 21:35:45
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/voytek/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port            : /dev/parport0
Using Programmer      : stk200
Setting isp clock delay: 100
AVR Part              : ATtiny2313
Chip Erase delay      : 9000 us
PAGEL                 : PD4
BS2                   : PD6
RESET disposition     : possible i/o
RETRY pulse           : SCK
serial program mode   : yes
parallel program mode : yes
Timeout               : 200
StabDelay             : 100
CmdexeDelay           : 25
SyncLoops             : 32
ByteDelay             : 0
PollIndex             : 3
PollValue             : 0x53
Memory Detail         :

Block Poll               Page                       Polled
Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
———– —- —– —– —- —— —— —- —— —– —– ———
eeprom        65     6     4    0 no        128    4      0  4000  4500 0xff 0xff
flash         65     6    32    0 yes      2048   32     64  4500  4500 0xff 0xff
signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
calibration    0     0     0    0 no          2    0      0     0     0 0x00 0x00

Programmer Type : PPI
Description     : STK200
VCC     =  (not used)
BUFF    = 4,5
RESET   = 9
SCK     = 6
MOSI    = 7
MISO    = 10
ERR LED = 0
RDY LED = 0
PGM LED = 0
VFY LED = 0

avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.05s
avrdude: Device signature = 0x1e910a
avrdude: safemode: lfuse reads as A6
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file „canon_remote.hex”
avrdude: input file canon_remote.hex auto detected as Intel Hex
avrdude: writing flash (418 bytes):
Writing | ################################################## | 100% 7.51s
avrdude: 418 bytes of flash written
avrdude: verifying flash memory against canon_remote.hex:
avrdude: load data flash data from input file canon_remote.hex:
avrdude: input file canon_remote.hex auto detected as Intel Hex
avrdude: input file canon_remote.hex contains 418 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 7.09s
avrdude: verifying …
avrdude: 418 bytes of flash verified
avrdude: reading input file „0xA6”
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xA6:
avrdude: load data lfuse data from input file 0xA6:
avrdude: input file 0xA6 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying …
avrdude: 1 bytes of lfuse verified
avrdude: safemode: lfuse reads as A6
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK
avrdude done.  Thank you.
Polecenia można łączyć.
Najpierw AVRDUDE zapisało program do pamięci. Nie podawałem ścieżki dostępu do pliku z programem ponieważ wywołałem AVRDUDE będąc w katalogu projektu.
-U flash:w:"canon_remote.hex"
 I potem zmieniło fusebity:
-U lfuse:w:0xA6:m