Klaus Zerbe wrote:
> Hi,
> i probably got into the same problems like Matt Eastburn.
>
> I also used AVStudio 4.13 to compile & link and burned the HEX and EEP
> files with AVR Prog 1.4 into an Atmega8L with an external Xtal with
> 36864 Mhz.
>
> I fused for Highsped external Xtal and 2.7V BOD, leaving all other fuses
> alone.
I found the following website useful when it comes to fuses:
http://palmavr.sourceforge.net/cgi-bin/fc.cgi
> Like for Matt the resulting controller did not communicate via USART.
> Reducing the baudrate didn't help. So I added some Assembler code for
> trace output and that worked. I could follow the inner interpreter and
> found this running all the time, but seemed not reaching the
> "applturnkey" ever.
Strange. Did you find out in which word the inner interpreter kept
so busy? I've observed this behavior only when I forgot to upload
the eeprom bytes.
> Finally I stopped this and used an ATmega168 instead. After correcting a
> Typo in "atmega168.asm" (The label ADCCaddr was written as ADCaddr) that
> compiled and linked fine and after burning that output amforth started
> without a problem.
It's not exactly a typo but a different name for the same address in
different tools. And I prefer the linux based ones ;=)
> So maybe something is wrong in "atmega8.asm" when using the Atmega8L ?
This and/or the fuses.
> @Matt: If possible, try also another controller since Atmega8 ist a
> little bit small for amforth anyway. There are only 17% memory free for
> your applications. Atmega168 is pincompatible but has 16kb instead 8kb
> FlashROM and a built-in far-distance JMP-instruction too ;)
at a very deep internal level, amforth uses the far-call instruction
even on systems which do not officially support the mnemomic. All
my atmega8 run fine with it and have no trouble with it, but maybe
not all are such tolerant. Can you please send me a picture of your
atmega directly? (the mailling list does not accept attachements)
together with your application definition file.
Matthias
|
