amforth-devel — Development discussion and user support

Re: [Amforth] Finding files

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

Hi,

when I look for a definition, a recursive grep is my best
friend, it is fed with the usual colon definition ": <name> " 
including proper whitespace. It's not completly foolproof
but works most the time

$:~/amforth$ grep -ri ": \.s " *
common/lib/forth2012/tools/dot-s.frt:: .s depth 0 ?do depth i - 1- pick
. loop ;
doc/TG/source/TG/recipes/Dumps.rst:   : .s  ( -- ) 

this works for other forth's as well.

HTH Matthias

Am Montag, den 22.10.2018, 13:17 +0000 schrieb Jan Kromhout:
> Hello,
> 
> Where can I find the definition files of the words “SEE, .S, DUMP”
> 
> Cheers
> 
> Jan
> 
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Finding files

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

Hello,

Where can I find the definition files of the words “SEE, .S, DUMP”

Cheers

Jan

Re: [Amforth] 16/32 Bit Fetch & Store.

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

Am Freitag, den 19.10.2018, 14:46 +0200 schrieb Tristan:
> Hello Martin,
> 
> Very intriguing, just when I am away from my machine so I can’t test
> things out!
> 
> If I remember correctly, the default Amforth avr build uses (rx,tx)
> interrupts to handle the serial prompt. If at the serial prompt I
> type in the word -int and “all” -int did was to issue the assembler
> cli instruction I should lose my serial prompt. I can’t check now but
> if the serial prompt does not disappear then there is other machinery
> at work. 

It depends. Serial send (TX) is since long not interrupt driven. It
works even with disabled interrupts. Receiving is usually interrupt
driven, but can be configured to a polling code. It has 2 advantages:
smaller code and works almost always. The disadvantage is, that 
characters may be lost if they arrive too fast. 

The non-avr platforms are all non-interrupt based.

Matthias

PS: nice discussions this week :=)

Re: [Amforth] Setting of the fuses Arduino Ono

[Dimitri G. <dg...@bi...>]

It's a bit more complicated. avrdude switches values between fuses when
reporting them (bug?) and when you see 0x07 where you expect to see 0xFF at
the extended fuse that's okay (at least for atmega 328p). You only need to
change lfuse into 0xE2 to disable downscaling to 1MHz and leave the rest at
default.

Here's a useful page: http://www.engbedded.com/fusecalc
Example, choose Atmega328p from the pull down menu, uncheck "divide clock
by 8" and you get the right fuse values including the story about the
0x07/0xFF.

rgds



On Tue, Oct 16, 2018 at 10:01 PM John Verne <joh...@gm...> wrote:

