amforth-devel

[Amforth-devel] Interrupt handling question

[<ha...@hu...>]

Hi,

I am trying to port my timer interrupt driven display code to
amforth-1.9 and have some problems with that.

On the documentation page
(http://amforth.sourceforge.net/interrupts.php), an example interrupt
handler is printed:

: doint1
    . ( <-- this is dangerous in interrupts )
;

The danger set aside (I guess the dangerous part is the fact that the
UART will generate another interrupt that may not be properly
handled), it seems that this example has a stack effect.  Is this
intended?  Is there something on the stack that the interrupt handler
must remove?

I am asking because my code crashes - If I leave the stack as it was
before entering the interrupt handler, I see periodic reboots (once a
second) when I enable the interrupt handler.  If I pop the topmost
item, amforth plain crashes with trash characters written to the
console.  It could be that the new interrupt handler code is too slow
to work with the timer interrupt, but before getting into debugging
that, I'd like to know if there is something fundamentally wrong with
my code.

BTW:  Is there anything in amforth except ISTORE that writes to flash?
 I am asking because I want to give amforth on a flashless AVR a try.

Thanks!
-Hans

Re: [Amforth-devel] Interrupt handling question

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans,

Hans H=FCbner schrieb:

> I am trying to port my timer interrupt driven display code to
> amforth-1.9 and have some problems with that.
>=20
> On the documentation page
> (http://amforth.sourceforge.net/interrupts.php), an example interrupt
> handler is printed:
>=20
> : doint1
>     . ( <-- this is dangerous in interrupts )
> ;
>=20
> The danger set aside (I guess the dangerous part is the fact that the
> UART will generate another interrupt that may not be properly
> handled), it seems that this example has a stack effect.

Ok, you are right. The example is a non-example. An interrupt
word must not have any stack effect.

>  Is this intended?

not really, sorry.

> Is there something on the stack that the interrupt handler
> must remove?

no. All the low level interrupt stuff is handled by amforth (namely
the reti instruction). On forth level there is no state to keep other
than the stacks.

> I am asking because my code crashes - If I leave the stack as it was
> before entering the interrupt handler, I see periodic reboots (once a
> second) when I enable the interrupt handler.

without your code it is difficult to analyze.

> If I pop the topmost
> item, amforth plain crashes with trash characters written to the
> console.

Well, that is most likly, see above.

> It could be that the new interrupt handler code is too slow
> to work with the timer interrupt,

The new code is faster then the old one.

> but before getting into debugging
> that, I'd like to know if there is something fundamentally wrong with
> my code.

you could try using a semaphore like flag to detect an interrupt
overrun.

> BTW:  Is there anything in amforth except ISTORE that writes to flash?

No, all words which write to flash call i! to do the "real work".

>  I am asking because I want to give amforth on a flashless AVR a try.

What's a flashless AVR??? Sounds like sodium free salt ;=3D)

Bye
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGNHVz9bEHdGEMFjMRAricAKCM3peY2gh0WLnTUqXK76nQHmws8gCgovch
DQ2roL6T+z0PnyYfNQdKBNM=3D
=3D+/GU
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Interrupt handling question

[<ha...@hu...>]

Hi Matthias,

2007/4/29, Matthias Trute <mt...@we...>:
> > I am asking because my code crashes - If I leave the stack as it was
> > before entering the interrupt handler, I see periodic reboots (once a
> > second) when I enable the interrupt handler.
>
> without your code it is difficult to analyze.

I take this as encouragment:

: start-display ( -- )
    init-display \ sets up port directions, globals
    0 display-number \ display a number

    ['] refresh-display 11 int! \ set up interrupt handler (we're in decimal)

    \ Timer clock => sysclk / 256
    4 TCCR0 c!
    \ Timer0 einschalten
    1 TIMSK c!
;

> >  I am asking because I want to give amforth on a flashless AVR a try.
>
> What's a flashless AVR??? Sounds like sodium free salt ;=)

It is one that uses the AVR_Core of OpenCores.  I am working on a FPGA
based CPU, and I need a simple controller environment in order to boot
the real CPU, inspect memory and the like.  I was using an 6809 until
now, but I have not been able to find a Forth interpreter for that, so
I had to use GCC.  It worked, but having to recompile and download the
debug monitor was kind of tedious.  Having an interactive environment
would be much preferable.

BTW:  For that project, I will also reanimate my "compile from ROM"
idea from months ago.  I got that mechanism working fine, but one
thing that is kind of burdensome is the fact that, after compiling
amforth I have to upload my compile-from-rom module before I can
actually compile.  Do you have a tool that aids in translating Forth
to Assembler, or to disassemble or some such?  It would not be too
hard to do it by hand, but it would still require some experience
which I do not have.

Cheers,
Hans

Re: [Amforth-devel] Interrupt handling question

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Hans,

> I take this as encouragment: 

> \ Timer clock => sysclk / 256 
> 4 TCCR0 c!
> \ Timer0 einschalten 
> 1 TIMSK c!

looks innocent but crashes here too :=(
I'll look at it very closly ASAP..

>> What's a flashless AVR??? Sounds like sodium free salt ;=)
> 
> It is one that uses the AVR_Core of OpenCores.

Cool stuff. What hardware do you use for it? Not that
I want to work with it, but to get a feeling for it...

> Having an interactive environment would be much preferable.

Forth has its advantages ;=)

> BTW:  For that project, I will also reanimate my "compile from ROM" 
> idea from months ago.

I think about the change from INTERPRET to EVALUATE. But it would work
with RAM strings, not FLASH strings...

> Do you have a tool that aids in translating Forth to Assembler,

I don't _have_ such a tool, I _am_ that tool ;=)

> or to disassemble or some such?

A kind of disassembler creates the html pages of
http://amforth.sf.net/words/ . It is written in
poor write-only perl, but drop me a line if you
want it.

> It would not be too hard to do it by hand, but it would still require
> some experience which I do not have.

It's not that difficult to convert forth -> ASM/XT_* by hand. esp when
the code already works ... I know that at least 2 members of this list
can do it ;=)) But they asked for such a tool too, there seems to be a
real demand for it...

Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGNPYY9bEHdGEMFjMRAn7aAJ9ak3ea7PFpfrCyMrlDPyOBfecR/ACgx/Jz
vWyF/UIFoy2VQnAirVtYz+w=
=tUum
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Interrupt handling question

[<ha...@hu...>]

Hi Matthias,

2007/4/29, Matthias Trute <mt...@we...>:
> >> What's a flashless AVR??? Sounds like sodium free salt ;=)
> >
> > It is one that uses the AVR_Core of OpenCores.
>
> Cool stuff. What hardware do you use for it? Not that
> I want to work with it, but to get a feeling for it...

I am using the Spartan 3E Starter Kit
(http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_47&products_id=92&language=en),
which is pretty cheap and has all sorts of peripheral chips.

> > Do you have a tool that aids in translating Forth to Assembler,
>
> I don't _have_ such a tool, I _am_ that tool ;=)

Given that the routines I need are really simple, maybe I can use you
as the tool?  My mechanism may also fill the needs of others:  I have
set up the necessary scripting that converts one or more forth files
(using "\ include" as syntax) to a hex file that can be flashed.  The
source is flashed so that the last adress is right below the boot
block.  Comments and while space are stripped.  The compile-from-rom
forth program changes the input vectors so that characters are read
from ROM until the last byte below the boot block has been hit.  Then,
the input vectors are set back to rx0/rx0?.

Together with my scripting mechanics (and the Forth file translated to
assembler), it will be possible to build a complete amforth system
from source without having to go round-trip to the target.  Presently,
my automatism stops after having compiled amforth and sent both
amforth and the source to be compiled to the target, because I first
need to upload the compile-from-rom stuff through the serial port.

It may even be good to add some more code so that the source can be
viewed on the target (in the tradition of making the source code
available to the "customer").

For my FPGA application, I will propably put the source into the
serial flash and compile from there, but I first want to have this
running on a real AVR.

Thanks for your support,
Hans

Re: [Amforth-devel] Interrupt handling question

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Hans,
>> > Do you have a tool that aids in translating Forth to Assembler,
>>
>> I don't _have_ such a tool, I _am_ that tool ;=)
> 
> Given that the routines I need are really simple, maybe I can use you
> as the tool?

I wont recommend me for routine tasks. I'm buggy[1] and my overhead
is pretty high since I tend to write scripts to assist me ;)

> My mechanism may also fill the needs of others:  I have
> set up the necessary scripting that converts one or more forth files
> (using "\ include" as syntax) to a hex file that can be flashed.  The
> source is flashed so that the last adress is right below the boot
> block.  Comments and while space are stripped.  The compile-from-rom
> forth program changes the input vectors so that characters are read
> from ROM until the last byte below the boot block has been hit.  Then,
> the input vectors are set back to rx0/rx0?.

I had quite a few uses for this io redirect, but yours is ingenious.

> Together with my scripting mechanics (and the Forth file translated to
> assembler), it will be possible to build a complete amforth system
> from source without having to go round-trip to the target.

That would be a host based compiler. Do you know the avr assembler
from Daniel Kryzcena? (krue.net). It is written for gforth and he
makes his avrforth with it.

> It may even be good to add some more code so that the source can be
> viewed on the target (in the tradition of making the source code
> available to the "customer").

You drive the idea of a "stand-alone" system to it's limit, don't you?

> For my FPGA application, I will propably put the source into the
> serial flash and compile from there, but I first want to have this
> running on a real AVR.

What's wrong with your io redirect? Put the base system into whatever
the flash is and let KEY read from eeprom, btw: do you want to publish
this module?

Bye
Matthias

[1] I found a stupid error in the interrupt system. For my atmegas
timer0 now increases a variable with your settings for an
hout by now... See svn trunk.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGNeEd9bEHdGEMFjMRAvWmAKDs1a68VzFdUc5/jwz5wg3CbPCKWwCgsQh3
w1LUgL67WNgR5j7rdjxiLco=
=AKs+
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Interrupt handling question

[<ha...@hu...>]

Hi Matthias,

2007/4/30, Matthias Trute <mt...@we...>:
> > Together with my scripting mechanics (and the Forth file translated to
> > assembler), it will be possible to build a complete amforth system
> > from source without having to go round-trip to the target.
>
> That would be a host based compiler. Do you know the avr assembler
> from Daniel Kryzcena? (krue.net). It is written for gforth and he
> makes his avrforth with it.

I have not looked at it, and the one thing I love most about amforth
is the fact that it is completely target-based.  Being able to hack
through a system interactively and to try out things and redefine
words on the fly is just great.  I don't want a host-target
configuration.

My mechanism is more useful for automatic deployment.  I usually put
the Forth source I work with into an open editor and then cut and
paste between my editor and the terminal program connected to the AVR.
 At some point in time, I decide that I need to start with a fresh
amforth (either because there is a new version, because my flash is
full or because I want to move from one AVR to another).  In that
case, I want to use my source file and replicate the installation on
another AVR, from scratch, with as little manual interaction as
possible.

> You drive the idea of a "stand-alone" system to it's limit, don't you?

Yeah, maybe.  Also the idea of "Open Source" makes most sense if the
source is always delivered with the system.  :)

> > For my FPGA application, I will propably put the source into the
> > serial flash and compile from there, but I first want to have this
> > running on a real AVR.
>
> What's wrong with your io redirect? Put the base system into whatever
> the flash is and let KEY read from eeprom

Exactly that!  It is just the missing link from *.asm + *.frt to a hex
file that automatically starts when I switch on the power of the AVR
that bothers me :)

> btw: do you want to publish this module?

You mean the compile-from-rom stuff?  Sure, if anyone wants to use it,
take it.  If someone asks, I'll also put some more comments and
options into the perl and makefile stuff.  Just let me know.

> [1] I found a stupid error in the interrupt system. For my atmegas
> timer0 now increases a variable with your settings for an
> hout by now... See svn trunk.

Thanks!  I'll check it out later on!

Cheers,
Hans

Re: [Amforth-devel] Interrupt handling question

[<ha...@hu...>]

2007/4/30, Matthias Trute <mt...@we...>:
> [1] I found a stupid error in the interrupt system. For my atmegas
> timer0 now increases a variable with your settings for an
> hout by now... See svn trunk.

I tried my display stuff with the trunk version, but it still crashes
once I unmask the interrupt.  I am using an atmega32 on an STK500,
maybe something is wrong with the definitions for that CPU?  What CPU
type do you test with?

Thanks!
Hans

Re: [Amforth-devel] Interrupt handling question

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans,

Hans H=FCbner wrote:

> I tried my display stuff with the trunk version, but it still crashes
> once I unmask the interrupt.  I am using an atmega32 on an STK500,
> maybe something is wrong with the definitions for that CPU?  What CPU
> type do you test with?

atmega32 @ 16 MHz

variable cnt0
0 cnt0 !
: inccnt0 1 cnt0 +! ;
' inccnt0 0B int!

works fine even for TCCR0 set to 1 (prescaler 64).
> 1 TIMSK c!
 ok
> TCCR0 c@ .
 4 ok
> : s1 10 0 do cnt0 @ . loop ;
 ok
> s1
 39AA 39AB 39AC 39AD 39AE 39B0 39B1 39B2 39B4 39B5 39B6 39B7 39B9 39BA
39BB 39BC
 ok
> 1 TCCR0 c!
 ok
> s1
 -106D -D1B -A53 -78C -4C5 -1FE CA 28E 4DA 728 973 BBE E0E 105C 1334 160A=
 ok

At that speed even the compiler works for a hello-world word..

I'd suspect your refresh-display code...

Bye
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGNuK29bEHdGEMFjMRAlY9AKDZCjlX7Ax1fbDj/J1Uh8kfSSqmwACcCSRT
+NlR4ZJsjw3pWWfLTCLKtME=3D
=3DrARo
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Interrupt handling question

[<ha...@hu...>]

2007/5/1, Matthias Trute <mt...@we...>:
> I'd suspect your refresh-display code...

... and rightfully so.  I had put a drop into it as I suspected that
there would be something on the stack to drop and forgot to remove
that.  Things run fine now, thanks for the fix!

-Hans