amforth-devel — Development discussion and user support

Re: [Amforth-devel] Atmega1280

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

Hi Andy,

> Looking at the quote below.
>
> Are we actually saying here that the top 64k is not accessible then on a 
> 128k device ??
>   

no no, the 128Kb are fully usable. No (further) restrictions are in place

> That the memory is arranged in Amforth in words (ie 16 bit) ??
>   

It depends. The key to understand it is the concept of an address unit.
One address unit provides atomic access to data. For RAM one
address unit contains 1 byte. One flash address unit has 2bytes.

Since amforth is a 16bit forth, there are 64K address units. That
translates to 64KB RAM and 128KB Flash (separate address
ranges, @ and i@ (and e@) have nothing in common). At that
level there is no difference between any controller, that amforth
supports.

At the assembly level (where you put your hands into the dirty
details) the flash has surprisingly both a 16bit and a 8bit
access schema, that needs to be taken into account. And the bigger
controllers need a different instruction  to read the (whole) flash. The
details are well hidden in the readflashcell and writeflashcell assembly
macros. For the full details you'll definitly need to read the data sheets
from Atmel.

But I hope, that the at90can128 file is a good starting point for the
atmega1281.

> Or that it is paged and therefore takes a bit more time to access ??
>   

The flash pages are not exposed, they are used internally only.
I may re-arrange the code to provide access to the pages in future
releases, e.g. to implement a block device for flash that is not
accessible otherwise (eg on the atmega256).

The increased access time comes from the additional code needed
to access the flash, but thats not that much. Only a few CPU cycles.

still more confused? sorry, but be assured: the atmega128 has nothing
that cannot be used with amforth and is not really slower than the
smaller device types.

Matthias

Re: [Amforth-devel] Atmega1280

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

Looking at the quote below.

Are we actually saying here that the top 64k is not accessible then on a 
128k device ??

That the memory is arranged in Amforth in words (ie 16 bit) ??

Or that it is paged and therefore takes a bit more time to access ??

Sorry for being a bit dim.....

Cheers

Andy kirby


Matthias Trute wrote:

> [1] The 128KB flash are seen as 64KWords to fit into the 16bit address
> range, and there are a few other instructions to use. And finally the big
> atmegas are slightly slower when accessing the flash since they need
> to execute more instructions. But thats all hidden inside a few macros.

Re: [Amforth-devel] Atmega1280

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

Andy,

>
> What can I say, you are all stars.

Thank you very much, but whats a star without the universe? ;=)
amforth got most of it's features from user feedback (anything from
within complaints and patches).

> The one processor that was short for me was the 1280 (Arduino Mega)
> which is pretty much a 640 but with 128k of memory instead of 64k. I am
> just about to set too and have a go at compiling for the 1280 and will
> mod the 640 file (I assume this is still the way to go, although the
> headers claim that the files are auto generated)

The files are generated with the pd2amforth utility, but edited
afterwards,
there is no complete toolchain to implement the files for a new controller
type. The manual changes are mostly trivial however...

> Questions.
>
> Who do I need to feedback difs changes tweaks etc to to get the  final
> 1280 dev files into the distribution (at some point) ??

Just send them to me directly. There is a patch tracker at the
sourceforge project site as well, it will reach me either way..

>
> Which variables do I need to tweak to increase the memory size?? (a
> quick win hopefully, for my first attempts)

You may use the at90can128 file as a starting point since it already
has all the changes needed for the 128KB flash [1]. Another hint is: use
the usart words with polling access. The interrupt driven IO may
sometimes be very frustrating to get working.

Then there should be only a very few addresses to check:
Usart ports, RAM start/end NRWW start address. Anything else
should be left unchanged. At least for the first try ;=)

Matthias

[1] The 128KB flash are seen as 64KWords to fit into the 16bit address
range, and there are a few other instructions to use. And finally the big
atmegas are slightly slower when accessing the flash since they need
to execute more instructions. But thats all hidden inside a few macros.

[Amforth-devel] Atmega1280

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

Mathias & the Guys

I have just been having a rummage through the latest release of Amforth 
and the wider support for Atmega processors is impressive.

Particularly as they cover most of the Arduino variants sufficiently 
enough to use their hardware.

What can I say, you are all stars.

I have started a new thread over on the RepRap forums to discuss Amforth 
and Reprap specificaly. Hopefully some of the folk who were interested 
in forth last we discussed it will still be interested enough to look 
into the potential.

The one processor that was short for me was the 1280 (Arduino Mega) 
which is pretty much a 640 but with 128k of memory instead of 64k. I am 
just about to set too and have a go at compiling for the 1280 and will 
mod the 640 file (I assume this is still the way to go, although the 
headers claim that the files are auto generated)



Questions.

Who do I need to feedback difs changes tweaks etc to to get the  final 
1280 dev files into the distribution (at some point) ??

Which variables do I need to tweak to increase the memory size?? (a 
quick win hopefully, for my first attempts)



I have got a couple or Arduino Mega's (Cost effective Chinese clones) so 
can spare one to experiment with for this.


Cheers

Andy Kirby (aka47)

[Amforth-devel] ATmega128 issues

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

Greeting!

New user here, having trouble with recent versions.

It appears the amforth 3.1 is the last version that works on the ATmega128.  I do not know if it applies only to my hardware or to the ATmega128 in general, can anyone comment?

I have an old Kanda STK300 development board and the associated AVR-ISP.  I am using AVR-ISP version 5.1.0.  

I think it has something to do with the ATmega128 having two usarts. Starting with version 3.2, the compilation error messages can be resolved by changing (for example on version 3,.2):
UDRIE to UDRIE0, [usart0.asm line 63]
FE, DOR, and PE to FE0, DOR0, and PE0, [usart0.asm line 121]
UDRIE to UDRIE0, [TX0.asm line 40]
but running the result gives no prompt. 
I got the impression that it is something to do with the interrupts, but this area is outside my expertise, so I'm just guessing. 

On version 3.1 down to 2.8, the code compiles with no errors and immediately displays the forth version number and prompt.  Fuses and clock are the same in all cases. 

Any hints or comments?

D


      

Re: [Amforth-devel] "We use amforth", don't we?

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

Moin Erich.

Die Solarwärmesammelei ist noch nicht reif vorgestellt zu werden.
Michael



Am 14.04.2010 um 21:41 schrieb Erich Waelde:

> Folks,
>
> I have been asked to produce a flyer about amforth. This flyer will  
> be handed
> out at the booth of the "Forth Gesellschaft e.V."[1] at the Linuxtag 
> [2] 2010 in
> Berlin. I will be there, we will have a few Forth related projects  
> on exhibit.
>
> In order to provide useful information, I would be very interested
> to hear from you:
>
> *Users of amforth*
>
> Have you run one or more projects with amforth?
>
> What is your project (controller/programm/periphery) doing?
>
> What things have you missed in amforth, what have you added?
>
> Is your project description available online?
>
> Are you willing to have you project listed on the flyer?
>
>
>
>
> The flyer will be freely available.
> Matthias has agreed to ask on the list for the information.
> Feel free to swamp the list with answers, links, pictures,  
> suggestions ...
>
> Cheers,
> Erich
>
> [1] www.forth-ev.de
> [2] www.linuxtag.org/2010
>
> ---------------------------------------------------------------------- 
> --------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] "We use amforth", don't we?

[Andy K. <an...@ak...>]

I would like to promote the use of AMFORTH for use in the RepRap Project 
with the next Generation of Electronics.

Unfortunately the consesus currently appears to be that the next 
generation will be Arduino Mega based. The Butterfly won't cut it.

So until I get some time to shorten my to-do list and create hardware 
definitions for amforth & the ATMega 1280, I have very little to offer.

Best of luck though, I could fancy berlin again. It was great St Nicholas.

Cheers

Andy Kirby

Erich Waelde wrote:
> Folks,
> 
> I have been asked to produce a flyer about amforth. This flyer will be handed
> out at the booth of the "Forth Gesellschaft e.V."[1] at the Linuxtag[2] 2010 in
> Berlin. I will be there, we will have a few Forth related projects on exhibit.
> 
> In order to provide useful information, I would be very interested
> to hear from you:
> 
> *Users of amforth*
> 
> Have you run one or more projects with amforth?
> 
> What is your project (controller/programm/periphery) doing?
> 
> What things have you missed in amforth, what have you added?
> 
> Is your project description available online?
> 
> Are you willing to have you project listed on the flyer?
> 
> 
> 
> 
> The flyer will be freely available.
> Matthias has agreed to ask on the list for the information.
> Feel free to swamp the list with answers, links, pictures, suggestions ...
> 
> Cheers,
> Erich
> 
> [1] www.forth-ev.de
> [2] www.linuxtag.org/2010
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth-devel] "We use amforth", don't we?

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

Folks,

I have been asked to produce a flyer about amforth. This flyer will be handed
out at the booth of the "Forth Gesellschaft e.V."[1] at the Linuxtag[2] 2010 in
Berlin. I will be there, we will have a few Forth related projects on exhibit.

In order to provide useful information, I would be very interested
to hear from you:

*Users of amforth*

Have you run one or more projects with amforth?

What is your project (controller/programm/periphery) doing?

What things have you missed in amforth, what have you added?

Is your project description available online?

Are you willing to have you project listed on the flyer?




The flyer will be freely available.
Matthias has agreed to ask on the list for the information.
Feel free to swamp the list with answers, links, pictures, suggestions ...

Cheers,
Erich

[1] www.forth-ev.de
[2] www.linuxtag.org/2010

Re: [Amforth-devel] Butterfly problems

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

Mike you might find the butterfly carrier from Ecros handy if you don't 
have one.

http://www.ecrostech.com/



On Tue, 16 Mar 2010, Mike Beach wrote:

> The .eep file was indeed the solution - yesterday. Thanks to Matthias for pointing that out.
>
> While happily starting to explore amforth, I must have done something to upset the
> Butterfly. I'm now thinking that's an apt description for its ruggedness! After erasing flash
> using PARALLEL programming, most bytes read back as DF; fewer when run at 5V, and all
> correct at 5.5V. But even there, it could not be programmed. Always the same error: some
> bytes were $20 less than required, so somewhere in the chip bit5 is being held low. Also, the
> battery has been dragged to below 3.0V. ESD? Finger trouble? Can't be too careful around
> this thing. I'll await a new Butterfly (or just the chip if I can find one) while on holiday for the
> next three weeks.
>
> Thanks for your notes, Ian. I'll have a look at your posts, and take the LCD and ADC as a bit
> of a challenge. For this project though, I'm expecting to use a separate 20x4 LCD, and
> external ADCs via a cable.
>
> Mike
>

Re: [Amforth-devel] Butterfly problems

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

Hi MIke.

Am 16.03.2010 um 16:31 schrieb Mike Beach:


> .. I'll have a look at your posts, and take the LCD and ADC as a bit
> of a challenge. For this project though, I'm expecting to use a  
> separate 20x4 LCD, and
> external ADCs via a cable.

May be you want to take a look at lcd.frt and lcd.asm. That worked  
fine in earlier versions of amforth and did well in amforth-3.9  
recently. You may chose to include lcd.asm while assembling, or use  
lcd.frt later to download forth code to a running amforth system on  
the butterfly.

I created this while using the polling i/o method for the USART, so  
the anforth system tolerated the redirection of the EMIT vector (see:  
source code lines 89,90) to send strings to the LCD:
: <lcd>   ( -- )   lcdcr    ['] lcdemit is emit ;
: </lcd>  ( -- )   tob wlcd ['] tx0     is emit  ;

But using the (default) interupt driven i/o method for EMIT, amforth  
will crash as son as you try to execute <lcd>. So you can not use  
ldc. or lcd" from the shelf if you use the interupt i/o. May be you  
find a way to work around this and improve the code to fit both ways  
to handle the terminal i/o.

Michael

Re: [Amforth-devel] Butterfly problems

[Mike B. <mi...@mj...>]

The .eep file was indeed the solution - yesterday. Thanks to Matthias for pointing that out.

While happily starting to explore amforth, I must have done something to upset the 
Butterfly. I'm now thinking that's an apt description for its ruggedness! After erasing flash 
using PARALLEL programming, most bytes read back as DF; fewer when run at 5V, and all 
correct at 5.5V. But even there, it could not be programmed. Always the same error: some 
bytes were $20 less than required, so somewhere in the chip bit5 is being held low. Also, the 
battery has been dragged to below 3.0V. ESD? Finger trouble? Can't be too careful around 
this thing. I'll await a new Butterfly (or just the chip if I can find one) while on holiday for the 
next three weeks.

Thanks for your notes, Ian. I'll have a look at your posts, and take the LCD and ADC as a bit 
of a challenge. For this project though, I'm expecting to use a separate 20x4 LCD, and 
external ADCs via a cable.

Mike



Hi Mike,

You might look at my earlier posts on the butterfly.  Possibly the changes 
I had to make have been integrated into the source tree now.  I'm pretty 
much the begginer though and the work I was doing was all under FreeBSD 
without AVRstudio.

I don't think I was ever able to get the LCD working correctly and I've 
lost momentum.

I'd be interested in your progress.  Let us know how it goes and 
especially if the LCD and AD words are working for you.

Ian

Re: [Amforth-devel] Butterfly problems

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

Hi Mike,

You might look at my earlier posts on the butterfly.  Possibly the changes 
I had to make have been integrated into the source tree now.  I'm pretty 
much the begginer though and the work I was doing was all under FreeBSD 
without AVRstudio.

I don't think I was ever able to get the LCD working correctly and I've 
lost momentum.

I'd be interested in your progress.  Let us know how it goes and 
especially if the LCD and AD words are working for you.

Ian

On Mon, 15 Mar 2010, Mike Beach wrote:

> Because amforth is available specifically for the AVR Butterfly ("Bf"), and that device
> includes some of the "peripherals" that I will need, I have elected to use it as the base for a
> current project rather than a simple breadboarding tile.
>
> The amforth files for Bf create a hex file on AVRStudio without error or warning, and a
> STK500 claims to successfully copy it to flash via ISP (just the one file, no EEPROM file as
> indicated at one point in the amforth documentation). Then when connected to a terminal,
> data can be seen going into the Bf, but nothing is ever returned to the terminal, nor is there
> any suggestion of a sign-on message being generated at reset.
>
> The same equipment is able to restore the original flash content, and the same terminal
> program is then is able to send a "name" string to the Bf, so all other hardware and software
> appears to be intact. The Bf reset line does go high when released.
>
> Can anyone offer suggestions? What have I missed? There was mention of a ready-to-run
> hex file for this device, but I haven't found it.
>
> Mike Beach
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] Butterfly problems

[Mike B. <mi...@mj...>]

Aha! Found it! The assembler generates a file with an .eep extension which is actually a hex 
file. That will no doubt be the missing ingredient. The automatically-generated batch file 
AvrBuild.bat begins to make slightly more sense. Once I get through this, I'll be tempted to 
write something for the benefit of others as ignorant as myself!

Mike


Hi Mike,

> The amforth files for Bf create a hex file on AVRStudio without error or warning, and a 
> STK500 claims to successfully copy it to flash via ISP (just the one file, no EEPROM file as 
> indicated at one point in the amforth documentation).

Exactly that is the problem: You definitly need the EEPROM hex file,
without it
amforth cannot work at all. Strange that the avrstudio does not generate
one..

You may find hex files in earlier versions, I sometimes miss to
generate one for a release. mea culpa. Please do not mix the versions
however...

Matthias


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Amforth-devel mailing list
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Butterfly problems

[Mike B. <mi...@mj...>]

Thanks, Matthias! Very glad there's a solid reason for the failure.

Probably simplest then if I look for an earlier version that includes both hex files ready-built.

Mike


Date sent:      	Mon, 15 Mar 2010 21:59:15 +0100
From:           	Matthias Trute <mt...@we...>
To:             	Everything around amforth <amf...@li...>
Subject:        	Re: [Amforth-devel] Butterfly problems

[ Double-click this line for list subscription options ] 

Hi Mike,

> The amforth files for Bf create a hex file on AVRStudio without error
> or warning, and a STK500 claims to successfully copy it to flash via
> ISP (just the one file, no EEPROM file as indicated at one point in the
> amforth documentation). 

Exactly that is the problem: You definitly need the EEPROM hex file,
without it amforth cannot work at all. Strange that the avrstudio does not generate
one..

You may find hex files in earlier versions, I sometimes miss to
generate one for a release. mea culpa. Please do not mix the versions
however...

Matthias

Re: [Amforth-devel] Butterfly problems

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

Hi Mike,

> The amforth files for Bf create a hex file on AVRStudio without error or warning, and a 
> STK500 claims to successfully copy it to flash via ISP (just the one file, no EEPROM file as 
> indicated at one point in the amforth documentation).

Exactly that is the problem: You definitly need the EEPROM hex file,
without it
amforth cannot work at all. Strange that the avrstudio does not generate
one..

You may find hex files in earlier versions, I sometimes miss to
generate one for a release. mea culpa. Please do not mix the versions
however...

Matthias

[Amforth-devel] Butterfly problems

[Mike B. <mi...@mj...>]

Because amforth is available specifically for the AVR Butterfly ("Bf"), and that device 
includes some of the "peripherals" that I will need, I have elected to use it as the base for a 
current project rather than a simple breadboarding tile.

The amforth files for Bf create a hex file on AVRStudio without error or warning, and a 
STK500 claims to successfully copy it to flash via ISP (just the one file, no EEPROM file as 
indicated at one point in the amforth documentation). Then when connected to a terminal, 
data can be seen going into the Bf, but nothing is ever returned to the terminal, nor is there 
any suggestion of a sign-on message being generated at reset.

The same equipment is able to restore the original flash content, and the same terminal 
program is then is able to send a "name" string to the Bf, so all other hardware and software 
appears to be intact. The Bf reset line does go high when released.

Can anyone offer suggestions? What have I missed? There was mention of a ready-to-run 
hex file for this device, but I haven't found it.

Mike Beach

Re: [Amforth-devel] Connection to host

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

Hi Andy,

> Mathias
>
> I think we probably agree on a large percentage of the below.
>
> Where we probably diverge a touch is that I think forth should be 
> sufficient in and of itself.
>   

I see the point and agree with you that we disagree ;=)

> I should be able to program in forth and create further firmware in the 
> same forth. I should be able to do everything (including put a forth 
> environment on to a virgin chip) without ever needing anything but forth.
>   

Thats possible to do. Given that the controllers use the same
memory architecture. For different systems, it's not that
easy. But I miss the real need to do that task. I know of
a user that wanted to build a network of controllers that
share forth source code, but I do not remember him
talking about initializing the bare metal using the same
way.

> Mathias I don't know if you are gifted or talented (or both), certainly 
> you are a clever guy. Clearly you have proved yourself many times over 
> by producing amforth. I think you are missing out on your just 
> recognition through amforth being difficult to adopt by folk who don't 
> have enough languages under their belt.
>   
I know that amforth is difficult to use for an absolute beginner. For
both langauge and hardware reasons. I myself had to spend a lot of
time until my first microcontroller program did run (no, it was not
amforth but a simple "hello world" that flashed a LED). The only
way around I see is that those people get a pre-programmed
chip / complete system. The arduino has it's success mainly
because of those pre-programmed hardware ready to use.

Thinking that approach further: the amforth core system can
reside within 8KB flash, selecting an atmega with that boot sector
size would allow an "undestroyable" amforth system. No user
could overwrite the forth system at will or by mistake. Well, there
are still a few things more to do, but that would work.

Matthias

Re: [Amforth-devel] Connection to host

[Andy K. <an...@ak...>]

Mathias

I think we probably agree on a large percentage of the below.

Where we probably diverge a touch is that I think forth should be 
sufficient in and of itself.

I should be able to program in forth and create further firmware in the 
same forth. I should be able to do everything (including put a forth 
environment on to a virgin chip) without ever needing anything but forth.

I am principally a C and Assembler programmer, programming for me comes 
before the language that the program is expressed in. (It's probably as 
a result of a CS degree and background)

Whilst I can and do program in a number of languages (professionally and 
otherwise) I fail to see why anyone else should......

Being multi lingual is great (for me) as a European (Multi lingual wet 
ware environment) I value it highly (multi lingual firm/hardware 
environment).

Unfortunately a large proportion of humanity is no where near as gifted 
(Nor as talented) why should they miss out and be unable to contribute 
their own capabilities (gifted or talented). Because they are 
linguistically challenged.

Forth is a very particular case in point. It isn't suitable for 
everyone. Not everyone can get a grip on RP (Reverse Polish, or stack 
based) notation much less the programmatic equivalent. Their minds don't 
work that way.

By the same token if their minds do but they struggle with infix 
notation why should they have to bother with C, or any other infix 
language (that can be used to express computer instruction).

Mathias I don't know if you are gifted or talented (or both), certainly 
you are a clever guy. Clearly you have proved yourself many times over 
by producing amforth. I think you are missing out on your just 
recognition through amforth being difficult to adopt by folk who don't 
have enough languages under their belt.

Erich

Yup you have found me out, I have been a militant supporter of Open 
source and "Standing on the shoulders of giants" since before the 
INTERNET was graphical (As well as contributing fiscally to the FSF, and 
always will do). The last 2 or 3 years most of my support has been 
behind the RepRap project http://reprap.org. I can see a big future for 
amforth in synergy with this project if it can get over it's Arduino 
Hardware allergy. I really wouldn't want to see either project struggle 
for the influence of the other though.........















Matthias Trute wrote:
> Andy,
> 
>> I have read the docs explaining the issues with the bootloader and 
>> arduino and fully agree. You are somewhat caught by how the architecture 
>> of the AVR's was designed. I don't see it as being a limitation of 
>> either amforth or Arduino. They are quite different animals. Trying to 
>> make one like the other could be a mistake.
>>   
> 
> It's not a limitation, but a question of what a program could do
> with the varios types of memories in the atmegas. IMHO most of
> the programmers think of the flash as a read-only mempory that
> needs hugh amounts of work to deal with. At most they place
> some constant data (string literals) in it. The bootloaders reflect
> that in many ways: They do not provide an API for the essential
> flash write operation, this function is only available if the bootloader
> reads data from the serial line. If you take a deeper look at the code,
> they usually do not use function (if coded in C) but operate
> in a single main() function without split-out modules, that could
> theoretically re-arranged to call the result an API.
> 
> Back to the arduino: The hardware works pretty well with amforth,
> the only thing missing is the arduino bootloader, that is not able
> to flash the amforth binary. If you use some other method for
> transferring amforth, everything's fine. But it's probably not an
> arduino anymore (the bootloader has a monitor as a debugging aid
> as well) since you cannot use the arduino software any longer.
>> In the interim, all (an easy statement to make) that amforth appears to 
>> lack for it to be able to give newbies a quick way in is a binary image 
>> (no compiling, or tool-chain necessary) for a very select number of off 
>> the shelf micro boards, and a detailed how-to do ICSP using avrdude and 
>> ultimately from a board running amforth (board to identical board clone 
>> using a forth programming routine).
>>   
> 
> There are way too many different boards out there, so I decided
> against selecting on of them and provide hex files for it. The
> AVR Butterfly is an exception, but it is somehow the same as the
> arduino: The bootloader is in the way: the one from atmel is
> unusable and once amforth is on the chip, you are on you own.
> 
> Since the use of an programming hardware tool is essential for
> using amforth, I selected the "advanced end uses" as the intended
> audience. It's definitly (and sadly) not a beginners toy...
> 
>> I fully agree that anyone capable of contributing to the current project 
>>   would have the necessary skills already. What about the next 
>> generation of would be forth hackers that have yet to discover that they 
>> are up for it though ??
>>   
> 
> Really good question. IMHO the most interesting part is that
> forth gives you an extendible command interpreter at hand.
> The price is that you need to learn how to deal with microcontrollers
> and that there is a tool chain with both soft- and hardware to be used.
> 
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Connection to host

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

Andy,

> I have read the docs explaining the issues with the bootloader and 
> arduino and fully agree. You are somewhat caught by how the architecture 
> of the AVR's was designed. I don't see it as being a limitation of 
> either amforth or Arduino. They are quite different animals. Trying to 
> make one like the other could be a mistake.
>   

