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 ([email protected]) wrote: > >> D Nyberg <[email protected]> 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! ------------------------------------------------------------------------------ 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 the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Amforth-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
