Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #10057 > unrolled thread

10,000 educational single board computers sold on the first day!

Back to article view | Back to comp.lang.forth

Contents

  10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-12 13:05 -0700
    Re: 10,000 educational single board computers sold on the first day! "A. K." <akk@nospam.org> - 2012-03-12 22:01 +0100
      Re: 10,000 educational single board computers sold on the first day! Pablo Hugo Reda <pabloreda@gmail.com> - 2012-03-12 14:08 -0700
    Re: 10,000 educational single board computers sold on the first day! Pablo Hugo Reda <pabloreda@gmail.com> - 2012-03-12 14:11 -0700
    Re: 10,000 educational single board computers sold on the first day! Pablo Hugo Reda <pabloreda@gmail.com> - 2012-03-12 14:14 -0700
    Re: 10,000 educational single board computers sold on the first day! Mark Wills <markrobertwills@yahoo.co.uk> - 2012-03-12 14:51 -0700
      Re: 10,000 educational single board computers sold on the first day! Jason Damisch <jasondamisch@yahoo.com> - 2012-03-12 16:11 -0700
        Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-13 00:55 -0700
          Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-13 01:36 -0700
            Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-13 07:10 -0700
          Re: 10,000 educational single board computers sold on the first day! Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-03-13 22:58 +0100
            Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-13 19:42 -0700
          Re: 10,000 educational single board computers sold on the first day! cas_news@strotmann.de (Carsten Strotmann (Usenet)) - 2012-03-22 18:31 +0100
            Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-22 10:58 -0700
              Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-22 22:52 -0700
            Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-22 23:30 -0700
              Re: 10,000 educational single board computers sold on the first day! Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-03-23 07:59 +0000
                Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-23 02:00 -0700
                  Re: 10,000 educational single board computers sold on the first day! Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-23 15:32 +0000
                    Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-23 12:10 -0700
                  Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-23 10:43 -0700
                    Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-24 22:39 -0700
                      Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-24 23:18 -0700
                        Re: 10,000 educational single board computers sold on the first day! "Elizabeth D. Rather" <erather@forth.com> - 2012-03-24 21:08 -1000
                          Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-25 01:53 -0700
                            Re: 10,000 educational single board computers sold on the first day! "Elizabeth D. Rather" <erather@forth.com> - 2012-03-25 08:38 -1000
                              Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-25 15:59 -0700
                                Re: 10,000 educational single board computers sold on the first day! "Elizabeth D. Rather" <erather@forth.com> - 2012-03-25 13:21 -1000
                              Re: 10,000 educational single board computers sold on the first day! cas_news@strotmann.de (Carsten Strotmann (Usenet)) - 2012-03-26 09:37 +0200
                        Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-25 00:26 -0700
                          Re: 10,000 educational single board computers sold on the first day! cas_news@strotmann.de (Carsten Strotmann (Usenet)) - 2012-03-25 11:36 +0200
                        Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-25 19:34 -0700
                          Re: 10,000 educational single board computers sold on the first day! "Elizabeth D. Rather" <erather@forth.com> - 2012-03-25 17:03 -1000
                            Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-25 20:13 -0700
                          Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-25 20:17 -0700
                            Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-25 21:31 -0700
                              Re: 10,000 educational single board computers sold on the first day! cas_news@strotmann.de (Carsten Strotmann (Usenet)) - 2012-03-26 08:57 +0200
                                Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-26 01:10 -0700
                                  Re: 10,000 educational single board computers sold on the first day! Mark Wills <markrobertwills@yahoo.co.uk> - 2012-03-26 02:55 -0700
                                  Re: 10,000 educational single board computers sold on the first day! Mark Wills <markrobertwills@yahoo.co.uk> - 2012-03-26 03:05 -0700
                                  Re: 10,000 educational single board computers sold on the first day! cas_news@strotmann.de (Carsten Strotmann (Usenet)) - 2012-03-26 15:45 +0200
                              Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-26 00:28 -0700
                                Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-26 02:43 -0700
                          Re: 10,000 educational single board computers sold on the first day! Mark Wills <markrobertwills@yahoo.co.uk> - 2012-03-26 02:35 -0700
                            Re: 10,000 educational single board computers sold on the first day! Paul Rubin <no.email@nospam.invalid> - 2012-03-26 02:44 -0700
                Re: 10,000 educational single board computers sold on the first day! Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-23 15:11 +0000
                  Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-23 11:38 -0700
                Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-23 09:49 -0700
                  Re: 10,000 educational single board computers sold on the first day! Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-03-25 22:24 +0100
                    Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-25 17:16 -0700
                      Re: 10,000 educational single board computers sold on the first day! Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-03-29 23:58 +0100
                        Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-29 18:16 -0700
      Re: 10,000 educational single board computers sold on the first day! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-13 08:49 -0500
        Re: 10,000 educational single board computers sold on the first day! Mark Wills <markrobertwills@yahoo.co.uk> - 2012-03-13 07:16 -0700
          Re: 10,000 educational single board computers sold on the first day! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-13 12:40 -0500
            Re: 10,000 educational single board computers sold on the first day! Alex McDonald <blog@rivadpm.com> - 2012-03-13 11:50 -0700
              Re: 10,000 educational single board computers sold on the first day! quiet_lad <gavcomedy@gmail.com> - 2012-03-13 15:11 -0700
                Re: 10,000 educational single board computers sold on the first day! "Harry Vaderchi" <admin@127.0.0.1> - 2012-03-13 22:21 +0000
                  Re: 10,000 educational single board computers sold on the first day! rickman <gnuarm@gmail.com> - 2012-03-15 14:22 -0700
                    Re: 10,000 educational single board computers sold on the first day! jacko <jackokring@gmail.com> - 2012-03-15 18:25 -0700
                      Re: 10,000 educational single board computers sold on the first day! Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-17 17:06 +0100
                        Re: 10,000 educational single board computers sold on the first day! dirk.bruehl@usa.net - 2012-03-17 11:47 -0700
                        Re: 10,000 educational single board computers sold on the first day! Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-18 11:23 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#10366

