[Amforth] AVR8: Mega 2560 Wiping Flash Memory

[Martin Nicholas via Amforth-devel]

I had problems with my Arduino Mega erasing parts of the flash memory;
sometimes the odd byte, sometimes the odd page.

I changed 3 things to the flashing code to make the problem go away:

1. Checked the SPMCSR:RWWSB bit. 
This is a crib from the Atmel example
(29.6.13 Simple Assembly Code Example for a Boot Loader).
>From the docs: "When the RWWSB bit is set, the RWW section cannot be
accessed."

Cribbed code:
; return to RWW section
; verify that RWW section is safe to read
Return:
in temp1, SPMCSR
sbrs temp1, RWWSB ; The RWW section is not ready yet
ret
; re-enable the RWW section
ldi spmcrval, (1

[Amforth] avr8 missing bm-test

[Tristan Williams]

A very minor item. 

avr8 has bm-set, bm-clear and bm-toggle as assembler words but does
not appear to have bm-test. This is not a big thing as it is easily
defined in forth as

: bm-test ( c a -- c ) c@ and ;

However, I've made myself an assembler version so I have a matching
set. It seems only very marginally faster than the forth one above.

; ( bitmask byte-addr -- byte )
; MCU
; return (byte at addr) AND bitmask 
VE_BM_TEST:
.dw $ff07
.db "bm-test"
.dw VE_HEAD
.set VE_HEAD = VE_BM_TEST
XT_BM_TEST:
.dw PFA_BM_TEST
PFA_BM_TEST:
movw zl, tosl
loadtos 
ld temp0, Z 
and tosl, temp0 
clr tosh; zero high byte of TOS  
jmp_ DO_NEXT


msp430 is missing bm-toggle and arm, risc-v have none of them. 

It also seemed a reasonable opportunity to try out tester-amforth.frt
I could well be using it incorrectly. Corrections welcomed.  

\ #include tester-amforth.frt

variable v

$ v !

\ some passes and fails to see what it looks like 

\ should pass
t{ $ff v bm-test -> $ff }t
\ should pass
t{ $1 v bm-test -> $1 }t
\ should pass
t{ $0 v bm-test -> $0 }t
\ should pass
t{ $ v bm-test -> $ff }t
\ should fail 
t{ $ v bm-test -> $ }t 
\ should pass  
t{ $ff00 v bm-test -> $00 }t 
\ should fail 
t{ $ff00 v bm-test -> $ff00 }t 

\ Not sure if this is an approved way of using t{ ... }t  

\ should pass for all values 
: test.1
#256 0 ?do
i v ! 
#256 0 ?do
t{ i v bm-test -> j $ff and i and }t
loop
loop
;

\ intentionally broken word 
: bm-broken ( mask a -- n )
2dup c@ dup 23 = rot rot = and if
drop drop 0 
else
bm-test
then
;

\ should fail only once when i=j=23 
: test.2
#256 0 ?do
i v !
#256 0 ?do
j 23 = if i . cr then
t{ i v bm-broken -> j $ff and i and }t
loop
loop
;

Best wishes,
Tristan





___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] avr8

[Erich Wälde]

Hello Brian,

thanks for your message!

> ... to the arm based systems where the  'real' work can be
> done.
Well observed imho. I read a book on PIC microcontrollers many
years back, where the authors made a case that if need be,
counted loops (in asm, no matter which way through the if
statements the code executes, it will always take exactly the
same time) are your tool to make the 8 bitter
- sing a song
- dim a 50/60 Hz lamp
- do one more job i forgot by now
- all at the same time and organize these three jobs well.

Eye opening and jaw droping at the same time. It has made a
lasting impression on me.


> So I ask that you don't eliminate the ability
> to build from source, even if it means using wine and the atmel
> (micochip) assembeler.

Rest assured. First of all *I* want to build from source any
time, because I still play with stuff written in assembly. And I
don't want this project to die, just because I happen to use it
myself! Who would have thought :-)

And most importantly: this is GPL software. The source ist the
fundamental representation of the whole project. It always must
be possible to build from source. I'm just a whee bit uneasy
that this fine project depends on non-free components for this
very step. And I had good discussions with Matthias about this.
There is just no /easy/ way out, I'm afraid.

