amforth-devel — Development discussion and user support

[Amforth-devel] Request For Clarification, ADC Library

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

I've found the ADC.frt file, and there's too much stuff in there for a 
sensible person to want to redo it, but I don't fully understand it yet, 
so I have some questions:

I have read on the web that the Atmel ADCs have severe accuracy problems 
(last 6 bits are little better than noise  in single ended mode, but 
differential is better), so... I'm guessing this word set operates in 
single ended mode? Can it, without extensive rewrite, be made to operate 
in differential mode? I gather that one ADC pin can be tied to ground, 
and any other ADC pin (or all other ADC pins?) can be made differential 
relative to that grounded pin. Am I understanding that correctly, and if 
so, could this word set be made to operate that way? For most 
applications, it seems to me that sacrificing one pin to ground would be 
a small price to pay if the others became more accurate as a result. Is 
this feasible?

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

[<ken...@al...>]

Hi, I soldered in a crystal and a couple of caps and it's working fine
now,  Amforth seems much more sensitive to clock frequency than the
Arduino C programs. 

I've had no trouble with the serial interface running C programs on the
BBB. That sent me on some wild goose chases trying to figure out what
was wrong with Amforth.

Thanks again for solving this one.

Ken

On Sun, 27 Mar 2011 21:08 -0600, "D Nyberg" <dny...@at...> wrote:
> I have few resources but the advice I can ask for here, and patience. 
> There's only so much you can lean on others who are not on payroll, so 
> I'd darn better be able to scrape up buckets of patience,  or I'll get 
> frustrated and make no progress! :) This would have been more fun with a 
> digital storage scope, but we make do with what we have.
> 
> You could also test the theory on your hardware, if you can run it under 
> a debugger, by adjusting the uart divider register up and down in 
> increments, to see if a nearby value would work better than what it's 
> using now. That assumes the resonator is stable, but possibly operating 
> at a different freq than expected, ie not varying moment to moment. I 
> don't know if that's their behavior or not though.
> 
> On 3/27/2011 11:07:25 AM, ken...@al... wrote:
>  > My thanks to all who worked on this problem. I have had an almost
>  > identical problem on a low cost arduino clone, the BBB by Modern Device.
>  > It uses a ceramic resonator rather than a crystal, so I expect the
>  > clock frequency to be a little off.
>  > I'll know whether that is the
>  > problem when I solder up one with a crystal instead.
>  >
>  > Good trouble shooting. You displayed more patience than I did.
>  >
>  > Ken
>  >
>  > On Sun, 27 Mar 2011 01:55 +0000, "Marcin Cieslak" <sa...@sa...>
>  > wrote:
>  > > >> D Nyberg <dny...@at...> wrote:
>  > > > 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
> 
> 
> ------------------------------------------------------------------------------
> 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
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

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

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

I have few resources but the advice I can ask for here, and patience. 
There's only so much you can lean on others who are not on payroll, so 
I'd darn better be able to scrape up buckets of patience,  or I'll get 
frustrated and make no progress! :) This would have been more fun with a 
digital storage scope, but we make do with what we have.

You could also test the theory on your hardware, if you can run it under 
a debugger, by adjusting the uart divider register up and down in 
increments, to see if a nearby value would work better than what it's 
using now. That assumes the resonator is stable, but possibly operating 
at a different freq than expected, ie not varying moment to moment. I 
don't know if that's their behavior or not though.

On 3/27/2011 11:07:25 AM, ken...@al... wrote:
 > My thanks to all who worked on this problem. I have had an almost
 > identical problem on a low cost arduino clone, the BBB by Modern Device.
 > It uses a ceramic resonator rather than a crystal, so I expect the
 > clock frequency to be a little off.
 > I'll know whether that is the
 > problem when I solder up one with a crystal instead.
 >
 > Good trouble shooting. You displayed more patience than I did.
 >
 > Ken
 >
 > On Sun, 27 Mar 2011 01:55 +0000, "Marcin Cieslak" <sa...@sa...>
 > wrote:
 > > >> D Nyberg <dny...@at...> wrote:
 > > > 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

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

