Lpc2000

Today I uploaded the newest version of Riscy Pygness (Pygmy Forth for
the ARM) to 

    http://pygmy.utoh.org/riscy/

the file riscy2-20050108-1856.zip contains the full source code and also
several binaries in Intel Hex format.  Two of the hex files are
available for separate download if you would rather take a quick look:

    combo.hex
     (for a 14.7456 MHz LPC2106, e.g. the Olimex board, 115200 bps)

    combotiny.hex 
     (for a 10 MHz LPC2106, e.g. New Micros tinyARM, 9600 bps)

I run with the Olimex board and haven't tried the New Micros board yet.
If you try it, please let me know how (and whether) it works.

This version runs from any serial terminal.  The heads are stored on the
target.  The dictionary can be extended interactively into RAM.

If you have an LPC2106 board running at 14.7456 MHz (or probably at 10
MHz) you should be able to run the Forth interactively just by burning
the hex file into the ARM and connecting a serial terminal to the first
serial port.  When it boots it says "Hi".  Pressing Enter should make it
respond with " ok".  Typing

     1 3 + .

Should print out 4

See the source code for all the words it knows.

The primitives are assembled using the Gnu ARM tool chain, which
culminates in the file riscy.bin.  So, if you want to change the
primitives, you would need access to the Gnu tool chain.

The high-level Forth is compiled and merged with riscy.bin to produced
combo.bin and combo.hex ready for downloading into the ARM.  The
compiler is written in Common Lisp.  I use CLISP on Linux, but any
Common Lisp should work with, at most, minor changes, either on Linux or
Windows.  The main load file is arm.lisp, which is very easy to read
and/or modify, just look for the lines such as

     (forth-compile-file "lpc.forth")
     (forth-compile-file "riscy.forth")
     
Included with it is source code for 

    accessing MMC and SD flash disks (in SPI mode), including FAT16,

    using the IAP routines to reprogram LPC flash,

    multitasking


The license is MIT/BSD style so you are free to use it in any sort of
project.

The threading model has changed somewhat compared to the previous
version.  Previously, code was limited to flash (i.e. the first 128 K
bytes of address space).  Now code anywhere in the 32-bit address space
can be executed.  This lets it compile interactively into RAM and also
makes it easy to port to other ARM chips regardless of their memory
maps.  The "tokens" still take just 16 bits each, so a *lot* of code
fits into the LPC flash.

So, to summarize,

  to take a quick look, burn the hex file into the target and 
  connect a serial terminal at the correct baud rate

  to modify the high-level Forth (but use the existing primitives), 
  install some sort of Common Lisp and edit arm.lisp to include the
  Forth files you want to compile.

  to change even the primitives, install the Gnu ARM tool chain.

  to use it as inspiration for MMC or SD or the IAP routines, for use
  with C or assembly, download the source code and read it.  I'll be
  glad to try to answer questions if Forth is a foreign language.

The main web site leads to a Swiki (a Wiki that you are welcome to use
to post comments, corrections, questions, etc.).  It is read only by
default, but you can log in with the name 'forth' and the password
'fourth' to have full access.  If that login information changes, please
email me and I'll send you the new login information.

-- 
Frank
http://pygmy.utoh.org

--- In lpc2000@yahoogroups.com, Frank Sergeant <frank@p...> wrote:
> Today I uploaded the newest version of Riscy Pygness (Pygmy Forth for
> the ARM) to 
> 
>     http://pygmy.utoh.org/riscy/
> 
> the file riscy2-20050108-1856.zip contains the full source code and also
> several binaries in Intel Hex format.  Two of the hex files are
> available for separate download if you would rather take a quick look:
...snip...
> -- 
> Frank
> http://pygmy.utoh.org

Would you mind posting this info to the armForth group here at Yahoo!
as well?  As far as I can tell your forth is the only one that is
actually available for ARM chips that are in use today.  

I have a Cogent board with an OKI ARM chip that I am not using.  If
you have any interest in porting to this hardware, it has the 67Q5003
CPU with SDRAM, SRAM, Flash, two serial ports and a 10/100 Ethernet
interface.  I would be happy to lend it to you.  

You might also be interested in the OKI-ARM-MCU group here.  Not much
going on at the moment, but OKI makes some very nice parts.  

As long as I am on the topic, you can get some nice hardware for a
song by buying a router.  You get multiple Ethernet ports, typically
an ARM MCU and enough memory to keep you happy.  I have seen several
people do that.  They normally have a monitor in ROM that you can use
to load the Flash with your code.  Pretty cool!

"Rick Collins" <gnuarm@...> writes:

> Would you mind posting this info to the armForth group here at Yahoo!
> as well?  As far as I can tell your forth is the only one that is
> actually available for ARM chips that are in use today.  

Ok, I just posted it there.

> I have a Cogent board with an OKI ARM chip that I am not using.
 ...
>   I would be happy to lend it to you.  

Thank you.  Let's keep it in mind for the future, but right now I have
too much to do with just the development systems already frowning at me
from the shelves, tapping their feet, saying "C'mon, c'mon, get to work.
Stop playing FreeCell."  If I could just get them to stop tapping their
feet ... that's the worst of it.
 
> As long as I am on the topic, you can get some nice hardware for a
> song by buying a router.

I like that idea, also the Game Boy Advance and/or one of the ARM-based
Palm Pilots (they will always be "Palm Pilots" to me).

However, for ease of development, I couldn't be happier than with the
Olimex LPC2106 board I'm using.

I have that board wired up to both an MMC socket (as in the pictures on
my web site) and an SD socket.  I can read and write MMC disks in either
socket and read and write SD disks in the SD socket.  In all cases, I am
using SPI mode, using the LPC's built-in SPI.  

With either an MMC disk or an SD disk, I am seeing a time of
approximately 78 MS to read a 512-byte sector.  I think a substantial
amount of that time is a delay internal to the card, rather than related
to the LPC.  I had hoped that the SD disk, even in MMC/SPI mode, would
be faster that the MMC disk, but it doesn't seem to be.

My next step in that direction, probably, is to wire an SD socket to
another Olimex board, using GPIO rather than the built-in SPI, and work
out talking to the disk using 4 data lines rather than just the one used
in SPI mode.  However, if the bulk of the time is spent internally in
the disk, I may not see the speedup I hope for.

I want the advantages of CompactFlash disk speed, with the far narrower
interface of an MMC or SD disk.


-- 
Frank