But: lurking folks on the list resorted to writing emails!
Even sending patches! Definitely progress around here.
Thank you!

Cheers,
Erich


-- 
May the Forth be with you ...


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] avr8

[Tristan Williams]

Hello Brian,

My suggestion was just that the prebuilt AVR hex files in the
distribution should include more assembler words as standard. 

Being able to build from source means being able to do things that
might otherwise prove impossible. Not something I would want to
change. 

Best wishes,
Tristan

On 06Jul20 10:08, Brian wrote:
> Sending this again
> 
> Hello,
> 
> I'm an avr8 user and love amforth. This is the best system for an eight bit
> micro that lets you have interactive use of the chip. Things like circuit
> python and ulisp are cool but so resource intensive or tied to the arduino
> ecosystem that they become fun toy environments (on the 8 bit platforms)
> meant to move you on to the arm based systems where the 'real' work can be
> done. So I ask that you don't eliminate the ability to build from source,
> even if it means using wine and the atmel (micochip) assembeler. These tools
> allowed me to build and run the current amforth on the avrbutterfly. I think
> this is a great project. I would love to help, especially in the
> documentation. I'll keep my eyes open to how to submit patches. Thanks for
> everything.
> 
> brian-in-ohio
> 
> On 7/1/20 2:17 AM, Tristan Williams wrote:
> Hello,
> 
> > Who of you is using which target controller?
> I use AVR atmega328p, atmega1284p, atmega2560
> 
> > Can we get rid of the Atmel/Microchip Avrasm Assembler?
> Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine
> that would be a lot of work and wine does run it very well.
> 
> Having "fuller" hex files in the distribution that have assembly words
> like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would
> delay the need to build AmForth. AVR flash and ram are not the limited
> resource they once were. It might be worth updating the documentation
> to say which hex files are available.
> 
> > Would it be feasible to drop msp430, arm, risc-v in order to simplify
> > the whole thing? yes/no?
> I think that depends on the collective response to the first question.
> 
> > amforth-shell.py and python3
> amforth-shell.py is a great tool for AmForth. I have modified it to
> run under python3 and it works well for me. I will put up a patch but
> it really needs testing in a python os/environment other than mine.
> 
> > ticket system or mailing list ?
> I would prefer a mailing list.
> 
> Thank you Erich for AmForth Weekend #1 - I look forward to #2
> 
> Best wishes,
> Tristan
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] avr8

[Brian]

Sending this again

Hello,

I'm an avr8 user and love amforth. This is the best system for an eight 
bit micro that lets you have interactive use of the chip. Things like 
circuit python and ulisp are cool but so resource intensive or tied to 
the arduino ecosystem that they become fun toy environments (on the 8 
bit platforms) meant to move you on to the arm based systems where the 
'real' work can be done. So I ask that you don't eliminate the ability 
to build from source, even if it means using wine and the atmel 
(micochip) assembeler. These tools allowed me to build and run the 
current amforth on the avrbutterfly. I think this is a great project. I 
would love to help, especially in the documentation. I'll keep my eyes 
open to how to submit patches. Thanks for everything.


brian-in-ohio

On 7/1/20 2:17 AM, Tristan Williams wrote:
Hello,


Who of you is using which target controller?

I use AVR atmega328p, atmega1284p, atmega2560


Can we get rid of the Atmel/Microchip Avrasm Assembler?

Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine
that would be a lot of work and wine does run it very well.

Having "fuller" hex files in the distribution that have assembly words
like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would
delay the need to build AmForth. AVR flash and ram are not the limited
resource they once were. It might be worth updating the documentation
to say which hex files are available.


Would it be feasible to drop msp430, arm, risc-v in order to simplify
the whole thing? yes/no?

I think that depends on the collective response to the first question.


amforth-shell.py and python3

amforth-shell.py is a great tool for AmForth. I have modified it to
run under python3 and it works well for me. I will put up a patch but
it really needs testing in a python os/environment other than mine.


ticket system or mailing list ?

I would prefer a mailing list.

Thank you Erich for AmForth Weekend #1 - I look forward to #2

Best wishes,
Tristan

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 build questions

[Tristan Williams]

Hello Peter,

Thank you. I hadn't considered semiconductor relays but will do so
now. Whilst the 2560 does have the extra UARTs, part of the appeal of
the 1284p is that it is still available in a DIP package. For a DAC I
was thinking of an MCP4801/4011/4821 (or the dual 4802) which would
give the option of 8, 10 or 12 bit for the same footprint.   

Do you have any views on UART RF modules? I have had success with
AmForth over RF before but unfortunately the company that made the
modules is no longer in that business. Consequently I am looking for a
replacement module for the 1284p board, ideally one with hardware
encryption (as the old one did).

Tristan

On 10May17 08:21, Peter C. Hauser wrote:
> Hello Tristan,
> 
> If you want a flexible multi-purpose board perhaps you want to include a DAC, 
> and a high resolution ADC.  Semiconductor relays for switching loads.  It may 
> also be useful to have extra UARTs, but for this you might prefer to use the 
> 2560 instead of the 1284.  If you want to connect RS232 devices you might add 
> a TTL to RS232 level convertor such as a MAX232.
> 
> Peter
> 
> 
> > On 9 May 2017, at 23:07, Tristan Williams  wrote:
> > 
> > Hello Matthias,
> > 
> >> I use a 1284 occasionally too. Works fine and without problems.
> > 
> > Thank you for this. It persuaded me to look at my hardware
> > again. Building a board that pays attention to the reference hardware
> > design seems to have made the difference. It works fine and without
> > problems for me also.
> > 
> > I am hugely enjoying using AmForth and a 1284p based board, with all
> > its extra resource, will only add to that. Making one will be a good
> > challenge for me.
> > 
> > I would be interested to hear what other functions/facilities people
> > think would be good to include in addition to the 1284p on a ~ 10cm x
> > 10cm pcb?
> > 
> > Tristan
> > 
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 build questions

[Peter C. Hauser]

Hello Tristan,

If you want a flexible multi-purpose board perhaps you want to include a DAC, 
and a high resolution ADC.  Semiconductor relays for switching loads.  It may 
also be useful to have extra UARTs, but for this you might prefer to use the 
2560 instead of the 1284.  If you want to connect RS232 devices you might add a 
TTL to RS232 level convertor such as a MAX232.

Peter


> On 9 May 2017, at 23:07, Tristan Williams  wrote:
> 
> Hello Matthias,
> 
>> I use a 1284 occasionally too. Works fine and without problems.
> 
> Thank you for this. It persuaded me to look at my hardware
> again. Building a board that pays attention to the reference hardware
> design seems to have made the difference. It works fine and without
> problems for me also.
> 
> I am hugely enjoying using AmForth and a 1284p based board, with all
> its extra resource, will only add to that. Making one will be a good
> challenge for me.
> 
> I would be interested to hear what other functions/facilities people
> think would be good to include in addition to the 1284p on a ~ 10cm x
> 10cm pcb?
> 
> Tristan
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 build questions

[Tristan Williams]

Hello Matthias,

> I use a 1284 occasionally too. Works fine and without problems.

Thank you for this. It persuaded me to look at my hardware
again. Building a board that pays attention to the reference hardware
design seems to have made the difference. It works fine and without
problems for me also.

I am hugely enjoying using AmForth and a 1284p based board, with all
its extra resource, will only add to that. Making one will be a good
challenge for me.

I would be interested to hear what other functions/facilities people
think would be good to include in addition to the 1284p on a ~ 10cm x
10cm pcb?

Tristan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 build questions

[Matthias Trute]

Am Montag, den 08.05.2017, 16:54 +0100 schrieb Tristan Williams:
> Hello Matthias,
> 
> Two build questions.
> 
> 1) 
> 
> I have downloaded 2252 and run into this error when building for my
> uno
> 
> amforth-6.5A/avr8\drivers/generic-isr.asm(28): error: jz: Unknown
> instruction or macro

Mea culpa. it should read breq instead of jz. I'll checkin a correction
as soon as possible.

> Separately, using 2147 (and also 6.2) I have been trying to get an
> ATmega1284p up and running with AmForth. After cleanly building and
> flashing the two hex files I connect via RX0/TX0 but can only receive
> characters from the 1284p. Pressing reset (repeatedly) shows me the
> version number and chip name but the interpreter does not respond to
> my key presses. I am using an FTDI usb/serial connector which
> connects
> successfully to my uno and leonardo. For good measure I have checked
> the RX0/TXO signals with an oscilloscope and they are both there. Any
> thoughts as to where I might look next? 

I use a 1284 occasionally too. Works fine and without problems. A first
check would be to use play with the command receive routine. Just add 
the line

.set WANT_ISR_RX = 1

somewhere before you include the usart driver file. Or change it to
0 to use the polling version without interrupts (useful in some
scenarios when you disable the interrupts but want a working prompt)

> 
> My interest in the ATmega1284p is that I have "promised" myself a
> nice
> new 10 cm square PCB dedicated to running AmForth and thought it
> would
> be the ideal chip for the job :) 

It's a  nice chip indeed. Lots of RAM.

Matthias
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] AVR8 build questions

[Tristan Williams]

Hello Matthias,

Two build questions.

1) 

I have downloaded 2252 and run into this error when building for my uno

amforth-6.5A/avr8\drivers/generic-isr.asm(28): error: jz: Unknown instruction 
or macro
amforth-6.5A/avr8\drivers/generic-isr.asm(28): error: isr_clean: Unknown 
instruction or macro

I also get the same error for the Leonardo and the 1284p. The jz (jump
if zero?) instruction/macro does not appear in generic-isa.asm in 6.4
or 2147 and both 6.4 and 2147 make cleanly on my system (under osx +
wine).

2)

Separately, using 2147 (and also 6.2) I have been trying to get an
ATmega1284p up and running with AmForth. After cleanly building and
flashing the two hex files I connect via RX0/TX0 but can only receive
characters from the 1284p. Pressing reset (repeatedly) shows me the
version number and chip name but the interpreter does not respond to
my key presses. I am using an FTDI usb/serial connector which connects
successfully to my uno and leonardo. For good measure I have checked
the RX0/TXO signals with an oscilloscope and they are both there. Any
thoughts as to where I might look next? 

My interest in the ATmega1284p is that I have "promised" myself a nice
new 10 cm square PCB dedicated to running AmForth and thought it would
be the ideal chip for the job :) 

Kind regards,
Tristan






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 watchdog (reset and interrupt) atmega328p

[MIchael Kalus]

Müsste es dann nicht c!wd heißen?
Michael

2017-05-07 15:42 GMT+02:00 Matthias Trute :

> Hi Tristan,
>
> I've put your code online, revision 2252 contains the new
> file. There is only one change: I renamed the wd! into !wdc.
> It tells "store to watchdog control" and follows the more
> or less informal convention that ! and @ can be preceeded
> with size information and followed by location information.
> Just like c!e or @i. Hope that's ok for you.
>
> http://amforth.sourceforge.net/TG/recipes/Watchdog.html
>
> Thank you
> Matthias
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 watchdog (reset and interrupt) atmega328p

[Matthias Trute]

Hi Tristan,

I've put your code online, revision 2252 contains the new
file. There is only one change: I renamed the wd! into !wdc.
It tells "store to watchdog control" and follows the more
or less informal convention that ! and @ can be preceeded
with size information and followed by location information.
Just like c!e or @i. Hope that's ok for you.

http://amforth.sourceforge.net/TG/recipes/Watchdog.html

Thank you
Matthias
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 watchdog (reset and interrupt) atmega328p

[Tristan Williams]

Hello Matthias,

> I'll look at them in the next few days. Since we've just discovered
> some interrupt related bugs so maybe I'll ask you to do some
> tests with the code I will checkin. Is this ok for you? 

Absolutely fine.

Tristan



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 watchdog (reset and interrupt) atmega328p

[Tristan Williams]

Hello Matthias,

> IIRC only the "disable watchdog" sequence is timing critical (the
> 4 cpu cycles you mention). All other tasks can be performed at
> lower speed, so a forth implementation should be fine.

My atmega328p seems to require any change to WDTCSR to be completed
within 4 cycles (I have tried), so I do not think a pure forth
solution (excluding using assembler.frt) is possible.
 
> It would be a great contribution for the cookbook. Esp if it works with
> Forth code.

This made me think that writing 4 or 5 assembler words was not the
best way. Instead, have one assembler word wd! to perform the timed
write to WDTCSR and then have forth words for -wdt +wdt -wdi +wdi
wd.delay! I think this was the approach (one assembler word) used in
2013 with assembler.frt so had I read it better I might have got there
more quickly.

https://sourceforge.net/p/amforth/mailman/message/31512894/

Included below are three files wdwrite.asm, wd.forth and
wd-example.forth. Regarding wdwrite.asm, it is the first time I have
used assembler since 1985. wd.forth has more comments than code and
wd-example.forth may not be up to cookbook standards, though it has a
number of examples. Many of these examples intentionally result in the
avr microprocessor being reset on the watchdog timeout...

; wdwrite.asm
; 
; 
VE_WDWRITE:
.dw $ff03
.db "wd!"
.dw VE_HEAD
.set VE_HEAD = VE_WDWRITE
XT_WDWRITE:
.dw PFA_WDWRITE
PFA_WDWRITE:

 in temp1,SREG
 push temp1

 mov temp0, tosl

 cli
 ; Reset Watchdog Timer
 wdr
 ; Clear WDRF in MCUSR
 in temp1, MCUSR
 andi temp1, (0xff & (0<

Re: [Amforth] AVR8 watchdog (reset and interrupt) atmega328p

[Matthias Trute]

Am Donnerstag, den 20.04.2017, 09:04 +0100 schrieb Tristan Williams:
> AVR8 watchdog (reset and interrupt) atmega328p
> 
> I wanted to use the 128 kHz watchdog oscillator as an additional
> timer.

The watchdog creates a full reset cycle, that means that the full
startup sequence is performed. Your turnkey action should take
care of this (register r10 holds the reset cause).

> 
> In the source tree there is an assembler word -wdt (no-wdt.asm),
> which
> writes $0 to WDTCSR (using the prescribed sequence), but I couldn't
> find something like a "+wdt". This may well be because I did not look
> hard enough, so my apologies if it was there all along.

IIRC only the "disable watchdog" sequence is timing critical (the
4 cpu cycles you mention). All other tasks can be performed at
lower speed, so a forth implementation should be fine.

> 
> Using -wdt as a template I have written four companion assembler
> words
> and a slightly modified version of -wdt (to leave the existing
> prescaler and WDIE bit unmodified).
> 
> +wdt ( -- )set WDE (System Reset Mode)   
> -wdt ( -- )unset WDE (leaves prescaler)  
> +wdi ( -- )set WDIE (Interrupt mode) 
> -wdi ( -- )unset WDIE (leaves prescaler) 
> wd.delay! ( n -- ) set prescaler , unset WDE and unset WDIE 
> 
> where n is the 4 bits representing the prescaler. 
> 
> With the 4 cycle write requirement dealt with by (optional at build
> time) built in words the 128kHz timer is accessible and adds a
> lot. Could similar words be added to AmForth or is this too
> device/application specific?

It would be a great contribution for the cookbook. Esp if it works with
Forth code.

Good work
Matthias
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] AVR8 watchdog (reset and interrupt) atmega328p

[Tristan Williams]

AVR8 watchdog (reset and interrupt) atmega328p

I wanted to use the 128 kHz watchdog oscillator as an additional
timer.  I saw that AVR8 watchdog timer and reset was addressed on the
mailing list in late 2013 using assembler.frt 

In the source tree there is an assembler word -wdt (no-wdt.asm), which
writes $0 to WDTCSR (using the prescribed sequence), but I couldn't
find something like a "+wdt". This may well be because I did not look
hard enough, so my apologies if it was there all along.

Using -wdt as a template I have written four companion assembler words
and a slightly modified version of -wdt (to leave the existing
prescaler and WDIE bit unmodified).

+wdt ( -- )set WDE (System Reset Mode)   
-wdt ( -- )unset WDE (leaves prescaler)  
+wdi ( -- )set WDIE (Interrupt mode) 
-wdi ( -- )unset WDIE (leaves prescaler) 
wd.delay! ( n -- ) set prescaler , unset WDE and unset WDIE 

where n is the 4 bits representing the prescaler. 

With the 4 cycle write requirement dealt with by (optional at build
time) built in words the 128kHz timer is accessible and adds a
lot. Could similar words be added to AmForth or is this too
device/application specific?






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel