amforth-devel

[Amforth] Issues with a word compile - flash or eeprom write issues

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

Hi, after a year I'm trying to run the latest version on atmega32
(11.0592Meg xtal). Compiling and flashing is ok, I get working
system with one exception - I cannot add a new word - ie 
> : foo 123 . ;
ok
> words
and it hangs here, so I have to reflash eeprom, then I can see words
again (without foo). Moreover, I tried my old v4.4 images (which
worked fine) with the same issue - I cannot compile a new word.
Otherwise it works fine (even the floating point calcs work
properly). It seems it does not write internaly to flash or eeprom
properly. The lock fuses are 0x3f (write enable). Baudrate, char and
line delay, waiting on "ok" is set properly. BOD disabled. Tried 2
chips at 3.3V and 5V. Chips erased, programmed with FF low and DF
high fuse (and many others..). What am I missing here?
Pito

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Charles S. <sum...@gm...>]

I had a similar problem with the uno until I saw I had left the flash
locked after I out on the forth image.
On May 6, 2012 7:51 AM, "pito" <pi...@vo...> wrote:

> Hi, after a year I'm trying to run the latest version on atmega32
> (11.0592Meg xtal). Compiling and flashing is ok, I get working
> system with one exception - I cannot add a new word - ie
> > : foo 123 . ;
> ok
> > words
> and it hangs here, so I have to reflash eeprom, then I can see words
> again (without foo). Moreover, I tried my old v4.4 images (which
> worked fine) with the same issue - I cannot compile a new word.
> Otherwise it works fine (even the floating point calcs work
> properly). It seems it does not write internaly to flash or eeprom
> properly. The lock fuses are 0x3f (write enable). Baudrate, char and
> line delay, waiting on "ok" is set properly. BOD disabled. Tried 2
> chips at 3.3V and 5V. Chips erased, programmed with FF low and DF
> high fuse (and many others..). What am I missing here?
> Pito
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

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

Hi,

> Hi, after a year I'm trying to run the latest version on atmega32
> (11.0592Meg xtal). Compiling and flashing is ok, I get working
> system with one exception - I cannot add a new word - ie 
>> : foo 123 . ;
> ok
>> words
> and it hangs here

Cannot reproduce:

 > : foo 123 . ;
   ok
 > words
  foo pick nip ...
 > foo

  123  ok

 >

> Otherwise it works fine (even the floating point calcs work
> properly). It seems it does not write internaly to flash or eeprom
> properly. The lock fuses are 0x3f (write enable). Baudrate, char and
> line delay, waiting on "ok" is set properly. BOD disabled. Tried 2
> chips at 3.3V and 5V. Chips erased, programmed with FF low and DF
> high fuse (and many others..). What am I missing here?

Try high fuse set to 0xd9 (Atmega32). This sets the boot flash section
to the default. high fuse 0xdf leads to a too small boot section
size, and effectivly disables flash write operations (a !e should
work however).

Lock fuses leave as they are set from the factory. Always. Never ever
change them.

Matthias

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

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

Matthias,
thanks - yes - the bootloader space is used by amforth .. do not ask
me how much time I've spent tackling this, finally I thought my both
chips are dead... :) ... the D9 did the trick..
> foo
123  ok
Thanks,
Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth] Issues with a word compile - flash or eeprom
Datum: 6.5.2012 - 16:20:37

> Hi,
> 
> > Hi, after a year I'm trying to run the latest
> > version on atmega32
> > > (11.0592Meg xtal). Compiling and flashing is ok,
> > I get working
> > > system with one exception - I cannot add a new
> > word - ie 
> > >> : foo 123 . ;
> > ok
> >> words
> > and it hangs here
> 
> Cannot reproduce:
> 
> > : foo 123 . ;
> ok
> > words
> foo pick nip ...
> > foo
> 
> 123  ok
> 
> >
> 
> > Otherwise it works fine (even the floating point
> > calcs work
> > > properly). It seems it does not write internaly
> > to flash or eeprom
> > > properly. The lock fuses are 0x3f (write
> > enable). Baudrate, char and
> > > line delay, waiting on "ok" is set properly. BOD
> > disabled. Tried 2
> > > chips at 3.3V and 5V. Chips erased, programmed
> > with FF low and DF
> > > high fuse (and many others..). What am I missing
> > here?
> > 
> Try high fuse set to 0xd9 (Atmega32). This sets
> the boot flash section
> to the default. high fuse 0xdf leads to a too
> small boot section
> size, and effectivly disables flash write
> operations (a !e should
> work however).
> 
> Lock fuses leave as they are set from the factory.
> Always. Never ever
> change them.
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> Exclusive live event will cover all the ways
> today's security and 
> threat landscape has changed and how IT managers
> can respond. Discussions 
> will include endpoint security, mobile security
> and the latest in malware 
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for
> http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Hi

When I take 2 new 328p with boot on it ( buy it recently from original supplier) then when I read the lock byte the should be the same?
If my working version has an other number, because I did some stupid things, I always can set it back to the origional value with avrdude?

Jan kromhout
Sacharovlaan 3
3223HM Hellevoetsluis-NL

Op 6 mei 2012 om 16:20 heeft Matthias Trute <mt...@we...> het volgende geschreven:

> Hi,
> 
>> Hi, after a year I'm trying to run the latest version on atmega32
>> (11.0592Meg xtal). Compiling and flashing is ok, I get working
>> system with one exception - I cannot add a new word - ie 
>>> : foo 123 . ;
>> ok
>>> words
>> and it hangs here
> 
> Cannot reproduce:
> 
>> : foo 123 . ;
>   ok
>> words
>  foo pick nip ...
>> foo
> 
>  123  ok
> 
>> 
> 
>> Otherwise it works fine (even the floating point calcs work
>> properly). It seems it does not write internaly to flash or eeprom
>> properly. The lock fuses are 0x3f (write enable). Baudrate, char and
>> line delay, waiting on "ok" is set properly. BOD disabled. Tried 2
>> chips at 3.3V and 5V. Chips erased, programmed with FF low and DF
>> high fuse (and many others..). What am I missing here?
> 
> Try high fuse set to 0xd9 (Atmega32). This sets the boot flash section
> to the default. high fuse 0xdf leads to a too small boot section
> size, and effectivly disables flash write operations (a !e should
> work however).
> 
> Lock fuses leave as they are set from the factory. Always. Never ever
> change them.
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

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

Hi Jan,

> When I take 2 new 328p with boot on it ( buy it recently from
> original supplier) then when I read the lock byte the should be the
> same? If my working version has an other number, because I did some
> stupid things, I always can set it back to the origional value with
> avrdude?

I've never changed any lock bits, just keep them as they are (all
1). When reading the lock bits (difficult enough), it may be
possible that the unused bits in a byte may come up as 0 oder
1, thus changing the byte value. If you really want to check
the lock bits, deal with the bits  themselves. For any details,
consult the (long) datasheet(s).

Arduino has pre-programmed the controllers, maybe they have
changed the lock bits too. You may have to ask the ardiuno
people, why (but I doubt that they did it).

Matthias

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Hi Matthias,

Thanks for the quick response.

If I understand correctly the best is to buy some bare 328p chips, and flash them without tatching the lock bits

This is perhaps the issue that my Amfort is not won't to run.

Cheers,

Jan

Op 6 mei 2012, om 19:16 heeft Matthias Trute het volgende geschreven:

> Hi Jan,
> 
>> When I take 2 new 328p with boot on it ( buy it recently from
>> original supplier) then when I read the lock byte the should be the
>> same? If my working version has an other number, because I did some
>> stupid things, I always can set it back to the origional value with
>> avrdude?
> 
> I've never changed any lock bits, just keep them as they are (all
> 1). When reading the lock bits (difficult enough), it may be
> possible that the unused bits in a byte may come up as 0 oder
> 1, thus changing the byte value. If you really want to check
> the lock bits, deal with the bits  themselves. For any details,
> consult the (long) datasheet(s).
> 
> Arduino has pre-programmed the controllers, maybe they have
> changed the lock bits too. You may have to ask the ardiuno
> people, why (but I doubt that they did it).
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

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

Hello,

On 05/06/2012 08:12 PM, Jan Kromhout wrote:
>
> If I understand correctly the best is to buy some bare 328p chips,
> and flash them without tatching the lock bits.

If fuses and "lock bits" refer to the same thing, then
no: "bare chips" and arduino boards are different things.
I personally use the following settings on arduino "duemilanove" 
and "uno" boards

MCU=atmega328p
# set the fuses according to your MCU
LFUSE=0xFF
HFUSE=0xD9
# some MCU have this one, see write-fuses target below
EFUSE=0x05

The bare chips will run on the internal RC oszillator at 1 (or 
8?) MHz, they will ignore the attached crystal, unless you 
correct the fuse bits.


There is a "readme.txt" file in the directory appl/arduino with 
more information on arduinos.

And just to make sure: you are aware, that flashing amforth to 
an arduino board does remove the arduino bootloader, are you?


Cheers,
Erich

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Hello,

Again thanks for the response.
Yes I know that the boot loader is removed.
Stil I am try now for about 14 days to get a running AMforth.

These are my settings.

I need the B5 otherwise I get errors. Running XP under Parallels on my IMAC Lion.
Try also different computers, no good result!

avrdude  -B 5 -q -c usbtiny  -P usb -p m328p -e -U efuse:w:0x05:m -U hfuse:w:0xd9:m -U lfuse:w:0xFF:m
avrdude  -B 5 -q -c usbtiny  -P usb -p m328p -e -U flash:w:amforth.hex:i 
avrdude  -B 5 -q -c usbtiny  -P usb -p m328p -e -U eeprom:w:amforth.eep:i

and these settings I used for unlocking in the past

avrdude  -q -c usbtiny -b -P usb -p m328p -e -U lock:w:0x3f:m

As programmer I use the USBTinyISP, under windows XP.

I am now on the end, the last try is that someone is checking my flashed arm forth. I send it to the US.

Someone experience with burning under XP?

Cheers,

Jan

Hellevoetsluis-NL


Op 6 mei 2012, om 21:00 heeft Erich Waelde het volgende geschreven:

> Hello,
> 
> On 05/06/2012 08:12 PM, Jan Kromhout wrote:
>> 
>> If I understand correctly the best is to buy some bare 328p chips,
>> and flash them without tatching the lock bits.
> 
> If fuses and "lock bits" refer to the same thing, then
> no: "bare chips" and arduino boards are different things.
> I personally use the following settings on arduino "duemilanove" 
> and "uno" boards
> 
> MCU=atmega328p
> # set the fuses according to your MCU
> LFUSE=0xFF
> HFUSE=0xD9
> # some MCU have this one, see write-fuses target below
> EFUSE=0x05
> 
> The bare chips will run on the internal RC oszillator at 1 (or 
> 8?) MHz, they will ignore the attached crystal, unless you 
> correct the fuse bits.
> 
> 
> There is a "readme.txt" file in the directory appl/arduino with 
> more information on arduinos.
> 
> And just to make sure: you are aware, that flashing amforth to 
> an arduino board does remove the arduino bootloader, are you?
> 
> 
> Cheers,
> Erich
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
avrdude  -q -c usbtiny -b -P usb -p m328p -e -U lock:w:0x3f:m

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Paulo F. <pa...@ke...>]

On 2012/05/06, at 20:00, Erich Waelde wrote:

> Hello,
> 
> On 05/06/2012 08:12 PM, Jan Kromhout wrote:
>> 
>> If I understand correctly the best is to buy some bare 328p chips,
>> and flash them without tatching the lock bits.
> 
> If fuses and "lock bits" refer to the same thing, then
> no: "bare chips" and arduino boards are different things.
> I personally use the following settings on arduino "duemilanove" 
> and "uno" boards
> 
> MCU=atmega328p
> # set the fuses according to your MCU
> LFUSE=0xFF
> HFUSE=0xD9
> # some MCU have this one, see write-fuses target below
> EFUSE=0x05
> 
> The bare chips will run on the internal RC oszillator at 1 (or 
> 8?) MHz, they will ignore the attached crystal, unless you 
> correct the fuse bits.
> 
> 
> There is a "readme.txt" file in the directory appl/arduino with 
> more information on arduinos.
> 
> And just to make sure: you are aware, that flashing amforth to 
> an arduino board does remove the arduino bootloader, are you?
> 
> 
> Cheers,
> Erich
> 

Yes, those settings work ok with an Arduino Duemilanove (atmega328p). 

Here are  the command lines for Unix ( in my case OSX) and an usbtiny programmer: 

===============================================================================
avrdude -c usbtiny -p m328p -e -U flash:w:duemilanove.hex:i -U eeprom:w:duemilanove.eep.hex:i

avrdude -c usbtiny -p m328p -U 'lfuse:w:0xFF:m'
avrdude -c usbtiny -p m328p -U 'hfuse:w:0xD9:m'
avrdude -c usbtiny -p m328p -U 'efuse:w:0x05:m'

===========================================================

Tested with three different arduinos!   ( just in case... )


My best regards 
Paulo Ferreira 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Thanks Paulo,

Could sommething going wrong with the burner?
Can you give me a hint how to do this on the OSX.
I have not yet the experiance. 

Cheers,

Jan kromhout
Sacharovlaan 3
3223HM Hellevoetsluis-NL

Op 6 mei 2012 om 22:27 heeft Paulo Ferreira <pa...@ke...> het volgende geschreven:

> 
> On 2012/05/06, at 20:00, Erich Waelde wrote:
> 
>> Hello,
>> 
>> On 05/06/2012 08:12 PM, Jan Kromhout wrote:
>>> 
>>> If I understand correctly the best is to buy some bare 328p chips,
>>> and flash them without tatching the lock bits.
>> 
>> If fuses and "lock bits" refer to the same thing, then
>> no: "bare chips" and arduino boards are different things.
>> I personally use the following settings on arduino "duemilanove" 
>> and "uno" boards
>> 
>> MCU=atmega328p
>> # set the fuses according to your MCU
>> LFUSE=0xFF
>> HFUSE=0xD9
>> # some MCU have this one, see write-fuses target below
>> EFUSE=0x05
>> 
>> The bare chips will run on the internal RC oszillator at 1 (or 
>> 8?) MHz, they will ignore the attached crystal, unless you 
>> correct the fuse bits.
>> 
>> 
>> There is a "readme.txt" file in the directory appl/arduino with 
>> more information on arduinos.
>> 
>> And just to make sure: you are aware, that flashing amforth to 
>> an arduino board does remove the arduino bootloader, are you?
>> 
>> 
>> Cheers,
>> Erich
>> 
> 
> Yes, those settings work ok with an Arduino Duemilanove (atmega328p). 
> 
> Here are  the command lines for Unix ( in my case OSX) and an usbtiny programmer: 
> 
> ===============================================================================
> avrdude -c usbtiny -p m328p -e -U flash:w:duemilanove.hex:i -U eeprom:w:duemilanove.eep.hex:i
> 
> avrdude -c usbtiny -p m328p -U 'lfuse:w:0xFF:m'
> avrdude -c usbtiny -p m328p -U 'hfuse:w:0xD9:m'
> avrdude -c usbtiny -p m328p -U 'efuse:w:0x05:m'
> 
> ===========================================================
> 
> Tested with three different arduinos!   ( just in case... )
> 
> 
> My best regards 
> Paulo Ferreira 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Paulo F. <pa...@ke...>]

On 2012/05/06, at 21:52, Jan Kromhout wrote:

> Thanks Paulo,
> 
> Could sommething going wrong with the burner?
> Can you give me a hint how to do this on the OSX.
> I have not yet the experiance. 
> 
> Cheers,
> 
> Jan kromhout
> Sacharovlaan 3
> 3223HM Hellevoetsluis-NL
> 

My preference goes to MacPorts: 
http://www.macports.org/

You need the Apple Developer tools and X11 installed and after installing Macports you can do on the command line things like: 

sudo port install avrdude


It downloads the sources, patches (if patches are needed), compiles and installs the software (avrdude in this case). 


It can do the same with: 

avarice @2.11 (cross)
    AVR JTAG-ICE control software

avr-binutils @2.22 (cross, devel)
    FSF Binutils for avr cross development

avr-gcc @4.7.0 (cross, devel)
    The GNU compiler collection for avr

avr-gdb @6.8 (cross)
    GDB for the AVR processors

avr-libc @1.8.0 (cross)
    C library for the AVR microcontroller.

uisp @20050207 (devel)
    AVR In-System Programmer

And for  'text mode" serial terminals you can have: 
  
minicom @2.5 (comms)
    Menu driven communications program

picocom @1.7 (comms)
    Minimal dumb-terminal emulation program

jerm @8095 (comms)
    communication terminal through serial and TCP/IP interfaces

kermit @9.0.302 (comms)
    Serial and network communications package.


My best regards 

Paulo Ferreira 



     

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Thank,

I need only avrdude, because I compile all in avr studio 5 under windows.
So I need only to transfer the hex files etc. with avrdude to my Arduino Uni.

