amforth-devel — Development discussion and user support

Re: [Amforth] Problems with a Duemilanove

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

Hi,

One more remark: The Duemilanove uses two different
controllers: Atmega168 (old) and Atmega328 (more recent),
you may have picked the wrong one.

Matthias

Re: [Amforth] Problems with a Duemilanove

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

Hello Torsten,

On 12/05/2011 07:48 PM, Torsten Sadowski wrote:
> Hi,
>
> I'm trying to run amforth on an Arduino Duemilanove.
> Compiling with Avra (from git) and uploading worked
> without a problem but I can't get a prompt in the serial
> terminal. I also set the fuses according to the Readme.
> I have the impression, that the chip does not start.
> I would expect some flicker on the TX diode when amforth
> sends the "I'm alive" message.

Just to double check, you did load two files, not one?
1. duemilanove.eep.hex
2. duemilanove.hex

The .eep.hex is loaded into the eeprom area, whithout that,
nothing will move.

>
> Could someone please send me Duemilanove hex-files that are known to work?

please find attached 2 files which I have used.
amforth Version 4.6

The files might be striped on the mailing list, so I add
your email explicitly.

Have fun,
Erich
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: duemilanove.eep.hex
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: duemilanove.hex

[Amforth] Problems with a Duemilanove

[Torsten S. <tsa...@gm...>]

Hi,

I'm trying to run amforth on an Arduino Duemilanove. Compiling with Avra (from git) and uploading worked without a problem but I can't get a prompt in the serial terminal. I also set the fuses according to the Readme. I have the impression, that the chip does not start. I would expect some flicker on the TX diode when amforth sends the "I'm alive" message.

Could someone please send me Duemilanove hex-files that are known to work?

Cheers,
Torsten

Re: [Amforth] Atmega328p

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

Mark,
1. did you try to burn in a blinking demo or something like that to
verify a) your hardware b) your programmer?
2. did you program flash as well as eeprom?
3. does your uart connectivity works? (try to connect rx and tx at
the atmega side together (disconnect the chip) and you have to see
echo on the terminal when writing
4. do use 9600, 8N1
5. ask somebody to provide you with ready compilation for your chip,
xtal, baudrate (2 files)
6. fuses - see http://www.engbedded.com/fusecalc/
p.


----- PŮVODNÍ ZPRÁVA -----
Od: "Mark Malmros" <m.m...@gm...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth] Atmega328p
Datum: 5.10.2011 - 14:35:00

> Thanks for that suggestion! Obvious next step. As
> it turns out, there's
> nothing "stable" coming out of the TXD(pin 3) - in
> fact on some resets it
> latches to vcc... ?  although I also got a nice
> pulse train on another reset
> - but mostly I see nothing! So need to investigate
> those issues.  I
> assembled a plain vanilla amforth 4.5 using the
> example template and
> appturnkey files... assume if all is well that
> will give me a simple forth
> prompt so further assuming my issue is hardware or
> the fuse bytes.
> 
> On Tue, Oct 4, 2011 at 8:44 PM, D Nyberg
> <dny...@at...> wrote:
> 
> > On 10/4/2011 10:43:00 AM, Mark Malmros
> > (m.m...@gm...) wrote:
> > >  > What am I missing?
> >  >
> >  > I am attempting to put amforth on a
> >  > Atmega328p following more or less
> >  > > the
> >  > Amforth Users Guide (which was written for
> >  > Amforth 4.2). I am working
> >  > >  > from
> >  > Linux.
> > ...
> >
> > Can you put  a scope  or even just a logic probe
> > in capture mode on the
> > > uart pins, to see if they're being wiggled at
> > all? If so, then the speed
> > > field of the fuse bits may be where you should
> > be looking. I had some
> > > difficulty with this on a 324. I eventually
> > brute forced it by trying
> > > many settings until I got console I/O that
> > looked  right. I still have
> > > no idea why the value  I settled  on is the
> > correct one.
> > >
> >
> > ------------------------------------------------------------------------------
> > > > > All the data continuously generated in your IT
> > infrastructure contains a
> > > definitive record of customers, application
> > performance, security
> > > threats, fraudulent activity and more. Splunk
> > takes this data and makes
> > > sense of it. Business sense. IT sense. Common
> > sense.
> > > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Amforth-devel mailing list for
> > http://amforth.sf.net/
> > > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT
> infrastructure contains a
> definitive record of customers, application
> performance, security
> threats, fraudulent activity and more. Splunk
> takes this data and makes
> sense of it. Business sense. IT sense. Common
> sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Amforth-devel mailing list for
> http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Atmega328p

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