It's not a limitation, but a question of what a program could do
with the varios types of memories in the atmegas. IMHO most of
the programmers think of the flash as a read-only mempory that
needs hugh amounts of work to deal with. At most they place
some constant data (string literals) in it. The bootloaders reflect
that in many ways: They do not provide an API for the essential
flash write operation, this function is only available if the bootloader
reads data from the serial line. If you take a deeper look at the code,
they usually do not use function (if coded in C) but operate
in a single main() function without split-out modules, that could
theoretically re-arranged to call the result an API.

Back to the arduino: The hardware works pretty well with amforth,
the only thing missing is the arduino bootloader, that is not able
to flash the amforth binary. If you use some other method for
transferring amforth, everything's fine. But it's probably not an
arduino anymore (the bootloader has a monitor as a debugging aid
as well) since you cannot use the arduino software any longer.
> In the interim, all (an easy statement to make) that amforth appears to 
> lack for it to be able to give newbies a quick way in is a binary image 
> (no compiling, or tool-chain necessary) for a very select number of off 
> the shelf micro boards, and a detailed how-to do ICSP using avrdude and 
> ultimately from a board running amforth (board to identical board clone 
> using a forth programming routine).
>   

There are way too many different boards out there, so I decided
against selecting on of them and provide hex files for it. The
AVR Butterfly is an exception, but it is somehow the same as the
arduino: The bootloader is in the way: the one from atmel is
unusable and once amforth is on the chip, you are on you own.

Since the use of an programming hardware tool is essential for
using amforth, I selected the "advanced end uses" as the intended
audience. It's definitly (and sadly) not a beginners toy...

> I fully agree that anyone capable of contributing to the current project 
>   would have the necessary skills already. What about the next 
> generation of would be forth hackers that have yet to discover that they 
> are up for it though ??
>   

Really good question. IMHO the most interesting part is that
forth gives you an extendible command interpreter at hand.
The price is that you need to learn how to deal with microcontrollers
and that there is a tool chain with both soft- and hardware to be used.


Matthias

Re: [Amforth-devel] Connection to host

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

Hi Andy,
thanks for your detailed reply.

To expand more on the "teaching class" thing ...

I would like to see a small board with
1. a usb connection, which
    a. brings in power
    b. connects to the serial tx/rx port
AND most importantly
    c. also provides a way to reload the board from scratch,
       be it In-System-Programming or JTAG or something else.

It is my firm believe that a participant of the class must be
able to load a virgin controller before the class is finished.

2. a prototype area

It also is my firm believe that a board must be extensible
somehow. Arduino shields are one way to do this.

3. the controller itself should be "removable" or exchangeable.

It has hit me more than once, that I suspected portpins to be broken.
So I insert another controller an see if the problem changes. There
is no other way to rule out a ``faulty'' controller. So I would
content with a little DIL-40 sized board with a MLF sized atmega-32
on top, for example.

4. some predefined periphery for the class
    a. a RGB led connected to the PWM Pins.
    b. some (4?) normal leds, some switches
    c. a buzzer or
    d. a small H-bridge for a stepper motor
    e. pullups for i2c, a sensor (temperature) or clock
       or a 1-wire controller
    f. a connector for a 10x2 LCDisplay
    g. a poti for one of the ADC pins

I want to have this, because I believe that only sufficiently
complex examples are going to hook newbies. ``let's blink an LED''
is a necessary step, but must not be the last one. ``let's make
the color of the led change any way we want, e.g. driven by the
temperature sensor ...'' sounds much better to me. But I may be
wrong.

Then, if the board is readily availabe, people can use this for their
next project without thinking.

Bootloader: I personally don't need it. If it helps a newbie to
start fiddling with controllers, fine. I need to teach how to get
a virgin controller off the ground anyway.
How do Arduino folks get a virgin controller flashed with the boot
loader?

It seems, we largely agree on this stuff.

Matthias is making another point: If we do not provide quite a number
of forth modules to access sensors and stuff, we won't get far. Look
at perl. Try to imagine perl without CPAN. So I ``donated'' the ewlib
directory with hopefully useful stuff.

We'll see. I want to get my current pet project out of the way before
trying to shape up a class. No need to hurry.


Btw: I went to FOSDEM (Brussels) beginning of February. The reprap folks
were there, too. But I missed to ask you, whether you went there as well.

Cheers,
Erich

Re: [Amforth-devel] Connection to host

[Andy K. <an...@ak...>]

Erich

I have read the docs explaining the issues with the bootloader and 
arduino and fully agree. You are somewhat caught by how the architecture 
of the AVR's was designed. I don't see it as being a limitation of 
either amforth or Arduino. They are quite different animals. Trying to 
make one like the other could be a mistake.

A minimalist AVR stamp sounds like a good idea. This though has been 
done and they are available to buy off the shelf as mass produced 
commodity hardware. ie quite inexpensive.

