amforth-devel — Development discussion and user support

Re: [Amforth-devel] amforth 4.0 for duemilanove hangs after prompt

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

Hello,

I can confirm the original problem
 > warning: end of .cseg at 0x8ce2 is beyond end of memory at 0x7fff".
for a duemilanove board with a fresh clean checkout of amforth 4.0.
I moved everything after the line

.include "words/ifetch.asm"

from dict_appl_core.inc to dict_appl.inc. That makes the warning go
away. There must be a better way to see, how much more fits into the
NRWW section.

Uploading(*) the resulting files to the board works, setting the fuses as
detailed in the readme.txt gives me a prompt (9600 baud).

amforth 4.0 ATmega328P ok
 > _

HOWEVER, compiling a word does stall the controller. Pressing reset gives
a new prompt, but the system is not working any more. Something related
to writing flash seems to be broken.

(*) uploading is done with a very simple "sp12" parport programmer.

Cheers,
Erich

On 08/04/2010 06:16 PM, ken...@al... wrote:
> Hi Andy,
>
> Thanks for your quick response.
>
>> What are you using as your build route/toolchain ?
>

Re: [Amforth-devel] amforth 4.0 for duemilanove hangs after prompt

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

Hi Andy,

Thanks for your quick response.  

> What are you using as your build route/toolchain ?

Kubuntu Linux v,9.10 on an AMD 64 bit dual core processor
Apache Ant version 1.7.1 compiled on July 2 2010
wine-1.0.1
AVRASM ver. 2.1.42 
then I move the .hex files to an old desktop and program the chip using
uisp version 20050207 and a very crude Parallel Port programmer from 
http://www.arduino.cc/en/Hacking/ParallelProgrammer

> A second question (sorry got to ask it most folks miss it) did you
> program the eeprom ??

Yes.  Don't feel bad - I've worked in Tech. Support and have had to ask,
"Is it plugged in?".

> What fuses did you program ??

None, I left them at the defaults for the duemilanove.

> At a guess I would think that the second problem is perhaps related to
>the first in that the core code compiles to just under 8k. This should
> fit into the memory of a 32k device easily with bags of room to spare.

Yes the code is less than 8k.  The problem is that there's an .org
0x3800 before the *_core* includes so they go into the NRWW section of
eprom.  With dict_minimum.inc in the *_core* group of includes, the
program overflows memory.

> Your base addresses etc would appear to be wrong.

Yes, I've spent a lot of time being confused the last couple of days. 
Atmel seems to use byte addresses sometimes and word (16 bit) addresses
others. e.g. with the proper fuses the datasheet says the NRWW section
is from 0x3800 to 0x3fff.  You will see that the assembly listing goes
up to 0x4671 but the error message says, "duemilanove.asm(24): warning:
end of .cseg at 0x8ce2 is beyond end of memory at 0x7fff". Two times
0x4671 is 0x8ce2.

I am inclined to believe that there may be a problem with my two
different serial port adapters since I've consistently had the "amf"
symptom since amforth 3.7.  However, I have been able to use both serial
port adapters to program the BBB using the bootloader.  I'm going to try
different baud rates just because it's easy and might work.

Regards,
Ken




