Czy ten makefile jest dobry? Chcę zaprogramować attiny2313, za pomocę programu Geany na Linuxie i taki znalazłem wzór makefile. Kompilacja przebiega prawidłowo, ale przy programowaniu procka otrzymuję komunikat: Tutaj makefile:Log z kompilacji:
Takie pliki wygenerowało:

Zalecam oszczędność (Prezes PKO ), lub większy kontroler.

Tylko że to prosty program do migania diodą z tej strony https://starter-kit.nettigo.pl/2012/04/ ... -opornych/ Chyba niepotrzebnie tyle plików mi wygenerował, bo eepromu przecież nie programuję, może dlatego tyle miejsca zajmuje.

Ten make dodaje chyba wszystko co może.
Proponuję zainstalować w Twoim Linuksie- Eclipse'a, tam z poziomu IDE będzie prościej zapanować nad kompilacją.
Opanować make też można, ale to już "wyższy stopień wtajemniczenia", na początek niepotrzebny.

Myślałem o tym, ale widziałem opinie, że Eclipse jest zasobożerne i może zamulać na moim komputerze. AVR8 Burn-O-Mat u mnie dość długo się uruchamia, więc nawet nie próbowałem instalować Eclipse, wolę coś lżejszego. Kiedyś komendy odpalałem z ręcznie z konsoli, ale wolałbym trochę zautomatyzować to, żeby wystarczyło tylko raz makefile dostosować do danego projektu i w wygodny sposób kompilować i programować jednym kliknięciem. Tylko właśnie te przykładowe makefile to takie kombajny są, a prostszych gdzie wystarczy zdefiniować podstawowe parametry kompilacji i programatora nie znalazłem.

A co Ty masz za komputer, że długo Ci się odpalają softy? Jak nie chcesz lub nie możesz go zmienić to powinno wystarczyć odpalanie ręcznie kompilatora a na koniec linkera.

Na starszym stacjonarnym robię, to nie kilkurdzeniowy sprzęt z kilka gb ramu, więc niektóre bardziej rozbudowane programy zamulają, ale do prostych zadań wystarcza. BurnOMat jest w Javie napisany i pewnie dlatego pojawia się po nieco dłuższej chwili, bo inne programy działają szybciej. Skoro na Eclipse sporo osób narzekało, że im wolno chodzi, to u mnie na pewno nie będzie lepiej. Trudno, coś będę kombinować z opcjami w Geany, ale wolałem to do makefile wrzucić.

Edit:
Pewnie głupie pytanie, ale jak definiuje się typ mikrokontrolera w avr-gcc i avrdude? Z tego co wiem, to w parametrach do avr-gcc podaje się -mmcu=attiny2313, a do polecenia avrdude -p t2313. Ale tamten makefile do obu poleceń wstawia attiny2313. Avrdude rozróżnia obie formy?

Puść z konsoli:
avrdude -pattiny2313 -P usb -c usbasp -n
lub
avrdude -pt2313 -P usb -c usbasp -n
to sprawdzisz.

Jak masz zabytkowy PC to zobacz czy np. to nie będzie odpowiednie:
https://www.forbot.pl/forum/topics20/programowanie-programowanie-avr-w-linux-vt3667.htm
http://home.roboticlab.eu/en/examples/setup/kontrollerlab

Bawisz się linuxem a nie spróbujesz tego co Ci podpowiedziałem.

Trudno, podrzucam przykład jak Mirkowy MkClipse (for Windows) kompiluje jeden z moich sofcików i nie potrzebujesz żadnego makefile'a:
avr-gcc -Wall -Os -Wstrict-aliasing=1 -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega32a -DF_CPU=11059200UL -MMD -MP -MF"Release/MK_USART/mkuart.d" -MT"Release/MK_USART/mkuart.o" -c -o "Release/MK_USART/mkuart.o" "MK_USART/mkuart.c""
avr-gcc -Wall -Os -Wstrict-aliasing=1 -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega32a -DF_CPU=11059200UL -MMD -MP -MF"Release/mk_build.d" -MT"Release/mk_build.o" -c -o "Release/mk_build.o" "mk_build.c""
avr-gcc -Wall -Os -Wstrict-aliasing=1 -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega32a -DF_CPU=11059200UL -MMD -MP -MF"Release/main.d" -MT"Release/main.o" -c -o "Release/main.o" "main.c""
avr-gcc -Wall -Os -Wstrict-aliasing=1 -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega32a -DF_CPU=11059200UL -MMD -MP -MF"Release/LCD/lcd44780.d" -MT"Release/LCD/lcd44780.o" -c -o "Release/LCD/lcd44780.o" "LCD/lcd44780.c""

avr-gcc -Wl,-Map,Release/DEM401_tester.map -Wl,--gc-sections -mmcu=atmega32a -o "Release/DEM401_tester.elf" Release/LCD/lcd44780.o Release/MK_USART/mkuart.o Release/main.o Release/mk_build.o
avr-objdump -h -S Release/DEM401_tester.elf > "Release/DEM401_tester.lss"
avr-objcopy -R .eeprom -R .fuse -R .lock -R .signature -O ihex Release/DEM401_tester.elf "Release/DEM401_tester.hex"
avr-objcopy -R .eeprom -R .fuse -R .lock -R .signature -O binary Release/DEM401_tester.elf "Release/DEM401_tester.bin"
avr-objcopy -j .eeprom --no-change-warnings --change-section-lma .eeprom=0 -O ihex Release/DEM401_tester.elf "Release/DEM401_tester.eep"
avr-size --format=avr --mcu=atmega32a Release/DEM401_tester.elf

Pod Linuksem bez parametru - P usb

Tam porty są inaczej nazywane. Wystarczy w tym przypadku parametr -c usbasp

Widać, że programowanie idzie prawidłowo ale wsad się nie mieści. Na początek powinieneś w sekcji opisanej jako "Library Options" pozbyć się niepotrzebnych w tym przypadku bibliotek: libm i libprinf. To powinno odchudzić kod.
Zakomentuj to co jest i utwórz symbole bez zawartości. W razie potrzeby skorzystania z printfów z floatami będzie można to łatwo odkomentować.

To to wiem, że w konsoli wystarczy odpalić i to działa, kiedyś tak właśnie robiłem. Teraz wpisałem sobie te polecenia w Geany do zakładki Zbuduj, dzięki czemu od razu kompiluje i programuje procka po wciśnięciu F9, ale nie edytuje się poleceń tak wygodnie jak w Makefile.
Spróbuję, ale pewnie i tak nie odchudzi tak bardzo.