I think that the problems occurs with flossing, because I get a "working" hex files from a member.
On his arduino it was working.
So I will try to flash it from my Mac OSX.

Best regards,

Jan
Op 6 mei 2012, om 23:24 heeft Paulo Ferreira het volgende geschreven:

> 
> On 2012/05/06, at 21:52, Jan Kromhout wrote:
> 
>> Thanks Paulo,
>> 
>> Could sommething going wrong with the burner?
>> Can you give me a hint how to do this on the OSX.
>> I have not yet the experiance. 
>> 
>> Cheers,
>> 
>> Jan kromhout
>> Sacharovlaan 3
>> 3223HM Hellevoetsluis-NL
>> 
> 
> My preference goes to MacPorts: 
> http://www.macports.org/
> 
> You need the Apple Developer tools and X11 installed and after installing Macports you can do on the command line things like: 
> 
> sudo port install avrdude
> 
> 
> It downloads the sources, patches (if patches are needed), compiles and installs the software (avrdude in this case). 
> 
> 
> It can do the same with: 
> 
> avarice @2.11 (cross)
>    AVR JTAG-ICE control software
> 
> avr-binutils @2.22 (cross, devel)
>    FSF Binutils for avr cross development
> 
> avr-gcc @4.7.0 (cross, devel)
>    The GNU compiler collection for avr
> 
> avr-gdb @6.8 (cross)
>    GDB for the AVR processors
> 
> avr-libc @1.8.0 (cross)
>    C library for the AVR microcontroller.
> 
> uisp @20050207 (devel)
>    AVR In-System Programmer
> 
> And for  'text mode" serial terminals you can have: 
> 
> minicom @2.5 (comms)
>    Menu driven communications program
> 
> picocom @1.7 (comms)
>    Minimal dumb-terminal emulation program
> 
> jerm @8095 (comms)
>    communication terminal through serial and TCP/IP interfaces
> 
> kermit @9.0.302 (comms)
>    Serial and network communications package.
> 
> 
> My best regards 
> 
> Paulo Ferreira 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Hello,

Thanks to all people how have response to my questions.
I have now a running system.

Special tanks to Chuck and Paulo.

I have put the hex files and store them into the directory of avrdude under the arduino.

Flashed to the Arduino under the OSX, and voila a working AMForth.

Try the same under windows XP and without any error message, nu running AMForth.

Cheers,

Jan


Op 6 mei 2012, om 22:52 heeft Jan Kromhout het volgende geschreven:

> Thanks Paulo,
> 
> Could sommething going wrong with the burner?
> Can you give me a hint how to do this on the OSX.
> I have not yet the experiance. 
> 
> Cheers,
> 
> Jan kromhout
> Sacharovlaan 3
> 3223HM Hellevoetsluis-NL
> 
> Op 6 mei 2012 om 22:27 heeft Paulo Ferreira <pa...@ke...> het volgende geschreven:
> 
>> 
>> On 2012/05/06, at 20:00, Erich Waelde wrote:
>> 
>>> Hello,
>>> 
>>> On 05/06/2012 08:12 PM, Jan Kromhout wrote:
>>>> 
>>>> If I understand correctly the best is to buy some bare 328p chips,
>>>> and flash them without tatching the lock bits.
>>> 
>>> If fuses and "lock bits" refer to the same thing, then
>>> no: "bare chips" and arduino boards are different things.
>>> I personally use the following settings on arduino "duemilanove" 
>>> and "uno" boards
>>> 
>>> MCU=atmega328p
>>> # set the fuses according to your MCU
>>> LFUSE=0xFF
>>> HFUSE=0xD9
>>> # some MCU have this one, see write-fuses target below
>>> EFUSE=0x05
>>> 
>>> The bare chips will run on the internal RC oszillator at 1 (or 
>>> 8?) MHz, they will ignore the attached crystal, unless you 
>>> correct the fuse bits.
>>> 
>>> 
>>> There is a "readme.txt" file in the directory appl/arduino with 
>>> more information on arduinos.
>>> 
>>> And just to make sure: you are aware, that flashing amforth to 
>>> an arduino board does remove the arduino bootloader, are you?
>>> 
>>> 
>>> Cheers,
>>> Erich
>>> 
>> 
>> Yes, those settings work ok with an Arduino Duemilanove (atmega328p). 
>> 
>> Here are  the command lines for Unix ( in my case OSX) and an usbtiny programmer: 
>> 
>> ===============================================================================
>> avrdude -c usbtiny -p m328p -e -U flash:w:duemilanove.hex:i -U eeprom:w:duemilanove.eep.hex:i
>> 
>> avrdude -c usbtiny -p m328p -U 'lfuse:w:0xFF:m'
>> avrdude -c usbtiny -p m328p -U 'hfuse:w:0xD9:m'
>> avrdude -c usbtiny -p m328p -U 'efuse:w:0x05:m'
>> 
>> ===========================================================
>> 
>> Tested with three different arduinos!   ( just in case... )
>> 
>> 
>> My best regards 
>> Paulo Ferreira 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Charles S. <sum...@gm...>]

Hi Jan,
Great to hear that you've got amForth running!
I'm a software QA guy in real life, so I'd be very interested in seeing the
steps you took on Windows tat did NOT work and the steps you took on OSX
that DID work. It might save others from a similar fate :)
cheers,
-chuck

On Mon, May 7, 2012 at 5:40 AM, Jan Kromhout <kro...@ho...> wrote:

> Hello,
>
> Thanks to all people how have response to my questions.
> I have now a running system.
>
> Special tanks to Chuck and Paulo.
>
> I have put the hex files and store them into the directory of avrdude
> under the arduino.
>
> Flashed to the Arduino under the OSX, and voila a working AMForth.
>
> Try the same under windows XP and without any error message, nu running
> AMForth.
>
> Cheers,
>
> Jan
>
>
> Op 6 mei 2012, om 22:52 heeft Jan Kromhout het volgende geschreven:
>
> > Thanks Paulo,
> >
> > Could sommething going wrong with the burner?
> > Can you give me a hint how to do this on the OSX.
> > I have not yet the experiance.
> >
> > Cheers,
> >
> > Jan kromhout
> > Sacharovlaan 3
> > 3223HM Hellevoetsluis-NL
> >
> > Op 6 mei 2012 om 22:27 heeft Paulo Ferreira <pa...@ke...> het volgende
> geschreven:
> >
> >>
> >> On 2012/05/06, at 20:00, Erich Waelde wrote:
> >>
> >>> Hello,
> >>>
> >>> On 05/06/2012 08:12 PM, Jan Kromhout wrote:
> >>>>
> >>>> If I understand correctly the best is to buy some bare 328p chips,
> >>>> and flash them without tatching the lock bits.
> >>>
> >>> If fuses and "lock bits" refer to the same thing, then
> >>> no: "bare chips" and arduino boards are different things.
> >>> I personally use the following settings on arduino "duemilanove"
> >>> and "uno" boards
> >>>
> >>> MCU=atmega328p
> >>> # set the fuses according to your MCU
> >>> LFUSE=0xFF
> >>> HFUSE=0xD9
> >>> # some MCU have this one, see write-fuses target below
> >>> EFUSE=0x05
> >>>
> >>> The bare chips will run on the internal RC oszillator at 1 (or
> >>> 8?) MHz, they will ignore the attached crystal, unless you
> >>> correct the fuse bits.
> >>>
> >>>
> >>> There is a "readme.txt" file in the directory appl/arduino with
> >>> more information on arduinos.
> >>>
> >>> And just to make sure: you are aware, that flashing amforth to
> >>> an arduino board does remove the arduino bootloader, are you?
> >>>
> >>>
> >>> Cheers,
> >>> Erich
> >>>
> >>
> >> Yes, those settings work ok with an Arduino Duemilanove (atmega328p).
> >>
> >> Here are  the command lines for Unix ( in my case OSX) and an usbtiny
> programmer:
> >>
> >>
> ===============================================================================
> >> avrdude -c usbtiny -p m328p -e -U flash:w:duemilanove.hex:i -U
> eeprom:w:duemilanove.eep.hex:i
> >>
> >> avrdude -c usbtiny -p m328p -U 'lfuse:w:0xFF:m'
> >> avrdude -c usbtiny -p m328p -U 'hfuse:w:0xD9:m'
> >> avrdude -c usbtiny -p m328p -U 'efuse:w:0x05:m'
> >>
> >> ===========================================================
> >>
> >> Tested with three different arduinos!   ( just in case... )
> >>
> >>
> >> My best regards
> >> Paulo Ferreira
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Live Security Virtual Conference
> >> Exclusive live event will cover all the ways today's security and
> >> threat landscape has changed and how IT managers can respond.
> Discussions
> >> will include endpoint security, mobile security and the latest in
> malware
> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >> _______________________________________________
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amf...@li...
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>



-- 
-chuck
* This sig intentionally left blank *

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Hi Chuck

I am glad that the problem is solved.
I am not in real time a programmer but a mechanical engineer who is writing optimization tools for dispatching powerplants.
But my hobby is electronics, and the arduino.

Cheers,

Jan

Jan kromhout
Sacharovlaan 3
3223HM Hellevoetsluis-NL

Op 7 mei 2012 om 14:27 heeft Charles Summers <sum...@gm...> het volgende geschreven:

> Hi Jan,
> Great to hear that you've got amForth running!
> I'm a software QA guy in real life, so I'd be very interested in seeing the
> steps you took on Windows tat did NOT work and the steps you took on OSX
> that DID work. It might save others from a similar fate :)
> cheers,
> -chuck
> 
> On Mon, May 7, 2012 at 5:40 AM, Jan Kromhout <kro...@ho...> wrote:
> 
>> Hello,
>> 
>> Thanks to all people how have response to my questions.
>> I have now a running system.
>> 
>> Special tanks to Chuck and Paulo.
>> 
>> I have put the hex files and store them into the directory of avrdude
>> under the arduino.
>> 
>> Flashed to the Arduino under the OSX, and voila a working AMForth.
>> 
>> Try the same under windows XP and without any error message, nu running
>> AMForth.
>> 
>> Cheers,
>> 
>> Jan
>> 
>> 
>> Op 6 mei 2012, om 22:52 heeft Jan Kromhout het volgende geschreven:
>> 
>>> Thanks Paulo,
>>> 
>>> Could sommething going wrong with the burner?
>>> Can you give me a hint how to do this on the OSX.
>>> I have not yet the experiance.
>>> 
>>> Cheers,
>>> 
>>> Jan kromhout
>>> Sacharovlaan 3
>>> 3223HM Hellevoetsluis-NL
>>> 
>>> Op 6 mei 2012 om 22:27 heeft Paulo Ferreira <pa...@ke...> het volgende
>> geschreven:
>>> 
>>>> 
>>>> On 2012/05/06, at 20:00, Erich Waelde wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> On 05/06/2012 08:12 PM, Jan Kromhout wrote:
>>>>>> 
>>>>>> If I understand correctly the best is to buy some bare 328p chips,
>>>>>> and flash them without tatching the lock bits.
>>>>> 
>>>>> If fuses and "lock bits" refer to the same thing, then
>>>>> no: "bare chips" and arduino boards are different things.
>>>>> I personally use the following settings on arduino "duemilanove"
>>>>> and "uno" boards
>>>>> 
>>>>> MCU=atmega328p
>>>>> # set the fuses according to your MCU
>>>>> LFUSE=0xFF
>>>>> HFUSE=0xD9
>>>>> # some MCU have this one, see write-fuses target below
>>>>> EFUSE=0x05
>>>>> 
>>>>> The bare chips will run on the internal RC oszillator at 1 (or
>>>>> 8?) MHz, they will ignore the attached crystal, unless you
>>>>> correct the fuse bits.
>>>>> 
>>>>> 
>>>>> There is a "readme.txt" file in the directory appl/arduino with
>>>>> more information on arduinos.
>>>>> 
>>>>> And just to make sure: you are aware, that flashing amforth to
>>>>> an arduino board does remove the arduino bootloader, are you?
>>>>> 
>>>>> 
>>>>> Cheers,
>>>>> Erich
>>>>> 
>>>> 
>>>> Yes, those settings work ok with an Arduino Duemilanove (atmega328p).
>>>> 
>>>> Here are  the command lines for Unix ( in my case OSX) and an usbtiny
>> programmer:
>>>> 
>>>> 
>> ===============================================================================
>>>> avrdude -c usbtiny -p m328p -e -U flash:w:duemilanove.hex:i -U
>> eeprom:w:duemilanove.eep.hex:i
>>>> 
>>>> avrdude -c usbtiny -p m328p -U 'lfuse:w:0xFF:m'
>>>> avrdude -c usbtiny -p m328p -U 'hfuse:w:0xD9:m'
>>>> avrdude -c usbtiny -p m328p -U 'efuse:w:0x05:m'
>>>> 
>>>> ===========================================================
>>>> 
>>>> Tested with three different arduinos!   ( just in case... )
>>>> 
>>>> 
>>>> My best regards
>>>> Paulo Ferreira
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>> malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Amforth-devel mailing list for http://amforth.sf.net/
>>>> Amf...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> 
>>> 
>>> 
>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> 
> 
> 
> 
> -- 
> -chuck
> * This sig intentionally left blank *
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Charles S. <sum...@gm...>]