Marc,

I found basically 3 reason for a non-working serial line

- wrong fuse settings. The controller works with a different
  clock as you think it does, which lead to different baud
  rates. The result is some garbage characters on the wire.
  The only solution is to use... the right settings.

- remove the programmer after burning the hex files. Sometimes
  they go crazy and keep the reset pin low -- nothing happens at
  all.

- some atmegas have more than one serial port, ok the 328p has
  only one but check the wiring (again).



HTH Matthias

Re: [Amforth] Atmega328p

[Mark M. <m.m...@gm...>]

Thanks for that suggestion! Obvious next step. As it turns out, there's
nothing "stable" coming out of the TXD(pin 3) - in fact on some resets it
latches to vcc... ?  although I also got a nice pulse train on another reset
- but mostly I see nothing! So need to investigate those issues.  I
assembled a plain vanilla amforth 4.5 using the example template and
appturnkey files... assume if all is well that will give me a simple forth
prompt so further assuming my issue is hardware or the fuse bytes.

On Tue, Oct 4, 2011 at 8:44 PM, D Nyberg <dny...@at...> wrote:

> On 10/4/2011 10:43:00 AM, Mark Malmros (m.m...@gm...) wrote:
>  > What am I missing?
>  >
>  > I am attempting to put amforth on a Atmega328p following more or less
> the
>  > Amforth Users Guide (which was written for Amforth 4.2). I am working
>  > from
>  > Linux.
> ...
>
> Can you put  a scope  or even just a logic probe in capture mode on the
> uart pins, to see if they're being wiggled at all? If so, then the speed
> field of the fuse bits may be where you should be looking. I had some
> difficulty with this on a 324. I eventually brute forced it by trying
> many settings until I got console I/O that looked  right. I still have
> no idea why the value  I settled  on is the correct one.
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Atmega328p

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

On 10/4/2011 10:43:00 AM, Mark Malmros (m.m...@gm...) wrote:
 > What am I missing?
 >
 > I am attempting to put amforth on a Atmega328p following more or less 
the
 > Amforth Users Guide (which was written for Amforth 4.2). I am working
 > from
 > Linux.
...

Can you put  a scope  or even just a logic probe in capture mode on the 
uart pins, to see if they're being wiggled at all? If so, then the speed 
field of the fuse bits may be where you should be looking. I had some 
difficulty with this on a 324. I eventually brute forced it by trying 
many settings until I got console I/O that looked  right. I still have  
no idea why the value  I settled  on is the correct one.

[Amforth] Atmega328p

[Mark M. <m.m...@gm...>]

What am I missing?

I am attempting to put amforth on a Atmega328p following more or less the
Amforth Users Guide (which was written for Amforth 4.2).  I am working from
Linux.

Using the example template.asm with the dict_appl.inc and dict_appl_core.inc
and the applturnkey.asm in ver 4.5 - it assembles without errors under
Studio 4 (4.18) running under wine.  Using avrdude 5.1 and either a
Avrispmkii or avr-pg2, I load the flash and the eeprom with their respective
hex files assembled under Studio 4.  Using the factory default settings OR
changing the fuse bytes, I am unable to pull up a forth prompt on the serial
port (9600 8n1).  The 328p is wired only to either a 10 or 6 pin ISP header
(depending on which programmer - both seem to work fine), a 16 mhz crystal
with 22pf caps (the only change in the template.asm file), and a max 232 for
the serial port.  This "simple wiring" has been triple checked.  The default
fuses (as found on a new chip) are high fuse: 0xD9 which I have set to
either 0xD1 or 0xD0 (BOOTRST ?) and low fuse default 0x62 which I reset to
0x67.  Guidance on the proper fuse settings is conFUSing.

What am I missing?

Re: [Amforth] atmega128

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

Hi D Williams -

I managed to get Amforth running on a Mega128. There are three 
undocumented file changes you need to make:

“core/devices/atmega128/device.asm”: add these lines (I put them after 
'ifndef EEPME' etc…)
.ifndef MCUSR
.equ MCUSR = MCUCSR
.endif

For some reason the Mega128 doesn't have the MCUSR register, but the 
MCUCSR does the same job (and a bit more...). Adding these lines ensures 
the code will compile with the Mega128 as well as the others supported.

“core/words/istore_nrww.asm” (or "core/words/store-i_nrww.asm")
edit line 114 from
in temp1, SPMCSR to
in_ temp1, SPMCSR ,
and line 122 from
out SPMCSR,temp0 to
out_ SPMCSR,temp0

The 'in' and 'out' commands only work for a limited range of addresses. 
Fortunately the macros 'in_' and 'out_' do the same job for all addresses.

Finally,

“core/drivers/usart_0.asm”: change lines 1 to 6 to:
.equ BAUDRATE_LOW = UBRR0L + $20
.equ BAUDRATE_HIGH = UBRR0H
.equ USART_C = UCSR0C
.equ USART_B = UCSR0B + $20
.equ USART_A = UCSR0A + $20
.equ USART_DATA = UDR0 + $20

These changes are caused by the Mega128 trying to cram a quart into a 
pint bottle. Some addresses are double booked, and this offset is needed 
to fix things.

With these modifications to the code I was able to get the system up and 
running in the AVR Studio (version 4) simulator - and even talk to it 
using 'Hapsim', which permits you to make a virtual serial connection to 
the emulated code.

Hope that's helpful -

David Jeffrey

On 9/15/2011 12:03 PM, Erich Waelde wrote:
> Hello,
>
>
> On 09/15/2011 05:22 PM, D Williams wrote:
>> FWIW - The last version that worked for me on the amtega128 was amforth 3.1
>> After that, I could not sort out the interrupts.
> There was a Problem with interrupt addresses being off by a factor of 2. But
> I don't recall, which version it was. And maybe it was a trunk version only,
> not a release. I'm using amforth 4.5 routinely on atmega32.
>
>>> Hello guys,
>>> I'm trying to build amforth for an ATmega128.
>>> It won't compile, searching for a definition of MCUSR.
>>> Attached you'll find the folder content I'm using (a standard template).
>>> amforth ver. 4.5
>>> AVR Studio 4 (latest build)
> Have you spotted Karl Lunts userguide on the webpage?
> http://amforth.sourceforge.net/amforth-userguide.pdf
>
> I'm not using AvrStudio, so I cannot comment on that other than
> asking: what is the exact error message you are getting?
>
>
> Cheers,
> Erich
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops?   How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] compilation / code programming problems

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

Hello,

On 09/15/2011 05:18 PM, Keith Causey wrote:
> Hello All,
>   I have tried several times to pose my question so I think that I may be
> doing something wrong. I am having problems both compiling for the ATMega
> 2560 and finding a device to up load the code (once it gets compiled) to
> said device.

compiling/assembling:
as Marcin has asked: What tools are you using? Assembling will work with
the AvrAssembler2 that comes with AvrStudio (it can be run with wine on Linux),
will work with avra when using the latest source from the git repository.
It will not work with the assembler that comes with avr-gcc, as far as I know.

uploading:
Im using
a. a dragon board
b. a AVR MKII programmer
c. a homebrew thing called sp12 dongle
all without a problem

