amforth-devel

[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)

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.

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

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