You did very well in working through the problem. I'm thrilled that you've
got things running now.
Don't hesitate to ask me anything you think I might be able to help you
with. I will probably ask you some questions in the near future on running
fig-forth on the microKim ;)
cheers,
-chuck

On Mon, May 7, 2012 at 8:54 AM, Jan Kromhout <kro...@ho...> wrote:

> Hi Chuck
>
> I am glad that the problem is solved.
> I am not in real time a programmer but a mechanical engineer who is
> writing optimization tools for dispatching powerplants.
> But my hobby is electronics, and the arduino.
>
> Cheers,
>
> Jan
>
> Jan kromhout
> Sacharovlaan 3
> 3223HM Hellevoetsluis-NL
>
> Op 7 mei 2012 om 14:27 heeft Charles Summers <sum...@gm...>
> het volgende geschreven:
>
> > Hi Jan,
> > Great to hear that you've got amForth running!
> > I'm a software QA guy in real life, so I'd be very interested in seeing
> the
> > steps you took on Windows tat did NOT work and the steps you took on OSX
> > that DID work. It might save others from a similar fate :)
> > cheers,
> > -chuck
> >
> > On Mon, May 7, 2012 at 5:40 AM, Jan Kromhout <kro...@ho...>
> wrote:
> >
> >> Hello,
> >>
> >> Thanks to all people how have response to my questions.
> >> I have now a running system.
> >>
> >> Special tanks to Chuck and Paulo.
> >>
> >> I have put the hex files and store them into the directory of avrdude
> >> under the arduino.
> >>
> >> Flashed to the Arduino under the OSX, and voila a working AMForth.
> >>
> >> Try the same under windows XP and without any error message, nu running
> >> AMForth.
> >>
> >> Cheers,
> >>
> >> Jan
> >>
> >>
> >> Op 6 mei 2012, om 22:52 heeft Jan Kromhout het volgende geschreven:
> >>
> >>> Thanks Paulo,
> >>>
> >>> Could sommething going wrong with the burner?
> >>> Can you give me a hint how to do this on the OSX.
> >>> I have not yet the experiance.
> >>>
> >>> Cheers,
> >>>
> >>> Jan kromhout
> >>> Sacharovlaan 3
> >>> 3223HM Hellevoetsluis-NL
> >>>
> >>> Op 6 mei 2012 om 22:27 heeft Paulo Ferreira <pa...@ke...> het
> volgende
> >> geschreven:
> >>>
> >>>>
> >>>> On 2012/05/06, at 20:00, Erich Waelde wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> On 05/06/2012 08:12 PM, Jan Kromhout wrote:
> >>>>>>
> >>>>>> If I understand correctly the best is to buy some bare 328p chips,
> >>>>>> and flash them without tatching the lock bits.
> >>>>>
> >>>>> If fuses and "lock bits" refer to the same thing, then
> >>>>> no: "bare chips" and arduino boards are different things.
> >>>>> I personally use the following settings on arduino "duemilanove"
> >>>>> and "uno" boards
> >>>>>
> >>>>> MCU=atmega328p
> >>>>> # set the fuses according to your MCU
> >>>>> LFUSE=0xFF
> >>>>> HFUSE=0xD9
> >>>>> # some MCU have this one, see write-fuses target below
> >>>>> EFUSE=0x05
> >>>>>
> >>>>> The bare chips will run on the internal RC oszillator at 1 (or
> >>>>> 8?) MHz, they will ignore the attached crystal, unless you
> >>>>> correct the fuse bits.
> >>>>>
> >>>>>
> >>>>> There is a "readme.txt" file in the directory appl/arduino with
> >>>>> more information on arduinos.
> >>>>>
> >>>>> And just to make sure: you are aware, that flashing amforth to
> >>>>> an arduino board does remove the arduino bootloader, are you?
> >>>>>
> >>>>>
> >>>>> Cheers,
> >>>>> Erich
> >>>>>
> >>>>
> >>>> Yes, those settings work ok with an Arduino Duemilanove (atmega328p).
> >>>>
> >>>> Here are  the command lines for Unix ( in my case OSX) and an usbtiny
> >> programmer:
> >>>>
> >>>>
> >>
> ===============================================================================
> >>>> avrdude -c usbtiny -p m328p -e -U flash:w:duemilanove.hex:i -U
> >> eeprom:w:duemilanove.eep.hex:i
> >>>>
> >>>> avrdude -c usbtiny -p m328p -U 'lfuse:w:0xFF:m'
> >>>> avrdude -c usbtiny -p m328p -U 'hfuse:w:0xD9:m'
> >>>> avrdude -c usbtiny -p m328p -U 'efuse:w:0x05:m'
> >>>>
> >>>> ===========================================================
> >>>>
> >>>> Tested with three different arduinos!   ( just in case... )
> >>>>
> >>>>
> >>>> My best regards
> >>>> Paulo Ferreira
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> ------------------------------------------------------------------------------
> >>>> Live Security Virtual Conference
> >>>> Exclusive live event will cover all the ways today's security and
> >>>> threat landscape has changed and how IT managers can respond.
> >> Discussions
> >>>> will include endpoint security, mobile security and the latest in
> >> malware
> >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >>>> _______________________________________________
> >>>> Amforth-devel mailing list for http://amforth.sf.net/
> >>>> Amf...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>>
> >>>
> >>>
> >>
> ------------------------------------------------------------------------------
> >>> Live Security Virtual Conference
> >>> Exclusive live event will cover all the ways today's security and
> >>> threat landscape has changed and how IT managers can respond.
> Discussions
> >>> will include endpoint security, mobile security and the latest in
> malware
> >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >>> _______________________________________________
> >>> Amforth-devel mailing list for http://amforth.sf.net/
> >>> Amf...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Live Security Virtual Conference
> >> Exclusive live event will cover all the ways today's security and
> >> threat landscape has changed and how IT managers can respond.
> Discussions
> >> will include endpoint security, mobile security and the latest in
> malware
> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >> _______________________________________________
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amf...@li...
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>
> >
> >
> >
> > --
> > -chuck
> > * This sig intentionally left blank *
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>



