Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[D N. <dny...@at...>]

Yes, my fuse settings were wrong, and that was part of the problem. 
Also, for reasons I don't understand, the 18.4 mHz crystal isn't making 
it run at 18.4, but rather I measure it (crudely) at around 17.5. I'll 
try to make a more precise measurement with oscilloscope in a little 
while. Adjusting the uart divider value, I empirically found a value 
that works, then adjusting F_CPU in the source made it part of the code. 
So now I'm getting coherent responses out of the serial port. The scope 
may tell me a better value for F_CPU than one I calculated by 
experimenting with the uart counter register, though, so I'll do that 
shortly. Also less tedious! :)

On 3/26/2011 12:48:07 PM, Marcin Cieslak (sa...@sa...) wrote:
 > >> D Nyberg <dny...@at...> wrote:
 > > Issue 2: With the console running, I can do a few really basic things
 > > such as 1 . yields a correct response of 1 <cr> ok, but... If I 
enter 1
 >
 > > 2 + . I get the strange response "?? -13 6" <cr> ok.
 >
 >
 > Does the "words" command work? If not, there may be different issues.
 >
 > First, did you upload also EEPROM file ("filename.eep.hex") as well?
 > Many control variables etc. are set using EEPROM.

I have made this mistake in the very recent past! :) Fortunately not 
right now, though.

 >
 > Or alternatvely, you fuses may be wrong. Apart from the clock,
 > there may be something with the size of your bootloader area (BOOTSZ0,
 > BOOTSZ1) or the "Boot Reset vector Enabled (BOOTRST).
 >
 > I am using this to determine correct values, I think Erich gave
 > you those that are okay:
 >
 > http://www.engbedded.com/fusecalc
 >
 > //Marcin
 >
 >
 > 
------------------------------------------------------------------------------
 > Enable your software for Intel(R) Active Management Technology to 
meet the
 > growing manageability and security demands of your customers. Businesses
 > are taking advantage of Intel(R) vPro (TM) technology - will your 
software
 > be a part of the solution? Download

I believe I have figured out the cause of the really mysterious -13 6 
error. For example, I could enter "1" and "1 1" but it would fail if I 
entered "1 1 + ." I think the error was because I am using tera term, 
which sends a whole line at once. Combine that with the imperfect clock 
setting, and I think the atmel uart saw unprintable characters by byte 6 
or 7 in a string because of timing problems. Or possibly it's still set 
to polled serial (I set that a while ago to reduce variables, when I was 
having trouble getting it to run at all); the pc may be overruning 
characters. Anything I did in 4 or  5 characters worked ok, anything 6 
or more failed. Now that I have adjusted the clock value, I'm able to 
enter long lines. Sneaky problem, huh? But I think it's fixed now.

Thanks!