On 23 Mrz., 05:00, Paul Rubin <no.em...@nospam.invalid> wrote:
> There are a bunch of national flags on the left side of the page.  Don't
> click on those.  At the upper right of the big white German text box in
> the middle, there is a British flag.  Click on that.

Thanks for this very helpful instruction, Paul! I appreciate that!

> The setup looks really great,

Thank you so much for your praise! Did you see the 4€4th label on the
microcontroller?
It appears when going down with the slider on the right side.

> though aren't the organizers losing a little bit of money on every board?

Don't worry, Paul! This is a voluntary altruistic venture. We don't
loose money - people ordering the 4€4th-LaunchPad have to pay postage
for mailing - but we don't earn money either.

> The part they are using has 16k of flash and 512b of ram, which is more
> than I thought was available in chips that fit the Launchpad board.  But
> 512b still sounds sort of small for Forth unless user-defined words can
> be written directly to flash somehow.

Compilation is directly into FLASH. This is a bit tricky, of course,
but it works.

> Otherwise, is there a way to split the Forth dictionary between flash and ram?

That may be a future upgrade. My idea for this upgrade is to compile
into RAM, and, if correct, transfer to FLASH.

I did this once with RSC-Forth on Mitsubishi's M38049: compiling into
RAM, until the program is set and before RAM is filled, and then
generate a relocated code, uploading a Hex file for the external FLASH-
programmer, worked great. All computations done automatically, because
the relocator was resident on the microcontroller. I doubt that there
is enough left to place this.

> Overall I hope TI makes some bigger cpus for that board.  Their FRAM cpu
> would be great.

TI now has a name for this new line of FRAM microcontrollers: it is
called "Wolverine".
May be they will have a DIL package some day, may be not. I guess it
is not meant for the LaunchPad clientele. But we have ported
CamelForth to TI's MSP-EXP430FR5739, look at http://www.camelforth.com,
click on "Contributed:" / "MSP430 FRAM (MSP-EXP430FR5739)" on the
right side panel.

