ANN: Riscy Pygness for the ARM version of May 9, 2010 is available
Frank Sergeant
The May 9, 2010 version of Riscy Pygness is now available.
Riscy Pygness is a 32-bit multitasking Pygmy Forth for the ARM. It
includes full source code for both the host (your desktop PC) and
target (your ARM development board). The license is BSD/MIT-like so
you can do (nearly) anything with it.
Full source code, binary images for several LPCxxxx ARM boards,
and user manual, are available at
It is aimed at relatively small embedded systems rather than desktop
systems or large embedded systems running an operating system (OS).
Riscy Pygness is a stand-alone system that is its own multitasking OS.
It can run in about 4 K bytes of flash and about 1.5 K bytes of RAM.
The size can be reduced further depending on your needs. This makes
it suitable for use in even the smaller ARM variants such as the NXP
LPC2101, LPC2102, and LPC2103. It can address the full 4 GB address
space, so it can take advantage of all the flash and RAM available in
even the larger variants.
During development, the host communicates with the target via a serial
port. The host provides the smart terminal and the compiling
services. The host can generate a new, customized Forth image for the
target.
The Forth itself runs on the target but you interact with it by typing
commands on the host, much as you would with a Forth running locally
on the host.
As you type each word at the terminal, the word is looked up on the
host which then sends a request to the target to execute the word.
Numbers typed at the terminal are sent to the target to be put on the
target's data stack. Word headers are kept on the host, not the
target, and all compilation work is done on the host.
The host and the target, working together, provide the effect of a
fully interactive Forth running on the target while conserving the
limited resources of the target.
I test the host part only on Linux (typically Debian or Ubuntu). Any
Unix/Linux system should be fine, even booting temporarily to a Debian
Live or Ubuntu Live CD should work. It may well run with the host
running a Microsoft OS, but I don't test it that way.
--
Frank
http://pygmy.utoh.org
rickman
development system I can use for embedded targets. Unfortunately the
basing it on Linux and Tcl gives it a very steep learning curve for
those of us who have only used Windows and Forth. I am curious, why
did you choose to use Tcl rather than a Forth system to host your
tools? I can't say for sure, but I would expect that if it ran under
a Forth system, it would be easy for anyone to use on nearly any
operating system. Am I being naive?
Rick
MarkWills
this out for sure!
Regards
Mark
ZB
> Unfortunately the basing it on Linux and Tcl
Actually, it isn't "unfortunately" at all - but "not that bad"... ;)
--
Zbigniew
rickman
> Dnia 13.05.2010 rickman <gnu...@gmail.com> napisa³/a:
>
> > Unfortunately the basing it on Linux and Tcl
>
> Actually, it isn't "unfortunately" at all - but "not that bad"... ;)
> --
> Zbigniew
Maybe for you Linux is a good thing. For me it is like getting a
program with the manual and all the help screens in a foreign
language. Funny, I have considered biting the bullet and switching to
Linux, but there are so many things I need that are not supported
under Linux. The only thing worse than using Linux for me would be
using both Linux and Windows.
Rick
ZB
> Maybe for you Linux is a good thing. For me it is like getting a
> program with the manual and all the help screens in a foreign
> language. Funny, I have considered biting the bullet and switching to
> Linux, but there are so many things I need that are not supported
> under Linux. The only thing worse than using Linux for me would be
> using both Linux and Windows.
But why do you think, you've got to use Linux? Just download appropriate
TCL-package for your version of Windows - can be a "compact" version
provided by Evolane ( http://www.evolane.com/software/etcl/ ) - and you're
fully prepared to run TCL scripts.
I bet, you need just this one:
http://www.evolane.com/download/etcl/win32/etcl-1.0.1-win32-setup.exe
--
Zbigniew
ZB
parameters, like e.g.: "/dev/ttyS0" with: "com1:". To have ability to edit
the scripts with no problems, treat them first with any "unix2dos" utility
(there's a need for "LF->CR-LF" conversion, you know...).
There are not numerous such caveats in TCL, and in case of the scripts
shipped with Pygness, perhaps just the one mentioned above. Properly written
TCL-scripts are portable.
--
Zbigniew
rickman
Thanks for the advice. Later this summer I may have time to pursue
this. But if it were a Forth system written in Forth, then I'd only
be dealing with one thing, Forth! That is my goal.
I just debugged a board on my customer's system which uses Linux on
their networking platforms. I likely could have done the work myself
if they had given me adequate info on how to make it all work, but
they only gave me the bits and pieces they thought I needed to make it
work. Each time I tried to work by myself there would be something in
the way I couldn't figure out. First it was just the command line
editor, he used something that had "modes" and it would stick me in
command mode where I couldn't even type on the command line! Other
times it would be that I wasn't logged into the right chassis and
other times it would be something more esoteric. The point is that if
it were better documented or something I was familiar with, I could
have worked without him and found the problems much faster.
If my time remains free this summer, I am going to work toward having
an embedded development system in Forth. I have an embedded processor
I want to finish off and will be supporting it under a Forth system.
But there are likely some good ideas in this ARM package that I can
learn from... if I can remember how to use tcl.
Rick
Frank Sergeant
> This is probably the closest I have found to an open source Forth
> development system I can use for embedded targets.
Yes, every bit of it is open source (the Forth, Tcl, Linux).
> Unfortunately the basing it on Linux and Tcl gives it a very steep
> learning curve for those of us who have only used Windows and Forth.
Well, it does come with a 43 page manual that attempts to explain
everything, including installation checklists. Perhaps you could skim
the manual. This might give a better idea as to whether it might be
feasible for you.
As to the host side being written in Tcl, I think you could think of
that as a black box. (Since it comes with source code, the black box
can be opened whenever you wish.)
> I am curious, why did you choose to use Tcl rather than a Forth system
> to host your tools?
My previous ARM Forth used Lisp for the host side. I have lately been
working for a client who adopted Tcl as our official language. (I have
often spent time pondering what the best language or development
environment would be. It seems, though, that I am never seriously
consulted about such decisions. By the time I join a project, these
decisions have already been made, for better or worse.) I have been
happy enough with Tcl. It is solid and well documented. Lisp worked
well. Tcl has works well. I am making a custom variant of Riscy
Pygness tuned for this client, so Tcl works especially well politically.
I don't much care these days for "efficiency" on the host side, just the
target side. So, why not? It might even be interesting to do the host
side in Smalltalk or Erlang some day.
> I can't say for sure, but I would expect that if it ran under a Forth
> system, it would be easy for anyone to use on nearly any operating
> system. Am I being naive?
I think you would still need to learn something about the system. I
see the manual as the key element in this, not the language the host
side happens to be implemented in.
Read the manual first? See what you think. Then, maybe boot from a
Linux live CD. The current Debian and Ubuntu Live CDs are great. They
let you play with Linux without making any commitment. Linux itself is
filled with documentation.
On the other hand, I don't know that it won't run just fine under a
Microsoft operating system. Tcl is very portable. I recommend the
one-file Tcl installation provided by Tclkit (as discussed in the
manual). If someone tries it under "Windows", I'd like to hear how it
worked and what adjustments, if any, you needed to make. Then I could
add that to the manual.
--
Frank
http://pygmy.utoh.org
Frank Sergeant
> Wow! This sounds incredible! Thanks for posting Frank, I will checking
> this out for sure!
Great. Please let me know how it works out.
--
Frank
http://pygmy.utoh.org
Stephen Pelc
wrote:
>If my time remains free this summer, I am going to work toward having
>an embedded development system in Forth. I have an embedded processor
>I want to finish off and will be supporting it under a Forth system.
>But there are likely some good ideas in this ARM package that I can
>learn from... if I can remember how to use tcl.
If you just want to be a tool user rather than a tool maker, you
can use the MPE Forth Stamp cross compiler for ARM/Cortex. It
has a VFX code generator, produces code for standalone or Umbilical
Forths. It costs GBP 75, EU ~84, USD ~114. The restrictions on the
Stamp versions of the compiler are that code is restricted to 120kb,
RAM to 64kb, and target support is for NXP LPC17xx and 2xxx only.
Full target source code is provided. It's all in Forth. It's all
fully documented. Choose Windows or Linux.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Helmut Giese
productivity aka 'getting things done'.
You see, using Tcl is _at least_ an order of magnitude faster than
coding in Forth. However, Tcl doesn't run on small micros - it needs
the resources of a full fledged OS.
In the spirit of "use the right tool for the job" I applaud Frank's
choice: On the host (where you have all the resources you can dream
of) use the most productive tool you know - and on the target, well,
it's got to be Forth.
As far as Linux is concerned: Don't let it bother you: Tcl is
extremely portable and therefore there are really just a handful of
adjustments to make - things even Tcl cannot abstract away: Under
Linux a serial port is e.g. named /dev/tty0 - under Windows it is
COM0: - little things like that..
I think Frank did a really good job listing the (few) changes to
riscy.tcl needed to have it run under Windows.
My advice would be: If you have a spare afternoon
- get a TclKit (the docs contain the link)
- go thru the list of changes to riscy.tcl and
- start it.
Once it runs you can forget that it is coded in Tcl and treat it as a
black box. And if it doesn't run
- come back here showing the error message or
- (maybe even better in the long run) turn to comp.lang.tcl - an
extremely friendly news group where people go out of their way to help
newbies.
Good luck
Helmut Giese