amforth-devel — Development discussion and user support

Re: [Amforth-devel] Connection to host

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

Just thought of something else, it may be worth adding an example 
invocation line for avrdude to the pages too. Maybe for N12 Pony & AVRISP.

Andy Kirby wrote:
> Pretty much there.
> 
> A suggestion...
> 
> for
> 
> "(same: rarly used). Any other programmer type may need support from the 
> microcontroller (a so called bootloader) but cannot program amforth (the 
> reasons are explained in the technical handbook). "
> 
> try
> 
> "(same: rarely used). Programming that relies on a boot loader on the 
> micro-controller itself can not load amforth (the reasons are explained 
> in the technical handbook)."
> 
> I think this means the same but the english is a little clearer.
> 
> Last tip, the mention of JTAG may be misleading, many of the Atmega 
> micro's do not have JTAG capability. I think you may have meant that the 
>   Atmel JTAG programmer could be used in it's ICSP mode.
> 
> If I have got it wrong I apologies in advance.
> 
> Is it worth considering putting in some hyperlinks to a couple of sites. 
> (ie Atmel,s programming tools and maybe the pony prog pages)
> 
> Hope this helps.
> 
> Cheers
> 
> Andy Kirby
> 
> 
> Matthias Trute wrote:
>> Mike,
>>
>> Mike Beach wrote:
>>> Many thanks, Erich and Andy, for your swift responses.
>>>
>>> Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe 
>>> someone will add a few words to the AMForth documentation.)
>>>   
>> I just edited the FAQ a little, maybe you can comment on it?
>>
>> http://amforth.sourceforge.net/faq.html (top2)
>>
>> 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
>>
> 
> 
> ------------------------------------------------------------------------------
> 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...>]

Must admit I agree with mathias re the unsuitability of retaining the 
arduino bootloader.

I do however agree that leveraging amforth using off the shelf commodity 
hardware. ie a re-purposed arduino mega board. Would be a definite boost 
  for the project.

The are available very cost effectively, www.DFRobot.com are even making 
them and exporting them from china.



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

Re: [Amforth-devel] Connection to host

[Tom A. <xy...@sy...>]

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

-- 
 --------------------------------------------------------------------
 - Tom Arnold           -  "...is it a virus, a drug, or a religion?"  
 - Sysabend Caretaker   -    Juanita Shrugs. "What's the difference?"
 ------------------------       -- Neal Stephenson,  Snow Crash 

Re: [Amforth-devel] Connection to host

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

Pretty much there.

A suggestion...

for

"(same: rarly used). Any other programmer type may need support from the 
microcontroller (a so called bootloader) but cannot program amforth (the 
reasons are explained in the technical handbook). "

try

"(same: rarely used). Programming that relies on a boot loader on the 
micro-controller itself can not load amforth (the reasons are explained 
in the technical handbook)."

I think this means the same but the english is a little clearer.

Last tip, the mention of JTAG may be misleading, many of the Atmega 
micro's do not have JTAG capability. I think you may have meant that the 
  Atmel JTAG programmer could be used in it's ICSP mode.

If I have got it wrong I apologies in advance.

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

Hope this helps.

Cheers

Andy Kirby


Matthias Trute wrote:
> Mike,
> 
> Mike Beach wrote:
>> Many thanks, Erich and Andy, for your swift responses.
>>
>> Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe 
>> someone will add a few words to the AMForth documentation.)
>>   
> 
> I just edited the FAQ a little, maybe you can comment on it?
> 
> http://amforth.sourceforge.net/faq.html (top2)
> 
> 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

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

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.



Mike Beach wrote:
> Many thanks, Erich and Andy, for your swift responses.
> 
> Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe 
> someone will add a few words to the AMForth documentation.)
> Good to know that the SP12 method does work, and to see some options.
> 
> The serial comms method presumably kicks in once you have a running system with the 
> requisite level & polarity match to RS232. (Presumably AMForth sets up the USART for 
> that.)
> 
> Mike
> 
>> Yup ISP is it, there are a few options.
>>
>> 1. As below.
>> 2. Google Pony Programmer, and make up a parallel port to ISP adapter 
>> from the schematic (Drive with avrdude)
>> 3. If you have an arduino and the ver 18 IDE there is an AVRISP sketch 
>> as part of the examples that can be used to convert the Arduino into an 
>> AVRISP programmer.
>> 4. Buy  puker Atmel AVRISP
>>
>> One or other of the above are worth having. Even if you down tools on 
>> Forth and later go for arduino having the above to burn bootloaders into 
>> blank chips is great for your own projects. (Prototyped on an arduino)
>>
>> Hope some of this helps.
>>
>> Cheers
>>
>> Andy Kirby
>>
> 
> 
> ------------------------------------------------------------------------------
> 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...>]

Mike,

Mike Beach wrote:
> Many thanks, Erich and Andy, for your swift responses.
>
> Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe 
> someone will add a few words to the AMForth documentation.)
>   

I just edited the FAQ a little, maybe you can comment on it?

http://amforth.sourceforge.net/faq.html (top2)

Matthias

Re: [Amforth-devel] Connection to host

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

Many thanks, Erich and Andy, for your swift responses.

Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe 
someone will add a few words to the AMForth documentation.)
Good to know that the SP12 method does work, and to see some options.

The serial comms method presumably kicks in once you have a running system with the 
requisite level & polarity match to RS232. (Presumably AMForth sets up the USART for 
that.)

Mike

> Yup ISP is it, there are a few options.
> 
> 1. As below.
> 2. Google Pony Programmer, and make up a parallel port to ISP adapter 
> from the schematic (Drive with avrdude)
> 3. If you have an arduino and the ver 18 IDE there is an AVRISP sketch 
> as part of the examples that can be used to convert the Arduino into an 
> AVRISP programmer.
> 4. Buy  puker Atmel AVRISP
> 
> One or other of the above are worth having. Even if you down tools on 
> Forth and later go for arduino having the above to burn bootloaders into 
> blank chips is great for your own projects. (Prototyped on an arduino)
> 
> Hope some of this helps.
> 
> Cheers
> 
> Andy Kirby
> 

Re: [Amforth-devel] Connection to host

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

Yup ISP is it, there are a few options.

1. As below.
2. Google Pony Programmer, and make up a parallel port to ISP adapter 
from the schematic (Drive with avrdude)
3. If you have an arduino and the ver 18 IDE there is an AVRISP sketch 
as part of the examples that can be used to convert the Arduino into an 
AVRISP programmer.
4. Buy  puker Atmel AVRISP

One or other of the above are worth having. Even if you down tools on 
Forth and later go for arduino having the above to burn bootloaders into 
blank chips is great for your own projects. (Prototyped on an arduino)

Hope some of this helps.

Cheers

Andy Kirby

Erich Waelde wrote:
> Correcting myself:
> 
> Erich Waelde wrote:
>> Hello Mike,
>>
>> Mike Beach wrote:
>>> ... The on-chip UART cannot be functional on a virgin chip (and in any 
>>> case RS232 levels would, of course, need at least level conversion). 
>>> The only methods I am aware of are "parallel programming" (simple in 
>>> concept but requires the manipulation of most AVR pins) or "serial 
>>> programming" (alias "In System Programming"), using a 6-pin SPI 
>>> interface, perhaps with the addition of a clock. The four SPI signal 
>>> pins (MOSI, MISO, RESET and SCLK) could in principle be driven from a 
>>> parallel port, as in the SP12 project - perhaps the answer.
>> In-Serial-Programming is the answer,
> -----^^^^^ SYSTEM! Unbelievable.
> 
>> and I'm using the sp12 Programmer, too!  :-)
>>
>> 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

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

Correcting myself:

Erich Waelde wrote:
> Hello Mike,
> 
> Mike Beach wrote:
>> ... The on-chip UART cannot be functional on a virgin chip (and in any 
>> case RS232 levels would, of course, need at least level conversion). 
>> The only methods I am aware of are "parallel programming" (simple in 
>> concept but requires the manipulation of most AVR pins) or "serial 
>> programming" (alias "In System Programming"), using a 6-pin SPI 
>> interface, perhaps with the addition of a clock. The four SPI signal 
>> pins (MOSI, MISO, RESET and SCLK) could in principle be driven from a 
>> parallel port, as in the SP12 project - perhaps the answer.
> 
> In-Serial-Programming is the answer,
-----^^^^^ SYSTEM! Unbelievable.

> and I'm using the sp12 Programmer, too!  :-)
> 
> Cheers,
> Erich

Re: [Amforth-devel] Connection to host

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

Hello Mike,

Mike Beach wrote:
> ... The on-chip UART cannot be functional on a virgin chip (and in 
> any case RS232 levels would, of course, need at least level conversion). The only methods 
> I am aware of are "parallel programming" (simple in concept but requires the manipulation 
> of most AVR pins) or "serial programming" (alias "In System Programming"), using a 6-pin 
> SPI interface, perhaps with the addition of a clock. The four SPI signal pins (MOSI, MISO, 
> RESET and SCLK) could in principle be driven from a parallel port, as in the SP12 project - 
> perhaps the answer.

In-Serial-Programming is the answer,
and I'm using the sp12 Programmer, too!  :-)

Cheers,
Erich

[Amforth-devel] Connection to host

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

Having read the documentation for AMForth, I am keen to use it for a current project, but it 
is still not clear to me how one initially downloads the compiled hex (or object) file to the 
AVR. Some kind of programmer is surely implied in addition to the PC on which the file has 
been generated, though it seems to be stated that this can be achieved with only a serial 
link to the target machine. The on-chip UART cannot be functional on a virgin chip (and in 
any case RS232 levels would, of course, need at least level conversion). The only methods 
I am aware of are "parallel programming" (simple in concept but requires the manipulation 
of most AVR pins) or "serial programming" (alias "In System Programming"), using a 6-pin 
SPI interface, perhaps with the addition of a clock. The four SPI signal pins (MOSI, MISO, 
RESET and SCLK) could in principle be driven from a parallel port, as in the SP12 project - 
perhaps the answer.

What am I missing?

Mike Beach

Re: [Amforth-devel] amforth and AVR Studioxx problem

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

David,

I cannot tell you much about the studio, I do not use it.
> Is there something obvious I am missing? From what I read in the forum, 
> the emulator has problems with amforth, but should it crash like this? 
>   
With the atxmega port, the studio could not even compile (assemble)
the code. It simply crashed. Studio18SP1 was slightly better since it
crashed only every 2nd (or) compile/simulator cycle... A very frustating
expirience..

I'd guess that amforth has too many source files for the studio...

The assembler itself works fine (for me)

And with the atmega128 itself, sorry. I've no access to one. the
at90can128 did work recently..

Matthias

[Amforth-devel] amforth and AVR Studioxx problem

[David J. <dav...@ea...>]

Hello,

I was excited to find a version of FORTH I can use with the AVR series, 
specifically the Mega128.

But I am having problems compiling it in AVR Studio. By editing a couple 
of files (mainly to fix USART register names: since the Mega128 has two, 
a -0 or -1 suffix is usually needed), and adding the necessary paths to 
the project, I can get a complete, error free assembly (F7 key). But 
when I click the assemble and run button (crtl+F7), I the message "an 
unhandled win32 exception occurred in AVRstudio.exe [3856]".

I tried version 4.13 and the latest , 4.18, of AVR Studio, with the same 
results.  Unhandled exception.

Then, to see if the problem lay with the 128 code, I tried using the AVR 
Butterfly template. Again, I could get it to assemble, but not assemble 
and run. Unhandled exception.

I did try loading the hex code into the Mega128, but I didn't see 
anything on the com port and wasn't able to talk to the device. (The 
card is an EMB128 made by ERE.) Is there any other way to check the code?

Is there something obvious I am missing? From what I read in the forum, 
the emulator has problems with amforth, but should it crash like this? 
Is there any way to confirm that the code is good without actually 
loading it into a device?

Thanks - David Jeffrey

-- 
David Jeffrey
DCJ Designs
825 Stannage Ave
Albany, CA 94706
phone:   (510) 526 1322
Cell:    (510) 734 7563

Re: [Amforth-devel] ATmega1280 Arduino Mega

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

Andy Kirby wrote:
> Do these have what I would need and if so how do I auto-generate the 
> .asm and .frt files from them ??
>   

I use the xml files located in the Partdescription directory from the
AVR studio
to generate the frt and asm files. amforth has the tool pd2amforth, that
takes every xml file in the current directory and tries to interpret it as
a partdescription (hence the pd) file. But be warned: there are many
dependencies
for various non-standard perl libraries... (my ubuntu box can install
them all
with apt-get from the ubuntu repositories.)

The generated files need some more work to be usable, they do not
work out-of-the-box. It only a helper tool....

good luck

Matthias

[Amforth-devel] ATmega1280 Arduino Mega

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

I am just attempting to sort out the .asm and .frt files for the Arduino 
Mega (atmega1280).

Looking into core/devices there is'nt a pair of files for this device 
already. Looking at the instructions it sugests copying an existing pair 
and modifying them.

When I open up the pair for the atmega644 a comment in the top claims 
that they were generated from an xml file somewhere.

Looking at the AVR toolchain there are device description xml files there.

Do these have what I would need and if so how do I auto-generate the 
.asm and .frt files from them ??

Cheers

Andy Kirby

Re: [Amforth-devel] Newbie

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

Mathias

Thanks for getting back to me, and my compliments on the work you have 
done, I am very impressed.

Loosing the Arduino bootloader is fine. I am currently looking to 
experiment with a Forth based firmware in connection with the RepRap 
project ( http://dev.forums.reprap.org/read.php?147,32542,page=1 ). 
They are currently using Arduino variants, but there are things that are 
needed to take the machinery to the next level. amForth looks to be that 
thing.

As an aside I noticed among the source files some for the AVR Butterfly, 
it could be worth your projects while to put together templates (ready 
to go) for the main arduino boards. ie Diecimilla, Duemilanove and Mega 
(ATmega168, ATmega328 and ATmega1280 respectively).

I suggest this not as a route to replace the arduino, but as a way that 
people interested in your project can get started with a hardware board 
available localy and cost effectively in many countries. All have ICSP 
capability which together with an example code app to clone the amForth 
from one board to an identical board (perhaps part of the core) would 
push forward the rate at which experimenters with amForth could 
replicate their amForth solutions.

Cheers

Andy Kirby






Matthias Trute wrote:
> Hi Andy,
> 
> 
>> The Arduino Mega uses :-
>>
>> ATMega 1280 16au, 16Mhz clock/crystal
>>   
> Not exactly this type of controller but similiar one work
> fine. Your chances are good to get amforth working.
> 
> But: You loose the arduino features since you need to
> re-program the entire chip.
> 
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] amforth + avr-gcc/avr-as => ok?

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

mei...@gm... wrote:
> Matthias Trute <mt...@we...> [10-01-30 16:24]:
>   
>> mei...@gm... wrote,
>>     
>>> Is there a way to get amforth running by using the avr-gcc-toolchein,
>>> which includes avr-as as assembler?
>>> How can it be done?
>>>   
>>>       
>> You will have to re-write all the sourcefiles to satisfy the syntax of
>> the gcc toolchain.
>>
>> Matthias
>>
>>
>>     
>
> Oh..uhhh...
> Does somedone this already with a (may be older) version of amforth?
>   

not to my knowledge. You could get merits in
writing a converter tool, IMHO.

Matthias

Re: [Amforth-devel] amforth + avr-gcc/avr-as => ok?

[<mei...@gm...>]

Matthias Trute <mt...@we...> [10-01-30 16:24]:
> mei...@gm... wrote,
> > Is there a way to get amforth running by using the avr-gcc-toolchein,
> > which includes avr-as as assembler?
> > How can it be done?
> >   
> 
> You will have to re-write all the sourcefiles to satisfy the syntax of
> the gcc toolchain.
> 
> Matthias
> 
> 

Oh..uhhh...
Does somedone this already with a (may be older) version of amforth?

mcc


> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

-- 
Please don't send me any Word- or Powerpoint-Attachments
unless it's absolutely neccessary. - Send simply Text.
See http://www.gnu.org/philosophy/no-word-attachments.html
In a world without fences and walls nobody needs gates and windows.

Re: [Amforth-devel] amforth + avr-gcc/avr-as => ok?

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

mei...@gm... wrote,
> Is there a way to get amforth running by using the avr-gcc-toolchein,
> which includes avr-as as assembler?
> How can it be done?
>   

You will have to re-write all the sourcefiles to satisfy the syntax of
the gcc toolchain.

Matthias

[Amforth-devel] amforth + avr-gcc/avr-as => ok?

[<mei...@gm...>]

Hi,

I want to use amforth on a ATmega644.
I am develing software under Linux and have no access to Windows PCs.
I dont want to install wine to unpack AVR-Studio install to get the
include files needed by avra -- beside the thing that this may or
may not be legal...

Is there a way to get amforth running by using the avr-gcc-toolchein,
which includes avr-as as assembler?
How can it be done?

Thank you for any help in advance!
Have a nice weekend!
mcc


-- 
Please don't send me any Word- or Powerpoint-Attachments
unless it's absolutely neccessary. - Send simply Text.
See http://www.gnu.org/philosophy/no-word-attachments.html
In a world without fences and walls nobody needs gates and windows.

Re: [Amforth-devel] Newbie

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

Hi Andy,


> The Arduino Mega uses :-
>
> ATMega 1280 16au, 16Mhz clock/crystal
>   
Not exactly this type of controller but similiar one work
fine. Your chances are good to get amforth working.

But: You loose the arduino features since you need to
re-program the entire chip.

Matthias

[Amforth-devel] Newbie

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

Hurro

Just a quick email to say hello, I am interested in running up an 
amForth for the Arduino Mega and was wondering if anyone else had 
already done this and could advise of pitfalls etc.

The Arduino Mega uses :-

ATMega 1280 16au, 16Mhz clock/crystal

(sorry if you already all knew this)

Cheers

Andy Kirby

Re: [Amforth-devel] Amforth on ATmega644P

[Robert L. <xu...@xu...>]

Erich-

Thank you for your response.  My patch to AVRA was somewhat slapdash and as
such, I tend to suspect that AVRA is doing something wrong.  I'll try
assembling with AVRStudio's assembler, see if that gets me anywhere.  It's
also possible (even likely) there was a change between 3.3 and 3.6 that is
causing this.  Would you mind sending me the template.asm and so forth you
used to build 3.3?  It would be educational, if nothing else.

Thanks again.


On Tue, Jan 5, 2010 at 9:03 AM, Erich Waelde <ew....@na...> wrote:

> Hello Robert,
>
> > Has anyone successfully gotten amforth working on an ATmega644P?  I
> > tried to do this today, and immediately ran afoul of the fact that
> > avra (AVR assembler, on Linux) doesn't support the ATmega644P.
>
> about a year ago, I experimented with atmega-644p controllers, too.
> This was with amforth 3.3
>
> I did *not* patch avra. And if I remember correctly, the include files
> from AVRStudio are of a newer format, and avra didn't like them. So I went
> and installed wine and the assembler from avrstudio. Yapp, not the
> best solution, but it worked for the moment.
>
> This results in the following call to produce the hex files:
>
> wine ~/wine/AvrAssembler2/avrasm2.exe -I ~/Forth/amforth/releases/3.3/core
> \
>  -I . -fI  -l main.lst -m main.map -e main.eep.hex main.asm
>
> So for the heck of it, I just grabbed a 644P and powered it up.
> The hex file loads and the controller does talk with me:
> > ver
> amforth 3.3 ATmega644P ok
> > .res
> free FLASH cells      25207
> free RAM cells        3795
> used EEPROM cells     42
> used data stack cells 0
> used return stack     10
> free return stack     70
>  ok
> > : hi ." hello, world!" cr ;
>  ok
> > hi
> hello, world!
>  ok
> >
>
> So far so good. How did I make it work??? Hm.
> . wine + avrassembler2 I mentioned above.
> . Fuse bits:
>  # external crystal at 11.0592 MHz
>  LFUSE=0xee
>  HFUSE=0x89
> . there are 31 interrupts now, you found that.
>
> It is certainly possible to dig out the differences to the old
> version 3.3, however, it would take some time.
>
> I could obviously send you my files, if you are interested
> in "code archeaology" :-)  I have not used the 644p any more yet.
>
> Cheers,
> Erich
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] Amforth on ATmega644P

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

Hello Robert,

> Has anyone successfully gotten amforth working on an ATmega644P?  I
> tried to do this today, and immediately ran afoul of the fact that
> avra (AVR assembler, on Linux) doesn't support the ATmega644P.

about a year ago, I experimented with atmega-644p controllers, too.
This was with amforth 3.3

I did *not* patch avra. And if I remember correctly, the include files
from AVRStudio are of a newer format, and avra didn't like them. So I went
and installed wine and the assembler from avrstudio. Yapp, not the
best solution, but it worked for the moment.

This results in the following call to produce the hex files:

wine ~/wine/AvrAssembler2/avrasm2.exe -I ~/Forth/amforth/releases/3.3/core \
  -I . -fI  -l main.lst -m main.map -e main.eep.hex main.asm

So for the heck of it, I just grabbed a 644P and powered it up.
The hex file loads and the controller does talk with me:
> ver
amforth 3.3 ATmega644P ok
> .res
free FLASH cells      25207
free RAM cells        3795
used EEPROM cells     42
used data stack cells 0
used return stack     10
free return stack     70
 ok
> : hi ." hello, world!" cr ;
 ok
> hi
hello, world!
 ok
>

So far so good. How did I make it work??? Hm.
. wine + avrassembler2 I mentioned above.
. Fuse bits:
  # external crystal at 11.0592 MHz
  LFUSE=0xee
  HFUSE=0x89
. there are 31 interrupts now, you found that.

It is certainly possible to dig out the differences to the old
version 3.3, however, it would take some time.

I could obviously send you my files, if you are interested
in "code archeaology" :-)  I have not used the 644p any more yet.

Cheers,
Erich

[Amforth-devel] Amforth on ATmega644P

[Robert L. <xu...@xu...>]

Hello-

Has anyone successfully gotten amforth working on an ATmega644P?  I
tried to do this today, and immediately ran afoul of the fact that
avra (AVR assembler, on Linux) doesn't support the ATmega644P.  I
patched avra to recognize the '644P (patch below), and was able to
build amforth.  After uploading it to the device, I got an amforth
prompt as expected, but creating a new word (e.g. : hello ." Hello
world" cr ; ) caused the device to apparently hang.  Still in search
of problems, I took a closer look at core/devices/atmega644.asm, and
noticed the number of interrupts listed there do not line up with the
datasheet.  I patched atmega644.asm (patch below), rebuilt, and
uploaded to the device, with identical results.

Can anyone suggest a course of action?  I'm relatively new to Forth,
so while my normal next step would be to delve into the amforth code,
it would be a steep learning curve; I thought I'd try here first.

My development device is a PDIP-40 ATmega644P, installed in an STK500
board with the crystal oscillator selected and a 10MHz crystal
installed.  My fuse bits are at the bottom of this email.

Transcript:
amforth 3.6 ATmega644P
> : hello ." Hello World " cr ;
(hangs)



AVRA Patch:

--- avra-1.2.3.orig/device.c    2007-06-25 14:43:10.000000000 -0700
+++ avra-1.2.3/device.c    2010-01-04 20:54:02.000000000 -0800
@@ -104,6 +104,7 @@
   {   "ATmega88",        4096,     0x100,     1024,    512,
DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
   {  "ATmega168",        8192,     0x100,     1024,    512,
DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
   { "ATmega8515",        8192,      0x60,      512,    512,
DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
+  { "ATmega644P",       32768,     0x100,     4096,   2048,
DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM},
   {NULL, 0, 0, 0, 0}
 };

atmega644.asm Patch:
--- atmega644.asm	2010-01-04 21:06:12.000000000 -0800
+++ atmega644P.asm	2010-01-04 21:06:54.000000000 -0800
@@ -2,7 +2,7 @@
 ; Built using part description XML file version 69
 ; generated automatically
 .nolist
-	.include "m644def.inc"
+	.include "m644Pdef.inc"
 .list

 .equ ramstart =  $100
@@ -43,7 +43,7 @@
 	rol zh
 .endmacro
 .equ intvecsize = 2 ; please verify; flash size: 65536 bytes
-.equ INTVECTORS = 28
+.equ INTVECTORS = 31
 .org $002
 	 rcall isr ; External Interrupt Request 0
 .org $004
@@ -98,7 +98,13 @@
 	 rcall isr ; 2-wire Serial Interface
 .org $036
 	 rcall isr ; Store Program Memory Read
+.org $038
+	 rcall isr ; USART1, Rx Complete
+.org $03A
+	 rcall isr ; USART1 Data register Empty
+.org $03C
+	 rcall isr ; USART1, Tx Complete
 mcustring:
-	.dw 9
-	.db "ATmega644",0
+	.dw 10
+	.db "ATmega644P"
 .set codestart=pc

Fuses:
# set the fuses according to your MCU
LFUSE=0xFE
HFUSE=0xDF
# some MCU have this one, see write-fuses target below
EFUSE=0xFF