> I wonder if Dirk's group might be able to get a special deal or
> donations from TI.

TI does a great donation! TI delivers the $4.30 LaunchPads with free
shipping to Germany. Just this morning today Michael got 10 (that's
the maximum order TI allows) more LaunchPads which I ordered two weeks
ago when I heard that he sold all fifty LaunchPads at the convention.
These microcontrollers have been developed in Germany, by the way!

> TI really seems to want to get these boards in the
> hands of people who would otherwise be playing with Arduinos, and this
> seems like a good project to help that.

Paul, you are totally right!

But to me TI seems to be the company best guarded against intrusion of
potential customers I ever dealt with. Since weeks I try to get in
contact with somebody. If I call to a phone number of TI, Freising,
Germany, I get connected to TI's European center in Prague, and they
don't know anything. The only thing what - partially - worked was a
call to TI's Semiconductor Support Center. I got phone numbers which
didn't work, and the ones which did, I was connected from one person
to the other until I ended up with a voice telling me "This phone
number doesn't exist".
But I got an email from support@ti.com.
They wrote to me:
"What could we have done better? Please take two minutes to help us
improve our services by answering three short questions. Your
evaluation of our performance is extremely valuable and will help us
be more responsive to your needs in the future. We look forward to
hearing your recommendations. To complete the survey, please click
here ...

For your reference, the description of your inquiry is included
below:
MSP-EXP430G2-- Has a promotional idea for the Launch Pad for Europe."

That was it! Filling in this survey and submitting didn't help up to
now - they didn't ask what I need, anyway. Next step on my list is to
answer to this email to find out what's happening then.

NEVER GIVE UP! somebody told me.

[toc] | [prev] | [next] | [standalone]

#10432

dirk.bruehl@usa.net writes:
> Thank you so much for your praise! Did you see the 4€4th label on the
> microcontroller?
> It appears when going down with the slider on the right side.

Oh very nice!  I didn't realize you had made stickers for the chip
packages.

> Compilation is directly into FLASH. This is a bit tricky, of course,
> but it works.

I don't understand how you handle the traditional Forth method of mixing
code and data in the dictionary then.  How does VARIABLE work in this
Forth?  Usually it is something like:

   : VARIABLE  ( "name" -- ) CREATE 1 cells allot ;

Do you have a separate data heap?  Also, can the Launchpad board
reprogram its flash a little bit at a time?  I didn't realize that.

[toc] | [prev] | [next] | [standalone]

#10433

On 25 Mrz., 01:39, Paul Rubin <no.em...@nospam.invalid> wrote:
> dirk.bru...@usa.net writes:
>
> > Compilation is directly into FLASH. This is a bit tricky, of course,
> > but it works.
>
> I don't understand how you handle the traditional Forth method of mixing
> code and data in the dictionary then.  How does VARIABLE work in this
> Forth?  Usually it is something like:
>
>    : VARIABLE  ( "name" -- ) CREATE 1 cells allot ;

There is a difference between a Forth system running in RAM and Forth
running in ROM or FLASH.
This is important for embedded systems. There are two methods: one
method is to copy the Forth image from ROM/FLASH into RAM at boot
time. I am pretty sure most people do that.
The other method is to run Forth directly in ROM/FLASH memory. In this
case Forth has to take care of proper definition of variables, of
course.

I had to redefine VARIABLE in RSC-Forth before putting my code from
RAM into EPROM:

\ Definition of RAM Variables 5/11/1998

HEX 7000 CONSTANT VAR        \ Start of RAM area for Variables
0 VARIABLE VARIABLE-OFFSET   \ Pointer for next Variable

: VARIABLE <BUILDS VARIABLE-OFFSET @ DUP 2+
   VARIABLE-OFFSET ! VAR           + DUP , ! DOES> @ ;

That was for me the easiest way to deal with this problem back then.

> Do you have a separate data heap?  Also, can the Launchpad board
> reprogram its flash a little bit at a time?  I didn't realize that.

