Cześć,
mam problem z zaprogramowaniem Atmega168A-PU w wersji DIP.
Mam plik *.hex z instrukcją ustawienie fuse bitów:
The Atmega168a has to be programmed using the .hex file. The "fuse bytes" for this project are extended_byte=0x01, high_byte=0xdf, low_byte=0xdf.
Atmega korzysta z zewnętrznego kwarca 12MHz z dwoma 18pF.
Program przyjmuje high i low bity ale przy extended ciągle wstawia swój F9 zamiast 01, przez co po wgraniu wsadu wywala błąd (tak mi się przynajmniej wydaje).
Co jest nie tak?

To może się wydawać dziwne ale w tym wypadku 0xF9 == 0x01
Przejdź sobie na tę stronę: http://www.engbedded.com/fusecalc, wybierz swój procek, ustaw fusy a potem niżej, w ramce oznaczonej "current settings" przeczytaj notkę wypisaną na czerwono. I wsio powinno się wyklarować.
A komunikat błędu jest jaki?

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Taki mam komunikat:

No tak, wyraźnie wykłada się na efusie.
Ale prawdopodobnie fusy się zaprogramowały. Wczytaj fusy z procka i sprawdź (pamiętając, że efus możę być równy zarówno 01 jak i F9).

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Po kliknięciu Sprawdź podłączony AVR otrzymuję fusy DF DF i F9.

czyli się zaprogramowały, możesz więc problem fusów uznać za rozwiązany i działać dalej
A czemu to tak wyszło? Widać Mirek założył, że niezdefiniowane bity mają przyjąć wartość "niezaprogramowane" (czyli 1), a 168-emka zrobiła psikusa i raportuje te bity jako "zaprogramowane". Czyżby różne procki pokazywały to inaczej? Jakbym miał pod ręką inną atmegę (np 128) to bym sprawdził co ona podaje.

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Aha, czyli układ powinien być już sprawny i gotowy do dalszego montażu? W takim razie działam dalej
Ciekaw jestem jeszcze opinii Mirka, może znowu jakich chochlik gdzieś się ukrył

Fusbity można też przestawiać w procu, który jest w układzie zmontowanym.

Nie ma co się bać fusebitów.

Po prostu WYŁĄCZ WERYFIKACJĘ fusów podczas ich programowania w MkAvrCalculator dla takich procków jak Atmega88/168/328 ale też 644 itp

to jest kwestia avrdude a nie programu MkAvrCalculator. Kłopot polega na tym, że ludzie którzy tworzyli definicje procków a różni ludzie je tworzą dla niektórych procków przyjęli że nie używane bity w ramach fusebitu EXTENDED mają wartość =1 a inni przyjęli że mają wartość =0

nie jest to w ogóle istotne z punktu widzenia programowania - no ale nie wiedzieć czemu przy zapisie avrdude na podstawie swojego configa przyjmuje że mają być zera (w tych nie używanych bitach a przy weryfikacji że jedynki - albo odwrotnie - już nie wnikam) i stąd ten głupi komunikat z avrdude

wystarczy jak mówię WYŁĄCZYĆ weryfikację i wszystko będzie się dobrze programować i odczytywać jeśli chodzi o FUSEBITY

naturalnie przy programowaniu samego wsadu czy eeproma można włączać sobie weryfikację tu zawsze dobrze działa

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Może podpiąć tą informację gdzieś, bo jest dosyć istotna.

No tak ale może niedługo zmienimy już avrdude na nowsze i może to nie będzie obowiązywać ? ... zobaczę

tak czy inaczej - nawet na czysto z konsoli jak się robi to avrdudem to jest dokładnie tak samo ... więc to na prawdę nic strasznego ...

jak uda nam się zupgrejdować avrdude na wersję 6.xx a nadal to będzie (sprawdzę) to wtedy w samym programie podepnę tą informację ewentualnie ok ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Spoko, ważne że jest na forum i można znaleźć