> Oh, wait. My last response is just going to add to the confusion. Sorry
> about that.
>
> Are you sure you have the fuse settings right in your command line? Have
> you swapped efuse and lfuse by accident in that command line?
>
> I would expect efuse to be 0xFF, which is the default. 0x05 doesn't really
> make sense, but does set a brown-out detector level -- which is true for
> 0xFD as well.
>
> The hfuse at 0xD9 is the default, and can be the most dangerous to change.
> Consider this an expert setting.
>
> lfuse is the one we usually want to change (unless tweaking brownout
> detection or debugging). This is the one where we set clock speed and
> oscillator source and so on, and is the one I usually customize. This
> should not be 0xFF unless you want to run at 1MHz instead of 8MHz. This is
> the one that is usually at 0x05 or 0x62.
>
> Double check your Makefile or the command you are typing in, and make sure
> you have't swapped the efuse and lfuse values.
>
> On Tue, 16 Oct 2018 at 14:56, Jan Kromhout <kro...@ho...> wrote:
>
> > When loading AmForth into my Arduino Uno  I get an error on the end.
> > My question is what to do in that case?
> > Are my settings of the fuse one?
> >
> > Cheers,
> >
> > Jan
> >
> >
> > avrdude: verifying ...
> > avrdude: verification error, first mismatch at byte 0x0000
> >          0xfd != 0x05
> > avrdude: verification error; content mismatch
> >
> > avrdude: safemode: efuse changed! Was 5, and is now fd
> > Would you like this fuse to be changed back? [y/n] n
> > avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
> >
> > My question is what to do in that situation?
> >
> >
> >
> >
> >
> > MacBook-Pro-van-Jan-5:avrdude jankromhout$ avrdude -P
> > /dev/tty.usbmodem00230362 -c avrispv2 -b 19200 -p m328p -e -U
> > flash:w:uno.hex:i -U eeprom:w:uno.eep.hex:i -U efuse:w:0x05:m -U
> > hfuse:w:0xD9:m -U lfuse:w:0xFF:m
> >
> > avrdude: AVR device initialized and ready to accept instructions
> >
> > Reading | ################################################## | 100% 0.00s
> >
> > avrdude: Device signature = 0x1e950f (probably m328p)
> > avrdude: erasing chip
> > avrdude: reading input file "uno.hex"
> > avrdude: writing flash (32638 bytes):
> >
> > Writing | ################################################## | 100% 2.06s
> >
> > avrdude: 32638 bytes of flash written
> > avrdude: verifying flash memory against uno.hex:
> > avrdude: load data flash data from input file uno.hex:
> > avrdude: input file uno.hex contains 32638 bytes
> > avrdude: reading on-chip flash data:
> >
> > Reading | ################################################## | 100% 1.86s
> >
> > avrdude: verifying ...
> > avrdude: 32638 bytes of flash verified
> > avrdude: reading input file "uno.eep.hex"
> > avrdude: writing eeprom (144 bytes):
> >
> > Writing | ################################################## | 100% 0.06s
> >
> > avrdude: 144 bytes of eeprom written
> > avrdude: verifying eeprom memory against uno.eep.hex:
> > avrdude: load data eeprom data from input file uno.eep.hex:
> > avrdude: input file uno.eep.hex contains 144 bytes
> > avrdude: reading on-chip eeprom data:
> >
> > Reading | ################################################## | 100% 0.02s
> >
> > avrdude: verifying ...
> > avrdude: 144 bytes of eeprom verified
> > avrdude: reading input file "0x05"
> > avrdude: writing efuse (1 bytes):
> >
> > Writing | ################################################## | 100% 0.01s
> >
> > avrdude: 1 bytes of efuse written
> > avrdude: verifying efuse memory against 0x05:
> > avrdude: load data efuse data from input file 0x05:
> > avrdude: input file 0x05 contains 1 bytes
> > avrdude: reading on-chip efuse data:
> >
> > Reading | ################################################## | 100% 0.00s
> >
> > avrdude: verifying ...
> > avrdude: verification error, first mismatch at byte 0x0000
> >          0xfd != 0x05
> > avrdude: verification error; content mismatch
> >
> > avrdude: safemode: efuse changed! Was 5, and is now fd
> > Would you like this fuse to be changed back? [y/n] n
> > avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
> >
> > avrdude done.  Thank you.
> >
> > MacBook-Pro-van-Jan-5:avrdude jankromhout$
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
>
> --
>
>
> [image: --]
>
> John Verne
> [image: https://]about.me/jverne
> <https://about.me/jverne?promo=email_sig>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] 16/32 Bit Fetch & Store.

[Tristan <ho...@tj...>]

Hello Martin,

Very intriguing, just when I am away from my machine so I can’t test things out!

If I remember correctly, the default Amforth avr build uses (rx,tx) interrupts to handle the serial prompt. If at the serial prompt I type in the word -int and “all” -int did was to issue the assembler cli instruction I should lose my serial prompt. I can’t check now but if the serial prompt does not disappear then there is other machinery at work. 

Best wishes,
Tristan 

Sent from my iPhone

> On 19 Oct 2018, at 10:36, Martin Nicholas via Amforth-devel <amf...@li...> wrote:
> 
> On Wed, 17 Oct 2018 13:27:09 +0100
> Tristan Williams <ho...@tj...> wrote:
> 
>>> On 17Oct18 10:25, Martin Nicholas via Amforth-devel wrote:
>>> Hi,
>>> 
>>> I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR.
>>> Although it's possible to code around a variable being changed by an
>>> interrupt (using C@ C! for example), the 16-bit counter registers
>>> can't be dealt with in a similar way. Section 17.3 of the datasheet
>>> "Accessing 16-bit Registers" deals with all this. @ and ! do do the
>>> byte accesses in the right order, but an interrupt using the 16-bit
>>> registers associated with a particular counter will overwrite the
>>> "TEMP (8-bit)" register (see Figure 17-4).
>>> 
>>> Cheers!
>>> 
>>> 
>> 
>> Hello Martin,
>> 
>> This page http://amforth.sourceforge.net/TG/AVR8.html sets out how
>> AmForth handles interrupts and I think it is relevant to your post. 
>> 
>> Earlier this year I wrote some forth[1] that used the word 1ms and it
>> was not running as I expected. I had not realised that the execution
>> of AmForth words written in assembler would not be interrupted. @ ! +!
>> are assembler words and so will not be interrupted.
>> 
>> Tristan
>> 
>> [1]
>> https://sourceforge.net/p/amforth/mailman/amforth-devel/?viewmonth=201806
>> 
> 
> No, thie problem with 1ms is specific to 1ms. I suspect the tight inner
> loop is uninterruptable. It is:
>> sbiw  Z, 1
>> brne  pc-1
> 
> Interrupts are enabled at all times (by APPLTURNKEY) unless you
> specifically disable them.
> 
> Looking at the vanilla build at:
> amforth-6.7/appl/template/template.lst
> These words enable interrupts: +INT APPLTURNKEY.
> These disable: -INT.
> These temporarily disable interrupts: RP! !E @E (!I-NRWW). They are
> re-enabled before exit.
> That's it. Search for "cli" and "sei".
> 
> When I have time I'll test my theory about 1ms. Atmel documentation is
> no help on this, although there are dark hints in the documentation
> for BRNE.
> 
> Confirm interrupt status with:
> "hex 5f c@ ."
> 
> Cheers!
> 
> -- 
> Regards,
> 
> Martin Nicholas.
> 
> E-mail: mg...@mg....
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] 16/32 Bit Fetch & Store.