-- 
-chuck
* This sig intentionally left blank *

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Chuck,

When I won't to run at a higher baud rate should I compile again?

Jan


Op 7 mei 2012, om 15:57 heeft Charles Summers het volgende geschreven:

> You did very well in working through the problem. I'm thrilled that you've
> got things running now.
> Don't hesitate to ask me anything you think I might be able to help you
> with. I will probably ask you some questions in the near future on running
> fig-forth on the microKim ;)
> cheers,
> -chuck
> 
> On Mon, May 7, 2012 at 8:54 AM, Jan Kromhout <kro...@ho...> wrote:
> 
>> Hi Chuck
>> 
>> I am glad that the problem is solved.
>> I am not in real time a programmer but a mechanical engineer who is
>> writing optimization tools for dispatching powerplants.
>> But my hobby is electronics, and the arduino.
>> 
>> Cheers,
>> 
>> Jan
>> 
>> Jan kromhout
>> Sacharovlaan 3
>> 3223HM Hellevoetsluis-NL
>> 
>> Op 7 mei 2012 om 14:27 heeft Charles Summers <sum...@gm...>
>> het volgende geschreven:
>> 
>>> Hi Jan,
>>> Great to hear that you've got amForth running!
>>> I'm a software QA guy in real life, so I'd be very interested in seeing
>> the
>>> steps you took on Windows tat did NOT work and the steps you took on OSX
>>> that DID work. It might save others from a similar fate :)
>>> cheers,
>>> -chuck
>>> 
>>> On Mon, May 7, 2012 at 5:40 AM, Jan Kromhout <kro...@ho...>
>> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> Thanks to all people how have response to my questions.
>>>> I have now a running system.
>>>> 
>>>> Special tanks to Chuck and Paulo.
>>>> 
>>>> I have put the hex files and store them into the directory of avrdude
>>>> under the arduino.
>>>> 
>>>> Flashed to the Arduino under the OSX, and voila a working AMForth.
>>>> 
>>>> Try the same under windows XP and without any error message, nu running
>>>> AMForth.
>>>> 
>>>> Cheers,
>>>> 
>>>> Jan
>>>> 
>>>> 
>>>> Op 6 mei 2012, om 22:52 heeft Jan Kromhout het volgende geschreven:
>>>> 
>>>>> Thanks Paulo,
>>>>> 
>>>>> Could sommething going wrong with the burner?
>>>>> Can you give me a hint how to do this on the OSX.
>>>>> I have not yet the experiance.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Jan kromhout
>>>>> Sacharovlaan 3
>>>>> 3223HM Hellevoetsluis-NL
>>>>> 
>>>>> Op 6 mei 2012 om 22:27 heeft Paulo Ferreira <pa...@ke...> het
>> volgende
>>>> geschreven:
>>>>> 
>>>>>> 
>>>>>> On 2012/05/06, at 20:00, Erich Waelde wrote:
>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> On 05/06/2012 08:12 PM, Jan Kromhout wrote:
>>>>>>>> 
>>>>>>>> If I understand correctly the best is to buy some bare 328p chips,
>>>>>>>> and flash them without tatching the lock bits.
>>>>>>> 
>>>>>>> If fuses and "lock bits" refer to the same thing, then
>>>>>>> no: "bare chips" and arduino boards are different things.
>>>>>>> I personally use the following settings on arduino "duemilanove"
>>>>>>> and "uno" boards
>>>>>>> 
>>>>>>> MCU=atmega328p
>>>>>>> # set the fuses according to your MCU
>>>>>>> LFUSE=0xFF
>>>>>>> HFUSE=0xD9
>>>>>>> # some MCU have this one, see write-fuses target below
>>>>>>> EFUSE=0x05
>>>>>>> 
>>>>>>> The bare chips will run on the internal RC oszillator at 1 (or
>>>>>>> 8?) MHz, they will ignore the attached crystal, unless you
>>>>>>> correct the fuse bits.
>>>>>>> 
>>>>>>> 
>>>>>>> There is a "readme.txt" file in the directory appl/arduino with
>>>>>>> more information on arduinos.
>>>>>>> 
>>>>>>> And just to make sure: you are aware, that flashing amforth to
>>>>>>> an arduino board does remove the arduino bootloader, are you?
>>>>>>> 
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Erich
>>>>>>> 
>>>>>> 
>>>>>> Yes, those settings work ok with an Arduino Duemilanove (atmega328p).
>>>>>> 
>>>>>> Here are  the command lines for Unix ( in my case OSX) and an usbtiny
>>>> programmer:
>>>>>> 
>>>>>> 
>>>> 
>> ===============================================================================
>>>>>> avrdude -c usbtiny -p m328p -e -U flash:w:duemilanove.hex:i -U
>>>> eeprom:w:duemilanove.eep.hex:i
>>>>>> 
>>>>>> avrdude -c usbtiny -p m328p -U 'lfuse:w:0xFF:m'
>>>>>> avrdude -c usbtiny -p m328p -U 'hfuse:w:0xD9:m'
>>>>>> avrdude -c usbtiny -p m328p -U 'efuse:w:0x05:m'
>>>>>> 
>>>>>> ===========================================================
>>>>>> 
>>>>>> Tested with three different arduinos!   ( just in case... )
>>>>>> 
>>>>>> 
>>>>>> My best regards
>>>>>> Paulo Ferreira
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond.
>>>> Discussions
>>>>>> will include endpoint security, mobile security and the latest in
>>>> malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Amforth-devel mailing list for http://amforth.sf.net/
>>>>>> Amf...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond.
>> Discussions
>>>>> will include endpoint security, mobile security and the latest in
>> malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Amforth-devel mailing list for http://amforth.sf.net/
>>>>> Amf...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>> malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Amforth-devel mailing list for http://amforth.sf.net/
>>>> Amf...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> -chuck
>>> * This sig intentionally left blank *
>>> 
>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> 
> 
> 
> 
> -- 
> -chuck
> * This sig intentionally left blank *
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

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