[<ken...@al...>]

My thanks to all who worked on this problem.  I have had an almost
identical problem on a low cost arduino clone, the BBB by Modern Device.
 It uses a ceramic resonator rather than a crystal, so I expect the
clock frequency to be a little off.  I'll know whether that is the
problem when I solder up one with a crystal instead.

Good trouble shooting.  You displayed more patience than I did.

Ken

On Sun, 27 Mar 2011 01:55 +0000, "Marcin Cieslak" <sa...@sa...>
wrote:
> >> D Nyberg <dny...@at...> wrote:
> > 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.
> 
> Thank you, too, since sometimes those problems pop up in a while,
> now we have a solution. 
> 
> //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 the Intel(R) Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

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

[Marcin C. <sa...@sa...>]

>> D Nyberg <dny...@at...> wrote:
> 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.

Thank you, too, since sometimes those problems pop up in a while,
now we have a solution. 

//Marcin

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!

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

[Marcin C. <sa...@sa...>]

>> 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. 

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

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

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

Okay, the problem seems to have been a combination of wrong fuse bits, 
plus my hardware is running at 17.5 mHz instead of 18.4 as the crystal 
is marked. I'm thinking maybe the caps attached to the crystal are funny 
or something. But now it works, even from startup.

Now to better re-learn forth :)

Thanks, Erich!

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

[Erich W. <ew....@na...>]

Hello,

On 03/26/2011 11:31 AM, D Nyberg wrote:
> Okay gang, I'm making progress with my efforts to get amforth running,
> but encountering perplexing problems.
>
> Issue 1: I got the console running, but only by overriding the kernel's
> calculated uart divider value of 0x33 with my empirically determined
> value of 0x71. Must be running at a clock rate wildly different from
> what the crystal says, or is ignoring the crystal or something like
> that. Any thoughts on possible causes for this?
>
A brand new controller runs on its internal RC oszillator at roughly 1 MHz,
no matter what crystal is connected. To make the external crystal the
clock source for the controller, you must set the fuses accordingly.

Example: on the arduino duemilanove (atmega328p) with 16 MHz crystal, the
fuse values are
LFUSE=0xFF
HFUSE=0xD9
EFUSE=0x05
Check the file
amforth/releases/4.2/appl/arduino/readme.txt
in the amforth source tree.


>
> 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.

The output
?? -13 6
says: What you typed in, resulted in an error (??), -13 is "word not found",
iirc, and 6 is the column in which the not-found word ends.



Cheers,
Erich

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

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

Okay gang, I'm making progress with my efforts to get amforth running, 
but encountering perplexing problems.

Issue 1: I got the console running, but only by overriding the kernel's 
calculated uart divider value of 0x33 with my empirically determined 
value of 0x71. Must be running at a clock rate wildly different from 
what the crystal says, or is ignoring the crystal or something like 
that. Any thoughts on possible causes for this?

(BTW is there any way to set a break point at access  to a register? It 
looks like only memory space accesses are candidates for breakpoints, 
but I dunno...studio 4 btw)

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.

That one doesn't make any any sense to me at all. Thoughts or ideas?

Thanks!

Re: [Amforth-devel] Difficulty with Hello World exercise

[pito <pi...@vo...>]

Hi Helmut,
is there any chance to patch your hapsim 2.17 for working with
avrstudio4 build 716 (or the latest if any)? Thanks, Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "D Nyberg" <dny...@at...>
Komu: amf...@li...
Předmět: Re: [Amforth-devel] Difficulty with Hello World exercise
Datum: 23.3.2011 - 10:10:24

