Forth for PIC18
Nickolai Leschov
My company is making instruments that contain PIC18 microcontrollers.
The current software is a good candidate for rewrite. I think of
rewriting it using Forth. Is there a Forth for PIC18 that I can use?
I would like umbilical Forth that would give me better debugging
capabilities than technology that is currently used.
Current gen instruments contain PIC18F452, next gen (which is a minor
update) will contain the same or pin-compatible newer one (PCB
schematics is practically done).
Regards,
Nickolai Leschov
Maki
--
M.Veselic
Sigma Lab.
"Nickolai Leschov" <nles...@gmail.com> wrote in message
news:g6p7l2$5du$1...@aioe.org...
DavidM
> My company is making instruments that contain PIC18 microcontrollers.
> The current software is a good candidate for rewrite. I think of
> rewriting it using Forth. Is there a Forth for PIC18 that I can use?
You could have a look at pic18forth.sf.net
doelie
metaprogramming.
http://zwizwa.be/archive/pic18-forth.pdf
http://zwizwa.be/staapl
Brad Eckert
>
> I would like umbilical Forth that would give me better debugging
> capabilities than technology that is currently used.
>
> Current gen instruments contain PIC18F452, next gen (which is a minor
> update) will contain the same or pin-compatible newer one (PCB
> schematics is practically done).
>
assembler, PIC24 (standard) C, Forth (used for simulations), or
whatever language you write a plug-in for. You then use MPLAB to
assemble/compile the code, program the part, etc. The generated VM
consists of an internal ROM (mostly tokens compiled from your Forth
source), some RAM and a token interpreter (most words are invoked
using one byte) so programs can be pretty compact. All models are 32-
bit.
I now have (but haven't released) a VHDL generator which creates a VM
that runs at 70MHz (1550 LUTs for CPU+UART+timer) on a Spartan3
evaluation board. It's kind of like eForth in hardware.
The debugger is a thin client that talks over RS232. That's the most
useful part of the whole thing, especially for viewing and altering
peripheral registers. It's possible to compile new words in the test
interpreter, but these words execute by invoking words over the
umbilical link so they are very slow.
For the PIC18, you can do a lot in 8K of ROM, although the PIC18F452
has limited RAM so it's a tight fit. There's a demo for that chip on a
PICDEM2 board (need 11.0592M xtal) but I wouldn't recommend that chip
for fminus.
While a 32-bit model may be overkill for small PIC18 applications,
it's intended to provide a future-proof programming model and to mimic
the desktop PC environment to simplify simulation. Now that the VHDL
model is working (and because it uses all synchronous RAMs/ROMs it
wasn't easy) it's an especially future-proof model.
-Brad
DavidM
> My company is making instruments that contain PIC18 microcontrollers.
> The current software is a good candidate for rewrite.
At risk of being branded a troll, is there any possibility of persuading
your company to extend the 'rewrite' down to the copper, and replace the
PIC18 chips with ATMega?
Depending on the projected life-cycle of the instruments, the company
might find a significant net saving in terms of development effort,
future enhancements etc.
Nickolai Leschov
> On Wed, 30 Jul 2008 12:09:36 +0400, Nickolai Leschov wrote:
>
>> My company is making instruments that contain PIC18 microcontrollers.
>> The current software is a good candidate for rewrite.
>
> At risk of being branded a troll, is there any possibility of persuading
> your company to extend the 'rewrite' down to the copper, and replace the
> PIC18 chips with ATMega?
Why should they, really?
I mean, I like the ATMega (the first new 8-bit architecture in 20 years,
yes!) but I don't see why it's worth changing from one 8-bit micro to
another of the same class when the current architecture works.
Nickolai
Mikael Nordman
> Hello,
>
> My company is making instruments that contain PIC18 microcontrollers.
> The current software is a good candidate for rewrite. I think of
> rewriting it using Forth. Is there a Forth for PIC18 that I can use?
>
It is a native forth executing completely on the PIC.
It is fairly fast since it compiles native code with inlined literals
and branches.
http://flashforth.sourceforge.net/
It works quite reliably and it has been used for a few commercial
projects, as instrument controller and for the user interface.
I also use it for filtering NMEA messages and data aquisition.
> I would like umbilical Forth that would give me better debugging
> capabilities than technology that is currently used.
FlashForth is not umbilical, nor does it have a debugger, but you can
code & test your application a word at a time, and look at memory
contents without stopping the realtime, providing you don't choke the
serial port.
Regards Mikael
Elizabeth D Rather
The main reason would be to get decent software development tools, which
can drastically cut your software development time, quite possibly
enough to cover the re-engineering cost. And the savings would continue
into the future with further mods to the software.
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."
==================================================