> Is there a list of source files that will actually compile or
> maybe a second source from someone who has parsed the pertinent files that
> will actually compile so that I can use those?

Starting from
https://amforth.svn.sourceforge.net/svnroot/amforth/releases/4.5/appl/
template is a directory holding a generic fileset, which needs to be edited
          (Makefile and template.asm)
atmega2561 may be of help (I don't have such a device).


> Additionally I have yet to
> receive a response so I think I may be using the wrong email address to
> contact you. Here's hoping that this one gets through ~ thank you in advance
> ~ keith

If you are working on Windows, please refer to Karl Lunts user guide:
http://amforth.sourceforge.net/amforth-userguide.pdf

If you are working on Linux, this document could be helpful, too:
http://amforth.sourceforge.net/pr/Fosdem2011-proceedings-amforth.pdf



Cheers,
Erich

Re: [Amforth] atmega128

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

Hello,


On 09/15/2011 05:22 PM, D Williams wrote:
>
> FWIW - The last version that worked for me on the amtega128 was amforth 3.1
> After that, I could not sort out the interrupts.

There was a Problem with interrupt addresses being off by a factor of 2. But
I don't recall, which version it was. And maybe it was a trunk version only,
not a release. I'm using amforth 4.5 routinely on atmega32.

>
>> Hello guys,
>> I'm trying to build amforth for an ATmega128.
>> It won't compile, searching for a definition of MCUSR.
>> Attached you'll find the folder content I'm using (a standard template).
>> amforth ver. 4.5
>> AVR Studio 4 (latest build)

Have you spotted Karl Lunts userguide on the webpage?
http://amforth.sourceforge.net/amforth-userguide.pdf

I'm not using AvrStudio, so I cannot comment on that other than
asking: what is the exact error message you are getting?


Cheers,
Erich

Re: [Amforth] compilation / code programming problems

[Leon M. <leo...@gm...>]

On Thu, Sep 15, 2011 at 10:18 AM, Keith Causey
<ke...@ha...>wrote:

> and finding a device to up load the code (once it gets compiled) to
> said device.


I think almost any device capable of programming an ATMega will do; I don't
think amforth has any special requirements for uploading. I've been using
this <http://www.ladyada.net/make/usbtinyisp/>.
-Leon

Re: [Amforth] compilation / code programming problems

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

>> Keith Causey <ke...@ha...> wrote:
> Hello All,
>  I have tried several times to pose my question so I think that I may be
> doing something wrong. I am having problems both compiling for the ATMega
> 2560 and finding a device to up load the code (once it gets compiled) to
> said device. 

I hope you are going to compile (assemble, actually) amforth,
the implementation for the FORTH programming language for AVR CPUs.

Can you post output from the compilation? Where the problem is?
Are you using AVRstudio with avrasm2? avra? Any information
how you invoke the compiler and the output would be appreciated.

//Marcin

[Amforth] atmega128

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

FWIW - The last version that worked for me on the amtega128 was amforth 3.1
After that, I could not sort out the interrupts.

>Hello guys,
>I'm trying to build amforth for an ATmega128.
>It won't compile, searching for a definition of MCUSR.
>Attached you'll find the folder content I'm using (a standard template).
>amforth ver. 4.5
>AVR Studio 4 (latest build)

>Any help is greatly appreciated.
>Thank you

[Amforth] compilation / code programming problems

[Keith C. <ke...@ha...>]

Hello All,
 I have tried several times to pose my question so I think that I may be
doing something wrong. I am having problems both compiling for the ATMega
2560 and finding a device to up load the code (once it gets compiled) to
said device. Is there a list of source files that will actually compile or
maybe a second source from someone who has parsed the pertinent files that
will actually compile so that I can use those?  Additionally I have yet to
receive a response so I think I may be using the wrong email address to
contact you. Here's hoping that this one gets through ~ thank you in advance
~ keith

Re: [Amforth] Beagleboard Trainer from TinCanTools

[Andrew H. <and...@4a...>]

Hi,

Thanks, one my ISP arrives I’ll give it a go.

My understanding is that "provides a second RS-232 serial port” refers a port added to the ARM on the beagle board.

I have already used the Arduino tools and avrgal to flash a simple, blink, programme on the atmega.

I’ll let you know how I get on.

Thanks,
Andrew

at 19:54, Matthias Trute wrote:

> Am 14.09.2011 20:23, schrieb Andrew Holt:
>> Hi,
>> 
>> You may, or may not, know that there is a add on for the beagle board
>> that is Arduino compatible and use the ATmega328.
>> 
>> I would like to use amforth with this board and was wondering if I am
>> going to be a pioneer, or if somebody else has already done it, and
>> can warn be of any pit falls and “traps for the unwary".
> 
> The controller itself works fine with amforth. What could cause
> troubles is the selection of the right usart port. You may check
> the layout first or simply try-and-change:
> 
> "The Trainer provides a second RS-232 serial port that interfaces to the
> ATmega328 processor. Commands can be transmitted back and forth between
> the BeagleBoard and ATmega328 processor. "
> 
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the 
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

=============================
Andrew Holt

Email: and...@4a...

De Omnibus Dubitandum
=============================

Re: [Amforth] Beagleboard Trainer from TinCanTools

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

Am 14.09.2011 20:23, schrieb Andrew Holt:
> Hi,
> 
> You may, or may not, know that there is a add on for the beagle board
> that is Arduino compatible and use the ATmega328.
> 
> I would like to use amforth with this board and was wondering if I am
> going to be a pioneer, or if somebody else has already done it, and
> can warn be of any pit falls and “traps for the unwary".

The controller itself works fine with amforth. What could cause
troubles is the selection of the right usart port. You may check
the layout first or simply try-and-change:

"The Trainer provides a second RS-232 serial port that interfaces to the
ATmega328 processor. Commands can be transmitted back and forth between
the BeagleBoard and ATmega328 processor. "


Matthias

[Amforth] Beagleboard Trainer from TinCanTools

[Andrew H. <and...@4a...>]

Hi,

You may, or may not, know that there is a add on for the beagle board that is Arduino compatible and use the ATmega328.

I would like to use amforth with this board and was wondering if I am going to be a pioneer, or if somebody else has already done it, and can warn be of any pit falls and “traps for the unwary".

Thanks,
Andrew
=============================
Andrew Holt

Email: and...@4a...

De Omnibus Dubitandum
=============================

Re: [Amforth] amforth 4.5 and ATmega128

[Paolo G. <pao...@fa...>]

Yes Jeffrey, I still have problems with ATMega128.

Could you please post your settings.
Thanks.
Paolo

----- Original Message ----- 
From: "david jeffrey" <dav...@ea...>
To: "Everything around amforth" <amf...@li...>; 
<amf...@li...>
Sent: Thursday, July 28, 2011 7:34 AM
Subject: Re: [Amforth] amforth 4.5 and ATmega128


> Hi Paulo,
>
> I did get amforth running on a mega128 and took notes on the changes 
> needed. Unfortunately I will not have access to my files till mid August. 
> If you are still stuck after the 9 Aug, get in touch.
>
> Cheers, David Jeffrey.
>
> "pao...@fa..." <pao...@fa...> wrote:
>
>>Hello guys,
>>I'm trying to build amforth for an ATmega128.
>>It won't compile, searching for a definition of MCUSR.
>>Attached you'll find the folder content I'm using (a standard
>>template).
>>amforth ver. 4.5
>>AVR Studio 4 (latest build)
>>
>>Any help is greatly appreciated.
>>Thank you
>>
>>------------------------------------------------------------------------------
>>Magic Quadrant for Content-Aware Data Loss Prevention
>>Research study explores the data loss prevention market. Includes
>>in-depth
>>analysis on the changes within the DLP market, and the criteria used to
>>evaluate the strengths and weaknesses of these DLP solutions.
>>http://www.accelacomm.com/jaw/sfnl/114/51385063/
>>_______________________________________________
>>Amforth-devel mailing list for http://amforth.sf.net/
>>Amf...@li...
>>https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ------------------------------------------------------------------------------
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel 

Re: [Amforth] amforth 4.5 and ATmega128

[david j. <dav...@ea...>]

Hi Paulo, 

I did get amforth running on a mega128 and took notes on the changes needed. Unfortunately I will not have access to my files till mid August. If you are still stuck after the 9 Aug, get in touch. 

Cheers, David Jeffrey. 

"pao...@fa..." <pao...@fa...> wrote:

>Hello guys,
>I'm trying to build amforth for an ATmega128.
>It won't compile, searching for a definition of MCUSR.
>Attached you'll find the folder content I'm using (a standard
>template).
>amforth ver. 4.5
>AVR Studio 4 (latest build)
>
>Any help is greatly appreciated.
>Thank you
>
>------------------------------------------------------------------------------
>Magic Quadrant for Content-Aware Data Loss Prevention
>Research study explores the data loss prevention market. Includes
>in-depth
>analysis on the changes within the DLP market, and the criteria used to
>evaluate the strengths and weaknesses of these DLP solutions.
>http://www.accelacomm.com/jaw/sfnl/114/51385063/
>_______________________________________________
>Amforth-devel mailing list for http://amforth.sf.net/
>Amf...@li...
>https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] amforth 4.5 and ATmega128

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

Hi Paolo,

> I'm trying to build amforth for an ATmega128.

A rather old controller. Are you sure that its not
a more modern one? I vaguly remember reading about
troubles with some Atmega103 compatability fuses as
well (not related with amforth on avrfreaks.net).

> It won't compile, searching for a definition of MCUSR.

Some googling told me (AVR Note AVR097: Migration between ATmega128 and
ATmega1281/ATmega2561) that the name of the MCUSR was MCUCSR. Thus
put a quick

.equ MCUSR = MCUCSR

inside your template.asm. The exact placement should not be important,
but if in doubt put this instruction into the first line.

Another thing are the IN instructions in words/core/store-i_nrww.asm.
Change all IN instructions into in_ (with the underscore) to make
the assembler happy. The reason is that the MCUSR is usually inside
the address region that the IN instruction can reach, only on
your controller it is outside. The IN_ macro has some checks to
decide between IN and a LDS for a particular address.

Tell if it works, I cannot test it myself. Then I can make a more
permanent change in the repository.

Matthias

Re: [Amforth] amforth 4.5 and ATmega128

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

Hello Paolo,

On 07/26/2011 03:10 PM, pao...@fa... wrote:
> Hello guys,
> I'm trying to build amforth for an ATmega128.
> It won't compile, searching for a definition of MCUSR.
> Attached you'll find the folder content I'm using (a standard template).
> amforth ver. 4.5
the attachment seems to be stripped away on the mailing list, but let's see:


 > make  DIR_ATMEL=~/wine/AvrAssembler2
wine ~/wine/AvrAssembler2/avrasm2.exe -I ~/wine/AvrAssembler2/Appnotes2 -I ../../core -I ../../core/devices/atmega128 -fI -v0 -e template.eep.hex -l template.lst template.asm
../../core\macros.asm(49): error: Illegal use of undefined or forward referenced symbol 'MCUSR' in conditional
../../core\macros.asm(57): error: Illegal use of undefined or forward referenced symbol 'MCUSR' in conditional

Assembly failed, 2 errors, 0 warnings
make: *** [template.hex] Error 1

This is probably, what you see.

 > grep MCU ~/wine/AvrAssembler2/Appnotes/m128def.inc
;* Target MCU        : ATmega128
.equ	MCUCR	= 0x35
.equ	MCUCSR	= 0x34
; MCUCR - MCU Control Register
; MCUCSR - MCU Control And Status Register
; MCUCSR - MCU Control And Status Register

yupp, MCUSR is *not* defined in m128def.inc. Poking into the mega32 stuff, which
I use a lot, I find a suspicious looking line here (last line):

 > grep MCU ~/wine/AvrAssembler2/Appnotes/m32def.inc
;* Target MCU        : ATmega32
.equ	MCUCR	= 0x35
.equ	MCUCSR	= 0x34
; MCUCR - General Interrupt Control Register
; MCUCSR - MCU Control And Status Register
; MCUCR - MCU Control Register
; MCUCSR - MCU Control And Status Register
.equ	MCUSR	= MCUCSR	; For compatibility

So adding that to m128def.inc, it changes the error message:

 > make  DIR_ATMEL=~/wine/AvrAssembler2
wine ~wine/AvrAssembler2/avrasm2.exe -I ~/wine/AvrAssembler2/Appnotes2 -I ../../core -I ../../core/devices/atmega128 -fI -v0 -e template.eep.hex -l template.lst template.asm
../../core\words/store-i_nrww.asm(114): error: Operand 2 out of range: 0x68
../../core\words/store-i_nrww.asm(122): error: Operand 1 out of range: 0x68

Assembly failed, 2 errors, 0 warnings
make: *** [template.hex] Error 1


Hmm. That I haven't seen before. The lines in question both mention
SPMCSR:
114: in   temp1, SPMCSR
122: out SPMCSR,temp0
SPMCSR = $68, says the datasheet.
So maybe "in" and "out" are out of range for $68.

Anyone else knows about this?

Cheers,
Erich

[Amforth] amforth 4.5 and ATmega128

[<pao...@fa...>]

Hello guys,
I'm trying to build amforth for an ATmega128.
It won't compile, searching for a definition of MCUSR.
Attached you'll find the folder content I'm using (a standard template).
amforth ver. 4.5
AVR Studio 4 (latest build)

Any help is greatly appreciated.
Thank you

Re: [Amforth] Amforth on Butterfly?

[Jim F. <ja...@wa...>]

On 14/07/2011 19:18, Matthias Trute wrote:
>
> Jim,
>
>> I'd like to install Amforth on an Atmel Butterfly I have, and am
>> currently waiting for delivery of a USBasp programmer.
>>
>> I anticipate using the pre-built hex files supplied with the
>> distribution, loading them with 'avrdude'.
>
> exactly.
>
>>
>> Are there any 'gotchas' I need to be aware of? In particular, I'm hazy
>> about 'fuses' and 'lock bits' - will I need to change any of them from
>> the existing butterfly default?
>
> I dont remember anything troublesome, it should just work. Just one
> hint: do not use the fast serial settings since the butterfly does
> not have a stable frequency. 9600 or even 4800 should be your choice.
> It depends on your particular device.
>
> The address http://www.forth-ev.de/wiki/doku.php/projects:avr:atmega169
> has some more information, google translator may be helpful (the page
> is in German)

Thanks for the reply Matthias. I can now go ahead with the confidence 
that it will work!

Jim

Re: [Amforth] Amforth on Butterfly?

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

Jim,

> I'd like to install Amforth on an Atmel Butterfly I have, and am 
> currently waiting for delivery of a USBasp programmer.
> 
> I anticipate using the pre-built hex files supplied with the 
> distribution, loading them with 'avrdude'.

exactly.

> 
> Are there any 'gotchas' I need to be aware of? In particular, I'm hazy 
> about 'fuses' and 'lock bits' - will I need to change any of them from 
> the existing butterfly default?

I dont remember anything troublesome, it should just work. Just one
hint: do not use the fast serial settings since the butterfly does
not have a stable frequency. 9600 or even 4800 should be your choice.
It depends on your particular device.

The address http://www.forth-ev.de/wiki/doku.php/projects:avr:atmega169
has some more information, google translator may be helpful (the page
is in German)

Matthias