4E4th is a simple Forth, based on CamelForth, as mentioned before.
Michael made it suitable for the Launchpad project.
There is a strict division in Forth system and Forth user part, each
of which has 8k. This makes it possible to reflash the user part while
the system part stays untouched.

[toc] | [prev] | [next] | [standalone]

#10435

On 3/24/12 8:18 PM, dirk.bruehl@usa.net wrote:
> On 25 Mrz., 01:39, Paul Rubin<no.em...@nospam.invalid>  wrote:
>> dirk.bru...@usa.net writes:
>>
>>> Compilation is directly into FLASH. This is a bit tricky, of course,
>>> but it works.
>>
>> I don't understand how you handle the traditional Forth method of mixing
>> code and data in the dictionary then.  How does VARIABLE work in this
>> Forth?  Usually it is something like:
>>
>>     : VARIABLE  ( "name" -- ) CREATE 1 cells allot ;
>
> There is a difference between a Forth system running in RAM and Forth
> running in ROM or FLASH.
> This is important for embedded systems. There are two methods: one
> method is to copy the Forth image from ROM/FLASH into RAM at boot
> time. I am pretty sure most people do that.
> The other method is to run Forth directly in ROM/FLASH memory. In this
> case Forth has to take care of proper definition of variables, of
> course.

In SwiftX, we run the kernel in ROM/FLASH and the developing application 
in RAM. When the application is fully tested, it can be run from 
ROM/FLASH. The "Proposed Cross-compiler Standard" (links here: 
http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2007-06/msg00283.html) 
includes provision for managing VARIABLEs in an embedded environment.

Code and data space are segregated, actually into 3 spaces:
	cData (code space) may be in ROM (or Flash) or RAM, containing all 
actual definitions
	iData (initialized data space) contains the "payloads" of VALUEs and 
other initialized data objects, initialized at power-up
	uData (uninitialized data space) is in pure RAM, not initialized at 
power-up, and the target app is responsible for any/all initializatio.

Whether VARIABLEs are in iData or uData is controlled by a flag.

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#10439

"Elizabeth D. Rather" <erather@forth.com> writes:
> In SwiftX, we run the kernel in ROM/FLASH and the developing
> application in RAM. When the application is fully tested, it can be
> run from ROM/FLASH. The "Proposed Cross-compiler Standard" (links

Thanks, that link is interesting.  The cool thing about this Launchpad
system is that it's not a cross compiler at all.  The entire interpreter
runs, stand alone, on the $4.30 experimenter board with a $1.20 (qty
100) processor.  You can just plug in a terminal emulator through USB
and start typing.

I wonder if the cross-compiler standard can also be used to metacompile
in a standardized way.

[toc] | [prev] | [next] | [standalone]

#10453

On 3/24/12 10:53 PM, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> In SwiftX, we run the kernel in ROM/FLASH and the developing
>> application in RAM. When the application is fully tested, it can be
>> run from ROM/FLASH. The "Proposed Cross-compiler Standard" (links
>
> Thanks, that link is interesting.  The cool thing about this Launchpad
> system is that it's not a cross compiler at all.  The entire interpreter
> runs, stand alone, on the $4.30 experimenter board with a $1.20 (qty
> 100) processor.  You can just plug in a terminal emulator through USB
> and start typing.
>
> I wonder if the cross-compiler standard can also be used to metacompile
> in a standardized way.

Absolutely. The cross-compiler is based on metacompilers used to 
maintain existing systems.

There are many advantages to cross-compiling vs. running a limited 
interpreter on the target. Among other things, it means the target's 
program can be tiny, as it doesn't need space for headers, its own 
compiler & assembler, and other programming tools. It's far faster to 
download compiled binary than ascii source to be compiled!

The main argument for having a full system on a little board is to be 
able to do interactive testing. But this is possible with 
cross-compilers using a simple umbilical. The host compiles the program, 
and keeps all the headers locally, with pointers into the target code, 
and downloads the target. If you type a word, the host's umbilical looks 
it up and sends a message to the target to execute it. The host's stack 
is transferred to and from the target. The result is true Forth 
interactivity just as you're accustomed to in a resident system, but 
with far better performance. The only support needed in the target is 
the ability to read a location, write to a location, and execute from a 
location: typically a few hundred bytes, far less than a resident Forth.

In olden times it was necessary to put the whole system on the target 
because then you could use a "dumb terminal" to talk to it. But nowadays 
there are no "dumb terminals" -- you're running a terminal emulator on a 
powerful computer that is fully capable of running a development system.

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#10467

"Elizabeth D. Rather" <erather@forth.com> writes:
> Absolutely. The cross-compiler is based on metacompilers used to
> maintain existing systems.

Neat, I'll try to read that spec.

> There are many advantages to cross-compiling vs. running a limited
> interpreter on the target. ...  In olden times it was necessary to put
> the whole system on the target because then you could use a "dumb
> terminal" to talk to it. 

Right, cross-compilation has practical advantages, but if practicality
is all we care about, then why are we messing with this stuff in the
first place ;-)?  The main interesting thing about this Launchpad
implementation is the shock value, of having a complete development
environment on this ultra-cheap board and super low powered cpu that can
run on a watch battery.

It's also nice to not depend on a host Forth which in turn ends up being
host specific.  Every OS these days has some kind of terminal emulator,
so you can connect to the 430 board from just about anything.  An
example would be using the 430 in a bike computer with serial over
bluetooth.  Then you could control it from your laptop, Android phone,
Iphone, Arduino, or whatever, without needing special code on each host.
Just start a tty and type stuff.

[toc] | [prev] | [next] | [standalone]

#10469

On 3/25/12 12:59 PM, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> Absolutely. The cross-compiler is based on metacompilers used to
>> maintain existing systems.
>
> Neat, I'll try to read that spec.

There are only two things peculiar to a "metacompiler" as compared with 
a cross-compiler:

1. The target is the same platform as the host; and

2. The target will have some features (e.g. compiler, assembler) that 
most cross-compiler targets don't need.

Otherwise, the principles (and most of the implementation) are the same.

>> There are many advantages to cross-compiling vs. running a limited
>> interpreter on the target. ...  In olden times it was necessary to put
>> the whole system on the target because then you could use a "dumb
>> terminal" to talk to it.
>
> Right, cross-compilation has practical advantages, but if practicality
> is all we care about, then why are we messing with this stuff in the
> first place ;-)?  The main interesting thing about this Launchpad
> implementation is the shock value, of having a complete development
> environment on this ultra-cheap board and super low powered cpu that can
> run on a watch battery.
>
> It's also nice to not depend on a host Forth which in turn ends up being
> host specific.  Every OS these days has some kind of terminal emulator,
> so you can connect to the 430 board from just about anything.  An
> example would be using the 430 in a bike computer with serial over
> bluetooth.  Then you could control it from your laptop, Android phone,
> Iphone, Arduino, or whatever, without needing special code on each host.
> Just start a tty and type stuff.

Yes, for that purpose a resident compiler is nice. FORTH, Inc.'s 
cross-compilers have an option to include a simplified compiler in the 
target for such situations.

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#10490

Hello Elizabeth,

"Elizabeth D. Rather" <erather@forth.com> writes:

>
> There are many advantages to cross-compiling vs. running a limited
> interpreter on the target. Among other things, it means the target's
> program can be tiny, as it doesn't need space for headers, its own
> compiler & assembler, and other programming tools. It's far faster to
> download compiled binary than ascii source to be compiled!

for the purpose of teaching the Forth workshops the small TI Board with a
interpreter in the target is almost ideal. We have people coming with
all kinds of different operating systems and configuration into the
workshop, and we only have limited time (1-3 hours), so we need to get
"up-and-running" with Forth in a few minutes. Treating the PC as a
"dumb-terminal" is the best solution, even that SwiftForth and other
cross-compiler do not have much dependencies on the OS level.

For serious work, larger applications, cross-compiling has many
advantages.

For learning, simple tools are key.