[Martin N. <amf...@mg...>]

On Wed, 17 Oct 2018 13:27:09 +0100
Tristan Williams <ho...@tj...> wrote:

> On 17Oct18 10:25, Martin Nicholas via Amforth-devel wrote:
> > Hi,
> > 
> > I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR.
> > Although it's possible to code around a variable being changed by an
> > interrupt (using C@ C! for example), the 16-bit counter registers
> > can't be dealt with in a similar way. Section 17.3 of the datasheet
> > "Accessing 16-bit Registers" deals with all this. @ and ! do do the
> > byte accesses in the right order, but an interrupt using the 16-bit
> > registers associated with a particular counter will overwrite the
> > "TEMP (8-bit)" register (see Figure 17-4).
> > 
> > Cheers!
> > 
> >   
> 
> Hello Martin,
> 
> This page http://amforth.sourceforge.net/TG/AVR8.html sets out how
> AmForth handles interrupts and I think it is relevant to your post. 
> 
> Earlier this year I wrote some forth[1] that used the word 1ms and it
> was not running as I expected. I had not realised that the execution
> of AmForth words written in assembler would not be interrupted. @ ! +!
> are assembler words and so will not be interrupted.
> 
> Tristan
> 
> [1]
> https://sourceforge.net/p/amforth/mailman/amforth-devel/?viewmonth=201806
> 

No, thie problem with 1ms is specific to 1ms. I suspect the tight inner
loop is uninterruptable. It is:
> sbiw  Z, 1
> brne  pc-1

Interrupts are enabled at all times (by APPLTURNKEY) unless you
specifically disable them.

Looking at the vanilla build at:
amforth-6.7/appl/template/template.lst
These words enable interrupts: +INT APPLTURNKEY.
These disable: -INT.
These temporarily disable interrupts: RP! !E @E (!I-NRWW). They are
re-enabled before exit.
That's it. Search for "cli" and "sei".

When I have time I'll test my theory about 1ms. Atmel documentation is
no help on this, although there are dark hints in the documentation
for BRNE.

Confirm interrupt status with:
"hex 5f c@ ."

Cheers!

-- 
Regards,

Martin Nicholas.

E-mail: mg...@mg....

Re: [Amforth] 16/32 Bit Fetch & Store.

[Tristan W. <ho...@tj...>]

On 17Oct18 10:25, Martin Nicholas via Amforth-devel wrote:
> Hi,
> 
> I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR.
> Although it's possible to code around a variable being changed by an
> interrupt (using C@ C! for example), the 16-bit counter registers can't
> be dealt with in a similar way. Section 17.3 of the datasheet
> "Accessing 16-bit Registers" deals with all this. @ and ! do do the byte
> accesses in the right order, but an interrupt using the 16-bit
> registers associated with a particular counter will overwrite the "TEMP
> (8-bit)" register (see Figure 17-4).
> 
> Cheers!
> 
> -- 
> Regards,
> 
> Martin Nicholas.
> 
> E-mail: rep...@mg...
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Hello Martin,

This page http://amforth.sourceforge.net/TG/AVR8.html sets out how
AmForth handles interrupts and I think it is relevant to your post. 

Earlier this year I wrote some forth[1] that used the word 1ms and it
was not running as I expected. I had not realised that the execution
of AmForth words written in assembler would not be interrupted. @ ! +!
are assembler words and so will not be interrupted.

Tristan

[1] https://sourceforge.net/p/amforth/mailman/amforth-devel/?viewmonth=201806

[Amforth] AVR Fuses

[Martin N. <amf...@mg...>]

Hi,

With "make install" the fuses are burnt after the flash, it's
possible the fuses are in such a state the the device is un-burnable.
Off-the-shelf parts (Arduinos and the like) are sometimes like this.

You can try burning the fuses first with: "make write-fuse" then
followed by "make install".

Maybe this should be considered a bug, maybe not.

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg...

[Amforth] 16/32 Bit Fetch & Store.

[Martin N. <amf...@mg...>]

Hi,

I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR.
Although it's possible to code around a variable being changed by an
interrupt (using C@ C! for example), the 16-bit counter registers can't
be dealt with in a similar way. Section 17.3 of the datasheet
"Accessing 16-bit Registers" deals with all this. @ and ! do do the byte
accesses in the right order, but an interrupt using the 16-bit
registers associated with a particular counter will overwrite the "TEMP
(8-bit)" register (see Figure 17-4).

Cheers!

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg...

Re: [Amforth] Setting of the fuses Arduino Ono

[Peter C. H. <Pet...@un...>]

Jan,

For the Arduino Uno we have been using the following command string successfully:

avrdude -p m328p -c avrispmkII -P usb -U efuse:w:0xFF:m -U hfuse:w:0xD9:m -U lfuse:w:0xFF:m -U flash:w:uno.hex:i -U eeprom:w:uno.eep.hex:i

Thus argument for efuse is set to FF instead of 05.  

The short explanation for this is a change inplemented in newer versions of AVRDude (something to do with how AVRDude reads back unused bits).  I had the same problem when I started with AMForth and it cost me a lot of time... 

Peter



> On 16 Oct 2018, at 20:56, Jan Kromhout <kro...@ho...> wrote:
> 
> When loading AmForth into my Arduino Uno  I get an error on the end.
> My question is what to do in that case?
> Are my settings of the fuse one?
> 
> Cheers,
> 
> Jan
> 
> 
> avrdude: verifying ...
> avrdude: verification error, first mismatch at byte 0x0000
>         0xfd != 0x05
> avrdude: verification error; content mismatch
> 
> avrdude: safemode: efuse changed! Was 5, and is now fd
> Would you like this fuse to be changed back? [y/n] n
> avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
> 
> My question is what to do in that situation?
> 
> 
> 
> 
> 
> MacBook-Pro-van-Jan-5:avrdude jankromhout$ avrdude -P /dev/tty.usbmodem00230362 -c avrispv2 -b 19200 -p m328p -e -U flash:w:uno.hex:i -U eeprom:w:uno.eep.hex:i -U efuse:w:0x05:m -U hfuse:w:0xD9:m -U lfuse:w:0xFF:m
> 
> avrdude: AVR device initialized and ready to accept instructions
> 
> Reading | ################################################## | 100% 0.00s
> 
> avrdude: Device signature = 0x1e950f (probably m328p)
> avrdude: erasing chip
> avrdude: reading input file "uno.hex"
> avrdude: writing flash (32638 bytes):
> 
> Writing | ################################################## | 100% 2.06s
> 
> avrdude: 32638 bytes of flash written
> avrdude: verifying flash memory against uno.hex:
> avrdude: load data flash data from input file uno.hex:
> avrdude: input file uno.hex contains 32638 bytes
> avrdude: reading on-chip flash data:
> 
> Reading | ################################################## | 100% 1.86s
> 
> avrdude: verifying ...
> avrdude: 32638 bytes of flash verified
> avrdude: reading input file "uno.eep.hex"
> avrdude: writing eeprom (144 bytes):
> 
> Writing | ################################################## | 100% 0.06s
> 
> avrdude: 144 bytes of eeprom written
> avrdude: verifying eeprom memory against uno.eep.hex:
> avrdude: load data eeprom data from input file uno.eep.hex:
> avrdude: input file uno.eep.hex contains 144 bytes
> avrdude: reading on-chip eeprom data:
> 
> Reading | ################################################## | 100% 0.02s
> 
> avrdude: verifying ...
> avrdude: 144 bytes of eeprom verified
> avrdude: reading input file "0x05"
> avrdude: writing efuse (1 bytes):
> 
> Writing | ################################################## | 100% 0.01s
> 
> avrdude: 1 bytes of efuse written
> avrdude: verifying efuse memory against 0x05:
> avrdude: load data efuse data from input file 0x05:
> avrdude: input file 0x05 contains 1 bytes
> avrdude: reading on-chip efuse data:
> 
> Reading | ################################################## | 100% 0.00s
> 
> avrdude: verifying ...
> avrdude: verification error, first mismatch at byte 0x0000
>         0xfd != 0x05
> avrdude: verification error; content mismatch
> 
> avrdude: safemode: efuse changed! Was 5, and is now fd
> Would you like this fuse to be changed back? [y/n] n
> avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
> 
> avrdude done.  Thank you.
> 
> MacBook-Pro-van-Jan-5:avrdude jankromhout$
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Coolterm on the Mac

[Peter C. H. <Pet...@un...>]

Jan,

By default CoolTerm starts up in the Raw mode, in which each character is sent as it is entered on the keyboard.   I presume when you hit the delete key it will be sent as a non-printable ASCII code. 

If you set CoolTerm to the Line mode (under Options / Terminal) you can then enter and edit individual lines before there are sent out.

Peter

> On 16 Oct 2018, at 20:21, Jan Kromhout <kro...@ho...> wrote:
> 
> Thanks Peter for the response.
> How do you have setup Coolterm?
> When I try to delete a character two dots are printed!
> 
> Thanks for any help.
> 
> Jan Kromhout
> Hellevoetsluis-NL
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Setting of the fuses Arduino Ono

[Dimitri G. <dg...@bi...>]

Default values I use are: lfuse = 0x62, hfuse = 0xDF, efuse = 0x01.
Highspeed mode: lfuse = 0xE2.

On Tue, Oct 16, 2018 at 10:01 PM John Verne <joh...@gm...> wrote:

> Oh, wait. My last response is just going to add to the confusion. Sorry
> about that.
>
> Are you sure you have the fuse settings right in your command line? Have
> you swapped efuse and lfuse by accident in that command line?
>
> I would expect efuse to be 0xFF, which is the default. 0x05 doesn't really
> make sense, but does set a brown-out detector level -- which is true for
> 0xFD as well.
>
> The hfuse at 0xD9 is the default, and can be the most dangerous to change.
> Consider this an expert setting.
>
> lfuse is the one we usually want to change (unless tweaking brownout
> detection or debugging). This is the one where we set clock speed and
> oscillator source and so on, and is the one I usually customize. This
> should not be 0xFF unless you want to run at 1MHz instead of 8MHz. This is
> the one that is usually at 0x05 or 0x62.
>
> Double check your Makefile or the command you are typing in, and make sure
> you have't swapped the efuse and lfuse values.
>
> On Tue, 16 Oct 2018 at 14:56, Jan Kromhout <kro...@ho...> wrote:
>
> > When loading AmForth into my Arduino Uno  I get an error on the end.
> > My question is what to do in that case?
> > Are my settings of the fuse one?
> >
> > Cheers,
> >
> > Jan
> >
> >
> > avrdude: verifying ...
> > avrdude: verification error, first mismatch at byte 0x0000
> >          0xfd != 0x05
> > avrdude: verification error; content mismatch
> >
> > avrdude: safemode: efuse changed! Was 5, and is now fd
> > Would you like this fuse to be changed back? [y/n] n
> > avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
> >
> > My question is what to do in that situation?
> >
> >
> >
> >
> >
> > MacBook-Pro-van-Jan-5:avrdude jankromhout$ avrdude -P
> > /dev/tty.usbmodem00230362 -c avrispv2 -b 19200 -p m328p -e -U
> > flash:w:uno.hex:i -U eeprom:w:uno.eep.hex:i -U efuse:w:0x05:m -U
> > hfuse:w:0xD9:m -U lfuse:w:0xFF:m
> >
> > avrdude: AVR device initialized and ready to accept instructions
> >
> > Reading | ################################################## | 100% 0.00s
> >
> > avrdude: Device signature = 0x1e950f (probably m328p)
> > avrdude: erasing chip
> > avrdude: reading input file "uno.hex"
> > avrdude: writing flash (32638 bytes):
> >
> > Writing | ################################################## | 100% 2.06s
> >
> > avrdude: 32638 bytes of flash written
> > avrdude: verifying flash memory against uno.hex:
> > avrdude: load data flash data from input file uno.hex:
> > avrdude: input file uno.hex contains 32638 bytes
> > avrdude: reading on-chip flash data:
> >
> > Reading | ################################################## | 100% 1.86s
> >
> > avrdude: verifying ...
> > avrdude: 32638 bytes of flash verified
> > avrdude: reading input file "uno.eep.hex"
> > avrdude: writing eeprom (144 bytes):
> >
> > Writing | ################################################## | 100% 0.06s
> >
> > avrdude: 144 bytes of eeprom written
> > avrdude: verifying eeprom memory against uno.eep.hex:
> > avrdude: load data eeprom data from input file uno.eep.hex:
> > avrdude: input file uno.eep.hex contains 144 bytes
> > avrdude: reading on-chip eeprom data:
> >
> > Reading | ################################################## | 100% 0.02s
> >
> > avrdude: verifying ...
> > avrdude: 144 bytes of eeprom verified
> > avrdude: reading input file "0x05"
> > avrdude: writing efuse (1 bytes):
> >
> > Writing | ################################################## | 100% 0.01s
> >
> > avrdude: 1 bytes of efuse written
> > avrdude: verifying efuse memory against 0x05:
> > avrdude: load data efuse data from input file 0x05:
> > avrdude: input file 0x05 contains 1 bytes
> > avrdude: reading on-chip efuse data:
> >
> > Reading | ################################################## | 100% 0.00s
> >
> > avrdude: verifying ...
> > avrdude: verification error, first mismatch at byte 0x0000
> >          0xfd != 0x05
> > avrdude: verification error; content mismatch
> >
> > avrdude: safemode: efuse changed! Was 5, and is now fd
> > Would you like this fuse to be changed back? [y/n] n
> > avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
> >
> > avrdude done.  Thank you.
> >
> > MacBook-Pro-van-Jan-5:avrdude jankromhout$
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
>
> --
>
>
> [image: --]
>
> John Verne
> [image: https://]about.me/jverne
> <https://about.me/jverne?promo=email_sig>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Setting of the fuses Arduino Ono

[John V. <joh...@gm...>]

Oh, wait. My last response is just going to add to the confusion. Sorry
about that.

Are you sure you have the fuse settings right in your command line? Have
you swapped efuse and lfuse by accident in that command line?

I would expect efuse to be 0xFF, which is the default. 0x05 doesn't really
make sense, but does set a brown-out detector level -- which is true for
0xFD as well.

The hfuse at 0xD9 is the default, and can be the most dangerous to change.
Consider this an expert setting.

lfuse is the one we usually want to change (unless tweaking brownout
detection or debugging). This is the one where we set clock speed and
oscillator source and so on, and is the one I usually customize. This
should not be 0xFF unless you want to run at 1MHz instead of 8MHz. This is
the one that is usually at 0x05 or 0x62.

Double check your Makefile or the command you are typing in, and make sure
you have't swapped the efuse and lfuse values.

On Tue, 16 Oct 2018 at 14:56, Jan Kromhout <kro...@ho...> wrote:

> When loading AmForth into my Arduino Uno  I get an error on the end.
> My question is what to do in that case?
> Are my settings of the fuse one?
>
> Cheers,
>
> Jan
>
>
> avrdude: verifying ...
> avrdude: verification error, first mismatch at byte 0x0000
>          0xfd != 0x05
> avrdude: verification error; content mismatch
>
> avrdude: safemode: efuse changed! Was 5, and is now fd
> Would you like this fuse to be changed back? [y/n] n
> avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
>
> My question is what to do in that situation?
>
>
>
>
>
> MacBook-Pro-van-Jan-5:avrdude jankromhout$ avrdude -P
> /dev/tty.usbmodem00230362 -c avrispv2 -b 19200 -p m328p -e -U
> flash:w:uno.hex:i -U eeprom:w:uno.eep.hex:i -U efuse:w:0x05:m -U
> hfuse:w:0xD9:m -U lfuse:w:0xFF:m
>
> avrdude: AVR device initialized and ready to accept instructions
>
> Reading | ################################################## | 100% 0.00s
>
> avrdude: Device signature = 0x1e950f (probably m328p)
> avrdude: erasing chip
> avrdude: reading input file "uno.hex"
> avrdude: writing flash (32638 bytes):
>
> Writing | ################################################## | 100% 2.06s
>
> avrdude: 32638 bytes of flash written
> avrdude: verifying flash memory against uno.hex:
> avrdude: load data flash data from input file uno.hex:
> avrdude: input file uno.hex contains 32638 bytes
> avrdude: reading on-chip flash data:
>
> Reading | ################################################## | 100% 1.86s
>
> avrdude: verifying ...
> avrdude: 32638 bytes of flash verified
> avrdude: reading input file "uno.eep.hex"
> avrdude: writing eeprom (144 bytes):
>
> Writing | ################################################## | 100% 0.06s
>
> avrdude: 144 bytes of eeprom written
> avrdude: verifying eeprom memory against uno.eep.hex:
> avrdude: load data eeprom data from input file uno.eep.hex:
> avrdude: input file uno.eep.hex contains 144 bytes
> avrdude: reading on-chip eeprom data:
>
> Reading | ################################################## | 100% 0.02s
>
> avrdude: verifying ...
> avrdude: 144 bytes of eeprom verified
> avrdude: reading input file "0x05"
> avrdude: writing efuse (1 bytes):
>
> Writing | ################################################## | 100% 0.01s
>
> avrdude: 1 bytes of efuse written
> avrdude: verifying efuse memory against 0x05:
> avrdude: load data efuse data from input file 0x05:
> avrdude: input file 0x05 contains 1 bytes
> avrdude: reading on-chip efuse data:
>
> Reading | ################################################## | 100% 0.00s
>
> avrdude: verifying ...
> avrdude: verification error, first mismatch at byte 0x0000
>          0xfd != 0x05
> avrdude: verification error; content mismatch
>
> avrdude: safemode: efuse changed! Was 5, and is now fd
> Would you like this fuse to be changed back? [y/n] n
> avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
>
> avrdude done.  Thank you.
>
> MacBook-Pro-van-Jan-5:avrdude jankromhout$
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>


-- 


[image: --]

John Verne
[image: https://]about.me/jverne
<https://about.me/jverne?promo=email_sig>

Re: [Amforth] Setting of the fuses Arduino Ono

[John V. <joh...@gm...>]

It is warning you that you are changing the low fuse settings. This is
because changing fuses can permanently damage the chip.

 In this case it looks like the existing fuse settings are CKSEL1 only, but
your AVRDude command wants to set 0x05, which enables a bunch of fuses.

You should be ok setting them to factory defaults. I don't have my Makefile
handy, but I think I use 0x62 or 0x05, which is suitable for any bootloader
(and thus suitable for AMForth.)

Here is a good reference:
https://www.instructables.com/id/How-to-change-fuse-bits-of-AVR-Atmega328p-8bit-mic/

There are online tools to generate fuse values:
http://www.engbedded.com/fusecalc

Every time I run into this I have to recheck my notes, which is why I save
the values in the Makefile. I've yet to blow up a 328P with fuses, but I
suppose it can be done. I'll respond with my Makefile snippet and rationale
later if it looks like it will help.

On Tue, Oct 16, 2018, 14:56 Jan Kromhout <kro...@ho...> wrote:

> When loading AmForth into my Arduino Uno  I get an error on the end.
> My question is what to do in that case?
> Are my settings of the fuse one?
>
> Cheers,
>
> Jan
>
>
> avrdude: verifying ...
> avrdude: verification error, first mismatch at byte 0x0000
>          0xfd != 0x05
> avrdude: verification error; content mismatch
>
> avrdude: safemode: efuse changed! Was 5, and is now fd
> Would you like this fuse to be changed back? [y/n] n
> avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
>
> My question is what to do in that situation?
>
>
>
>
>
> MacBook-Pro-van-Jan-5:avrdude jankromhout$ avrdude -P
> /dev/tty.usbmodem00230362 -c avrispv2 -b 19200 -p m328p -e -U
> flash:w:uno.hex:i -U eeprom:w:uno.eep.hex:i -U efuse:w:0x05:m -U
> hfuse:w:0xD9:m -U lfuse:w:0xFF:m
>
> avrdude: AVR device initialized and ready to accept instructions
>
> Reading | ################################################## | 100% 0.00s
>
> avrdude: Device signature = 0x1e950f (probably m328p)
> avrdude: erasing chip
> avrdude: reading input file "uno.hex"
> avrdude: writing flash (32638 bytes):
>
> Writing | ################################################## | 100% 2.06s
>
> avrdude: 32638 bytes of flash written
> avrdude: verifying flash memory against uno.hex:
> avrdude: load data flash data from input file uno.hex:
> avrdude: input file uno.hex contains 32638 bytes
> avrdude: reading on-chip flash data:
>
> Reading | ################################################## | 100% 1.86s
>
> avrdude: verifying ...
> avrdude: 32638 bytes of flash verified
> avrdude: reading input file "uno.eep.hex"
> avrdude: writing eeprom (144 bytes):
>
> Writing | ################################################## | 100% 0.06s
>
> avrdude: 144 bytes of eeprom written
> avrdude: verifying eeprom memory against uno.eep.hex:
> avrdude: load data eeprom data from input file uno.eep.hex:
> avrdude: input file uno.eep.hex contains 144 bytes
> avrdude: reading on-chip eeprom data:
>
> Reading | ################################################## | 100% 0.02s
>
> avrdude: verifying ...
> avrdude: 144 bytes of eeprom verified
> avrdude: reading input file "0x05"
> avrdude: writing efuse (1 bytes):
>
> Writing | ################################################## | 100% 0.01s
>
> avrdude: 1 bytes of efuse written
> avrdude: verifying efuse memory against 0x05:
> avrdude: load data efuse data from input file 0x05:
> avrdude: input file 0x05 contains 1 bytes
> avrdude: reading on-chip efuse data:
>
> Reading | ################################################## | 100% 0.00s
>
> avrdude: verifying ...
> avrdude: verification error, first mismatch at byte 0x0000
>          0xfd != 0x05
> avrdude: verification error; content mismatch
>
> avrdude: safemode: efuse changed! Was 5, and is now fd
> Would you like this fuse to be changed back? [y/n] n
> avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)
>
> avrdude done.  Thank you.
>
> MacBook-Pro-van-Jan-5:avrdude jankromhout$
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] Setting of the fuses Arduino Ono

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