In the interim, all (an easy statement to make) that amforth appears to 
lack for it to be able to give newbies a quick way in is a binary image 
(no compiling, or tool-chain necessary) for a very select number of off 
the shelf micro boards, and a detailed how-to do ICSP using avrdude and 
ultimately from a board running amforth (board to identical board clone 
using a forth programming routine).

I fully agree that anyone capable of contributing to the current project 
  would have the necessary skills already. What about the next 
generation of would be forth hackers that have yet to discover that they 
are up for it though ??

I think that although awesome the amforth project is at the same cross 
roads as many forths before it. It needs something more (perhaps only a 
little thing or two) to make it sufficiently accessible to non forth 
users who are interested. Feed the interest and this new blood will take 
itself to the next screen/level.

Maybe they will by pass toolchain and C development altogether and 
settle into entirely native forth development. This is one of forths 
more appealing aspects.

I think there is an opening for new forthies to contribute forth code 
towards a growing library that resides upon the amforth foundations. If 
we can get them there.........





Erich Waelde wrote:
> Hi folks,
> 
> Tom Arnold wrote:
>> On Thu, Mar 04, 2010 at 09:22:22PM +0000, Andy Kirby wrote:
>>> What would be really cool would be if you could take an off the shelf 
>>> Arduino Mega, burn amforth onto it and then use this Forthduino to clone 
>>> itself to other off the shelf Arduino Mega's
>>>
>>> I guess a new design of Atmel based micro board that was purely amforth 
>>> would be cool too.
>> Making amforth work with the Arduino bootloader I think would open up
>> amforth to a lot more people who may not otherwise want to undertake trying
>> to play with it.  Forth has a somewhat bad ( un-deserved ) reputation as being 
>> difficult to deal with as it is.  Having it incompatible with widely
>> available cheap hardware just adds to that.  The Arduino bootloader is
>> nothing magical.  Its just a simple software implementation of the STK500
>> protocol.  
>>
>> Going with Arduino vs a dedicated amforth board opens up amforth to the
>> world of arduino "shields" ( I hate that name ) which widens up the hardware
>> available to quickly throw at a project.
>>
>> I know there are reasons why its not supported, like Arduino didn't exist
>> with amforth first came about, I'm only saying it'd be nice.  I wish I had
>> the skillset to make it happen.  It is worth pointing out that a USB based
>> Atmel programmer is dirt cheap these days ( $20 or so from AdaFruit I think
>> ).  That makes it fairly easy to turn an Arduino Mega into an AmforthMega.
>> Easy but not trivial.  Supporting the loader would make it trivial...
>>
> 
> I agree very much with this comment. I'm trying to set up a class to teach
> microcontroller programming using amforth on an atmega32 or similar. We had
> long and somewhat heated discussions about the hardware to use. We are
> still very much undecided.
> 
> Making amforth work with the arduino boot loader requires some work on the
> arduino bootloader, as far as I have understood this. It's not impossible. It
> just needs to be done. The key point is that the workings of i! and i@ must
> reside in the protected flash (boot loader area). Or something along
> these lines.
> 
> Cheers,
> Erich
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Connection to host

[Andy K. <an...@ak...>]

That would be fine.

I understand your not wanting to duplicate what is already out there.

Matthias Trute wrote:
> Andy,
> 
> Andy Kirby wrote:
>> Pretty much there.
>>
>> A suggestion...
>>   
> 
> Highly appreciated. Thank you.
>> Last tip, the mention of JTAG may be misleading, many of the Atmega 
>> micro's do not have JTAG capability.
> 
> But all, on that amforth can run. At least I'm almost sure ;=)
> 
>>  I think you may have meant that the 
>>   Atmel JTAG programmer could be used in it's ICSP mode.
>>   
> 
> Well, the method the hex files are transferred to the
> controller is completly unrelated to amforth itself. There
> are no dependencies.. With the one exception, that a
> bootloader cannot be used at all (with the potential exception
> from the exception if amforth is adapted to use some API
> call from the bootloader to perform the flash self
> programming).
> 
>> Is it worth considering putting in some hyperlinks to a couple of sites. 
>> (ie Atmel,s programming tools and maybe the pony prog pages)
>>   
> 
> I think that everybody who works with the Atmel controllers
> will soon know the tools and how they work. There are so
> many websites around, that I do not want to publish the same
> information again; this time my way. Same argument why
> I omit schematics and such information.
> 
> I'll collect some links to such websites and put them on
> the links page. Is that ok?
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Connection to host

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

Hi folks,