-- Carsten

[toc] | [prev] | [next] | [standalone]

#10436

dirk.bruehl@usa.net writes:
> 4E4th is a simple Forth, based on CamelForth, as mentioned before.
> Michael made it suitable for the Launchpad project.
> There is a strict division in Forth system and Forth user part, each
> of which has 8k. This makes it possible to reflash the user part while
> the system part stays untouched.

Oh ok, I didn't understand it when I first saw it, I guess.  But it is
really brilliant.  I wish TI shipped the launchpad board with that 20
pin part.  I guess I have to buy one of those boards for myself now.
I've never played with a microcontroller Forth before, and didn't have
much use for the Launchpad board with that very limited processor and
complicated programming toolchain.  But with a standalone Forth on
board, it's completely different.

Thanks!

[toc] | [prev] | [next] | [standalone]

#10441

Hello Paul,

Paul Rubin <no.email@nospam.invalid> writes:

> Oh ok, I didn't understand it when I first saw it, I guess.  But it is
> really brilliant.  I wish TI shipped the launchpad board with that 20
> pin part.  I guess I have to buy one of those boards for myself now.

As far as I understand the story Dirk told, the TI Launchpad boards ordered from DigiKey
already came with the correct 20pin MCU (contrary to the
expectations). There is no guarantee, but one might be lucky.

-- Carsten

[toc] | [prev] | [next] | [standalone]

#10477

dirk.bruehl@usa.net writes:
> : VARIABLE <BUILDS VARIABLE-OFFSET @ DUP 2+
>    VARIABLE-OFFSET ! VAR           + DUP , ! DOES> @ ;
> That was for me the easiest way to deal with this problem back then.

OK, but I'm still confused about one issue: what happens with a normal
colon definition, like

   : square ( n -- n ) dup * ;

Does that manage to compile a few bytes of code and headers into flash,
i.e. does the chip support updating individual flash bytes?  I thought
the usual way flash worked was you have to write a whole page at a time,
with the pages tending to be large.

It will be great if they make those FRAM parts in DIP format.  The
so-called "value line" is a bit disappointing since even the more
powerful, non "value" chips are still nice and small compared with the
32-bit stuff that's out there now.

[toc] | [prev] | [next] | [standalone]

#10479

On 3/25/12 4:34 PM, Paul Rubin wrote:
> dirk.bruehl@usa.net writes:
>> : VARIABLE<BUILDS VARIABLE-OFFSET @ DUP 2+
>>     VARIABLE-OFFSET ! VAR           + DUP , ! DOES>  @ ;
>> That was for me the easiest way to deal with this problem back then.
>
> OK, but I'm still confused about one issue: what happens with a normal
> colon definition, like
>
>     : square ( n -- n ) dup * ;
>
> Does that manage to compile a few bytes of code and headers into flash,
> i.e. does the chip support updating individual flash bytes?  I thought
> the usual way flash worked was you have to write a whole page at a time,
> with the pages tending to be large.
>
> It will be great if they make those FRAM parts in DIP format.  The
> so-called "value line" is a bit disappointing since even the more
> powerful, non "value" chips are still nice and small compared with the
> 32-bit stuff that's out there now.

Boards obviously differ, and flash is getting easier to use in small 
amts. But I've always found it easier to do development compiling to 
RAM, with a kernel (or tested portions of a kernel) in flash. So, you 
can re-write your flash whenever you have a body of tested code to add 
to what's there.

Whether you're compiling to flash or RAM can be controlled by specifying 
the address of the start of code space; edit it to an addr in the memory 
segment you want to compile to.

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#10480

"Elizabeth D. Rather" <erather@forth.com> writes:
> Boards obviously differ, and flash is getting easier to use in small
> amts. But I've always found it easier to do development compiling to
> RAM, with a kernel (or tested portions of a kernel) in flash. 

Yes, using RAM that way is obviously a much more pleasant approach, but
we're talking about a specific board (the TI Launchpad), with a specific
chip that has 16k of flash and 0.5k of ram.  So compiling a lot of code
into ram is not really an option.

