standard wordset for MCUs

[Carsten Strotmann (Usenet)]

Hello c.l.f colleagues,

does a standard wordset (or best common practice) exist for Forth on
Microcontrollers? Based on a discussion inside the german Forth
community I'm looking esp. for common best practice for such things
like:

* does HERE point to Flash or RAM?
* common words to access I/O ports
* common words to fetch/store in flash/eeprom in addition to @/! for RAM
* common words to 'compile' to RAM (when ,/c, compiles to dictionary in
* Flash)

Would it make sense to have a formal (like as part of Forth 200x)
standardization of an MCU word set?

-- Carsten

[Elizabeth D. Rather]

There is a proposed standard for cross-compilers aimed at
microcontrollers here:
http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2007-06/msg00283.html
(in 2 formats, pdf and doc). Read XCpaper first, it's an overview.
XCtext5 is the normative part (5th draft), while XCapp5 is an
explanatory appendix. This technology has been in use for over 10 years.
The current Forth 200x committee is hoping to standardize this, but is
looking for some updates.

Hope this helps!

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Mikael Nordman]

On 31.3.2012 19:38, Carsten Strotmann (Usenet) wrote:
> community I'm looking esp. for common best practice for such things
> like:
>
> * does HERE point to Flash or RAM?
> * common words to access I/O ports
> * common words to fetch/store in flash/eeprom in addition to @/! for RAM
> * common words to 'compile' to RAM (when ,/c, compiles to dictionary in
> * Flash)

> -- Carsten

When I started my FlashForth many years ago I asked comp.lang.forth
this very same question.
First there was Elizabeths answer pointing to the cross-compiler
standard. Since I was doing an interactive Forth I did
not use exactly that.

In FF there are three kinds of data space, RAM, FLASH and EEPROM.
HERE points to the data space.
There are three DP pointers of which one can be active at a time
as set by the words RAM, FLASH, EEPROM.

The compiler always uses the FLASH DP for allocating code space. In a
non-harvard target, the ram or eeprom DP could also
be used by the compiler for the code space.

In order to not have different memory access words FF
also has runtime multi branch @ and ! words.
The flash, eeprom and ram is mapped inside @ and ! into a 64 Kbyte
address range(FF is a 16-bit implementation).

So if I do
RAM CREATE BUF1 200 ALLOT it will create a definition in flash which
points to ram and increment the ram DP with 200.

FLASH CREATE BUF2 200 ALLOT will create a definition in flash that
points to the first free flash cell after the definition itself,
and increment the flash DP with 200.

I/O ports are memory mapped in ram. Assembly code can be used for
efficient bit manipulation on the I/O ports.

, and C, work in all the three data spaces using the current DP.

In general the comments from users have been very positive for this
architecture. It is easy to use and it works symmetrically for all
kinds of memories.

You can try out FlashForth on the 8 and 16-bit PICs and on Atmega.

Cheers /Mike

[dirk....@usa.net]

On 31 Mrz., 14:16, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 3/31/12 6:38 AM, Carsten Strotmann (Usenet) wrote:
>
> > Hello c.l.f colleagues,
>
> > does a standard wordset (or best common practice) exist for Forth on
> > Microcontrollers? Based on a discussion inside the german Forth
> > community I'm looking esp. for common best practice for such things
> > like:
>
> > * does HERE point to Flash or RAM?
> > * common words to access I/O ports
> > * common words to fetch/store in flash/eeprom in addition to @/! for RAM
> > * common words to 'compile' to RAM (when ,/c, compiles to dictionary in
> > * Flash)
>
> > Would it make sense to have a formal (like as part of Forth 200x)
> > standardization of an MCU word set?
>
> There is a proposed standard for cross-compilers aimed at

> microcontrollers here:http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2007-06/...

> (in 2 formats, pdf and doc). Read XCpaper first, it's an overview.
> XCtext5 is the normative part (5th draft), while XCapp5 is an
> explanatory appendix. This technology has been in use for over 10 years.
> The current Forth 200x committee is hoping to standardize this, but is
> looking for some updates.
>
> Hope this helps!
>
> Cheers,
> Elizabeth
>

Forth is the language of my choice because with Forth I am able to
program everything I like.

Chuck Moore had the great idea to make his Forth portable to different
computer systems by using only a few words to connect to the system,
as there are KEY?, KEY, EMIT, and the like.
This was an excellent choice of a genius, and I am sure nobody will
dispute this.

But with Embedded Systems using microcontrollers there is a challenge:
There have to be words to connect to the system, too, as there are
ADC@, DAC!, PWM!, TIMER!, and the like. These words allow portability
of user programs which is not possible with C.
I have a dreadful experience trying to port a C program running on the
MSP430F2012 to run on the MSP430G2553. It was impossible to me. TI
made a lot of changes in the hardware. Everything I liked to do is
reading an ADC, writing PWM and a Timer. If there would be a Forth
having these words ADC@, PWM!, TIMER!, I wouldn't have any problem.

Before I had this MSP project, I used RSC-Forth since 1984.
RSC-Forth has several hardware related words like these:

General I/O: EEC! SCDR SCSR SCCR MCR PG PF PE PD PC PB PA IER IFR
NMIVEC IRQVEC INTVEC INTFLG KHZ

Memory Words: BANKEXECUTE BANKEEC! BANKC@ BANKC! EEC! MEMTOP

Disk Words: FORMAT FMTRK SEEK INIT DWRITE DREAD SELECT DISK R/W B/SCR
B/BUF

Control Words: AUTOSTART FINIS SOURCE XOFF XON MON

Not all words are needed everywhere, especially the Disk Words aren't
needed anymore, but these words convinced me that Forth is a good
programming language for microprocessors, and I stayed with Forth.

Cheers,
Dirk.