Tom Arnold wrote:
> On Thu, Mar 04, 2010 at 09:22:22PM +0000, Andy Kirby wrote:
>> What would be really cool would be if you could take an off the shelf 
>> Arduino Mega, burn amforth onto it and then use this Forthduino to clone 
>> itself to other off the shelf Arduino Mega's
>>
>> I guess a new design of Atmel based micro board that was purely amforth 
>> would be cool too.
> 
> Making amforth work with the Arduino bootloader I think would open up
> amforth to a lot more people who may not otherwise want to undertake trying
> to play with it.  Forth has a somewhat bad ( un-deserved ) reputation as being 
> difficult to deal with as it is.  Having it incompatible with widely
> available cheap hardware just adds to that.  The Arduino bootloader is
> nothing magical.  Its just a simple software implementation of the STK500
> protocol.  
> 
> Going with Arduino vs a dedicated amforth board opens up amforth to the
> world of arduino "shields" ( I hate that name ) which widens up the hardware
> available to quickly throw at a project.
> 
> I know there are reasons why its not supported, like Arduino didn't exist
> with amforth first came about, I'm only saying it'd be nice.  I wish I had
> the skillset to make it happen.  It is worth pointing out that a USB based
> Atmel programmer is dirt cheap these days ( $20 or so from AdaFruit I think
> ).  That makes it fairly easy to turn an Arduino Mega into an AmforthMega.
> Easy but not trivial.  Supporting the loader would make it trivial...
> 

I agree very much with this comment. I'm trying to set up a class to teach
microcontroller programming using amforth on an atmega32 or similar. We had
long and somewhat heated discussions about the hardware to use. We are
still very much undecided.

Making amforth work with the arduino boot loader requires some work on the
arduino bootloader, as far as I have understood this. It's not impossible. It
just needs to be done. The key point is that the workings of i! and i@ must
reside in the protected flash (boot loader area). Or something along
these lines.

Cheers,
Erich

Re: [Amforth-devel] Connection to host

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

Andy,

Andy Kirby wrote:
> Pretty much there.
>
> A suggestion...
>   

Highly appreciated. Thank you.
> Last tip, the mention of JTAG may be misleading, many of the Atmega 
> micro's do not have JTAG capability.

But all, on that amforth can run. At least I'm almost sure ;=)

>  I think you may have meant that the 
>   Atmel JTAG programmer could be used in it's ICSP mode.
>   

Well, the method the hex files are transferred to the
controller is completly unrelated to amforth itself. There
are no dependencies.. With the one exception, that a
bootloader cannot be used at all (with the potential exception
from the exception if amforth is adapted to use some API
call from the bootloader to perform the flash self
programming).

> Is it worth considering putting in some hyperlinks to a couple of sites. 
> (ie Atmel,s programming tools and maybe the pony prog pages)
>   

I think that everybody who works with the Atmel controllers
will soon know the tools and how they work. There are so
many websites around, that I do not want to publish the same
information again; this time my way. Same argument why
I omit schematics and such information.

I'll collect some links to such websites and put them on
the links page. Is that ok?

Matthias

Re: [Amforth-devel] Connection to host

[Mike B. <mi...@mj...>]

On Thu, 4 Mar 2010 13:55:36 -0800, Tom Arnold <xy...@sy...> wrote:

> On Thu, Mar 04, 2010 at 09:22:22PM +0000, Andy Kirby wrote:
> > What would be really cool would be if you could take an off the shelf 
> > Arduino Mega, burn amforth onto it and then use this Forthduino to clone 
> > itself to other off the shelf Arduino Mega's
> > 
> > I guess a new design of Atmel based micro board that was purely amforth 
> > would be cool too.
> 
> Making amforth work with the Arduino bootloader I think would open up
> amforth to a lot more people who may not otherwise want to undertake trying
> to play with it.  Forth has a somewhat bad ( un-deserved ) reputation as being 
> difficult to deal with as it is.  Having it incompatible with widely
> available cheap hardware just adds to that.  The Arduino bootloader is
> nothing magical.  Its just a simple software implementation of the STK500
> protocol.  
> 
> Going with Arduino vs a dedicated amforth board opens up amforth to the
> world of arduino "shields" ( I hate that name ) which widens up the hardware
> available to quickly throw at a project.
> 
> I know there are reasons why its not supported, like Arduino didn't exist
> with amforth first came about, I'm only saying it'd be nice.  I wish I had
> the skillset to make it happen.  It is worth pointing out that a USB based
> Atmel programmer is dirt cheap these days ( $20 or so from AdaFruit I think
> ).  That makes it fairly easy to turn an Arduino Mega into an AmforthMega.
> Easy but not trivial.  Supporting the loader would make it trivial...


I'm working with a breadboarding tile for an ATMega88 in the 32MLF package, including 
crystal, decoupling, reset, and 6-pin SPI connector - not very different from some of the 
simpler Arduinos. I've glued it to the top of an IDC connector to plug into the board that it is 
to control. An off-the-shelf version of this which included an RS232 interface and pre-loaded 
with amforth would have been irresistible. (ok, make it the 16k or 32k flash version!)

In comparison, I'm wondering how popular the various "BASIC Stamp" - type of boards 
might be, as a guide to the prospects for a Forth-based board. Forth is, after all, so much 
more amenable than BASIC (at least I think so - but then, I've been a Forth convert since 
the 70s.)

Mike Beach