When loading AmForth into my Arduino Uno  I get an error on the end.
My question is what to do in that case?
Are my settings of the fuse one?

Cheers,

Jan


avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xfd != 0x05
avrdude: verification error; content mismatch

avrdude: safemode: efuse changed! Was 5, and is now fd
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)

My question is what to do in that situation?





MacBook-Pro-van-Jan-5:avrdude jankromhout$ avrdude -P /dev/tty.usbmodem00230362 -c avrispv2 -b 19200 -p m328p -e -U flash:w:uno.hex:i -U eeprom:w:uno.eep.hex:i -U efuse:w:0x05:m -U hfuse:w:0xD9:m -U lfuse:w:0xFF:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: reading input file "uno.hex"
avrdude: writing flash (32638 bytes):

Writing | ################################################## | 100% 2.06s

avrdude: 32638 bytes of flash written
avrdude: verifying flash memory against uno.hex:
avrdude: load data flash data from input file uno.hex:
avrdude: input file uno.hex contains 32638 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.86s

avrdude: verifying ...
avrdude: 32638 bytes of flash verified
avrdude: reading input file "uno.eep.hex"
avrdude: writing eeprom (144 bytes):

Writing | ################################################## | 100% 0.06s

avrdude: 144 bytes of eeprom written
avrdude: verifying eeprom memory against uno.eep.hex:
avrdude: load data eeprom data from input file uno.eep.hex:
avrdude: input file uno.eep.hex contains 144 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 144 bytes of eeprom verified
avrdude: reading input file "0x05"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x05:
avrdude: load data efuse data from input file 0x05:
avrdude: input file 0x05 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xfd != 0x05
avrdude: verification error; content mismatch

avrdude: safemode: efuse changed! Was 5, and is now fd
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (E:05, H:DE, L:FF)

avrdude done.  Thank you.

MacBook-Pro-van-Jan-5:avrdude jankromhout$

[Amforth] Coolterm on the Mac

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

Thanks Peter for the response.
How do you have setup Coolterm?
When I try to delete a character two dots are printed!

Thanks for any help.

Jan Kromhout
Hellevoetsluis-NL

Re: [Amforth] How to download complete set of data from source forge.net

[Tristan W. <ho...@tj...>]

Hello Jan,

If you are happy to have version 6.7 rather than most recent sources
(see http://amforth.sourceforge.net/ below Work In Progress for more
information ) then using this link is probably the easiest way.

https://sourceforge.net/projects/amforth/files/amforth/6.7/

Then click on an archive link. If you are using OS X then I would choose
amforth-6.7.tar.gz as OS X knows what to do with this file type. On my
system double-clicking on it will expand it to a folder - and the
AmForth directory tree will be below the amforth-6.7 folder.

Kind regards,

Tristan


On 16Oct18 10:03, Jan Kromhout via Amforth-devel wrote:
> Hello,
> 
> In https://sourceforge.net/p/amforth/code/HEAD/tree/releases/ <http://sourceforge.net/> I found the release 6.7.
> How can I complete download this in one to my computer?
> 
> Thanks for any help.
> 
> Jan Kromhout
> Hellevoetsluis-NL
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth] How to download complete set of data from source forge.net