TI has some other chips that have 16k of FRAM and 1k of regular RAM,
which seem to me to be REALLY attractive as Forth processors.  But at
the moment, those chips aren't available for the board we're talking
about, which holds socketed DIP processors.  The FRAM processors are SMT
only, and the cheapest board with one is over 5x the price of the DIP
board, though still amazingly affordable by any serious developer's
standards.

It might very well gain some popularity for Swift if Swift targeted
these boards ;-).

[toc] | [prev] | [next] | [standalone]

#10481

On 25 Mrz., 22:34, Paul Rubin <no.em...@nospam.invalid> wrote:
> dirk.bru...@usa.net writes:
> > : VARIABLE <BUILDS VARIABLE-OFFSET @ DUP 2+
> >    VARIABLE-OFFSET ! VAR           + DUP , ! DOES> @ ;
> > That was for me the easiest way to deal with this problem back then.
>
> OK, but I'm still confused about one issue: what happens with a normal
> colon definition, like
>
>    : square ( n -- n ) dup * ;
>
> Does that manage to compile a few bytes of code and headers into flash,

Yes!

> i.e. does the chip support updating individual flash bytes?

Yes!
With one restriction: only once.
To rewrite a byte the FLASH segment has to be erased.

> I thought
> the usual way flash worked was you have to write a whole page at a time,
> with the pages tending to be large.

That's true. Normally you have to write a page of 256 bytes minimum.
But not so here, and we take advantage of that fact.

> It will be great if they make those FRAM parts in DIP format.

You are right. But may be, may be not.
The new FRAM series has the code name "Wolverine" now:
http://www.ti.com/en/graphics/tihome/brand/hmpg-feature-wolverine-EN.swf
Big hype in the press:
Bye-Bye Batteries? TI Says New Wolverine Chip Can Cut Power Needs
http://go.bloomberg.com/tech-blog/2012-02-28-bye-bye-batteries-ti-says-new-wolverine-chip-can-cut-power-needs/

And there was a New MSP430 Wolverine Dev Kit with LCD BoosterPack
shown at the embedded world in Nuremberg, Germany, some weeks ago:
http://www.43oh.com/2012/02/fresh-new-msp430-wolverine-dev-kit-with-lcd-boosterpack/

> The
> so-called "value line" is a bit disappointing since even the more
> powerful, non "value" chips are still nice and small compared with the
> 32-bit stuff that's out there now.

That's why is called value line. You pay only some quarters instead of
some bucks.
What do you expect?

Cheers,
Dirk.

[toc] | [prev] | [next] | [standalone]

#10482

dirk.bruehl@usa.net writes:
>> i.e. does the chip support updating individual flash bytes?
> Yes!  With one restriction: only once.
> To rewrite a byte the FLASH segment has to be erased.

OK, that's fine, it sounds perfectly usable, just keep writing new
definitions to flash.  If the flash page size is 256B, maybe it's even
possible to compact the flash contents by swapping ram to flash and then
shuffling stuff around, erasing flash pages as stuff gets compacted.

> The new FRAM series has the code name "Wolverine" now:
> http://www.ti.com/en/graphics/tihome/brand/hmpg-feature-wolverine-EN.swf

I can't watch the swf but www.ti.com/wolverine has a bunch of info.  It
looks like these are newer parts than the stuff on the initial FRAM dev
board, and that some Wolverines will have 64k of FRAM on chip.  I think
it's time for a fully self-hosted Forth system on one of those ;-).

> That's why is called value line. You pay only some quarters instead of
> some bucks.  What do you expect?

Well, the 16k/512B part that 4e4th uses is around $1 in quantity, and
for a little bit more you can get 32-bit chips with a LOT more
resources.  It's true the low end value line is in the 25 cent range.

I notice one slightly annoying thing about 4e4th/Camelforth which is
that it doesn't seem to be actually self hosted.  It relies on some kind
of fancy external macro assembler to build the kernel with, rather than
a self-contained Forth assembler.  I guess that is practical but it
means you need another machine to run the assembler on, I guess.