On Wed, 04 Aug 2010 14:33 +0100, "an...@ki..."
<an...@ki...> wrote:
> At a guess I would think that the second problem is perhaps related to
>the first in that the core code compiles to just under 8k. This should
> fit into the memory of a 32k device easily with bags of room to spare.
> 
> Your base addresses etc would appear to be wrong.
> 
> A second question (sorry got to ask it most folks miss it) did you
> program the eeprom ??
> 
> What are you using as your build route/toolchain ??
> 
> What fuses did you program ??
> 
> I haven't built the most recent release but will do when I get a mo. Its
> on the to-do list.
> 
> Cheers
> 
> Andy Kirby
> 
> 
> 
> On 04/08/10 03:41, ken...@al... wrote:
> > Hi,
> > 
> > I have tried using both my serial port adapter and my FTDI USB serial
> > adapter on amforth 4.0 assembled for the duemilanove.  (The board I'm
> > actually using is one of the free clones of the arduino with separate
> > serial adapters). I have used both minicom under linux and a terminal
> > emulator under Windows with nearly the same results.  Both of the serial
> > adapters have been used successfully for serial programming of the
> > arduino.
> > 
> > When minicom starts I see:
> > 
> > 
> > amforth 4.0 ATmega328P
> >> amf
> > 
> > Pressing reset on the Arduino causes another "amf" to be output so I
> > get:
> > 
> > 
> > amforth 4.0 ATmega328P
> >> amfamf
> > 
> > There is no response to keyboard input.
> > 
> > Do you have any suggestions on where to start troubleshooting this
> > problem?  I noticed that the duemilanove is using polling for both input
> > and output now.  I had the same symptoms with earlier versions using
> > interrupts.
> > 
> > Thanks,
> > Ken
> > 
> > ------------------------------------------------------------------------------
> > The Palm PDK Hot Apps Program offers developers who use the
> > Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> > of $1 Million in cash or HP Products. Visit us here for more details:
> > http://p.sf.net/sfu/dev2dev-palm
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > 
> 
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] amforth 4.0 for duemilanove hangs after prompt

[<an...@ki...>]

At a guess I would think that the second problem is perhaps related to
the first in that the core code compiles to just under 8k. This should
fit into the memory of a 32k device easily with bags of room to spare.

Your base addresses etc would appear to be wrong.

A second question (sorry got to ask it most folks miss it) did you
program the eeprom ??

What are you using as your build route/toolchain ??

What fuses did you program ??

I haven't built the most recent release but will do when I get a mo. Its
on the to-do list.

Cheers

Andy Kirby



On 04/08/10 03:41, ken...@al... wrote:
> Hi,
> 
> I have tried using both my serial port adapter and my FTDI USB serial
> adapter on amforth 4.0 assembled for the duemilanove.  (The board I'm
> actually using is one of the free clones of the arduino with separate
> serial adapters). I have used both minicom under linux and a terminal
> emulator under Windows with nearly the same results.  Both of the serial
> adapters have been used successfully for serial programming of the
> arduino.
> 
> When minicom starts I see:
> 
> 
> amforth 4.0 ATmega328P
>> amf
> 
> Pressing reset on the Arduino causes another "amf" to be output so I
> get:
> 
> 
> amforth 4.0 ATmega328P
>> amfamf
> 
> There is no response to keyboard input.
> 
> Do you have any suggestions on where to start troubleshooting this
> problem?  I noticed that the duemilanove is using polling for both input
> and output now.  I had the same symptoms with earlier versions using
> interrupts.
> 
> Thanks,
> Ken
> 
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth-devel] amforth 4.0 for duemilanove hangs after prompt

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

Hi,

I have tried using both my serial port adapter and my FTDI USB serial
adapter on amforth 4.0 assembled for the duemilanove.  (The board I'm
actually using is one of the free clones of the arduino with separate
serial adapters). I have used both minicom under linux and a terminal
emulator under Windows with nearly the same results.  Both of the serial
adapters have been used successfully for serial programming of the
arduino.

When minicom starts I see:


amforth 4.0 ATmega328P
> amf

Pressing reset on the Arduino causes another "amf" to be output so I
get:


amforth 4.0 ATmega328P
> amfamf

There is no response to keyboard input.

Do you have any suggestions on where to start troubleshooting this
problem?  I noticed that the duemilanove is using polling for both input
and output now.  I had the same symptoms with earlier versions using
interrupts.

Thanks,
Ken

[Amforth-devel] amforth4.0 too large for Arduino Duemilanove

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

Hi,

I'm trying amforth v.4.0 on a freeduino, the BBB from Modern Devices in
the U.S.  uisp gave me an error about an address violation (Sorry, I
don't have the exact text.)  I looked at dueminanove.lst.  It has a
Warning, "duemilanove.asm(24): warning: end of .cseg at 0x8ce2 is beyond
end of memory at 0x7fff".

I moved dict_minimum from dict_appl_core.inc to dict_appl.inc and got
rid of the error message.  According to the listing, the end of used
memory is now 0x3f00 instead of 0x4671.  This may not be the best
solution for the ATmegas with larger NRWW memory spaces.

Thanks for your effort.  I'm looking forward to writing forth for this
little machine.

Ken

[Amforth-devel] For - next vs Do - Loop

[D W. <dou...@ya...>]

> I've tried FlashForth recently (have a
look on it - a lot of ineresting features you may utilise), however
the creator does insist on FOR NEXT instead of DO LOOP. Frankly, I
do not understand that..Pito