> Thank you! :)
> 
> On 3/23/2011 2:04:04 AM, Kalus Michael
> (mic...@on...) wrote:
> > Hi.
> >
> > http://dl.dropbox.com/u/1170761/aStudio4b589.exe
> >
> > michael
> >
> >
> >
> > Am 23.03.2011 um 07:09 schrieb D Nyberg:
> >
> > > On 3/22/2011 2:35:17 AM, pito (pi...@vo...)
> > > wrote:
> > > > >> Which AvrStudio4 build do you run? I've
> > >> upgraded to the latest 716
> > >> > >> and the Hapsim2.17 does not hook..
> > >>
> > > Okay, the hapsim page says it definitely works
> > > with studio 4 up to
> > > > > build
> > > 684. I too am up to 716 right now. How does
> > > one go about
> > > > > downgrading to
> > > 684, anyone know?
> 
> 
> ------------------------------------------------------------------------------
> > 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
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Difficulty with Hello World exercise

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

Thank you! :)

On 3/23/2011 2:04:04 AM, Kalus Michael (mic...@on...) wrote:
 > Hi.
 >
 > http://dl.dropbox.com/u/1170761/aStudio4b589.exe
 >
 > michael
 >
 >
 >
 > Am 23.03.2011 um 07:09 schrieb D Nyberg:
 >
 > > On 3/22/2011 2:35:17 AM, pito (pi...@vo...) wrote:
 > >> Which AvrStudio4 build do you run? I've upgraded to the latest 716
 > >> and the Hapsim2.17 does not hook..
 > >>
 > > Okay, the hapsim page says it definitely works with studio 4 up to
 > > build
 > > 684. I too am up to 716 right now. How does one go about
 > > downgrading to
 > > 684, anyone know?

Re: [Amforth-devel] Difficulty with Hello World exercise

[Kalus M. <mic...@on...>]

Hi.

http://dl.dropbox.com/u/1170761/aStudio4b589.exe

michael



Am 23.03.2011 um 07:09 schrieb D Nyberg:

> On 3/22/2011 2:35:17 AM, pito (pi...@vo...) wrote:
>> Which AvrStudio4 build do you run? I've upgraded to the latest 716
>> and the Hapsim2.17 does not hook..
>>
> Okay, the hapsim page says it definitely works with studio 4 up to  
> build
> 684. I too am up to 716 right now. How does one go about  
> downgrading to
> 684, anyone know?

Re: [Amforth-devel] Difficulty with Hello World exercise

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

On 3/22/2011 2:35:17 AM, pito (pi...@vo...) wrote:
 > Which AvrStudio4 build do you run? I've upgraded to the latest 716
 > and the Hapsim2.17 does not hook..
 >
Okay, the hapsim page says it definitely works with studio 4 up to build 
684. I too am up to 716 right now. How does one go about downgrading to 
684, anyone know?

Re: [Amforth-devel] Difficulty with Hello World exercise

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

On 3/22/2011 2:35:17 AM, pito (pi...@vo...) wrote:
 > Which AvrStudio4 build do you run? I've upgraded to the latest 716
 > and the Hapsim2.17 does not hook..

Well, rats! I too am running 716, so maybe that's why I'm not seeing 
anything on hapsim. Not having seen it run before, I don't have a 
standard of comparison to know what's normal. Um... I guess now I get to 
breakpoint emit and stuff and try to figure it out that way. :(

Re: [Amforth-devel] Difficulty with Hello World exercise

[pito <pi...@vo...>]

Which AvrStudio4 build do you run? I've upgraded to the latest 716
and the Hapsim2.17 does not hook..

----- PŮVODNÍ ZPRÁVA -----
Od: "D Nyberg" <dny...@at...>
Komu: amf...@li...
Předmět: Re: [Amforth-devel] Difficulty with Hello World exercise
Datum: 22.3.2011 - 9:29:56

> On 3/21/2011 2:19:15 AM, pito (pi...@vo...)
> wrote:
> > from my previous post...
> >
> > ....By chance I found the crash is caused
> > by the debugger - when the asm source wants to
> > continue into a
> > > "debugger" (for the code outside the
> > "amforth.asm") the debuger is
> > > called, but not set properly (my understanding)
> > and crashes.
> > > Now, how it works:
> > 1. compile amforth in AVR Studio as usuall
> > 2. then close all projects
> > 3. open file - e.g. amforth42_1284p.hex (MUST BE
> > .HEX)
> > > 4. Studio offers a new project name e.g.
> > amforth42_1284p_hex.aps -
> > > do save
> > 5. select device and debug platf
> 
> Okay, so I've been working with a clean
> (unmodified) amforth build in 
> the simulator, using this trick of loading the
> .hex file into a new 
> project. Determining what's going on in a forth
> system is hard enough as 
> is, when we have labels, but okay, I'll give it a
> go.
> 
> When I tell it to run, it ends up in the weeds,
> executing illegal 
> instruction ffff. As usual, it's hard to tell how
> it got there and as 
> far as I know, there's no way to get studio4 to
> show a log or traceback. 
> So I've been running it in autostep. Good news is
> it's not executing any 
> illegal instructions, bad news is it's been
> running a long time, and I 
> don't see any characters appearing at the
> simulated terminal (using hapsim).
> 
> So my question is, does anyone know how many
> instructions or cycles it 
> takes for a correctly operating amforth to send
> its first characters out 
> the uart, so I can tell if it's taken too long,or
> just has not yet 
> gotten that far?
> 
> ------------------------------------------------------------------------------
> > 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
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Difficulty with Hello World exercise

[pito <pi...@vo...>]

>From reset to the first characters ~3-4sec (old 1.7GHz notebook). P.

----- PŮVODNÍ ZPRÁVA -----
Od: "D Nyberg" <dny...@at...>
Komu: amf...@li...
Předmět: Re: [Amforth-devel] Difficulty with Hello World exercise
Datum: 22.3.2011 - 9:29:56

> On 3/21/2011 2:19:15 AM, pito (pi...@vo...)
> wrote:
> > from my previous post...
> >
> > ....By chance I found the crash is caused
> > by the debugger - when the asm source wants to
> > continue into a
> > > "debugger" (for the code outside the
> > "amforth.asm") the debuger is
> > > called, but not set properly (my understanding)
> > and crashes.
> > > Now, how it works:
> > 1. compile amforth in AVR Studio as usuall
> > 2. then close all projects
> > 3. open file - e.g. amforth42_1284p.hex (MUST BE
> > .HEX)
> > > 4. Studio offers a new project name e.g.
> > amforth42_1284p_hex.aps -
> > > do save
> > 5. select device and debug platf
> 
> Okay, so I've been working with a clean
> (unmodified) amforth build in 
> the simulator, using this trick of loading the
> .hex file into a new 
> project. Determining what's going on in a forth
> system is hard enough as 
> is, when we have labels, but okay, I'll give it a
> go.
> 
> When I tell it to run, it ends up in the weeds,
> executing illegal 
> instruction ffff. As usual, it's hard to tell how
> it got there and as 
> far as I know, there's no way to get studio4 to
> show a log or traceback. 
> So I've been running it in autostep. Good news is
> it's not executing any 
> illegal instructions, bad news is it's been
> running a long time, and I 
> don't see any characters appearing at the
> simulated terminal (using hapsim).
> 
> So my question is, does anyone know how many
> instructions or cycles it 
> takes for a correctly operating amforth to send
> its first characters out 
> the uart, so I can tell if it's taken too long,or
> just has not yet 
> gotten that far?
> 
> ------------------------------------------------------------------------------
> > 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
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Difficulty with Hello World exercise

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

On 3/21/2011 2:19:15 AM, pito (pi...@vo...) wrote:
 > from my previous post...
 >
 > ....By chance I found the crash is caused
 > by the debugger - when the asm source wants to continue into a
 > "debugger" (for the code outside the "amforth.asm") the debuger is
 > called, but not set properly (my understanding) and crashes.
 > Now, how it works:
 > 1. compile amforth in AVR Studio as usuall
 > 2. then close all projects
 > 3. open file - e.g. amforth42_1284p.hex (MUST BE .HEX)
 > 4. Studio offers a new project name e.g. amforth42_1284p_hex.aps -
 > do save
 > 5. select device and debug platf

Okay, so I've been working with a clean (unmodified) amforth build in 
the simulator, using this trick of loading the .hex file into a new 
project. Determining what's going on in a forth system is hard enough as 
is, when we have labels, but okay, I'll give it a go.

When I tell it to run, it ends up in the weeds, executing illegal 
instruction ffff. As usual, it's hard to tell how it got there and as 
far as I know, there's no way to get studio4 to show a log or traceback. 
So I've been running it in autostep. Good news is it's not executing any 
illegal instructions, bad news is it's been running a long time, and I 
don't see any characters appearing at the simulated terminal (using hapsim).

So my question is, does anyone know how many instructions or cycles it 
takes for a correctly operating amforth to send its first characters out 
the uart, so I can tell if it's taken too long,or just has not yet 
gotten that far?

[Amforth-devel] arduino uno

[Erich W. <ew....@na...>]

Hi,

yesterday I tried to run amforth (4.2) on a new "arduino uno" board.

In short words: it works with the exact same settings as for the
"arduino duemilanove".

The only difference is the name of the serial device (on Linux)
duemilanove:   /dev/ttyUSB#
uno:           /dev/ttyACM#


Cheers,
Erich

Re: [Amforth-devel] Difficulty with Hello World exercise

[pito <pi...@vo...>]

from my previous post...

....By chance I found the crash is caused
by the debugger - when the asm source wants to continue into a
"debugger" (for the code outside the "amforth.asm") the debuger is
called, but not set properly (my understanding) and crashes.
Now, how it works:
1. compile amforth in AVR Studio as usuall
2. then close all projects
3. open file - e.g. amforth42_1284p.hex (MUST BE .HEX)
4. Studio offers a new project name e.g. amforth42_1284p_hex.aps -
do save
5. select device and debug platform (simulator2 and 1284p)
6. finish
7. debuger opens and you will see the flash disassembled
8. then go Debug -> Up/download memory, choose EEPROM and load
eeprom from file e.g. amforth42_1284p.eep, open memory watch window
and select eeprom - you will see the eeprom content
9. TERMINAL - I did not find terminal in AVR Studio, so I downloaded
HAPSIM for AVR Studio: download, run hapsim.exe and do file -> New
Control -> Terminal, it will connect to AVR studio, you may set
settings
10. Place breakpoints where you want (here you see entire flash
disassembling only, so help yourself and open .lst file and navigate
accordingly) when not keen on stepping via all code there
11. when you Run the debuger you will see after few seconds
amforth's hello and promt in the Terminal, you may work as usual
(mind the respones are several seconds) and you may step via the
flash. ......

----- PŮVODNÍ ZPRÁVA -----
Od: "D Nyberg" <dny...@at...>
Komu: amf...@li...
Předmět: [Amforth-devel] Difficulty with Hello World exercise
Datum: 20.3.2011 - 23:30:35

> I'm having some difficulty getting started with
> amforth on my target 
> system; I'm shaking down the entire tool chain at
> once. (I'm a bit rusty 
> with forth generally, but used it intensively back
> in the F79 days, so 
> I'm remembering more every day) But my target
> hardware etc is all new at 
> this point, and I'm a bit stuck.
> 
> My workbench pc runs XP, and I've installed the
> latest AVR Studio 4 with 
> all 3 service packs. Attached to it is a dragon,
> and my newly assembled 
> dragon rider kit. The dragon rider seems to have
> survived smoke test, 
> and as far as I can tell is working correctly.
> Installed in the dragon 
> rider is a 324P. Dragon rider also has the serial
> option instralled, and 
> that's connected by straight-through cable to that
> pc's serial port 
> running teraterm.
> 
> I unpacked the amforth zip distribution and
> created a project per Karl 
> Lunt's getting started guide. I changed only the
> clock speed declaration 
> to match the 18.something mHz crystal supplied
> with the dragon rider, 
> and I also set both serial directions to polled,
> to simplify things for 
> now. I set include paths with the -I options in
> Studo 4 and built the 
> project. All seems to have worked, and hex files
> were created.
> 
> Studio downloads and verifies the code, both flash
> and eeprom regions. 
> Letting it run generates no OK prompt, so I've
> single stepped the 
> project from startup, by hitting F11 a step at a
> time. Control moves 
> through the usual init pointers type stuff, then
> jumps to the inner 
> interpreter at DO_EXECUTE.  When we get to the
> ijmp instruction, the Z 
> register contains 0x3860, which according to the
> map file is 
> PFA_DOLITERAL. This seems reasonable to me. But
> when the ijmp 
> instruction executes, studio4 crashes. It does
> this every time.
> 
> I duplicated these steps on my desktop machine
> (running windows 2000) 
> and targeted for the simulator. Everything works
> the same; execution of 
> that ijmp instruction again has 0x3860 in Z, and
> also crashes studio4.
> 
> Surely something that simple, in a tool chain
> that's been released as 
> long as studio4 has been out, can't be a simple
> bug in avr studio 
> regarding the ijmp instruction. But I'm scratching
> my head over this, 
> and have not, as a result, made much progress at
> getting amforth to run 
> here.
> 
> Any suggestions,please?
> 
> 
> ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> A question and answer guide to determining the
> best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Difficulty with Hello World exercise

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

On 3/20/2011 7:04:52 PM, Karl Lunt (kar...@se...) wrote:
 > Exactly. I've never had good luck using any simulator, AVRStudio's
 > included. I much prefer to trust the real hardware, even if you
 > start out using an LED for debug.
 >
 > BTW, have you tried out AVRStudio5 yet? It was released just a few
 > weeks ago and from the release notes, it looks like an excellent
 > upgrade.
 >
 > Karl


Well I first saw this effect while running on the hardware, using the 
dragon, and replicated it in the simulator to eliminate any possible 
faults in the dragon rider (as it's a newly soldered kit, and I don't 
much trust it yet). It manifested the same in both environments.

I'm using JTAG with dragon; does anyone have data to the effect that 
this sort of glitch is jtag specific, ie one of the other debug 
interfaces might behave differently? I would think using simulator would 
eliminate that variable.

I thought of trying 5, and may have to, but they made that one dependent 
on .net framework 4, which will not install on win2k, so only the xp 
machine runs that. I had hoped to be able to run the same toolchain at 
bench and desk.  Why they chose to restrict the next version that way I 
don't know, but they can do whatever they want without my permission. :( 
If I'm stuck using 5, then that suxxorz, as I'll have to do most of my 
coding at the bench, rather than the more comfortable desk place. :(

Re: [Amforth-devel] Difficulty with Hello World exercise

[Karl L. <kar...@se...>]

Exactly.  I've never had good luck using any simulator, AVRStudio's  
included.  I much prefer to trust the real hardware, even if you  
start out using an LED for debug.

BTW, have you tried out AVRStudio5 yet?  It was released just a few  
weeks ago and from the release notes, it looks like an excellent  
upgrade.

Karl

On Mar 20, 2011, at 3:16 PM, Marcin Cieslak wrote:

>> I duplicated these steps on my desktop machine (running windows 2000)
>> and targeted for the simulator. Everything works the same;  
>> execution of
>> that ijmp instruction again has 0x3860 in Z, and also crashes  
>> studio4.
>>
>> Surely something that simple, in a tool chain that's been released as
>> long as studio4 has been out, can't be a simple bug in avr studio
>> regarding the ijmp instruction. But I'm scratching my head over this,
>> and have not, as a result, made much progress at getting amforth  
>> to run
>> here.
>
> I am not using AVR studio at all (avra here) but it was mentioned
> on the mailing list that this is a known problem.  I don't think any
> solution has been found.
>
> What I do (and many others) we just upload our code to the target
> (I'm using avrdude) and we hack from there :)
>
> //Marcin
>
>
> ---------------------------------------------------------------------- 
> --------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Difficulty with Hello World exercise

[Marcin C. <sa...@sa...>]

> I duplicated these steps on my desktop machine (running windows 2000) 
> and targeted for the simulator. Everything works the same; execution of 
> that ijmp instruction again has 0x3860 in Z, and also crashes studio4.
>
> Surely something that simple, in a tool chain that's been released as 
> long as studio4 has been out, can't be a simple bug in avr studio 
> regarding the ijmp instruction. But I'm scratching my head over this, 
> and have not, as a result, made much progress at getting amforth to run 
> here.

I am not using AVR studio at all (avra here) but it was mentioned
on the mailing list that this is a known problem.  I don't think any
solution has been found.

What I do (and many others) we just upload our code to the target  
(I'm using avrdude) and we hack from there :)

//Marcin

[Amforth-devel] Difficulty with Hello World exercise

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

I'm having some difficulty getting started with amforth on my target 
system; I'm shaking down the entire tool chain at once. (I'm a bit rusty 
with forth generally, but used it intensively back in the F79 days, so 
I'm remembering more every day) But my target hardware etc is all new at 
this point, and I'm a bit stuck.

My workbench pc runs XP, and I've installed the latest AVR Studio 4 with 
all 3 service packs. Attached to it is a dragon, and my newly assembled 
dragon rider kit. The dragon rider seems to have survived smoke test, 
and as far as I can tell is working correctly. Installed in the dragon 
rider is a 324P. Dragon rider also has the serial option instralled, and 
that's connected by straight-through cable to that pc's serial port 
running teraterm.

I unpacked the amforth zip distribution and created a project per Karl 
Lunt's getting started guide. I changed only the clock speed declaration 
to match the 18.something mHz crystal supplied with the dragon rider, 
and I also set both serial directions to polled, to simplify things for 
now. I set include paths with the -I options in Studo 4 and built the 
project. All seems to have worked, and hex files were created.

Studio downloads and verifies the code, both flash and eeprom regions. 
Letting it run generates no OK prompt, so I've single stepped the 
project from startup, by hitting F11 a step at a time. Control moves 
through the usual init pointers type stuff, then jumps to the inner 
interpreter at DO_EXECUTE.  When we get to the ijmp instruction, the Z 
register contains 0x3860, which according to the map file is 
PFA_DOLITERAL. This seems reasonable to me. But when the ijmp 
instruction executes, studio4 crashes. It does this every time.

I duplicated these steps on my desktop machine (running windows 2000) 
and targeted for the simulator. Everything works the same; execution of 
that ijmp instruction again has 0x3860 in Z, and also crashes studio4.

Surely something that simple, in a tool chain that's been released as 
long as studio4 has been out, can't be a simple bug in avr studio 
regarding the ijmp instruction. But I'm scratching my head over this, 
and have not, as a result, made much progress at getting amforth to run 
here.

Any suggestions,please?

Re: [Amforth-devel] MCU in template.asm

[Matthias T. <mt...@we...>]

Hi,

> The makefile says that the MCU is also to be specified in template.asm, 
> but there appears to be no example line.

The definitions moved over time from one file to another, the remark in
the template/makefile is simply an artifact, please ignore it. Whats
relevant is the line

INCLUDE=-I $(AMFORTH) -I $(AMFORTH)/devices/$(MCU)

which uses the Makefile variable MCU. Some earlier versions used the
the line

.include "devices/atmega16.asm"

instead of the current

.include "device.asm"

in template.asm. With the above INCLUDE settings, the right controller
type is now used from the device/ source tree.

My goal was to simplify the definitions and put the controller
definitions into one file, not more. And the MCU needs to be known
for at least avrdude as well, thus the Makefile is the master.
(build.xml is the same story).

Matthias