[Jan K. <jan...@ic...>]

Hello,

In https://sourceforge.net/p/amforth/code/HEAD/tree/releases/ <http://sourceforge.net/> I found the release 6.7.
How can I complete download this in one to my computer?

Thanks for any help.

Jan Kromhout
Hellevoetsluis-NL

Re: [Amforth] A good editor/terminal for MacOSX

[Peter C. H. <pet...@un...>]

Hello,

We have been using CoolTerm on the Mac.

When you send files with it you just have to make sure to add some delays in the preferences settings of CoolTerm so that Forth does not get overwhelmed.

Peter Hauser

> On 15 Oct 2018, at 14:56, Jan Kromhout via Amforth-devel <amf...@li...> wrote:
> 
> Hello,
> 
> What is a good editor/terminal to type in Forth, and also send the Forth files to the Arduino?
> 
> Thanks for any help.
> 
> Jan Kromhout
> Hellevoetsluis-NL
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] A good editor/terminal for MacOSX

[John V. <joh...@gm...>]

Your tool chain will really depend on the host computer type. The tools
available on Windows are different than than those for Linux, for example.

The FAQ and user guides are pretty good start, with dips into the more
technical guide and cookbook for specific tips.

Check out the Tools section of the user manual.

On Mon, Oct 15, 2018, 08:57 Jan Kromhout via Amforth-devel <
amf...@li...> wrote:

> Hello,
>
> What is a good editor/terminal to type in Forth, and also send the Forth
> files to the Arduino?
>
> Thanks for any help.
>
> Jan Kromhout
> Hellevoetsluis-NL
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] A good editor/terminal for MacOSX

[Jan K. <jan...@ic...>]

Hello,

What is a good editor/terminal to type in Forth, and also send the Forth files to the Arduino?

Thanks for any help.

Jan Kromhout
Hellevoetsluis-NL

Re: [Amforth] Question

[John V. <joh...@gm...>]

There is an SVN link off the amforth sourceforge page. As far as I know,
this is where the source for the shipped libraries resides.

On Mon, Oct 15, 2018, 08:37 Jan Kromhout via Amforth-devel <
amf...@li...> wrote:

> Hello,
>
> It’s a while ago that I implemented AmForth (4.8) on a Arduino.
>
> Now I am a little confused. Where to find the source with all libs like
> postpone.frt.
> Cannot find them.
>
>
>
> Please can you help me out?
>
> With kindly regards,
>
> Jan Kromhout
> Hellevoetsluis-NL
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] Question

[Jan K. <jan...@ic...>]

Hello,

It’s a while ago that I implemented AmForth (4.8) on a Arduino.

Now I am a little confused. Where to find the source with all libs like postpone.frt.
Cannot find them.



Please can you help me out?

With kindly regards,

Jan Kromhout
Hellevoetsluis-NL

Re: [Amforth] Bug in atmega2560 Code.

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

Hi Martin,

your mail hit my spam folder... Sorry


> Looks like there is a bug in file:
> /amforth-6.7/avr8/words/store-i_big.asm
> That is:
> > out_ rampz, zl
> 
> should be:
> > out_ eind, zl
> 
> EICALL and EIJMP both use this register for the extra bits.
> 

I cannot test it right now, but your description sounds right.
Changed with rev2335

Thanks
Matthias

[Amforth] Bug in atmega2560 Code.

[Martin N. <amf...@mg...>]

Hi,

Looks like there is a bug in file:
/amforth-6.7/avr8/words/store-i_big.asm
That is:
> out_ rampz, zl
should be:
> out_ eind, zl
EICALL and EIJMP both use this register for the extra bits.

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg...