amforth-devel — Development discussion and user support

Re: [Amforth-devel] Starting amforth

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

e.g. the atmega32 running @16MHz and 5V:
Active current 22mA
Sleep modes:
Idle - current 11mA
Standby - current ~500uA
Powersave (WDT dis) - current 13uA
Powerdown (WDT en) - current ~14uA
Powerdown (WDT dis) - current 1uA


----- PŮVODNÍ ZPRÁVA -----
Od: "pito" <pi...@vo...>
Komu: mic...@on...,
amf...@li...
Předmět: Re: [Amforth-devel] Starting amforth
Datum: 8.4.2011 - 21:57:10

> > To all:
> > Would a simple
> > 
> > ' sleep is pause
> > 
> > work to put device into powersave mode?
> 
> There is a lot of powersavings modes in atmega
> (e.g. atmega32):
> Idle
> ADC Noise Reduction
> Power-down
> Power-save
> Standby
> Extended Standby
> 
> Moreover you may disable some internal subsystems
> to lower power.
> So the "sleep" words shall have actually a
> parameter: MCUCR register
> which defines all possible modes. The power
> consumption differs
> significantly from the mode chosen as well as the
> way have you can
> wakeup the chip. See the manual. P.
> 
> 

Re: [Amforth-devel] Starting amforth

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

> To all:
> Would a simple
> 
> ' sleep is pause
> 
> work to put device into powersave mode?

There is a lot of powersavings modes in atmega (e.g. atmega32):
Idle
ADC Noise Reduction
Power-down
Power-save
Standby
Extended Standby

Moreover you may disable some internal subsystems to lower power.
So the "sleep" words shall have actually a parameter: MCUCR register
which defines all possible modes. The power consumption differs
significantly from the mode chosen as well as the way have you can
wakeup the chip. See the manual. P.

Re: [Amforth-devel] Starting amforth

[Kalus M. <mic...@on...>]

Hi Hannu.


Am 08.04.2011 um 06:41 schrieb Hannu Vuolasaho:

> Q: Is somewhere simple LED blinker example?
> A: saw examples directory and studying those programs. But the  
> workflow from forth code to standalone program is missing

\ example:
: main ( -- )  begin led-on 1000 ms led-off 1000 ms key? until  ;
' main is turnkey

Mathias made a vector in eeprom called TURNKEY that holds the  
execution token of the forth word to start with after booting amforth  
on a device.

Mathias: maybe its a god idea to put it in faq.



> Q: How do I store the forth program to MCU so that when it starts I  
> don't need use serial port to upload it?
> A: Well This is same question as previous.

1. flash amforth into device
2. develop your forth code on the device. Since it is in flash, is  
permanent.
3. set turnkey, Since it is in eeprom its permanent too.
4. turn off power of device. Turn power on, it will run your  
application.

Step 2 can be very strenuous. amforth is very simple, it is for tiny  
devices. I use gforth or some other "big" forth systems to develop  
most of the forth code before it goes down the device and runs on  
amforth. Since amforth is standard forth, this works nice. You have  
to simulate features of the device. Fine tuning then is done  
interactive on the device itself. So its kind of iteration using  
gforth, test it in amforth on the device, continue this loop  
modifying code until it does the job.

Usually it takes a lot of re-flashing amforth till everything is  
works well.


>
> Q: If my program get's into infinite loop is there any other way  
> except reset to return to prompt?
> A:

No.

So define the main loop abortion condition first, then add its task.

Common constructs are:
: main ( -- ) begin ... key? until ;  \ test for any key
: main ( -- ) begin ." ." 1000 ms key? dup if drop key $03 = then  
until ; \ test ctrl-c


> Q: Register read and write?
> A: 1 PIN_NUMBER lshift REGISTER_NAME or!  to set one bit. Are  
> registers normally included? ( in C #include "avr/io.h" is needed)

No. (as far as I know)



> Q: How interrupts are used?
> A: First there has to be word for interrupt and it has to be told  
> to sytem so that it knows what to run on interrupt and then  
> registers are written to enable that interrupt.

Religious content ;-)

My opinion: Never use (highlevel) forth on a embedded device to serve  
an interrupt. Use the method that comes with the device. On atmega:  
place a jump to code fragment that will set a variable. If service  
may be slow, serve that variable in your forth task later.


> Q: sleepmodes and multitasking?
> A: After reading technical manual which is nice document I was left  
> little uncertain about multitasking. It is co-operative and pause  
> causes context change. By default pause was defined as nop? I'm  
> interested this since I noticed from archives that this was used to  
> save power.

There is a nice multitasker wordset, I myself did not use it.

To all:
Would a simple

   ' sleep is pause

work to put device into powersave mode?



> Q: Can Amforth used as calculator?
> A: Instead of using dc to calculate time to next coffee break forth  
> prompt over serial cable could be used for that. Or can it?

You will have to set up a real time clock in your device first I  
guess, using a timer interrupt to count down the seconds, minutes,  
hours.

Michael

Re: [Amforth-devel] Starting amforth

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

hi Hannu

> 
> Q: Is somewhere simple LED blinker example? A: saw examples
> directory and studying those programs. But the workflow from forth
> code to standalone program is missing

I'll write one, asap. It's really a FAQ ...

> 
> Q: How do I store the forth program to MCU so that when it starts I 
> don't need use serial port to upload it? A: Well This is same 
> question as previous.

A forth program consists of words. You do not need to upload them
repeatedly since they become part of the dictionay when they are
defined. And the dictionary (just enter words to get the content)
if kept across turn-off/turn-on/resets.

You have two ways to start your program: interactivly
by opening a terminal to your system and calling the start-word or
you use the turnkey feature which does the autexec.bat job. Just
keep in mind, that the command prompt itself is a started with the
turnkey, you can effectivly disable any command prompt by overwriting
the turnkey action.

Unless for very well tested code, I prefer the interactive method.
Overwriting turnkey is not difficult, but much harder to debug...

> 
> Q: If my program get's into infinite loop is there any other way 
> except reset to return to prompt? A:

Not really. The atmegas do not support any protection against errors.
Amforth does not do so as well, simply for speed reasons. Any runtime
checks slow down the system. Compile time checks cost code space which
is usually never enough.

And yes: its easy to corrupt the system and the only way to a get it up
again is to re-flash it from the hex files. But thats done easily and
does not hurt. IMHO.

> 
> Q: Register read and write? A: 1 PIN_NUMBER lshift REGISTER_NAME or! 
> to set one bit. Are registers normally included? ( in C #include 
> "avr/io.h" is needed)

The names of the registers are usually not available. Its of course
possible to include them but this makes the dictionary much larger
and usually only a few registers are used in normal programs. And
again: code space is limited.

If you really want to include the register names, you can define
constants in your application master file (template.asm) just like

.set WANT_PORTA = 1
.set WANT_PORTB = 1
etc

The file core/devices/<controller>/device.asm has many of such
variables. Just keep in mind: that WANT_something = 1 only
makes the register names available. There is no code associated
with.


> 
> Q: How interrupts are used? A: First there has to be word for 
> interrupt and it has to be told to sytem so that it knows what to
> run on interrupt and then registers are written to enable that 
> interrupt.

Interrupts are .. difficult. I prefer implementing them in assembly,
but one class of interrupts can be implemented in forth as well. details
are in the technical handbook.

> 
> Q: sleepmodes and multitasking? A: After reading technical manual 
> which is nice document I was left little uncertain about 
> multitasking. It is co-operative and pause causes context change. By 
> default pause was defined as nop? I'm interested this since I
> noticed from archives that this was used to save power.

Again: save code space but enable more advanced code structurs.
The basic core does not do multitaskink, but provides the tools
to implement it. Thats why pause is a noop by default, and thats
clearly not a multitasker.

Same with power saving. Not every application wants to save power,
what you've read is more an outline how it could be done, not tested
code. Maybe pito has some better ideas

> 
> Q: Can Amforth used as calculator? A: Instead of using dc to 
> calculate time to next coffee break forth prompt over serial cable 
> could be used for that. Or can it?

Sure it can do so. Remember: amforth is 16bit, only numbers between
-32000 und +32000 work trivially, others need more attention

I just updated the FAQ section to demonstrate the interactive use.
One example reads the return stack pointer from the atmega core,
let me know if it helps you.

> 
> Anyway all help is appreciated by this newbie forther.

Just ask, It may take some time for the answer, but I'll do my best

Matthias

[Amforth-devel] Starting amforth

[Hannu V. <vu...@ms...>]

Hello everyone.

I made my first contact to Forth this week and read through Starting forth and saw how some of my problems might be easily solved with forth. Yes they are solvable with C also but I can see some beauty with forth.

I started to search forth for AVR and found Amforth. As my next toy is still in delivery, I don't have dev board to test. I'm just reading.

However I'm curious. When I get my dev board,  compile Amforth, write it to chip and all the thing which are in user guide. I believe there is a gap here. From Amforth installation to working standalone program.

I believe this is rather FAQ (or it should be) but I'll ask anyway. And try to answer so that you can correct my misconceptions.

Q: Is somewhere simple LED blinker example?
A: saw examples directory and studying those programs. But the workflow from forth code to standalone program is missing

Q: How do I store the forth program to MCU so that when it starts I don't need use serial port to upload it?
A: Well This is same question as previous.

Q: If my program get's into infinite loop is there any other way except reset to return to prompt?
A: 

Q: Register read and write? 
A: 1 PIN_NUMBER lshift REGISTER_NAME or!  to set one bit. Are registers normally included? ( in C #include "avr/io.h" is needed)

Q: How interrupts are used?
A: First there has to be word for interrupt and it has to be told to sytem so that it knows what to run on interrupt and then registers are written to enable that interrupt.

Q: sleepmodes and multitasking?
A: After reading technical manual which is nice document I was left little uncertain about multitasking. It is co-operative and pause causes context change. By default pause was defined as nop? I'm interested this since I noticed from archives that this was used to save power.

Q: Can Amforth used as calculator?
A: Instead of using dc to calculate time to next coffee break forth prompt over serial cable could be used for that. Or can it?

Anyway all help is appreciated by this newbie forther.

best regards,
Hannu Vuolasaho
 		 	   		  

[Amforth-devel] Fast I/O library

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

Hi, some time back I assembled this library for fast i/o. Maybe
somebody fid is usefull. Not fully tested, no warranty of any kind.
P.
=============================================================
; FAST i/o LIBRARY for amforth
; assembled from various sources
; Pito 1/2011
; not fully tested and maybe not fully optimized
; no warranty of any kind (;-))
; works via PINMASKS

; ( pinmask portadr -- ) fast pin_output port
; R( -- )
VE_PIN_OUT:
.dw $ff0a
.db "pin_output"
.dw VE_HEAD
.set VE_HEAD = VE_PIN_OUT
XT_PIN_OUT:
.dw PFA_PIN_OUT
PFA_PIN_OUT:
movw ZL, tosl
sbiw Z, 1
ld R16, Z
loadtos
or R16, tosl
st Z, R16
loadtos
jmp DO_NEXT


; ( pinmask portadr -- ) fast pin_input port
; R( -- )
VE_PIN_INP:
.dw $ff09
.db "pin_input",0 
.dw VE_HEAD
.set VE_HEAD = VE_PIN_INP
XT_PIN_INP:
.dw PFA_PIN_INP
PFA_PIN_INP:
movw ZL, tosl
sbiw Z, 1
ld R16, Z
loadtos
com tosl
and R16, tosl
st Z, R16
loadtos
jmp DO_NEXT


; ( pinmask portadr -- ) fast low port
; R( -- )
VE_LOW:
.dw $ff03
.db "low",0 
.dw VE_HEAD
.set VE_HEAD = VE_LOW
XT_LOW:
.dw PFA_LOW
PFA_LOW:
movw ZL, tosl
ld R16, Z
loadtos
com tosl
and R16, tosl
st Z, R16
loadtos
jmp DO_NEXT


; ( pinmask portadr -- ) fast high port
; R( -- )
VE_HIGH:
.dw $ff04
.db "high"
.dw VE_HEAD
.set VE_HEAD = VE_HIGH
XT_HIGH:
.dw PFA_HIGH
PFA_HIGH:
movw ZL, tosl
ld R16, Z
loadtos
or R16, tosl
st Z, R16
loadtos
jmp DO_NEXT


; ( pinmask portadr -- ) fast toggle port
; R( -- )
VE_TOGGLE:
.dw $ff06
.db "toggle" 
.dw VE_HEAD
.set VE_HEAD = VE_TOGGLE
XT_TOGGLE:
.dw PFA_TOGGLE
PFA_TOGGLE:
movw ZL, tosl
ld R16, Z
loadtos
eor R16, tosl
st Z, R16
loadtos
jmp DO_NEXT


; ( pinmask portadr -- c ) fast is_low? port
; R( -- )
VE_ISLOW:
.dw $ff07
.db "is_low?",0
.dw VE_HEAD
.set VE_HEAD = VE_ISLOW
XT_ISLOW:
.dw PFA_ISLOW
PFA_ISLOW:
movw ZL, tosl
ld R16, Z
com R16
loadtos
and tosl, R16 
clr tosh
jmp DO_NEXT


; ( pinmask portadr -- c ) fast is_high? port
; R( -- )
VE_ISHIGH:
.dw $ff08
.db "is_high?"
.dw VE_HEAD
.set VE_HEAD = VE_ISHIGH
XT_ISHIGH:
.dw PFA_ISHIGH
PFA_ISHIGH:
movw ZL, tosl
ld R16, Z
loadtos
and tosl, R16 
clr tosh
jmp DO_NEXT	


; ( pinmask portadr -- c ) fast pin_low? port
; R( -- )
VE_PINLOW:
.dw $ff08
.db "pin_low?"
.dw VE_HEAD
.set VE_HEAD = VE_PINLOW
XT_PINLOW:
.dw PFA_PINLOW
PFA_PINLOW:
movw ZL, tosl
sbiw ZL, 2
ld R16, Z
com R16
loadtos
and tosl, R16 
clr tosh
jmp DO_NEXT	


; ( pinmask portadr -- c ) fast pin_high? port
; R( -- )
VE_PINHIGH:
.dw $ff09
.db "pin_high?",0
.dw VE_HEAD
.set VE_HEAD = VE_PINHIGH
XT_PINHIGH:
.dw PFA_PINHIGH
PFA_PINHIGH:
movw ZL, tosl
sbiw ZL, 2
ld R16, Z
loadtos
and tosl, R16 
clr tosh
jmp DO_NEXT		


; ( pinmask portadr -- c ) fast pin! port
; R( -- )
VE_PINSTORE:
.dw $ff04
.db "pin!"
.dw VE_HEAD
.set VE_HEAD = VE_PINSTORE
XT_PINSTORE:
.dw PFA_PINSTORE
PFA_PINSTORE:
movw ZL, tosl
ld R16, Z
loadtos
mov R17, tosl
com tosl
and R16, tosl
loadtos
and R17, tosl
or R16, R17
st Z, R16
loadtos
jmp DO_NEXT			


; ( pinmask portadr -- c ) fast pin@ port
; R( -- )
VE_PINFETCH:
.dw $ff04
.db "pin@"
.dw VE_HEAD
.set VE_HEAD = VE_PINFETCH
XT_PINFETCH:
.dw PFA_PINFETCH
PFA_PINFETCH:
movw ZL, tosl
sbiw Z, 2
ld R16, Z
loadtos
and tosl, R16
clr tosh
jmp DO_NEXT		

[Amforth-devel] Karl amforth - fram,eeprom

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

Hi, I've seen a new set of files in
..\amforth\applications\karlforth - is there any interesting reading
(except the sources) to that available?? Thanks, Pito.

Re: [Amforth-devel] Ultra Low Power operation

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

The only "real" low power mode is the "power-down" (with WTD
disabled <1uA, with WDT on 6-10uA). This mode cannot be wakedup by
usart. All other modes are mostly >>100ua.
Power-down: Only an External Reset, a Watchdog Reset, a Brown-out
Reset, a Two-wire Serial Interface address match interrupt, an
External level interrupt on INT0 or INT1, or an External interrupt
on
INT2 can wake up the MCU...

----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: amf...@li...
Předmět: Re: [Amforth-devel] Ultra Low Power operation
Datum: 4.4.2011 - 20:16:43

> Hi,
> 
> 
> > Hi, as the amforth will not be a subject of
> > power computing let me
> > > ask the experts following:
> > 1. would it be possible to create a mechanism
> > where amforth/atmega
> > > will be run on _very_ low power - basically
> > powerdown or sleep
> > 
> I did not yet implemented it, but the strategy
> should be strait
> forward (as far as I understood the sleep mode
> section):
> 
> 1) use the multitasker
> 2) setup an idle task which does nothing but enter
> the right
> sleep mode
> 3) whenever an interrupt is able to wake up the
> controller, the
> processing will continue. Sooner or later the
> multitasker will
> re-call the sleep task and everything is quiet
> again.
> 
> > 2. the rx will be connected to an additional
> > interrupt pin
> > 
> The usart interrupts can trigger the sleep-end
> condition itself.
> 
> > 3. after receiving a character it will issue
> > some message on state -
> > > that everything is ok (e.g. none reset or
> > power-off occured) and it
> > > will start to communicate with us in a normal
> > way..
> > 
> After leaving the sleep mode, the controller
> continues just like
> if nothing has happened. Until the next sleep
> instruction is called
> (there is a stupid wrapper word in the dictionary
> which does nothing
> but call the SLEEP intruction.)
> 
> > 4. when not communicating with host for e.g.
> > 10sec, or none tasks to
> > > accomplish, it will go to low power state
> > again..
> > 
> why wait? whenever the idle task is activated, the
> main task has nothing
> to do at all.
> 
> Some googling revealed some pitfalls (connected
> usart devices or
> connected programming tools like debuggers may
> prevent the power save
> effects) however. in German:
> http://www.mikrocontroller.net/articles/Sleep_Mode
> 
> I'd like to hear if it works. If it doesn't of
> course too
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> > Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code
> yourself; 
> WebMatrix provides all the features you need to
> develop and 
> publish your website.
> http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Ultra Low Power operation

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

Hi,


> Hi, as the amforth will not be a subject of power computing let me
> ask the experts following:
> 1. would it be possible to create a mechanism where amforth/atmega
> will be run on _very_ low power - basically powerdown or sleep

I did not yet implemented it, but the strategy should be strait
forward (as far as I understood the sleep mode section):

1) use the multitasker
2) setup an idle task which does nothing but enter the right
   sleep mode
3) whenever an interrupt is able to wake up the controller, the
   processing will continue. Sooner or later the multitasker will
   re-call the sleep task and everything is quiet again.

> 2. the rx will be connected to an additional interrupt pin

The usart interrupts can trigger the sleep-end condition itself.

> 3. after receiving a character it will issue some message on state -
> that everything is ok (e.g. none reset or power-off occured) and it
> will start to communicate with us in a normal way..

After leaving the sleep mode, the controller continues just like
if nothing has happened. Until the next sleep instruction is called
(there is a stupid wrapper word in the dictionary which does nothing
but call the SLEEP intruction.)

> 4. when not communicating with host for e.g. 10sec, or none tasks to
> accomplish, it will go to low power state again..

why wait? whenever the idle task is activated, the main task has nothing
to do at all.

Some googling revealed some pitfalls (connected usart devices or
connected programming tools like debuggers may prevent the power save
effects) however. in German:
http://www.mikrocontroller.net/articles/Sleep_Mode

I'd like to hear if it works. If it doesn't of course too

Matthias

[Amforth-devel] Ultra Low Power operation

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

Hi, as the amforth will not be a subject of power computing let me
ask the experts following:
1. would it be possible to create a mechanism where amforth/atmega
will be run on _very_ low power - basically powerdown or sleep
2. the rx will be connected to an additional interrupt pin (e.g.
wired-or from various sources) and when a character comes (startbit
does log1->log0) it will fire interrupt and wake up the chip (first
character will be lost probably as the chip needs some time to
wakeup)
3. after receiving a character it will issue some message on state -
that everything is ok (e.g. none reset or power-off occured) and it
will start to communicate with us in a normal way..
4. when not communicating with host for e.g. 10sec, or none tasks to
accomplish, it will go to low power state again..

The idea behind is to power a gadget from a 3V coin battery, or a
nimh AAA cell (and to use e.g. max1724 upconverter to 3v3 or 5v)
maybe charged from a sollar cell.

So the challenge is to achieve an ultra low power operation, without
loosing RAM and i/o information, but be ready to ad-hoc communicate
with a host via the serial anytime. I think this needs a support
from amforth "OS" side as well. P.

Re: [Amforth-devel] Speed analysis.. "one"

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

Forth Academy (;-))).P.

----- PŮVODNÍ ZPRÁVA -----
Od: "Kalus Michael" <mic...@on...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth-devel] Speed analysis..  "one"
Datum: 3.4.2011 - 12:38:13

> 
> 
> 
> Am 03.04.2011 um 12:27 schrieb D Nyberg:
> 
> > I think you would also see a huge speed increase
> > if you defined  
> > > constant
> > named "1" and tried it again too. That used to
> > be standard in F79 and
> > > 83, though it was more about size than speed.
> >
> > On 4/3/2011 4:16:17 AM, pito (pi...@vo...)
> > wrote:
> > >> : exa1 1 1 + . ;
> >> compilation 55sec (avrstudio window hidden)
> >> run ~0.3sek
> >>
> >> : exa2 1000 1000 3000 + - . ;
> >> compilation 78sec (avrstudio window hidden)
> >> run ~0.3sek
> >>
> >> Quite surprised the write to flash works with
> >> avrstudio
> >> >> simulator(v4, b716). I have ~250 words more in
> >> flash then the basic
> >> >> clean amforth 4.2 compilation.
> 
> If we do it like ZERO we get:
> 
> ; ( -- 1 ) Arithmetics
> ; R( -- )
> ; leaves the value 1 on TOS
> VE_ONE:
> .dw $ff01
> .db "1",0
> .dw VE_HEAD
> .set VE_HEAD = VE_ONE
> XT_ONE:
> .dw PFA_ONE
> PFA_ONE:
> savetos
> PFA_ONE1:
> ldi tosl,1
> ldi tosh,0
> jmp DO_NEXT
> 
> 
> But a forth version compiles two cells shorter:
> ; ( -- 1 )
> ; R( -- )
> ; leaves the value 1 on TOS
> VE_1:
> .dw $FF01
> .db "1",0
> .dw VE_HEAD
> .set VE_HEAD = VE_1
> XT_1:
> .dw PFA_DOVARIABLE
> PFA_1:
> .dw $1
> 
> ; forth:
> ; 1 constant 1
> 
> 
> Wonder which one is faster?
> Michael
> 
> 
> 
> ------------------------------------------------------------------------------
> > Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code
> yourself; 
> WebMatrix provides all the features you need to
> develop and 
> publish your website.
> http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Speed analysis.. "one"

[Kalus M. <mic...@on...>]

Am 03.04.2011 um 12:27 schrieb D Nyberg:

> I think you would also see a huge speed increase if you defined  
> constant
> named "1" and tried it again too. That used to be standard in F79 and
> 83, though it was more about size than speed.
>
> On 4/3/2011 4:16:17 AM, pito (pi...@vo...) wrote:
>> : exa1 1 1 + . ;
>> compilation 55sec (avrstudio window hidden)
>> run ~0.3sek
>>
>> : exa2 1000 1000 3000 + - . ;
>> compilation 78sec (avrstudio window hidden)
>> run ~0.3sek
>>
>> Quite surprised the write to flash works with avrstudio
>> simulator(v4, b716). I have ~250 words more in flash then the basic
>> clean amforth 4.2 compilation.

If we do it like ZERO we get:

; ( -- 1 ) Arithmetics
; R( -- )
; leaves the value 1 on TOS
VE_ONE:
     .dw $ff01
     .db "1",0
     .dw VE_HEAD
     .set VE_HEAD = VE_ONE
XT_ONE:
     .dw PFA_ONE
PFA_ONE:
     savetos
PFA_ONE1:
     ldi tosl,1
     ldi tosh,0
     jmp DO_NEXT


But a forth version compiles two cells shorter:
; ( -- 1 )
; R( -- )
; leaves the value 1 on TOS
VE_1:
     .dw $FF01
     .db "1",0
     .dw VE_HEAD
     .set VE_HEAD = VE_1
XT_1:
     .dw PFA_DOVARIABLE
PFA_1:
     .dw $1

; forth:
; 1 constant 1


Wonder which one is faster?
Michael

Re: [Amforth-devel] Speed analysis..

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

I think you would also see a huge speed increase if you defined constant 
named "1" and tried it again too. That used to be standard in F79 and 
83, though it was more about size than speed.

On 4/3/2011 4:16:17 AM, pito (pi...@vo...) wrote:
 > : exa1 1 1 + . ;
 > compilation 55sec (avrstudio window hidden)
 > run ~0.3sek
 >
 > : exa2 1000 1000 3000 + - . ;
 > compilation 78sec (avrstudio window hidden)
 > run ~0.3sek
 >
 > Quite surprised the write to flash works with avrstudio
 > simulator(v4, b716). I have ~250 words more in flash then the basic
 > clean amforth 4.2 compilation. P
 >
 > ----- PÙVODNÍ ZPRÁVA -----
 > Od: "Kalus Michael" <mic...@on...>
 > Komu: "Everything around amforth"
 > <amf...@li...>
 > Pøedmìt: Re: [Amforth-devel] Speed analysis..
 > Datum: 3.4.2011 - 10:04:25

Re: [Amforth-devel] Speed analysis..

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

: exa1 1 1 + . ;
compilation 55sec (avrstudio window hidden)
run ~0.3sek

: exa2 1000 1000 3000 + - . ; 
compilation 78sec (avrstudio window hidden)
run ~0.3sek

Quite surprised the write to flash works with avrstudio
simulator(v4, b716). I have ~250 words more in flash then the basic
clean amforth 4.2 compilation. P

----- PŮVODNÍ ZPRÁVA -----
Od: "Kalus Michael" <mic...@on...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth-devel] Speed analysis..
Datum: 3.4.2011 - 10:04:25

> Hi.
> 
> pito wrote:
> > Hi, when running the amforth4.2 in simulator
> > I've observed
> > > following:
> > a) "1 1 + ." takes 42sec to calculate
> > b) "1000 1000 3000 + - ." takes 60sec to
> > calculate.
> > > Does it mean the amforth spends most of the time
> > with tokens lookup?
> > 
> Interpreting a commandline speeds up if you use a
> constant found in  
> the dictionary, as 1 or 2 or other constants you
> create. INTERPRET  
> tries to FIND a WORD first, if that fails, tries
> to convert it as a  
> NUMBER, and if that fails too you get an
> errormessage.
> 
> Try:
> : example1  1 1 + . ;
> : example2  1000 1000 + . ;
> What runtimes did you find now?
> 
> 
> Michael
> 
> 
> ------------------------------------------------------------------------------
> > Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code
> yourself; 
> WebMatrix provides all the features you need to
> develop and 
> publish your website.
> http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Speed analysis..

[Kalus M. <mic...@on...>]

Hi.

pito wrote:
> Hi, when running the amforth4.2 in simulator I've observed
> following:
> a) "1 1 + ." takes 42sec to calculate
> b) "1000 1000 3000 + - ." takes 60sec to calculate.
> Does it mean the amforth spends most of the time with tokens lookup?

Interpreting a commandline speeds up if you use a constant found in  
the dictionary, as 1 or 2 or other constants you create. INTERPRET  
tries to FIND a WORD first, if that fails, tries to convert it as a  
NUMBER, and if that fails too you get an errormessage.

Try:
: example1  1 1 + . ;
: example2  1000 1000 + . ;
What runtimes did you find now?


Michael

Re: [Amforth-devel] Speed analysis..

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

pito wrote:
> Hi, when running the amforth4.2 in simulator I've observed
> following:
> a) "1 1 + ." takes 42sec to calculate
> b) "1000 1000 3000 + - ." takes 60sec to calculate.
> Does it mean the amforth spends most of the time with tokens lookup?

The dictionary is always searched first. A number conversion is the
second step, thus: yes in your case most of the time is spent in useless
dictionary lookups. There are varios ways to speed things up, but they
have more or less hack value. (see the recognizers in subversion trunk)

> P.
> PS: I've spend some time with FlashForth 4.7 (pic24 and dspic33,
> subroutine threaded) and the mips to mips comparision with the same
> code (Sieve, the only difference the FF uses "for next" instead of
> "do loop") shows 8x speed advantage of the FF.

Flashforth is  "subroutine threaded forth with native code generation"
(from the homepage), amforth is indirect threaded without any native code
generation.

I'd have expected a (much) bigger speed difference.

Matthias

[Amforth-devel] Speed analysis..

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

Hi, when running the amforth4.2 in simulator I've observed
following:
a) "1 1 + ." takes 42sec to calculate
b) "1000 1000 3000 + - ." takes 60sec to calculate.
Does it mean the amforth spends most of the time with tokens lookup?
P.
PS: I've spend some time with FlashForth 4.7 (pic24 and dspic33,
subroutine threaded) and the mips to mips comparision with the same
code (Sieve, the only difference the FF uses "for next" instead of
"do loop") shows 8x speed advantage of the FF.

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[Kalus M. <mic...@on...>]

Hi.

..
> Are you (or anyone) using lib/xonxoff.frt?

No.

I modified QUIT to achieve a xon xoff handshake with Zterm (mac OSX).

The Idea was:
Create 2 vectors in eeprom to hold execution token (xt) for words to  
send control characters to terminal - value startterminal and value  
stopterminal. Default is NOOP for both. The XONXOFF command then  
replaces the default values with TX_XON and XT_XOFF Words. The FINIS  
command set both back to NOOP.

QUIT checks state, if compiling it uses a prompts that executes stop-  
and startterminal, else uses amforth standard prompt.

A soucefile has XONXOFF at the beginning ans FINIS at end of code.
There is en errorhandler as well that may by turnd on and off.

My amforthversion 3.6 uses pollling method for USART.

Michael




Am 30.03.2011 um 23:24 schrieb Marcin Cieslak:

>>> Kalus Michael <mic...@on...> wrote:
>> I use ZTerm with Mac OSX. In typing mode, it stops sending when XOFF
>> character is echoed, and continues after XON. So my amforth CR sends
>> xoff to the Terminal too, and the OK is followed by XON.
>> (Typing mode: copy&paste forth souce into ZTerm window, do not use
>> ZTerms file transfer feature. Setup the ZTerm as VT100 with line
>> prompt character ^C ($13 = xoff)).
>
> Are you (or anyone) using lib/xonxoff.frt? It never worked for me
> (caused quick breakage in all communications on my Arduino).
>
> I am using GNU screen utility to paste files to amforth-
> there is a "slowpaste" (or "defslowpaste") option to add
> delay when pasting. 50 millseconds are fine.
>
> //Marcin

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

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

>> Kalus Michael <mic...@on...> wrote:
> I use ZTerm with Mac OSX. In typing mode, it stops sending when XOFF  
> character is echoed, and continues after XON. So my amforth CR sends  
> xoff to the Terminal too, and the OK is followed by XON.
> (Typing mode: copy&paste forth souce into ZTerm window, do not use  
> ZTerms file transfer feature. Setup the ZTerm as VT100 with line  
> prompt character ^C ($13 = xoff)).

Are you (or anyone) using lib/xonxoff.frt? It never worked for me
(caused quick breakage in all communications on my Arduino).

I am using GNU screen utility to paste files to amforth- 
there is a "slowpaste" (or "defslowpaste") option to add
delay when pasting. 50 millseconds are fine.

//Marcin

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

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

the amforth issues one additional SPACE and that creates an issue
with Mosaic when editing the line and using backspace. The fix - do
comment out the XT_SPACE below:

...
PFA_ACCEPT5:
.dw XT_DUP        ; ( -- addr k k )
.dw XT_EMIT       ; ( -- addr k )
;.dw XT_SPACE     ; ( -- addr k ) <<<<< 20101026 by Pito
.dw XT_EMIT               ; ( -- addr ) 
....


----- PŮVODNÍ ZPRÁVA -----
Od: "pito" <pi...@vo...>
Komu: mic...@on...,
amf...@li...
Předmět: Re: [Amforth-devel] Progress and More Difficulties with
Hello
Datum: 30.3.2011 - 10:22:00

> .. there is an issue with Mosaic Terminal - the
> BackSpace issue I've
> addressed in one of my last year's topics - the
> fix is easy (just a
> small change in one amforth word). P.
> 
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "pito" <pi...@vo...>
> Komu: mic...@on...,
> amf...@li...
> Předmět: Re: [Amforth-devel] Progress and More
> Difficulties with
> Hello
> Datum: 30.3.2011 - 10:03:58
> 
> > I've been using "Mosaic Terminal" (free
> > download,
> > > designed for
> > forth)under XP. Just set "Wait for Echo" ON and
> > "Binary Char Delay"
> > 0.005 (or less). It runs 115200 8N1 without a
> > problem (when your
> > crystal allows such speed, of course).
> > Copy/paste
> > > sources. This
> > terminal is the only one I can use with amforth.
> > For FlashForth the
> > Tera Term (FF supports Xon/Xoff) is the one
> > which
> > > works fine any
> > speed. Pito
> > 
> > ----- PŮVODNÍ ZPRÁVA -----
> > Od: "Kalus Michael"
> > <mic...@on...>
> > > Komu: "Everything around amforth"
> > <amf...@li...>
> > Předmět: Re: [Amforth-devel] Progress and More
> > Difficulties with
> > Hello
> > Datum: 30.3.2011 - 4:47:21
> > 
> > > Hi.
> > > 
> > > 
> > > Am 29.03.2011 um 21:33 schrieb Matthias Trute:
> > > ..
> > > > Receiving characters is a completly
> > > > different
> > > > > > > thing. The characters
> > > > > can come at any time, therefore the code
> > > > > needs
> > > > > > > to deal with the
> > > > > situation relativly fast (at least before
> > > > > the
> > > > > > > next character
> > > > > arrives).
> > > 
> > > If you just want to connect a terminal to type
> > > in
> > > > commands, amforth  
> > > is fast enough to handle this situation: Wait
> > > for
> > > > a key, grab it, put  
> > > it in inputbuffer, wait again.
> > > amforths accepts keys till end of line, then
> > > interprets the line.
> > > See: uart-rx-poll.asm
> > > Since you - the user - wait for the ok of
> > > amforth
> > > > to appear, there is  
> > > no overflow.
> > > I use 12Mhz chrystal, 14400 Baud, atmega168,
> > > works
> > > > fine this way.
> > > 
> > > But to download a file you have to make shure
> > > your
> > > > sending program  
> > > will immediatly stop sending if a CR is
> > > echoed,
> > > > > and continues after  
> > > OK is encounterd. Terminals usualy can not
> > > handle
> > > > this situation.  
> > > That is why Mathias is using a Phyton script
> > > for
> > > > > downloads.
> > > 
> > > I use ZTerm with Mac OSX. In typing mode, it
> > > stops
> > > > sending when XOFF  
> > > character is echoed, and continues after XON.
> > > So
> > > > > my amforth CR sends  
> > > xoff to the Terminal too, and the OK is
> > > followed
> > > > > by XON.
> > > (Typing mode: copy&paste forth souce into
> > > ZTerm
> > > > > window, do not use  
> > > ZTerms file transfer feature. Setup the ZTerm
> > > as
> > > > > VT100 with line  
> > > prompt character ^C ($13 = xoff)).
> > > 
> > > There may be about two characters on its way
> > > down
> > > > to amforth till  
> > > terminal finaly stops sending more characters.
> > > I
> > > > > allways insert 4 or  
> > > more blanks at the beginning of each line in
> > > my
> > > > > forth sources to  
> > > handle this situation. This way interpretation
> > > of
> > > > a line stays  
> > > successful even if some characters are lost in
> > > the
> > > > handshaking process.
> > > 
> > > : hallo ." hallo world" ;
> > > ^^^^
> > > 
> > > Maybe this helps.
> > > Michael
> > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > > > > > > > > > > Enable your software for Intel(R)
> > > > > > > Active
> > > > > > > > > Management Technology to meet the
> > > growing manageability and security demands of
> > > your
> > > > customers. Businesses
> > > are taking advantage of Intel(R) vPro (TM)
> > > technology - will your software 
> > > be a part of the solution? Download the
> > > Intel(R)
> > > > > Manageability Checker 
> > > today! http://p.sf.net/sfu/intel-dev2devmar
> > > _______________________________________________
> > > > > Amforth-devel mailing list
> > > Amf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > > > > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > > > > > Enable your software for Intel(R) Active
> > Management Technology to meet the
> > growing manageability and security demands of
> > your
> > > customers. Businesses
> > are taking advantage of Intel(R) vPro (TM)
> > technology - will your software 
> > be a part of the solution? Download the Intel(R)
> > Manageability Checker 
> > today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > 
> 
> 
> ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active
> Management Technology to meet the
> growing manageability and security demands of your
> customers. Businesses
> are taking advantage of Intel(R) vPro (TM)
> technology - will your software 
> be a part of the solution? Download the Intel(R)
> Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

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

.. there is an issue with Mosaic Terminal - the BackSpace issue I've
addressed in one of my last year's topics - the fix is easy (just a
small change in one amforth word). P.

----- PŮVODNÍ ZPRÁVA -----
Od: "pito" <pi...@vo...>
Komu: mic...@on...,
amf...@li...
Předmět: Re: [Amforth-devel] Progress and More Difficulties with
Hello
Datum: 30.3.2011 - 10:03:58

> I've been using "Mosaic Terminal" (free download,
> designed for
> forth)under XP. Just set "Wait for Echo" ON and
> "Binary Char Delay"
> 0.005 (or less). It runs 115200 8N1 without a
> problem (when your
> crystal allows such speed, of course). Copy/paste
> sources. This
> terminal is the only one I can use with amforth.
> For FlashForth the
> Tera Term (FF supports Xon/Xoff) is the one which
> works fine any
> speed. Pito
> 
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "Kalus Michael" <mic...@on...>
> Komu: "Everything around amforth"
> <amf...@li...>
> Předmět: Re: [Amforth-devel] Progress and More
> Difficulties with
> Hello
> Datum: 30.3.2011 - 4:47:21
> 
> > Hi.
> > 
> > 
> > Am 29.03.2011 um 21:33 schrieb Matthias Trute:
> > ..
> > > Receiving characters is a completly different
> > > thing. The characters
> > > > can come at any time, therefore the code
> > > > needs
> > > > > > to deal with the
> > > > situation relativly fast (at least before
> > > > the
> > > > > > next character
> > > > arrives).
> > 
> > If you just want to connect a terminal to type
> > in
> > > commands, amforth  
> > is fast enough to handle this situation: Wait
> > for
> > > a key, grab it, put  
> > it in inputbuffer, wait again.
> > amforths accepts keys till end of line, then
> > interprets the line.
> > See: uart-rx-poll.asm
> > Since you - the user - wait for the ok of
> > amforth
> > > to appear, there is  
> > no overflow.
> > I use 12Mhz chrystal, 14400 Baud, atmega168,
> > works
> > > fine this way.
> > 
> > But to download a file you have to make shure
> > your
> > > sending program  
> > will immediatly stop sending if a CR is echoed,
> > and continues after  
> > OK is encounterd. Terminals usualy can not
> > handle
> > > this situation.  
> > That is why Mathias is using a Phyton script for
> > downloads.
> > 
> > I use ZTerm with Mac OSX. In typing mode, it
> > stops
> > > sending when XOFF  
> > character is echoed, and continues after XON. So
> > my amforth CR sends  
> > xoff to the Terminal too, and the OK is followed
> > by XON.
> > (Typing mode: copy&paste forth souce into ZTerm
> > window, do not use  
> > ZTerms file transfer feature. Setup the ZTerm as
> > VT100 with line  
> > prompt character ^C ($13 = xoff)).
> > 
> > There may be about two characters on its way
> > down
> > > to amforth till  
> > terminal finaly stops sending more characters. I
> > allways insert 4 or  
> > more blanks at the beginning of each line in my
> > forth sources to  
> > handle this situation. This way interpretation
> > of
> > > a line stays  
> > successful even if some characters are lost in
> > the
> > > handshaking process.
> > 
> > : hallo ." hallo world" ;
> > ^^^^
> > 
> > Maybe this helps.
> > Michael
> > 
> > 
> > ------------------------------------------------------------------------------
> > > > > > Enable your software for Intel(R) Active
> > Management Technology to meet the
> > growing manageability and security demands of
> > your
> > > customers. Businesses
> > are taking advantage of Intel(R) vPro (TM)
> > technology - will your software 
> > be a part of the solution? Download the Intel(R)
> > Manageability Checker 
> > today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > 
> 
> 
> ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active
> Management Technology to meet the
> growing manageability and security demands of your
> customers. Businesses
> are taking advantage of Intel(R) vPro (TM)
> technology - will your software 
> be a part of the solution? Download the Intel(R)
> Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

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

I've been using "Mosaic Terminal" (free download, designed for
forth)under XP. Just set "Wait for Echo" ON and "Binary Char Delay"
0.005 (or less). It runs 115200 8N1 without a problem (when your
crystal allows such speed, of course). Copy/paste sources. This
terminal is the only one I can use with amforth. For FlashForth the
Tera Term (FF supports Xon/Xoff) is the one which works fine any
speed. Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Kalus Michael" <mic...@on...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth-devel] Progress and More Difficulties with
Hello
Datum: 30.3.2011 - 4:47:21

> Hi.
> 
> 
> Am 29.03.2011 um 21:33 schrieb Matthias Trute:
> ..
> > Receiving characters is a completly different
> > thing. The characters
> > > can come at any time, therefore the code needs
> > to deal with the
> > > situation relativly fast (at least before the
> > next character
> > > arrives).
> 
> If you just want to connect a terminal to type in
> commands, amforth  
> is fast enough to handle this situation: Wait for
> a key, grab it, put  
> it in inputbuffer, wait again.
> amforths accepts keys till end of line, then
> interprets the line.
> See: uart-rx-poll.asm
> Since you - the user - wait for the ok of amforth
> to appear, there is  
> no overflow.
> I use 12Mhz chrystal, 14400 Baud, atmega168, works
> fine this way.
> 
> But to download a file you have to make shure your
> sending program  
> will immediatly stop sending if a CR is echoed,
> and continues after  
> OK is encounterd. Terminals usualy can not handle
> this situation.  
> That is why Mathias is using a Phyton script for
> downloads.
> 
> I use ZTerm with Mac OSX. In typing mode, it stops
> sending when XOFF  
> character is echoed, and continues after XON. So
> my amforth CR sends  
> xoff to the Terminal too, and the OK is followed
> by XON.
> (Typing mode: copy&paste forth souce into ZTerm
> window, do not use  
> ZTerms file transfer feature. Setup the ZTerm as
> VT100 with line  
> prompt character ^C ($13 = xoff)).
> 
> There may be about two characters on its way down
> to amforth till  
> terminal finaly stops sending more characters. I
> allways insert 4 or  
> more blanks at the beginning of each line in my
> forth sources to  
> handle this situation. This way interpretation of
> a line stays  
> successful even if some characters are lost in the
> handshaking process.
> 
> : hallo ." hallo world" ;
> ^^^^
> 
> Maybe this helps.
> Michael
> 
> 
> ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active
> Management Technology to meet the
> growing manageability and security demands of your
> customers. Businesses
> are taking advantage of Intel(R) vPro (TM)
> technology - will your software 
> be a part of the solution? Download the Intel(R)
> Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[Kalus M. <mic...@on...>]

Hi.


Am 29.03.2011 um 21:33 schrieb Matthias Trute:
..
> Receiving characters is a completly different thing. The characters
> can come at any time, therefore the code needs to deal with the
> situation relativly fast (at least before the next character
> arrives).

If you just want to connect a terminal to type in commands, amforth  
is fast enough to handle this situation: Wait for a key, grab it, put  
it in inputbuffer, wait again.
amforths accepts keys till end of line, then interprets the line.
See: uart-rx-poll.asm
Since you - the user - wait for the ok of amforth to appear, there is  
no overflow.
I use 12Mhz chrystal, 14400 Baud, atmega168, works fine this way.

But to download a file you have to make shure your sending program  
will immediatly stop sending if a CR is echoed, and continues after  
OK is encounterd. Terminals usualy can not handle this situation.  
That is why Mathias is using a Phyton script for downloads.

I use ZTerm with Mac OSX. In typing mode, it stops sending when XOFF  
character is echoed, and continues after XON. So my amforth CR sends  
xoff to the Terminal too, and the OK is followed by XON.
(Typing mode: copy&paste forth souce into ZTerm window, do not use  
ZTerms file transfer feature. Setup the ZTerm as VT100 with line  
prompt character ^C ($13 = xoff)).

There may be about two characters on its way down to amforth till  
terminal finaly stops sending more characters. I allways insert 4 or  
more blanks at the beginning of each line in my forth sources to  
handle this situation. This way interpretation of a line stays  
successful even if some characters are lost in the handshaking process.

     : hallo ." hallo world" ;
^^^^

Maybe this helps.
Michael

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

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

Hi,

> As I understand it, the amforth way of dealing with interrupts on the 
> serial port is to have the ISR set a flag, and the uart is truly 
> serviced when the inner interpreter steps to the next word.

You are right that the inner interpreter can deal with interrupts (to
some extent), but the usart communication for the command interpreter
does not use it. The reason is simple: I initially wrote it in assembly
language. I tried to redesign it to use the forth interrupts, but never
really succeeded for many and varying reason...

The interrupts amforth can handle with the current inner interpreter
hook are restricted to _not_ require any hardware access during the
interrupts. That means: if an interrupt is triggered and needs to be
cleared by reading some special address (e.g. reading the received
character from the USART data register), that read operation does not
happen.

That means, that the interrupt sources does not get cleared and re-fires
immedieatly, making the system unusable (looks like a crash). Details
are outlines in the docs (somewhere).

Serial communication has to aspects: sending and receiving single
characters.

Sending characters is trivial since the application knows when and what
to send. The hardware module does the lowlevel task for the shifting
out of the bits and framing etc.

This is pure forth code and there is no timing problem (IMHO). Just have
a look at the usart-tx-poll.asm file.

There is an interrupt based routine as well (usart-tx-isr.asm), but
avoid using it. It works but gives no benefit while making the code more
complicated.


Receiving characters is a completly different thing. The characters
can come at any time, therefore the code needs to deal with the
situation relativly fast (at least before the next character
arrives).

The USART receiver can be polled for a character and set a flag if
anything is available. The same flag can be used to trigger an interrupt
that reads the character and handle it. If the polling is done often
enough, it works surprisingly well. This is what the usatz-rx-poll.asm
code does.

A better solution is usart-rx-isr.asm. This code uses interrupts and
an internal ring buffer (16 characters long) to keep the characters.
The KEY and KEY? words simply check the length of the (used) ring
buffer and extract the characters from it.

Matthias

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

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

On 3/27/2011 8:22:27 PM, ken...@al... wrote:
 > Hi, I soldered in a crystal and a couple of caps and
 > it's working fine
 > now, Amforth seems much more sensitive to clock frequency than the
 > Arduino C programs.
 >
 > I've
 > had no trouble with the serial interface running C programs on the
 > BBB. That sent me on some wild goose chases trying to figure out what
 > was wrong with Amforth.
 >

As I understand it, the amforth way of dealing with interrupts on the 
serial port is to have the ISR set a flag, and the uart is truly 
serviced when the inner interpreter steps to the next word. There is an 
elegance to that approach, as it allows secondary ISR to be written in 
forth, but it has more latency than a traditional ISR (grab byte and 
stuff into ring buffer immediately). Without hardware drtiven serial 
handshake, that increased latency may account for the greater  
sensitivity to timing?