Lpc2000

--- In lpc2000@yahoogroups.com, Alaric B Snell <alaric@a...> wrote:
> 
> Background: I'm writing my LPC21xx FORTH, as before mentioned. It's now 

Dude!  What would it take to get you to defect over to the OKI ARM
camp?  I am looking to host Forth on the OKI 67Q5003 ARM mcu.  I am a
newbie to the ARM and I have not worked with Forth at this level
before.  So I was looking at using a commercial Forth like MPE.  But
it will be pretty expensive to buy one complete with a support package
for a new chip like this.  

> setting the system state up fine and starting executing after
assembling 
> a few basic words (like EMIT, for now hardcoded to use UART0, although 
> at a later date to support swapping in different input/output
drivers by 
> updating a pointer; I plan to support console over I2C, for 
> multi-processor setups) onto a dictionary list. But I want to have an 
> interrupt handler for UART0 that puts characters into a buffer for KEY 
> to read, except for Ctrl+C which will reset the stacks and drop into
the 
> interpreter with the console driver switched to UART0, and Ctrl+R which 
> will do same but also reset the wordlist pointer (for when you've
REALLY 
>   hosed the system) - these are needed because the system will, by 
> default, load a file from a FLASH filesystem on startup and begin 
> executing, so we need a way to force it into a clean working state that 
> cannot be overriden.

I don't think I would use a serial port character for this, it would
be very dangerous in any real world system.  A wrong baud rate could
result in any given character being "received".  Given time, the
system will get hosed.  Instead, I suggest that an input be used to
indicate on reset what actions to be taken.  A single input pin can be
used to check for a jumper to ground, a jumper to a Vdd pullup or no
jumper.  Then a push button reset will boot normally or have two
levels of recovery from a problem.