The creator of forth feels that FOR - NEXT is significantly more efficient than DO - LOOP.  Unfortunately, I have no luck google-ing the exact page I wish to reference, but here is a page that quotes Moore

<chipChuck> FOR NEXT is much simpler than DO LOOP, especially for hardware implementation

http://tom.bespin.org/src/old/Chuck%20Moore%205-4-02.txt

Since forth is Moore's personal tool, he does whatever he wishes, and others chose to follow or not.  All implementations are considered simultaneously 'correct' if they do what they are intended, and 'incorrect' if they differ from Chuck.  And Chuck tends change his mind as he sees fit, and doesn't always tell anyone, so nobody really worries. The result is many different 'flavors' of forth. 

Doug Williams CSQE



      

Re: [Amforth-devel] amforth - how to make him case insensitive

[<an...@ki...>]

Umm I prefer languages and OS's to be case sensitive.

(I guess being a unix/linux type of guy)

In forths case the case sensitivity gives you more scope to create words
that are named meaningfuly.

If you are operating case insensitive you have less combinations
available to you when making words and are more likely to end up naming
your forth functions and subroutines with soemthing that is meaningless.
just because you are running out of options (particularly when trying to
think of a new word name on the fly, without digging out a dictionary).

It's arithmetic really, this is why passwords that use upper and lower
case on case sensitive systems are far more secure. (combinatorial
explosion)

However....

There is perhaps an argument for adopting a case styling convention for
word names that differs from say variable names to help code readability.

What that stylistic convention could be I am not going to get into. It
is a very easy way to promote a mass brawl as firmly held preferences
vary so widely. Casing though is one of many options.

Thoughts for what they are worth...



On 29/07/10 18:16, Matthias Trute wrote:
> Pito,
> 
> 
>> when you do insist on case sensitivness than do make the forth words
>> uppercase...
> 
> Why do you think I insist on case sensitivness? Case sensitivness
> is simpler to implement (take it as an axiom if you do not believe
> it). Its very easy do write a converter in any language on the PC 
> side, even windows VBS can do that:
> 
> Dim upper as String = "converted from lowercase" 
> Console.WriteLine(upper.ToUpper())
>     Console.WriteLine(UCase(upper))
>     Console.WriteLine(StrConv(upper,VbStrConv.UpperCase))
> 
> not to mention the many unix tools like tr...
> 
>> Who actually needs case sensitive forth?? 
> 
> I do and will do so for the next few months, at least.
> 
>> PS: It is interesting how the creators of such
>> nice sw implementations do insist on something, which an average
>> user does not understand.. I've tried FlashForth recently (have a
>> look on it - a lot of ineresting features you may utilise), however
>> the creator does insist on FOR NEXT instead of DO LOOP. Frankly, I
>> do not understand that..
> 
> Thats life. And FF is interesting, indeed.
> 
> 
> Matthias
> 
> PS: If _you_ insist on case insensitivness, feel free to send a 
> patch, that I can consider to include into amforth. Thats the way Open
> Source Software works and thats the reason why I share amforth with 
> other people
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> 
> 
> 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] amforth - how to make him case insensitive

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

Pito,


> when you do insist on case sensitivness than do make the forth words
> uppercase...

Why do you think I insist on case sensitivness? Case sensitivness
is simpler to implement (take it as an axiom if you do not believe
it). Its very easy do write a converter in any language on the PC 
side, even windows VBS can do that:

Dim upper as String = "converted from lowercase" 
Console.WriteLine(upper.ToUpper())
    Console.WriteLine(UCase(upper))
    Console.WriteLine(StrConv(upper,VbStrConv.UpperCase))

not to mention the many unix tools like tr...

> Who actually needs case sensitive forth?? 