[toc] | [prev] | [next] | [standalone]

#10487

Hello Paul,

Paul Rubin <no.email@nospam.invalid> writes:
>
> I notice one slightly annoying thing about 4e4th/Camelforth which is
> that it doesn't seem to be actually self hosted.  It relies on some kind
> of fancy external macro assembler to build the kernel with, rather than
> a self-contained Forth assembler.  I guess that is practical but it
> means you need another machine to run the assembler on, I guess.

keep in mind that the 4e4th is only a few days old, you can't expect
everything to be perfect already. And it is open source, so if you like,
help to get it self-hosted.

-- Carsten

[toc] | [prev] | [next] | [standalone]

#10491

cas_news@strotmann.de (Carsten Strotmann (Usenet)) writes:
>> 4e4th/Camelforth ... doesn't seem to be actually self hosted.  It
>> relies on some kind of fancy external macro assembler >
> keep in mind that the 4e4th is only a few days old, you can't expect
> everything to be perfect already. And it is open source, so if you like,
> help to get it self-hosted.

Oh ok, I didn't realize that part of the code was so recent.  I thought
that it was part of the Camelforth MSP430 port which has been around for
a while.  Anyway, it's an awesome job, getting a real Forth running on
that board.  The assembly code is quite readable even though I've never
programmed the MSP430 (it probably helps that I'm familiar with the
PDP-11 which is sort of an ancestor of the 430).  Overall it's a great
education in how computers actually work at the low level, probably much
more than the Raspberry Pi.

Is the external assembler something you wrote, or is it one of the
Launchpad tools (IAR Kickstart or something like that)?

Anyway, it's all very nice work, congrats on the excellent job.

[toc] | [prev] | [next] | [standalone]

#10505

On Mar 26, 9:10 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> cas_n...@strotmann.de (Carsten Strotmann (Usenet)) writes:
>
> >> 4e4th/Camelforth ... doesn't seem to be actually self hosted.  It
> >> relies on some kind of fancy external macro assembler >
> > keep in mind that the 4e4th is only a few days old, you can't expect
> > everything to be perfect already. And it is open source, so if you like,
> > help to get it self-hosted.
>
> Oh ok, I didn't realize that part of the code was so recent.  I thought
> that it was part of the Camelforth MSP430 port which has been around for
> a while.  Anyway, it's an awesome job, getting a real Forth running on
> that board.  The assembly code is quite readable even though I've never
> programmed the MSP430 (it probably helps that I'm familiar with the
> PDP-11 which is sort of an ancestor of the 430).  Overall it's a great
> education in how computers actually work at the low level, probably much
> more than the Raspberry Pi.
>
> Is the external assembler something you wrote, or is it one of the
> Launchpad tools (IAR Kickstart or something like that)?
>
> Anyway, it's all very nice work, congrats on the excellent job.

Yes, indeed. Congratulations! I'm very excited by this. I have a
number of MSP430 boards on my desk right now, including the LaunchPad
which cost $4.30 (neat!).

Just been looking at some of the FRAM stats. According to TI:

* FRAM can be written to 100 trillion times (14 zeros). FLASH is
around 10,000.
* At the maximum write speed of flash (13 kB/s) a 512 byte block will
deplete in under seven minutes (with flash). With FRAM it would
require 150,000 years to deplete.
* The FRAM is organised into blocks, similar to Flash. However, the
massive write endurance enjoyed by FRAM means that you simply treat it
as RAM. There is no write depletion to worry about, thus you don't
need to worry about (for example) moving blocks around in order write-
level your memory. It's just RAM. Write at the byte level and enjoy.
Goodbye Flash!

Must do something with these '430 boards. They've been on my desk for
months.

[toc] | [prev] | [next] | [standalone]

#10507

Does anyone have any information on the capabilities of CamelForth?

I'm looking on the CF website, but there doesn't seem to be a manual
of any kind. For example, does CamelForth support multi-tasking?

Mark

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web