Hello Jan,

On 05/07/2012 04:29 PM, Jan Kromhout wrote:
> When I won't to run at a higher baud rate should I compile again?

Yes, when you want to change the baudrate, you need to edit your 
duemilanove.asm file

.equ BAUD = 9600


reassemble amforth and flash it onto the controller again.

Cheers,
Erich

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

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

Hi Jan,

> Chuck,
> 
> When I won't to run at a higher baud rate should I compile again?

That would probably be the easiest way.

Technically it is not needed however. The serial
settings come from the VALUE baud (check with e.g.

 \ I use 38400 instead of 9600
 amforth 4.9 ATmega1284P 16000 kHz
 > baud u.
 25  ok
 >
). The initial value is calculated at compile time
but nothing prevents you from changing it at runtime.

The two bytes from this value are written literally
into the baudrate registers at startup (e.g. COLD),
thus the name of the value "BAUD" is somewhat
misleading. The datasheets have a rather big table
for some cpu frequencies and baud rates. The compile
time calculation is done in the file
core/amforth-eeprom.inc An untested forth snippet is
in lib/misc.frt

The steps are
1) get the new settings (e.g. from datasheet)
2) store them into BAUD
3) reset the controller (COLD)
4) reconfigure your terminal

If you write to the baud rate registers directly (its
not rocket science, after all), you can even change
the settings on the fly. You should use one command line
for both bytes however with the order high-byte
low-byte (again: datasheet).

Matthias
PS: Is there someone who wants to implement auto-baud?

[Amforth] AVR online baudrate calculator

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

FYI - AVR baud calculator

http://www.wormfood.net/avrbaudcalc.php?postbitrate=9600&postclock=11.0592


----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth] Issues with a word compile - flash or eeprom
Datum: 7.5.2012 - 21:14:08

> Hi Jan,
> 
> > Chuck,
> > 
> > When I won't to run at a higher baud rate should
> > I compile again?
> > 
> That would probably be the easiest way.
> 
> Technically it is not needed however. The serial
> settings come from the VALUE baud (check with e.g.
> 
> \ I use 38400 instead of 9600
> amforth 4.9 ATmega1284P 16000 kHz
> > baud u.
> 25  ok
> >
> ). The initial value is calculated at compile time
> but nothing prevents you from changing it at
> runtime.
> 
> The two bytes from this value are written
> literally
> into the baudrate registers at startup (e.g.
> COLD),
> thus the name of the value "BAUD" is somewhat
> misleading. The datasheets have a rather big table
> for some cpu frequencies and baud rates. The
> compile
> time calculation is done in the file
> core/amforth-eeprom.inc An untested forth snippet
> is
> in lib/misc.frt
> 
> The steps are
> 1) get the new settings (e.g. from datasheet)
> 2) store them into BAUD
> 3) reset the controller (COLD)
> 4) reconfigure your terminal
> 
> If you write to the baud rate registers directly
> (its
> not rocket science, after all), you can even
> change
> the settings on the fly. You should use one
> command line
> for both bytes however with the order high-byte
> low-byte (again: datasheet).
> 
> Matthias
> PS: Is there someone who wants to implement
> auto-baud?
> 
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> Exclusive live event will cover all the ways
> today's security and 
> threat landscape has changed and how IT managers
> can respond. Discussions 
> will include endpoint security, mobile security
> and the latest in malware 
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for
> http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>