home .. forth .. colorforth mail list archive ..

Re: [colorforth] distributed colorforth?


Dave,

Your project sounds good.  I would recommend that you look at
http://www.reda4.org

Pablo Reda's web site about his colorforth variants may be
of help to you.  I ran his reda4 ipaq code (PXA255 I think)
and it might have a lot of what you are looking for already
coded.

Pablo used the OS interface that was present however rather
than building a stand-alone system that included its own
OS services. Chuck prefers to build from the ground up but
it may make more sense for you to build on top of drivers
that you already have available for the hardware you are
using, touch screen, display, network services, files on
the SD card etc.   Or perhaps you have studied all the
low level details and want to jump it at the lowest
driver level. I don't know how much of Pablo's code
would be of use to you, if any, but I do recommend that
you check into it yourself.

If you google on Pablo Reda you can get pages translated
to English but there are other ways to get translations.
Maybe you wouldn't need translation. ;-) You might want
to email him with questions about his colorforth variant
if that makes sense.

He has a PC version and an ipaq version of reda4.  He has
pages about using it for educating children.  There are a
lot of screen shots etc.  If it has some of what you
need I would think you want to download a copy and run it
on an ipaq to help with the job of porting.

I did some colorforth like code for F21 way back when.
Chuck is interested in making a SEAforth version of
colorforth instead of developing SEAforth code in
colorforth on a Pentium PC.  He wILL also port the
okad colorforth code to processors of his own design.
He has been interested in what other people find when
they create a colorforth for a new environment.

I think it is also interesting that you have more than
one processor and can have both multitasking and
multiprocessing without going to an outside network
for more remote processors. I will be happy to comment
on your approach to the multiprocessing aspect of your app.

Best Wishes

> Hey all I have a simple scenario that some colorforth
> programmers may have some insight towards.
>
> I am currently trying to evaluate colorforth for a personal project
> involving some embedded work.  While
> the project will eventually run on something other than x86, I have been
> -fighting- playing with
> colorforth on the PC to replicate the software environment of the end
> device.
>
> The control panel in question is a dual screen touch input device
> roughly the size of a typical paperback novel,
> the hardware is readily available off the shelf dual PXA boards with
> wifi (802.11b/g) with 2GB microSD cards
> for storage.  The current design has one processor per screen, and the
> communicate to each other over the network.
>
> My vision for this thing is one part e-book, one part network console,
> one part fun hobby project.  (although I've had some interest from
> medical device people and education especially now that the new OLPC
> design is public).
>
> What I'm looking for is:
>
> 1.) A rough estimate of how much colorforth is currently x86 specific
> and will require porting
> 2.) A rough estimate of how many screens in colorforth it would be to
> write a basic 802.11b/g stack w/ support for UDP
>
> My thinking is that if I can port colorforth, and get a basic wireless
> stack setup to the point where I can fire off UDP
> packets to a remote server then building the rest of the interface will
> be trivial in comparison.  From a software
> standpoint, what I'd like to do is have a simple client server program
> written in colorforth that sends "forthlets" over
> UDP between the processors for evaluation. (these same forthlets can be
> fired off to any number of colorforth servers
> on the net for processing that can't be handled locally)
>
> The other language that I'm evaluating for this project is Erlang, which
> has the basic client server messaging model built
> into the language, but I don't care for the huge amount of overhead the
> full OTP + Linux solution would place upon the device.
>
> It seems to me in the world of multiple processors, and distributed
> applications, Forth (and Object Oriented Forths) would be
> the ideal fit.  Any ideas?
>
> Dave
>
> PS. Yes I would love to get my hands on a nice multiprocessor chip that
> would work as a CPU/DSP combo.  I've got a Xilinx
> Virtex4 eval board that I've been planning on prototyping such a beast
> on, but I don't think I'll ever have enough time to
> do it.
>
>
> Email: dave@xxxxxxxxxxxxxx
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
> Main web page - http://www.colorforth.com
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com