I do and will do so for the next few months, at least.

> PS: It is interesting how the creators of such
> nice sw implementations do insist on something, which an average
> user does not understand.. I've tried FlashForth recently (have a
> look on it - a lot of ineresting features you may utilise), however
> the creator does insist on FOR NEXT instead of DO LOOP. Frankly, I
> do not understand that..

Thats life. And FF is interesting, indeed.


Matthias

PS: If _you_ insist on case insensitivness, feel free to send a 
patch, that I can consider to include into amforth. Thats the way Open
Source Software works and thats the reason why I share amforth with 
other people

Re: [Amforth-devel] amforth - how to make him case insensitive

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

Matthias,
when you do insist on case sensitivness than do make the forth words
uppercase... There are tons of sw and libraries on the web you
cannot run easily as they are uppercase... Who actually needs case
sensitive forth?? PS: It is interesting how the creators of such
nice sw implementations do insist on something, which an average
user does not understand.. I've tried FlashForth recently (have a
look on it - a lot of ineresting features you may utilise), however
the creator does insist on FOR NEXT instead of DO LOOP. Frankly, I
do not understand that..Pito
----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth"
<amf...@li...>Předmět: Re: [Amforth-devel] amforth - how to make him case
Datum: 28.7.2010 - 20:26:22

> Hi,
> 
> > Hi friends,
> > is there any trick how to make him Case
> > insensitive?
> amforth is case sensitive, I may change that
> sometimes,but now. A quick fix is a simple case converter,
> like perl or tr, but I do not know about such
> toolsfor Windows ;=)
> 
> PS: the python scripts could do the job as well,
> there are python build-in functions to convert
> case, but see above not for Windows...
> 
> maybe VBS or javascript could be used as well...
> 
> Matthias
> 

Re: [Amforth-devel] Variable and 2variable space in ram, .res info

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

Am Montag, den 26.07.2010, 18:05 +0200 schrieb pito: 
> Hi, 
> why a variable xxx occupies 2 cells? (when observing with ".res"
> word) and 2variable 4 cells? (with the definition -> : 2variable
> here 2 cells allot constant ; ).OR: does .res returns # of Bytes instead of cells?

.res prints usually bytes, the cells are misleading at all. Will fix
ASAP

Matthias

Re: [Amforth-devel] amforth - how to make him case insensitive

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

Hi,

> Hi friends,
> is there any trick how to make him Case insensitive?

amforth is case sensitive, I may change that sometimes,
but now. A quick fix is a simple case converter,
like perl or tr, but I do not know about such tools
for Windows ;=)

PS: the python scripts could do the job as well,
there are python build-in functions to convert
case, but see above not for Windows...

maybe VBS or javascript could be used as well...

Matthias

[Amforth-devel] Variable and 2variable space in ram, .res info

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

Hi, 
why a variable xxx occupies 2 cells? (when observing with ".res"
word) and 2variable 4 cells? (with the definition -> : 2variable
here 2 cells allot constant ; ).OR: does .res returns # of Bytes instead of cells?

> .res
free FLASH cells      9628 
free RAM cells        1754 
used EEPROM cells     62 
used data stack cells 0 
used return stack     10 
free return stack     70 
ok
> 2variable diameter
ok
> .res
free FLASH cells      9620 
free RAM cells        1750 
used EEPROM cells     62 
used data stack cells 0 
used return stack     10 
free return stack     70 
ok
>  variable aaa
ok
> .res
free FLASH cells      9614 
free RAM cells        1748 
used EEPROM cells     62 
used data stack cells 0 
used return stack     10 
free return stack     70 
ok

Thanks, pito.

[Amforth-devel] amforth - how to make him case insensitive

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

Hi friends,
is there any trick how to make him Case insensitive? There is a lot
of examples with uppercase words, however amforth rejects such
sources..Thanks, Pito.

[Amforth-devel] Forfiter 1.4 - still a speed issue, Mosaic Terminal

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

Hi, I've tried the new Forfiter 1.4. Unfortunately it still does not
work at 115200. I'am using the MosaicTerminal v1.27 now. It supports
Forth upload and does work fine at 115200. Pito

Re: [Amforth-devel] Beginner's experience

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

Pito,

At first: Thank you ver much for sharing your experience with us (me).
I highly appreciate it!

> I got a dev system which is fully stable (usb usart and usb programmer,
> Avr Studio, Avrdude, XP SP3). So I am a win user who does not fit into
> the community (:-)..

Hey, despite the fact that I prefer Linux does not mean its unusual to
use different program starting environments ;=)

> I found Forfiter, which enabled me to upload (however it works with 
> 19k2 max) as it has ok commit. 

Lubos told recently me that he has published a new version of his tool. 
And that he does not use high speed transfers ;=)

> I do not have access to python and pearl scripts (XP Python incompatibility)so
> the only way is to upload the required frts (marker, 2x, atmega32 reg
> def, etc)each time again. Then marker - dev and I tried again. When
> happy and none crash I used -dev to start again without a reflash.

You can not only upload a hex file to the controller but also download
the flash/eeprom from the controller. That I do so from time to time..


> The biggest problem for me (a beginner) is the "OS" ruggedness and support.
> The new words might be available on net, but the OS is hardwired. Words
> like .s and .res did not help me much, so I did mostly "try and error"
> wise, with frequent reflashing the rom. Many times the systems stoped
> response after running the new word and I lost the acces to the system.
> Even hardware reset did not help.

Sounds familiar :=( Any idea for a debugger? It has to be small, and
minimal invasive and fool proof..

> The ctrl-C for return to interpreter, or ctrl-Q for a soft reset would
> be
> really necessary. Also some stack overflow exception with a return to
> prompt would be a nice feature.

I usually press a reset button. Works almost all of the time. But see
above: any ideas (and code of course) for a debugger are welcome.

> Maybe the current linux toolchain is more advanced, however the development
> process with amforth and my XP tools is a challenge for a beginner (not
> speaking about a good simulator..)

The linux toolchain is absolutly mine, I think I'm the only one who
uses ant for calling a windows assembler with it. Feel free to send
patches/documentation/howtos to do it better. I just hacked
an ugly screenshot series to document the avr studion usage, but I'd not
really recommend it.

> PS: Any plans for amforth 32bit with float??

Not currently. Maybe someone want to volonteer?

Matthias

Re: [Amforth-devel] devices

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

Ian,

> For devices does AVRA only need to support the following in order to
> support AMForth?
>
> at90can128	atmega168	atmega32	atmega644	atmega88
> atmega1280	atmega169	atmega328p	atmega644p	atxmega128a1
> atmega16	atmega2561	atmega640	atmega8
>
> This is just a listing from the amforth-cur/releases/4.0/core/devices
> directory.

Well this is a list of known-good devices. amforth should run on any
Atmega with at least 8KB flash memory.

Matthias

[Amforth-devel] devices

[Ian J. <ij...@sa...>]

OK,

I think this is a dumb question but ... I once met a Rhodes Scholar that asked similar questions... just before she became a Rhodes Scholar.  Anyway here goes.

For devices does AVRA only need to support the following in order to support AMForth?

at90can128	atmega168	atmega32	atmega644	atmega88
atmega1280	atmega169	atmega328p	atmega644p	atxmega128a1
atmega16	atmega2561	atmega640	atmega8

This is just a listing from the amforth-cur/releases/4.0/core/devices directory.

Ian
ij...@sa...

Re: [Amforth-devel] My issue with 2variable in int_isr

[<an...@ki...>]

I don't know about the tronics but I certainly loose the urge to try.

On 09/07/10 19:58, pito wrote:
> Does your dev system stop working when outside 30degC? (:-))). P.
> 
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "Matthias Trute" <mt...@we...>
> Komu: "Everything around amforth" <amf...@li...>
> Předmět: Re: [Amforth-devel] My issue with 2variable in int_isr
> Datum: 9.7.2010 - 20:26:08
> 
>> Hi Pito,
>>
>>
>>> it crashes in such a way I have to reflash rom to
>>> get access to system.
>>>> What is the trick here?
>>
>> Well, it crashes outside of any interrupt as well.
>> I've got
>> no idea why so far. And it's way too hot outside...
>>
>> Sorry
>> Matthias
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] My issue with 2variable in int_isr

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

Does your dev system stop working when outside 30degC? (:-))). P.

----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth" <amf...@li...>
Předmět: Re: [Amforth-devel] My issue with 2variable in int_isr
Datum: 9.7.2010 - 20:26:08

> Hi Pito,
> 
> 
> > it crashes in such a way I have to reflash rom to
> > get access to system.
> > > What is the trick here?
> 
> Well, it crashes outside of any interrupt as well.
> I've got
> no idea why so far. And it's way too hot outside...
> 
> Sorry
> Matthias
> 

Re: [Amforth-devel] My issue with 2variable in int_isr

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

Hi Pito,


> it crashes in such a way I have to reflash rom to get access to system.
> What is the trick here?

Well, it crashes outside of any interrupt as well. I've got
no idea why so far. And it's way too hot outside...

Sorry
Matthias

[Amforth-devel] My issue with 2variable in int_isr

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

Hi dear friends,
when I enable interrupt this works well:

decimal
2variable ticker
variable seconds
262144. 2constant clkpi    ( clks per interrupt = 256*prescaler )
1. ticker 2!
0 seconds !
\ overflow2 interupt service routine
\ ! not optimised yet
: tick_isr
ticker 2@ clkpi d- ticker 2!
ticker 2@ clkpi d< if  f_cpu ticker 2@ d+ ticker 2!
1 seconds +!
then ;

However with 2variable "seconds" definition:

decimal
2variable ticker
2variable seconds
262144. 2constant clkpi    ( clk per interrupt = 256*prescaler )
1. ticker 2!
0. seconds 2!
\ overflow2 interupt service routine
\ ! not optimised yet
: tick_isr
ticker 2@ clkpi d- ticker 2!
ticker 2@ clkpi d< if  f_cpu ticker 2@ d+ ticker 2!
1. seconds 2@ d+ seconds 2!
then ;

it crashes in such a way I have to reflash rom to get access to system.
What is the trick here?
I've tried
: 2variable create 0 , 0 , ;
as well as
: 2variable here 2 cells allot constant ;
Thanks a lot,
Pito

[Amforth-devel] Beginner's experience

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

Hi dear friends,
as the amforth is a nice gadget worth of consideration, let me summarise

my beginner's first impression I've got after few evenings with it (and
forth). It is my second attempt to learn and utilise it, the first I
did was in '82 as I had built my first ucomputer (8085 based).

I got a dev system which is fully stable (usb usart and usb programmer,
Avr Studio, Avrdude, XP SP3). So I am a win user who does not fit into

the community (:-)..

The install of the fresh amforth from the template was easy, some editing
of template was required (see my earlier posts). Then I started my
learning process by trying the examples. None .py tools used.

Here I learned the dict* files needs to be enhanced by several words

in .asm, in order to start with. The upload of .frt for atmega32 and

other words needed was not easy as of the delay required. Hyperterminal
is of no use. After long tweaking and 20 reflashes (because of hangs)
I found Forfiter, which enabled me to upload (however it works with 
19k2 max) as it has ok commit. 

It seems there is no check whether a word has been uploaded correctly,
so it happened the words were uploaded partially because of a missing

definition following an abort of the upload. However the word
appeared in wordlist. So I had many new words. And sometimes I had
to reflash because of a hang. 

When I tried a small routine within an interrupt routine I need to 
reflash at least 15 times to get it stable (I think because
of stackoverun and resulting crashes - no prompt, thus reflash). So the
development cycle was longer as with C or asm.

I do not have access to python and pearl scripts (XP Python incompatibility)so
the only way is to upload the required frts (marker, 2x, atmega32 reg
def, etc)each time again. Then marker - dev and I tried again. When
happy and none crash I used -dev to start again without a reflash.

The biggest problem for me (a beginner) is the "OS" ruggedness and support.
The new words might be available on net, but the OS is hardwired. Words
like .s and .res did not help me much, so I did mostly "try and error"
wise, with frequent reflashing the rom. Many times the systems stoped
response after running the new word and I lost the acces to the system.
Even hardware reset did not help.

