amforth-devel — Development discussion and user support

[Amforth-devel] Constant array?

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

Hi,

(I am a beginner in Forth, so please excuse me if the question is stupid).

I need to create a lookup table in Flash which will be used to
translate decimal digits to 7 segment display digits.

In a RAM-based forth, I could write something like

table constant -2 allot
63 , 6 , 91 , 79 , 102 , 109 , 125 , 7 , 127 , 111 ,

This would (as far as I understand) a base pointer table that pointed
to the 63, with the other values following.

How would I do this with amforth?  As far as I can read from the
source code, allot acts on the heap (RAM) pointer.  Is there something
equivalent to allot that acts on the current dictionary pointer?  I
would be willing to waste one byte for each entry in the table and use
16 bits for each, but i=B4d like to easily access the base pointer of
the table.

Thanks!
Hans

Re: [Amforth-devel] python uploading script

[pix <pi...@te...>]

On Fri, Mar 09, 2007 at 09:01:24AM +0100, Matthias Trute wrote:
> Limit the number of characters sent per second to some adjustable
> value

actually, why would this be necessary? has anyone encountered the
buffers getting overloaded with the echo-tracking flow control scheme?

if you just want to send characters slowly, there is pv, and ascii-xfr
(comes with minicom, alows separate character/line delays).

the idea of amforth-upload was to upload as fast as possible without
overloading amforth.

.. and timing is a pain to implement ;)

pix.

Re: [Amforth-devel] python uploading script

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

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

pix schrieb:
> On Fri, Mar 09, 2007 at 09:01:24AM +0100, Matthias Trute wrote:
>> Limit the number of characters sent per second to some adjustable
>> value
> 
> actually, why would this be necessary? has anyone encountered the
> buffers getting overloaded with the echo-tracking flow control scheme?

As I wrote: Those are wishes other users wrote to me, maybe not related
directly with your tool. personally I think that your scheme is quit
good, I cannot imagine how it can overload the amforth buffers (I do
hope that someday a "real" flow control will work).

Matthias

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

iD8DBQFF8VGQLo3irIddFw4RAtK5AJ9x5Gm1J8D0o8OYwQSZbR3DOR3qIQCfSUHz
rAdiWuJH9SbKcLS6ddNf4NA=
=Tu15
-----END PGP SIGNATURE-----

Re: [Amforth-devel] python uploading script

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

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

Hi Pix,

> would it be to ugly to have the script implement "INCLUDE" and
> "INCLUDE?" on it's side?

I see no other place to implement it. If amforth sees these instructions
it will abort.

>> If amforth signals an abort instead of the ok the script should stop
>> uploading.
> 
> do you mean, any of the error messages starting with "??" ?

Yes.

>> Limit the number of characters sent per second to some adjustable value
> 
> hmmm. doable i guess. 
> 
> i was wondering, would there be any value in sending a few more
> characters than have been echoed back? is there any kind of buffer?

there are two buffers: usart receive buffer (16 characters long) and the
forth TIB (80 characters). Only the characters in the TIB had echos
back to the serial line (except some control characters). The usart
buffer keeps the "unread" characters that wait for the next execution
of key. I'm not fully satisfied with it but it works "good enough",
at least for me....

> i was thinking the script at the moment might be too cautious.

That's impossible ;=)

Bye
Matthias

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

iD8DBQFF8RRULo3irIddFw4RAhGlAJwMSYRYj410g+2M/zfsLqC6HI93eQCgyc9c
6Tg4X0S92vVOpRa7r2sESSg=
=comk
-----END PGP SIGNATURE-----

Re: [Amforth-devel] python uploading script

[pix <pi...@te...>]

On Thu, Mar 08, 2007 at 09:21:45PM +0100, Matthias Trute wrote:
> Hi Pix,
> 
> > is there any kind of accepted standard for forth
> > pre-processor syntax?
> 
> None I'm aware, but a few users wrote me in PM some wishes:

would it be to ugly to have the script implement "INCLUDE" and
"INCLUDE?" on it's side?

> If amforth signals an abort instead of the ok the script should stop
> uploading.

do you mean, any of the error messages starting with "??" ?

> Limit the number of characters sent per second to some adjustable value

hmmm. doable i guess. 

i was wondering, would there be any value in sending a few more
characters than have been echoed back? is there any kind of buffer? i
was thinking the script at the moment might be too cautious.

i noticed it's also possible to add the script as an upload protocol in
minicom. you need to set the -f option so that it doesn't check to see
who else has the tty open.

> I've added a link to your site in the FAQ.

oh, thanks.

pix.

Re: [Amforth-devel] python uploading script

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

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

Hi Pix,

> is there any kind of accepted standard for forth
> pre-processor syntax?

None I'm aware, but a few users wrote me in PM some wishes:

If amforth signals an abort instead of the ok the script should stop
uploading.

Limit the number of characters sent per second to some adjustable value


I've added a link to your site in the FAQ.

Matthias

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

iD8DBQFF8HBZLo3irIddFw4RAu7VAKDApeaPBKVWL22fNKwiUPTT/0X/KgCggG+U
iIHA90f9sYGN3PdiGCZmyNM=
=6UCu
-----END PGP SIGNATURE-----

[Amforth-devel] Windows Terminal for amForth

[Marcel D. <mde...@my...>]

Hi Windows users,
Assembling amForth 1.3 with AVRStudio under Windows

Since I own a test board with an atmega32, all the following hints refer to this controller and its
related source files. They should be usable to the other controllers too, by replacing 'mega32'
files with 'megaxx' where applicable. As for the moment I have not tested any of them.

Assembling original source files with AVRASM2 in Atmel AvrStudio 4.12 yields the following errors:
(numbered 1. to 5.)

1. Invalid redifinition of 'RWWSRE'   in atmega32.asm (line 16)
2. Invalid redifinition of 'UDR0'     in atmega32.asm (line 22)

   These values are defined in m32def.inc in the first place (file comes with AVRStudio);

   Resolved by commenting out line 16 in atmega32.asm, by commenting out line 22 in atmega32.asm
   and by replacing UDR0 with UDR in uasrt.asm source file. (m32def.inc is a system file and must
   not be altered).

      A fix should replace UDR0 in atmega32.asm with a new definition (e.g. UDR_0)
      or replace UDR0 with UDR in amForth sources.
      References to UDR0 are in:
        atmega8.asm
        atmega16.asm
        atmega32.asm
        atmega168.frt
        usart.asm
      I replaced UDR0 by UDR (24feb07)!

3. Undefined label TWSIaddr in atmega32.asm (line 68)

   Resolved by changing TWSIaddr into TWIaddr in line 68

4. Overlapping of object code in cseg in usart.asm (line 10)
5. Overlapping of object code in cseg in usart.asm (line 12)

   Atmels assembler does not accept different code sequences for the same address range (imho this
   is bad practice anyway).

   Resolved by commenting out several lines in usart.asm (lines 6..14) like this:

    /* .set pc_ = pc

    .org URXCaddr
      rjmp usart0_rx_isr
    .org UDREaddr
      rjmp usart0_udre_isr

    .org pc_ */

   and by modifying interrupt vectors in atmega32.asm:
    .org        URXCaddr ; USART Receive Complete Interrupt Vector Address
        rjmp usart0_rx_isr
    .org        UDREaddr ; USART Data Register Empty Interrupt Vector Address
        rjmp usart0_udre_isr

   I modestly think the interrrupt vectors belong in atmega32.asm rather than in usart.asm.


The resulting code assembles with no error and runs on my test board.

Note: in AvrStudio you must manually save any changed files before a new build!

Corrections above yield the following values (e.a.):

EQU  URXCaddr     0000001a
EQU  UDREaddr     0000001c
EQU  RWWSRE       00000004
EQU  UDR          0000000c
EQU  UDR0         00000000 ; These seem to be correct.

Any feedback welcome!

md 24feb07, 03mar07

-- 
derri

Re: [Amforth-devel] Windows Terminal for amForth

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

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

Hi,

Marcel Derrmann wrote:

> AmForth is not limited to Linux users. Although the sources are
> written for the avra assembler, you can build amForth with Atmels
> AVRStudio, after half a dozen of minor changes. If there is interest,
> I can mail or post my approach.

Please do so.

Most (all?) of the changes are due the fact that avra (the linux
assember I use) does not understand the avrasm2 syntax. The include
files from avrasm1 and avrasm2 do not contain the same definitions.
For whatever reason...


> What about including the hex target files in the amForth download?

They can only be used for a very limited range of hardware platforms.
Even such an trivial change as the oszillator frequency needs a
rebuild. For this reason I do not publish hexfiles. Future versions
for specific target may have hexfiles, the AVR butterfly or "my"
little robots are candidates for this.

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

iD8DBQFF6+StLo3irIddFw4RAhvHAKCLPsmjNGeI9pdNypZzmnRELd+v0QCfaRP4
Jtj0f35u/50nsbGcf7GtSn0=
=W9Gg
-----END PGP SIGNATURE-----

[Amforth-devel] New release 1.4

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

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

Hi,

I've just compiled release 1.4 of amforth before the changelog
is getting too long ;=)

It contains a few new words..

abort" ( f -- ) prints the string and aborts if flag permits
unused ( -- n)  returns the number of unsed flash cells
                  (multiply with 2 and you get the number of
                   bytes)

.. some words changed ..

pad does no longer have it's own ram space. It is now located
at and above heap. please note, that word uses pad too.

case & co are now in an optional compile-time dictionary. This
dictionary is intended to be used for "bigger" atmegas and
contains some other words like d+ d- etc.

quit has some internal changes (see abort") and any thrown
exception will do abort too.

/mod is changed from usigned division to signed (symmetric)
/ and mod depend on it and have changed therefore too. The
old /mod may re-appear as u/mod in the optional dictionary
if needed.

serial flow control (xonxoff) still does not work, it is not
included in this release.



Have fun with it

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

iD8DBQFF6+DILo3irIddFw4RAuddAJ4yN4feuhKwsitWCQmWxO5j4wF67wCguFV/
TCnsvbExWprrDLjueyr/OdM=
=ZkTm
-----END PGP SIGNATURE-----

[Amforth-devel] Here is a code example for LCD display on AVR Butterfly.

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

Hi. Its experimental. Any idea making a background task using the  
interrupt of amforth?
   http://www.forth-ev.de/wiki/doku.php/projects:avr:beispielsoftware


michael

[Amforth-devel] Windows Terminal for amForth

[Marcel D. <mde...@my...>]

Hi Windows users,

AmForth is not limited to Linux users. Although the sources are
written for the avra assembler, you can build amForth with Atmels
AVRStudio, after half a dozen of minor changes. If there is interest,
I can mail or post my approach.

What about including the hex target files in the amForth download?
  
To play around with amForth under Windows, I use NMITerm.exe as a
terminal. It handles uploads automatically, (e.g. to compile sources
like the hardware definition files into the target system). You only
have to convert the source files from Unix style to Dos style (i.e.
replace line ends LF (0x0A) with CR LF (0x0D 0x0A).

  The terminal installer NMITerm can be found at
  http://www.newmicros.com/ after clicking the "Downloads" button.

-- 
derri

Re: [Amforth-devel] python uploading script

[pix <pi...@te...>]

On Fri, Mar 02, 2007 at 04:45:56PM +0100, Matthias Trute wrote:
> > i took hans' suggestion and made it strip out comments before
> > uploading.  it uses a regular expression, so there is the
> > possibility that it will strip out comment-shaped things inside a ."
> > " group, but apart from that it seems to work.
> 
> Cool stuff. Can you add an include statement? That could simplify
> greater uploads or rebuilds.

good idea. is there any kind of accepted standard for forth
pre-processor syntax?

actually, since the script can read from the commandline, you could do
include with m4 or cpp.

pix.

[Amforth-devel] python uploading script

[pix <pi...@te...>]

On Fri, Mar 02, 2007 at 06:57:48AM +0100, pix wrote:
> i've just been working on a python script to upload forth source files
> to amforth. it watches the character echo to do a kind of software
> flow control, and waits for a prompt after each line. to test it with
> different inputs, i've been using the files in blocks, and when i hit
> blocks/interrupts.frt i ran into what i think is a parser bug in
> amforth.

i took hans' suggestion and made it strip out comments before uploading.
it uses a regular expression, so there is the possibility that it will
strip out comment-shaped things inside a ." " group, but apart from that
it seems to work.

the script is here:

http://libarynth.fo.am/cgi-bin/view/Libarynth/AmForth#better%20uploading%20with%20python

you probably need linux or at least osx to run this. it might also work
under windows if it is possible to specify a serial port as a filename
(like COM1:).

i also have a note on the page about adding backup/restore rules to the
makefile, because matthias said this was tricky in an earlier post.

pix.

Re: [Amforth-devel] leftbracket bug

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

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

Pix,

> when given a long sequence starting with a right bracket, after hitting
> enter, amforth basically goes crazy and needs to be reset. it gets
> triggered by the first line of blocks/interrupts.frt:

Thanks. The solution is quite simple: Increase PADSIZE in
devices/atmega...asm to at least TIBSIZE. Then ( should
work if the closing backet is on the same line. Multiline
comments still won't work, since the interpreter does not
hold the "comment state" over line breaks (like e.g. the
compile state).

> as you can see it doesn't matter if you close the sequence or not.

your xxx are to much and to long That will overwrite internal
data structures. Too bad, the atmega does not have virtual
memory with page protection ;=)

> this is with amforth 1.3

I will document it, so that others may decide if they
want to live with short word comments in () or use \.
Increasing the default has drawbacks since it needs
a lot more of the very short RAM.

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

iD8DBQFF58Z/Lo3irIddFw4RAvqRAJ4sz8oKSjFj1UAqXynE8ejlT3hdDgCeLlkf
Y/50CvLip+PrgEgvNqG+3nY=
=5mkh
-----END PGP SIGNATURE-----

[Amforth-devel] leftbracket bug

[pix <pi...@te...>]

hi,

i've just been working on a python script to upload forth source files
to amforth. it watches the character echo to do a kind of software flow
control, and waits for a prompt after each line. to test it with
different inputs, i've been using the files in blocks, and when i hit
blocks/interrupts.frt i ran into what i think is a parser bug in
amforth.

when given a long sequence starting with a right bracket, after hitting
enter, amforth basically goes crazy and needs to be reset. it gets
triggered by the first line of blocks/interrupts.frt:

( make noop the default interrupt word )

as a test i made a file of different length leftbracket sequences:

> ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 ok
> ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 ok
> ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 ok
> ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 ok
> ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>^[[?1;2c^[[?1;2c

the stuff at the end is amforth going squirrely and confusing my terminal.

here is the same test but with closed bracket sequences:

> ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx )
 ok
> ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx )
 ok
> ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx )
 ok
> ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx )
 okøø ^[[?1;2c

as you can see it doesn't matter if you close the sequence or not.

this is with amforth 1.3

pix.

Re: [Amforth-devel] hello world (eg LED blinking)

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

Hans H=FCbner schrieb:

> Cool, a Wiki!  Matthias, would you think that an amforth Wiki would be
> good? I mean, one that is linked from your project page or even one
> that _is_ your project page?

the amforth site itself: no. The work to install and maintain such
an installation (yes, I do know a lot of wikis) is no real fun (for me).

bye
Matthias

Re: [Amforth-devel] hello world (eg LED blinking)

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

pix schrieb:
> hi,
> 
> i just spent some time playing around with amforth. so far, the fruits
> of my labour don't go much further than the uC hello-world equivalent of
> blinking an LED, but i have written it up anyhow incase anyone is
> interested in a really basic example:
> 
> http://libarynth.fo.am/cgi-bin/view/Libarynth/AmForth

Cool.

> ideally i would have things like PORTC and DDRC as constants, and a word
> for building the right bitmask, but one step at a time, this is my first
> forth ;)

In addition to what Hans wrote you may  find blocks/pollin.frt
interesting too. It contains a similar "hello word" for a development
boards from www.pollin.de (no, I am not a reseller or get any
benefit from them)

> also, how do i delete a word?

You have to load the word forget from blocks/ans.frt (you can load the
entire file and get many more or less useful words or copy'n'paste the
definition). "forget" was removed to save space in the default
installation.


Matthias

Re: [Amforth-devel] hello world (eg LED blinking)

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

2007/3/1, pix <pi...@te...>:
> i just spent some time playing around with amforth. so far, the fruits
> of my labour don't go much further than the uC hello-world equivalent of
> blinking an LED, but i have written it up anyhow incase anyone is
> interested in a really basic example:
>
> http://libarynth.fo.am/cgi-bin/view/Libarynth/AmForth

Cool, a Wiki!  Matthias, would you think that an amforth Wiki would be
good?  I mean, one that is linked from your project page or even one
that _is_ your project page?

> ideally i would have things like PORTC and DDRC as constants, and a word
> for building the right bitmask, but one step at a time, this is my first
> forth ;)

There are constants for the supported CPUs in the devices/ directory.
Cut and paste the file to your Atmel, off you go!

Cheers,
Hans

[Amforth-devel] hello world (eg LED blinking)

[pix <pi...@te...>]

hi,

i just spent some time playing around with amforth. so far, the fruits
of my labour don't go much further than the uC hello-world equivalent of
blinking an LED, but i have written it up anyhow incase anyone is
interested in a really basic example:

http://libarynth.fo.am/cgi-bin/view/Libarynth/AmForth

ideally i would have things like PORTC and DDRC as constants, and a word
for building the right bitmask, but one step at a time, this is my first
forth ;)

also, how do i delete a word? from my learning and experimenting i have
lots of multiply defined BLINK words ;)

thanks,

pix.

Re: [Amforth-devel] amforth-1.3 on atmega8

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

Hans,

> Is there any information available on how one would proceed to get an
> application running with amforth?

there are (nearly) no code examples specific for amforth. The homepage
(amforth.sf.net) has some trivial examples..

But amforth tries to speak the standard (ans94) forth dialect, so it
should not be too difficult to find example code. amforth does not have
all ans94 words, but those present should work as specified.

> I see that there are several files
> in the blocks/ subdirectory that appear to be Forth libraries, but how
> would I add those files to the Flash image?

Just transfer them line by line (with a delay of approx 1 sec between
2 lines) to the controller. Don't push them too fast to the =B5C, the
serial line has no handshake and will terribly overloaded. I use a
simple perl script which may work on linux only however. The handshake
(xon/xoff or rts/cts) is still on my todo list...

One user told me that he uses avrdude to transfer the flash/eeprom
back to the host computer to save time to re-install the system if
needed. Really tricky.

> Is the svn repository available for public read access?

It is publicly readable, Instructions are at

http://sourceforge.net/svn/?group_id=3D179967

> Again, thanks for your support and this great piece of software!

I really would like hear more.

Matthias

Re: [Amforth-devel] amforth-1.3 on atmega8

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

Hello Matthias,

thanks for your quick reply.  The problem has been the clock.  At 8
Mhz, 9600 are not really attainable and I guess that the AVR just
received garbage when I was trying to define a word.  I installed a
3.6864 Mhz xtal and now things work on the ATMEGA8L-8PI just fine!
Great!  Thanks for this very cool piece of software.

Is there any information available on how one would proceed to get an
application running with amforth?  I see that there are several files
in the blocks/ subdirectory that appear to be Forth libraries, but how
would I add those files to the Flash image?

Is the svn repository available for public read access?

Again, thanks for your support and this great piece of software!

-Hans

2007/2/26, Matthias Trute <mt...@we...>:
> Hello Hans,
>
> > I am now trying to run amforth-1.3 on an atmega8l-8pi.  Compiling and
> > flashing the software went fine, and I get the startup banner.
> > Interactive commands work, but if I try to define a word, the system
> > crashes and I seem to need to reprogram the eeprom to recover.  Does
> > anyone have a hint?
> >
> > amforth 1.3
> >
> >> 1 2 3 + + .
> >  6 ok
> >> : foo 1 2 + . ;
> >  ?? FFF3 C
>
> On my Atmega8 (16PU) everything works fine. No problems.
> Please check your fuses & lockbits and re-set them to
> factory defaults (except oscillator settings). Basically the
> fff3 is decimal -13 and that means that the word ending at
> character 12 (the c says that) was not found and could be converted
> to a number. For version 1.3 you could try to enter the
> ; again, since the interpreter remains in compilation mode even
> for such aborts.
>
> The upcoming version 1.4 (svn trunk) will reset the state to
> interpreter mode.
>
> Bye
> Matthias
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] amforth-1.3 on atmega8

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

Hello Hans,

> I am now trying to run amforth-1.3 on an atmega8l-8pi.  Compiling and
> flashing the software went fine, and I get the startup banner.
> Interactive commands work, but if I try to define a word, the system
> crashes and I seem to need to reprogram the eeprom to recover.  Does
> anyone have a hint?
> 
> amforth 1.3
> 
>> 1 2 3 + + .
>  6 ok
>> : foo 1 2 + . ;
>  ?? FFF3 C

On my Atmega8 (16PU) everything works fine. No problems.
Please check your fuses & lockbits and re-set them to
factory defaults (except oscillator settings). Basically the
fff3 is decimal -13 and that means that the word ending at
character 12 (the c says that) was not found and could be converted
to a number. For version 1.3 you could try to enter the
; again, since the interpreter remains in compilation mode even
for such aborts.

The upcoming version 1.4 (svn trunk) will reset the state to
interpreter mode.

Bye
Matthias

[Amforth-devel] amforth-1.3 on atmega8

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

Hi,

I found amforth yesterday and was very happy about that!  I'm teaching
my son Forth as the first programming language and it would be very
cool if he could have some fun with an AVR.

I am now trying to run amforth-1.3 on an atmega8l-8pi.  Compiling and
flashing the software went fine, and I get the startup banner.
Interactive commands work, but if I try to define a word, the system
crashes and I seem to need to reprogram the eeprom to recover.  Does
anyone have a hint?

amforth 1.3

> 1 2 3 + + .
 6 ok
> words
up 0 1ms >< cmove> i! i@ i sp! sp@ rp! rp@ +! rshift lshift 1- 1+ not xor or and
 /mod 2* 2/ invert * + - 0> 0< > < 0= = 0<> <> r@ >r r> rot drop over swap ?dup
dup c@ c! ! @ e@ e! abort execute exit noop ver interpret .s idump depth rp0 sp0
 compile immediate recurse ( \ user constant variable [ ] ; : does> create <reso
lve <mark >resolve >mark pause 'pause quit find word number char endcase endof o
f case +loop loop do again until repeat while begin then else if throw catch han
dler ['] ' words type itype ." digit accept . sign #> #s # <# hold count space c
r max min abs mod / negate 'turnkey heap edp bl hex decimal , allot here head dp
 key? 'key? key 'key emit? 'emit? emit 'emit hld pad tib #tib >in base state lit
eral rx0? rx0 tx0? tx0 intvector intcounter  ok
> : foo 1 2 + . ;
 ?? FFF3 C

Thanks!
Hans

Re: [Amforth-devel] Looking for examples

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

Gerald,

> Are there any "usable" examples that illustrate the usage
> of amforth with microcontrollerspecific tasks?

Not yet. Maybe later I will add some basic
routines like TWI/I2C or SPI access.

> just to get a glimpse on it a simple timerbased port high/low thingy would
> be nice.

You name a current task : the timer doesn't really work with
amforth. I work on it, but don't have a solution.

 > would amforth be usable for things like the example on the bottom
> of this email too?

Since I intend to control some little robots, the are chances that
amforth will do such tasks, sometime. But don't hold your breath for
it..

Bye
Matthias

[Amforth-devel] Looking for examples

[<gl...@re...>]

Hello,

Are there any "usable" examples that illustrate the usage
of amforth with microcontrollerspecific tasks?

just to get a glimpse on it a simple timerbased port high/low thingy woul=
d
be nice.

i could not find that usefull examples on the projects webpage.
only fragments.

would amforth be usable for things like the example on the bottom
of this email too?
(a simple servocontroller utilizing 2 timers and powermanagement.
atmega16@16Mhz)

btw.

id like to use amforth to build a reconfigurable scheduler with an
external rtc as timekeeper.


thanks
 gerald




static void io_init(void)
{
PORTA =3D 0x0;
DDRA =3D 0x0;
PORTB =3D 0x0;
DDRB =3D 0xff;
PORTC =3D 0x0;
DDRC =3D 0x0;
PORTD =3D 0x0;
DDRD =3D 0x0;
ACSR =3D 0x80;
}

void timers_init(void)
{
//timer0
OCR0 =3D 160;
TCNT0 =3D 96;
SET_BIT(TCCR0,CS00);
SET_BIT(TIMSK,TOIE0); // timer0 overflow als interruptquelle
SET_BIT(TCCR0,WGM00); //fast PWM
SET_BIT(TCCR0,WGM01);
//timer1
OCR1A =3D 50000;
OCR1B =3D 50000;
TCNT1 =3D 60550;
TCCR1A =3D 0x00;
TCCR1B =3D 0x02;
//timer1 -prescaler
SET_BIT(TCCR1B,CS10);
SET_BIT(TIMSK,TOIE1); // time1 overflow als interruptquelle
}


SIGNAL(SIG_OUTPUT_COMPARE0)
{
static unsigned int counter;
 PORTB =3D 0xff;
 counter++;
 if (counter >=3D 130)
 { PORTB =3D 0x00;
        CLEAR_BIT(TIMSK,OCIE0);
        TCNT1 =3D 60550;
        SET_BIT(TIMSK,TOIE1);
        counter =3D 0;
 }
}

SIGNAL(SIG_OVERFLOW1)
{
cli();
CLEAR_BIT(TIMSK,TOIE1);
SET_BIT(TIMSK,OCIE0);
sei();
}


int main(void)
{
        io_init();
        timers_init();
        sei();
        set_sleep_mode(SLEEP_MODE_IDLE);
        while(1)
        {
        sleep_mode();
        }
}