[Rozwiązano] ATmega2560 i CKDIV8 - nieprawidłowa prędkość po wyłączeniu fuse bitu

Cześć,
programuję ATmegę 2560. Procek jest taktowany zewnętrznym kwarcem 16MHz. Po wyłączeniu fuse bitu CKDIV8 procesor zaczął działać nieprawidłowo, przykładowo jeśli mam w kodzie wstawiony "_delay_ms(250)" to wykona się to kilkanaście razy szybciej niż to wpisane 250ms.
W Elipsie w zakładce MCU Clock Frequency w Eclipsie wybrałem zegar 16MHz.
Ktoś ma jakiś pomysł z czym to może być związane, to moja pierwsza przygoda z tak dużym procesorem.

CKDIV8 to bit odpowiedzialny za częstotliwość zegara taktującego procesor. Jeśli wyłączysz ten bit to zegar przyspieszy 8-krotnie. Według Twojego opisu wszystko jest ok.

Chyba nie do końca rozumiem w takim razie jak działa ten bit. Jeśli wybrałem zewnętrzny zegar 16MHz i wyłączyłem ten bit to procesor będzie taktowany z częstotliwością 16MHz. W takim układzie w programie definiuję F_CPU na 16MHz. Jeśli zostawiam CKDIV8 włączone to F_CPU powinienem mieć zdefiniowane jako 2MHz?
Bo aktualnie mam wyłączony CKDIV8 i F_CPU zdefiniowane na 16MHz i program wykonuje się za szybko. Czy jest możliwe że Eclips gdzieś ma zaszytą informację o tym czy wewnętrzny podział zegara jest włączony/wyłączony i przez to program wykonuje się źle?

loleczek189 napisał:

Jeśli wybrałem zewnętrzny zegar 16MHz i wyłączyłem ten bit to procesor będzie taktowany z częstotliwością 16MHz. W takim układzie w programie definiuję F_CPU na 16MHz. Jeśli zostawiam CKDIV8 włączone to F_CPU powinienem mieć zdefiniowane jako 2MHz?

Dokładnie tak.

Jest możliwe, że w niewłaściwym miejscu masz definicję F_CPU. Powinno to być w makefile, czyli w IDE gdzieś w opcjach projektu. Jesli to definiujesz w kodzie, to może być problem. Przy taktowaniu 16 MHz i takim ustawieniu F_CPU nie ma siły, żeby delay było krótsze, może co najwyżej się 8-krotnie wydłużyć.

F_CPU zdefiniowane w makefile, wybrane w opcjach projektu- korzystam z eclipsa.
Czy możliwe jest to że procesor jest uszkodzony i dlatego tak się zachowuje czy to raczej mało prawdopodobne?

Nie, procesor zachowuje się prawidłowo. Problem tkwi w definicji częstotliwości zegara w programie - jak pisał tmf. W ramach testu wpisz sobie np. 1MHz oraz 16MHz i sprawdź jaki to będzie miało wpływ na działanie programu. Pamiętaj, że eclipse to jest tylko edytor. Równie dobrze mógłbyś napisać, że piszesz program w notatniku i, że w ustawieniach notatnika ustawiasz częstotliwość. Tym czasem najważniejsze jest to co widzi kompilator czyli AVR GCC bo to on tworzy kod wynikowy.

Procesor działa normalnie z włączonym dzielnikiem( z 16MHz) i częstotliwością ustawioną na 16MHz w środowisku.

Procesor działa normalnie, ale skoro w eclipse ustawiłeś 16MHz a procesor z dzielnikiem jest taktowany częstotliwością 2MHz to chyba sam widzisz, że coś jest nie tak w tymi Twoimi ustawieniami z eclipsa. Dlatego napisałem Ci abyś ustawił w programie częstotliwość np. 1MHz i zobaczył jaki to będzie miało wpływ na szybkość działania aplikacji.

loleczek189 napisał:

F_CPU zdefiniowane w makefile, wybrane w opcjach projektu- korzystam z eclipsa.

Pokaż wyjście z konsoli, gdy kompilujesz projekt. W wywołaniu gcc powinieneś widzieć w jaki sposób info o F_CPU jest wysyłane do kompilatora i czy się to zgadza z tym co zdefiniowałeś.
Gdybyś używał Atmel Studio, które znam to mógłbym coś więcej poradzić, Eclipse jest dla mnie zbyt egzotyczne

Ok, zaraz sprawdzę co dzieje się dla różnych ustawień częstotliwości w Eclipsie.
make all
'Building file: ../printer/printer.c'
'Invoking: AVR Compiler'
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega2560 -DF_CPU=16000000UL -MMD -MP -MF"printer/printer.d" -MT"printer/printer.o" -c -o "printer/printer.o" "../printer/printer.c"
'Finished building: ../printer/printer.c'
' '
'Building file: ../LCD/lcd44780.c'
'Invoking: AVR Compiler'
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega2560 -DF_CPU=16000000UL -MMD -MP -MF"LCD/lcd44780.d" -MT"LCD/lcd44780.o" -c -o "LCD/lcd44780.o" "../LCD/lcd44780.c"
'Finished building: ../LCD/lcd44780.c'
' '
'Building file: ../main.c'
'Invoking: AVR Compiler'
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega2560 -DF_CPU=16000000UL -MMD -MP -MF"main.d" -MT"main.o" -c -o "main.o" "../main.c"
'Finished building: ../main.c'
' '
'Building target: DPF_Cleaner.elf'
'Invoking: AVR C Linker'
avr-gcc -Wl,-Map,DPF_Cleaner.map -Wl,-u,vfprintf -mmcu=atmega2560 -o "DPF_Cleaner.elf" ./printer/printer.o ./LCD/lcd44780.o ./main.o -lm -lprintf_flt
'Finished building target: DPF_Cleaner.elf'
' '
'Invoking: AVR Create Extended Listing'
avr-objdump -h -S DPF_Cleaner.elf >"DPF_Cleaner.lss"
'Finished building: DPF_Cleaner.lss'
' '
'Create Flash image (ihex format)'
avr-objcopy -R .eeprom -R .fuse -R .lock -R .signature -O ihex DPF_Cleaner.elf "DPF_Cleaner.hex"
'Finished building: DPF_Cleaner.hex'
' '
'Create eeprom image (ihex format)'
avr-objcopy -j .eeprom --no-change-warnings --change-section-lma .eeprom=0 -O ihex DPF_Cleaner.elf "DPF_Cleaner.eep"
'Finished building: DPF_Cleaner.eep'
' '
'Invoking: Print Size'
avr-size --format=avr --mcu=atmega2560 DPF_Cleaner.elf
AVR Memory Usage
----------------
Device: atmega2560

Program: 6200 bytes (2.4% Full)
(.text + .data + .bootloader)

Data: 332 bytes (4.1% Full)
(.data + .bss + .noinit)


'Finished building: sizedummy'
' '

No to robi się dziwnie. Zrzut sugeruje., że wszystko jest ok i program jest kompilowany dla 16 MHz, więc skrócenie delay jest niemożliwe. Pokaż najprostszy testowy program demonstrujący problem.
O ile mógłbym sobie wyobrazić powody, dla których opóźnienie się wydłuża, to brakuje mi już pomysłu dla którego w powyższej sytuacji miałby byc krótsze.

excray napisał:

abyś ustawił w programie częstotliwość np. 1MHz i zobaczył jaki to będzie miało wpływ na szybkość działania aplikacji

Jakieś postępy?

Najprawdopodobniej udało mi się rozwiązać. Problemem jednak było środowisko, pomogła reinstalacja.
Mam jeszcze problem z enkoderem, działa tylko w jedną stronę- nie da się zmniejszać wartości zmiennej a jeśli od komentuję linijkę "pozycja_menu--; w przerwaniu INT1 wartość stoi w miejscu. Obsługę enkodera wrzuciłem w przerwania, deboucing zrobiony jest hardwarowo:



Inicjalizacja enkodera wygląda w ten sposób:

Przede wszystkim, enkodery zwykle dają wynik w kodzie Graya. Więc twoje funkcje są całkowicie błędne - musisz najpierw zdekodować sygnał, a dopiero potem zmianiać na jego podstawie zmienną.

Czyli to, że na innym mikrokontrolerze ten kod działał prawidłowo to tylko przypadek i miałem dużo szczęścia?

loleczek189 napisał:

Czyli to, że na innym mikrokontrolerze ten kod działał prawidłowo to tylko przypadek i miałem dużo szczęścia?

Raczej tak. Enkoder daje dwa, przesunięte o 90 stopni (zazwyczaj) sygnały. Zawierają one zakodowaną informację o kierunku i liczbie kroków. Poszukaj jakiegoś przykładu jak taki sygnał zdekodować.

Rób sobie clean projektu po każdej zmianie parametrów. Jak chcesz sprawdzić czy o to chodziło to wystarczy zmienić taktowanie na 4MHz, zrobić clean, skompilować, zmienić na 16Mhz, skompilować i wgrać. Pewnie wgra Ci w wersji dla 4MHz. Przejście na Atmel Studio po Eclipse może być ciężkie, ale nie ma takich dziwnych zachowań i obsługuje wszystko co aktualnie wydaje producent. Dodanie do Eclipse Atmegi 328PB było nieco kłopotliwe. Kiedyś zrobiłem sobie blinka dla Arduino MEGA w Eclipse, wgrywam bez błędów i nic nie działa, skopiowałem do Arduino i po wgraniu USBASP czy przez bootloader działa, to samo w AS 6.2 - działa, a Eclipse nie działa. To samo z programatorem AVR ISP MKII działa w Arduino, AS i Eclipse - no magia, do dzisiaj nie wiem o co chodzi.

Reinstalacja środowiska rozwiązała problem