The ctrl-C for return to interpreter, or ctrl-Q for a soft reset would
be
really necessary. Also some stack overflow exception with a return to
prompt would be a nice feature.

Simple an ability to run a word and interrupt it anytime with a return

to prompt is higly required. So the main differentiator against others
shall be the blackbox is bullet proof and always responsive. I do not
know
how to achieve that (maybe an OS interrupt with highest priority always
checking the incoming RX escape sequences.. e.g. every system tick..).
The amforth, from my understanding, will never be used by someone for
extreme time critical applications, so more such OS features in its
kernel/interpreter would be an andvatage.

My trigger to spend some time with forth is basicly a) with my interest
in
FPGA, simple hw implementation of many forth processors in today's high
density arrays, and b) that I do like such small black boxes (e.g. parallax
stamps, 51 basics, etc) to play with between football matches..

Maybe the current linux toolchain is more advanced, however the development
process with amforth and my XP tools is a challenge for a beginner (not
speaking about a good simulator..)

PS: Any plans for amforth 32bit with float??

Cheers,
Pito

Re: [Amforth-devel] USART.asm driver - U2X and baud error

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

all atmels use U2x, it is a part of calculus of the baudrate... Yes we
can adapt, of course..Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth" <amf...@li...>
Předmět: Re: [Amforth-devel] USART.asm driver - U2X and baud error
Datum: 8.7.2010 - 12:22:03

> Hi Pito,
> 
> > I see in usart.asm driver you are not considering
> > U2X (which may improve
> > > baudrate precision for certain combinations). Also
> > error is set to +/-
> > > 1% max. So when compiling one gets "systematic baud
> > errors .." even
> > > when the combination may work properly. It is not
> > so important and probaly
> > > your intention, however I did some experiments with
> > baudrates and Xtals
> > > and I saw that message even I know that a combination
> > is correct.
> > 
> I picked up the settings based upon readings I found
> in various sites of
> teh internet and they work most of the time well. The
> error range is
> based upon the same basis. remember that amforth runs
> on a wide variety
> of controllers with different usart module versions.
> feel free to adapt
> the code to whatever suits you, it's easy.
> 
> Matthias
> 

Re: [Amforth-devel] Thanks

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

Hi Leon,
the accuracy of an internal RC oscillator according to atmel is +/- 3%.
You may calibrate it (see atmega docs) to get better. There is also
a dependency on voltage and temperature, what can be another few percent
with RC. The recomended precision for 8N1 communication is +/- 4.5%
for a given baudrate. So you may get problems. It does not matter whether
you use 1,4,or 8MHz internal RC oscillator.
As a rule of thumb the RC oscilator stability is 10^-2, cheapo Xtals
10^-5, good Xtals 10^-6, thermostated (ovenised) 10^-7, rubidum source
10^-10, cesium 10^-13. Short time stability 10x better (e.g. for 10sec).
However, there is "aging" factor as well. With cheapo Xtals 100ppm per
annum. So you have the choice...
Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Leon Nathaniel Maurer" <leo...@gm...>
Komu: amf...@li...
Předmět: [Amforth-devel] Thanks
Datum: 8.7.2010 - 6:33:35

> It looks like I've got amforth working (photographic
> evidence:
> http://tinyurl.com/2d7cddx) -- thanks for your help!
> 
> To avoid future problems, I do have a couple related
> quick questions. The FAQ
> notes the default 1MHz clock (8 MHz internal RC clock
> divided by 8) can be
> unreliable and suggests: "Try to maximize the CPU frequency."
> What are the
> symptoms of this problem? Just not being able to get
> the serial communication
> to work? Does it help to use the internal clock but
> not divide by 8 (giving an
> 8MHz clock), or is inaccuracy with the internal clock
> part of the problem?
> 
> Thanks.
> -Leon
> 
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Thanks

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

Hi.
..
> Funnily enough 16Mhz the frequency that the arduino's use was found to
> be a good match.
>
> I have had acceptable results with 20Mhz xtals as well.

I'm running boards with atmega168 using 8, 16 and 20 Mhz with no  
problems.
Michael