Witam, do dziś używałem ATMEGA32, teraz walczę z ATMEGA64. Na początek coś prostego miganie diodami (PORTA) - procedura opóźniająca zaczerpnięta z jakiegoś starego programu na ATMEGA32.
i nie działa, na PORTA nic się nie dzieje. Jeśli zamiast
wstawię
to diody zaczynają migać (miganie jest widoczne, więc nie migają z okresem 10ms). Jeśli procedurę opóźniającą wywołuję więcej razy to wszystko przestaje działać.
Myślałem, że przesiadka na "większy" procesor będzie łatwa, ale widzę schody. Zastanawiam się, czy "makefile", którego używałem z ATMEGA32 nie powinien być zmodernizowany (pomijając zmianę typu procesora). Używam takiego:
Mam kwarc 16M, fusebity ustawione jak na rysunku.
Jeśli ktoś wie, co robię nie tak, to proszę o jakieś info, bo siedzę nad tym już kilka godzin.
Pozdrawiam.
----------------------------------------------------------EDIT---------------------------------------------------------------------------------------------
Zmieniłem soft na coś takiego:
i okazuje się, że śle na terminal sekwencję "012345" i tak w kółko. Wniosek jest taki, że się resetuje - z parametrów transmisji można wyliczyć po jakim czasie jeśli taka informacja coś wniesie.
Teraz konkurs, co może być źródłem resetu?
Watchdog nie jest włączony (nie dotykałem jego rejestrów)
Brown-out reset też to raczej nie
Pin RESET jest podciągnięty do VCC przez Rez. 15k
Zostaje jeszcze JTAG, ale już dziś jeden procesor przestał gadać ze mną po SPI jak przestawiłem fusebit JTAGEN na 1 i wolałbym nie eksperymentować z ostatnim działającym prockiem
.
W ATMEGA32 i 16 nie wyłączałem JTAGA jeśli nie potrzebowałem jego portu i nie było problemu.
Wyczyściłem procesor do ustawień fabrycznych, więc tryb zgodności z ATMEGA103 nie jest już włączony.
Kiedyś miałem takie szopki, jak wgrałem do ATMEGA16 kod skompilowany na ATMEGA32
#define F_CPU 16000000UL
#include <util/delay.h>
#include <avr/io.h>
void waitms(unsigned int ms)
{
unsigned int i;
for (i=0;i<ms;i++)
{
_delay_ms(1);
}
}
int main(void)
{
DDRA=0xff;
while(1)
{
waitms(5);
PORTA^=0xff;
}
}
i nie działa, na PORTA nic się nie dzieje. Jeśli zamiast
waitms(5);
wstawię
_delay_ms(1);
_delay_ms(1);
_delay_ms(1);
_delay_ms(1);
_delay_ms(1);
to diody zaczynają migać (miganie jest widoczne, więc nie migają z okresem 10ms). Jeśli procedurę opóźniającą wywołuję więcej razy to wszystko przestaje działać.
Myślałem, że przesiadka na "większy" procesor będzie łatwa, ale widzę schody. Zastanawiam się, czy "makefile", którego używałem z ATMEGA32 nie powinien być zmodernizowany (pomijając zmianę typu procesora). Używam takiego:
PRG = pro
OBJ = pro.o
MCU_TARGET = atmega64
OPTIMIZE = -O2
DEFS =
LIBS =
# You should not have to change anything below here.
CC = avr-gcc
# Override is only needed by avr-lib build system.
override CFLAGS = -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) $(DEFS)
override LDFLAGS = -Wl,-Map,$(PRG).map
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
all: $(PRG).elf lst text eeprom
$(PRG).elf: $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
clean:
rm -rf *.o $(PRG).elf *.eps *.png *.pdf *.bak
rm -rf *.lst *.map $(EXTRA_CLEAN_FILES)
lst: $(PRG).lst
%.lst: %.elf
$(OBJDUMP) -h -S $< > $@
# Rules for building the .text rom images
text: hex bin srec
hex: $(PRG).hex
bin: $(PRG).bin
srec: $(PRG).srec
%.hex: %.elf
$(OBJCOPY) -j .text -j .data -O ihex $< $@
%.srec: %.elf
$(OBJCOPY) -j .text -j .data -O srec $< $@
%.bin: %.elf
$(OBJCOPY) -j .text -j .data -O binary $< $@
# Rules for building the .eeprom rom images
eeprom: ehex ebin esrec
ehex: $(PRG)_eeprom.hex
ebin: $(PRG)_eeprom.bin
esrec: $(PRG)_eeprom.srec
%_eeprom.hex: %.elf
$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O ihex $< $@
%_eeprom.srec: %.elf
$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O srec $< $@
%_eeprom.bin: %.elf
$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O binary $< $@
# Every thing below here is used by avr-libc's build system and can be ignored
# by the casual user.
FIG2DEV = fig2dev
EXTRA_CLEAN_FILES = *.hex *.bin *.srec
dox: eps png pdf
eps: $(PRG).eps
png: $(PRG).png
pdf: $(PRG).pdf
%.eps: %.fig
$(FIG2DEV) -L eps $< $@
%.pdf: %.fig
$(FIG2DEV) -L pdf $< $@
%.png: %.fig
$(FIG2DEV) -L png $< $@
Mam kwarc 16M, fusebity ustawione jak na rysunku.
Jeśli ktoś wie, co robię nie tak, to proszę o jakieś info, bo siedzę nad tym już kilka godzin.
Pozdrawiam.
----------------------------------------------------------EDIT---------------------------------------------------------------------------------------------
Zmieniłem soft na coś takiego:
int main(void)
{
USARTUSB_Init();
sei();
USARTUSB_Transmit(48);
USARTUSB_Transmit(49);
USARTUSB_Transmit(50);
USARTUSB_Transmit(51);
USARTUSB_Transmit(52);
USARTUSB_Transmit(53);
USARTUSB_Transmit(54);
USARTUSB_Transmit(55);
USARTUSB_Transmit(56);
USARTUSB_Transmit(57);
while(1)
{
}
}
i okazuje się, że śle na terminal sekwencję "012345" i tak w kółko. Wniosek jest taki, że się resetuje - z parametrów transmisji można wyliczyć po jakim czasie jeśli taka informacja coś wniesie.
Teraz konkurs, co może być źródłem resetu?
Watchdog nie jest włączony (nie dotykałem jego rejestrów)
Brown-out reset też to raczej nie
Pin RESET jest podciągnięty do VCC przez Rez. 15k
Zostaje jeszcze JTAG, ale już dziś jeden procesor przestał gadać ze mną po SPI jak przestawiłem fusebit JTAGEN na 1 i wolałbym nie eksperymentować z ostatnim działającym prockiem
W ATMEGA32 i 16 nie wyłączałem JTAGA jeśli nie potrzebowałem jego portu i nie było problemu.
Wyczyściłem procesor do ustawień fabrycznych, więc tryb zgodności z ATMEGA103 nie jest już włączony.
Kiedyś miałem takie szopki, jak wgrałem do ATMEGA16 kod skompilowany na ATMEGA32
