1000 Scouts to solder together MSP430 Forth systems - a Forth computer each end of July - and planned to connect them all as a 1000 Bit Display on the last day

[JUERGEN]

How can we promote the Forth language usage?
Go to the Young Generation,
or maker fares
and next to the Coder Clubs
and schools

When the IET asked us to support an electronics activity at this year's Scout's Jamboree in the UK, we said yes - not knowing really what we got ourselves onto.
A lot more work than we had assumed.
But there we are:
Design the board and the system
Plan the software
Prepare for worst case component scenarios - but still make sure for a positive experience for up to 1000 scouts.

This is where we thought it stops
- but then we found out that there is no budget really for this project
- so learning about fundraising was then included as well.
And people we knew have been appreciating the work we do, supporting us with components and money.


Finding money and components was key for the success of this project.
MPE was very helpful, as was HIDECS. And Michael and Dirk.
Anybody I asked contributed where possible.

If you or your company wants to help and get their logo into the prospectus - just go ahead. Send £100 and a logo - and you are in as the others.

For the rest of the supporters have a look at the official link

http://mycommunity.theiet.org/blogs/96/2612

and more on the Forth side:

http://www.forth-ev.de/ click on English version
Download the main scouts files from here.

And as you are there, have a look as well at MMT, as this scouts project is using the same hardware:

http://www.forth-ev.de/wiki/doku.php/projects:mmt4ue2:start
here as well as German and as English version

As this scouts jamboree is an international event, we assume we can spread the Forth message further.

As you can see, FTDI has already donated USBtoTTL cables - so the scouts can start programming in Forth - at the event or later.

Some schools have found this project already and called me, and we will support them after the event end of July.
A bit simpler to control IO and LEDs than using Phython and RPI ...
And definitely an intelligent IO even for Arduino and RPI.

As of today we have nearly all of the parts - the rest should come in over the next 4 weeks.
If not donated, then sponsors have given the money to buy the missing parts.

The system shows the beating heart of the owner as seen on the Forth-ev website
- and they can all be connected as a social network,
the Forth software is nearly ready.

During the next weeks we are preparing a simple Forth programming scenario as we are sure the hardware will be there;
just using about 20 Forth Words to have a minimum Word set to control IOs
- the full Forth Word set is available in the background anyway for further programming and it all is programmed into the MSP430.

I might come back to the Forth Community soon, showing the minimum hardware and asking for simple Forth examples using this hardware to support this project.

[Mark Wills]

This is too cool for words! MAJOR congratulations to all involved.

Mark

[JUERGEN]

On Thursday, June 18, 2015 at 8:07:26 AM UTC+1, Mark Wills wrote:
> This is too cool for words! MAJOR congratulations to all involved.
>
> Mark

Well it takes time, but the set is nearly ready:

If people want to see where it comes from:

Forth - The Early Years: Background information about the beginnings of this Computer Language

And how the language works:

Programming A Problem Oriented Language: Forth - how the internals work

Then want to see some more examples:

FORTH LITE TUTORIAL: Forth Tutorial tested with free MPE VFX Forth, mostly compatible with FORTH INC. SwiftForth.

And even an application example is available soon, how to rewrite and existing application in Forth:
Compatible with:

Learning Programming with MyCo: Learning Programming easily - independent of a PC

in short they are all available at:

goo.gl/gPkXPG



Not to forget the Starting Forth, reformatted for offline reading and printout
to be downloaded from:

http://www.exemark.com/FORTH.htm see item 3

[Alexander Skobelev]

JUERGEN <epld...@aol.com> writes:

> [ … ]

> and more on the Forth side:
>
> http://www.forth-ev.de/ click on English version
> Download the main scouts files from here.

Hmm, I didn't find where the link to English version is.

> [ … ]

[JUERGEN]

On Friday, June 19, 2015 at 3:48:29 PM UTC+1, Alexander Skobelev wrote:
> JUERGEN <epld...@aol.com> writes:
>
> > [ ... ]

> > and more on the Forth side:
> >
> > http://www.forth-ev.de/ click on English version
> > Download the main scouts files from here.
>
> Hmm, I didn't find where the link to English version is.
>

> > [ ... ]

Pfadfinder und Forth?
1000 solche Controller, der größte Forth Cluster, gebaut von Pfadfindern (for English version please click here)
underneath the links to the PDFs

just tried it, or go directly to English
http://www.forth-ev.de/staticpages/index.php/20150518223732910
and the links to the PDFs as well

and the same on the MMT side
http://www.forth-ev.de/wiki/doku.php/projects:mmt4ue2:start

Click here for English Version
or directly for English
http://www.forth-ev.de/wiki/doku.php/en:projects:mmt4ue2:start

Enjoy the videos Michael did

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> http://mycommunity.theiet.org/blogs/96/2612

Nice! Is it running a resident MPE Forth on the '2553 part, as
indicated by the label? Or is it 4e4th which is maybe smaller?

Around here we use the AVR for most introductory MCU things, but of
course the MSP430 is a nicer chip in lots of ways.

[JUERGEN]

Thanks for asking.

As usual with Forth and especially here, any implementation will do. As this is promoted by the IET and going out to the international group of scouts, supporters across Europe, Press releases Europeanwide ( and as you cannot stop it now, coverage visible worldwide ) it seemed to be a good idea to have a commercial product involved - MPE Forth. This will give the readers or participants a different image of the project.
Part of the design has been done with 4e4th - as of the people involved.
But the idea and the concept is not limited to any.

eForth might be even better as of the 4k footprint, so more space for applications.

It is a nice side effect that we promote Forth here, not as a language but as application software - the guys will not know how to spell Forth, but learn on the way why it is used here - apart from the fact that it is the best one anyway ...

The Forths used here are based on the people who know their own flavour best and help me with this project tremendously - mainly Michael Kalus, Dirk Bruehl, and Paul Bennett.

MSP430 was chosen as of 20 pins only and availability in a good old through hole package - remember, some total beginners will solder here for the first time and build a battery driven microcontroller project with all of the development software and application software on-chip.

Regarding the processor choice: not to forget the tremendous TI support - they sent 1000 chips foc - I just had to explain clearly what we want to achieve.
I have them here.


We go here for minimum complexity of board and software usage, a small and battery driven system - but it can be extended in any way.
All of the headers are there to stick a wire in or another header.
We actually have as well the IO shield for a few of them - the hard core.

Minimum step size for learning is my target for this project - to achieve maximum success and have fun only if possible - and learn about Forth on the way.

Connect an FTDI cable and you are ready to program.
Connect external hardware and for example get your 3 or 4 RC Servo Robot going ...

Our biggest hardware challenge will be the 1024 unit network (if enough scouts get soldering) - all of them connected and controlled centrally from one of the same battery driven units.

Any company here on clf can get their name in - based on a contribution - see the PDF information at www.forth-ev.de and as well now at the IET Blog http://mycommunity.theiet.org/blogs/96/2612

The flashing LED represents the beating heart of the one who built the unit
- and they will all be connected on the final day
as a "social network".

A 32 by 32 bit LED array, battery driven - with a size of about 2 x 2 meters ...
Bit adressable. Running time of the unit would be about 1 - 2 weeks.

This is not just planned as a one off - but will be taken to schools afterwards in the UK.

The cost is low and it can be repaired - so you can try things out - and kill a chip - just replace it and continue ...

Paul and I will probably spend quite a bit of time with the scouts at the camp last week of July, to ensure that this project and activity is a memorable success for them,
and the supporters will get pictures and as such get something back for their kind donation.

I think I might even have convinced Stephen Pelc of MPE to come up and see us, and do a few demos for the scouts.

Definitely something for the scouts to talk about with their mates during the event and show to others afterwards.


The list of sponsors is getting longer, from TI and FTDI via Dyson Foundation to samtec and many others. All donating either parts or giving a financial contribution.

I had a closer look at the sponsor list yesterday and was impressed to see what we have achieved over the last 2 months. And there is another month to go.

[Howerd]

Hi Juergen & Team,

Excellent project :-)

Best regards,
Howerd

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
>> Nice! Is it running a resident MPE Forth on the '2553 part, as
>> indicated by the label? Or is it 4e4th which is maybe smaller?

> As usual with Forth and especially here, any implementation will do.

Well ok, but I wondered if you were using MPE because 1) I didn't
realize MPE Forth was small enough to run resident on the 2553 (so I
thought maybe you're using a tethered version), and 2) while MPE Forth
is a great product for professional use, if the idea is to empower new
makers/hackers, I think it's best to use completely FOSS software that
they can study and modify and redistribute.

> eForth might be even better as of the 4k footprint, so more space for
> applications.

Wow, I didn't realize eForth was that small. Interesting.

> MSP430 was chosen as of 20 pins only and availability in a good old
> through hole package - remember, some total beginners will solder here

Yes, it sounded like the main goal was to teach something about
electronics and soldering. Otherwise it might have been better to use
the Launchpad board or something comparable. Here are some other
beginning electronic projects that might be of interest:

https://noisebridge.net/wiki/Circuit_Hacking_Mondays

> Regarding the processor choice: not to forget the tremendous TI
> support - they sent 1000 chips foc -

Yes, it's wonderful to get so much hardware for free.

> Our biggest hardware challenge will be the 1024 unit network (if
> enough scouts get soldering) - all of them connected and controlled
> centrally from one of the same battery driven units.

It will be interesting to hear more about that. How about something
like a 32x32 Pong game with no central control? Each unit would be
connected to its neighbors by GPIO, and the paddle and ball locations
would propagate through the network, as would some kind of global "start
new game" command.

[Mark Wills]

Paul, VFX Lite is free ;-)

[Paul Rubin]

Mark Wills <markwi...@gmail.com> writes:
> Paul, VFX Lite is free ;-)

It's downloadable at no charge, but it's not FOSS unless I'm very
mistaken.

[JUERGEN]

As stated before - MPE's MSP430 LITE and 4e4th.

MSP430 LITE is free of charge
see http://www.mpeforth.com/xc7lite.htm

The LITE version was especially done by MPE after many discussions to have a commercial product, but foc to start with. And it is resident, just add a terminal. Umbilical is possible with it as well.

And there is another and very strong reason: all the software and the examples now done for the MSP430 can be easily ported to the MPE ARM LITE - probably not possible with any other compiler solution as far as I know.
Both versions supported by a commercial Forth supplier.
And there is no reason why the example software cannot be ported to the flavour of the month - or the new compiler not even available yet.

A tethered approach for beginners - I would not even dream about starting them there.

This is an foc project taking a lot of my private time and based on the support of the people who give their time for free. As result it is based on the knowledge they have.

I had mentioned this hardware a year ago - the resulting comments showed how wide the interest and the wishes go. Well there are enough Arduinos and Pis out there. Would I use a soldering iron on them - probably once.
Can I just repair them by sticking another chip in - no.

Using LP - fine, but who would give us 1000 Launchpads for free for this project - and the electronic badge would be a bit large and heavy to carry around. And you cannot put it in your pocket.

I am thankful about the support I get.
If people have other and better ideas - well do it and share it.

There is a commercial world out there and there is the rest - no judgement. If the outside world has the idea that Forth is only for hobbyists, it will stay where it is now - or more bluntly it will be less in the next generation to come.
I got my Starting Forth from a customer as a thank you many years ago, and the language stayed interesting for me , but I was surprised to see how the language world has developed.

Well the Pong idea is brilliant, can you please expand on the hardware implementation and the software approach you are offering please.

Our plan is to build a 1024 bit unit with an LED each - bit adresseable.
Any shape is possible as the TicTac Boxes are just mounted on the shape required.

Which leads to a question for all here who might like a little challenge:

A next step would be software wise and for now after the event:

Build a software UART but not standard 8 bit, a lot longer, 1024 bits long plus a few bits, that is for the master to send out this string. The 1024 slaves are only listening to this string and pick out their bit. Just passive in this respect. This would give us the opportunity to transmit to the array a lot faster than bit addressing.
... and if sequential frames are implemented to add information - then more bits per pixel can show a few bits per pixel ...

A test hardware consisting of around 32 units will be built for software testing soon.

[Stephen Pelc]

On Sat, 20 Jun 2015 15:33:01 -0700, Paul Rubin
<no.e...@nospam.invalid> wrote:

>JUERGEN <epld...@aol.com> writes:
>>> Nice! Is it running a resident MPE Forth on the '2553 part, as
>>> indicated by the label? Or is it 4e4th which is maybe smaller?
>> As usual with Forth and especially here, any implementation will do.
>
>Well ok, but I wondered if you were using MPE because 1) I didn't
>realize MPE Forth was small enough to run resident on the 2553 (so I
>thought maybe you're using a tethered version), and 2) while MPE Forth
>is a great product for professional use, if the idea is to empower new
>makers/hackers, I think it's best to use completely FOSS software that
>they can study and modify and redistribute.

The free (of charge) MPE Lite compiler for the MSP430 targets the
'2553 part with a standalone Forth. An umbilical Forth is also
available but needs a protocol update to be useful.

The Lite compiler has direct integration to the 2553 Launchpad's FET.

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

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> As stated before - MPE's MSP430 LITE and 4e4th.

Ah, ok, I wasn't completely understanding this earlier.

> The LITE version was especially done by MPE after many discussions to
> have a commercial product, but foc to start with. And it is resident,
> just add a terminal. Umbilical is possible with it as well.

Do you (or Stephen) happen to know the code size for the resident
interpreter on the 2553? Is it possible to compile to flash from the
interpreter on the 2553 directly, without the Launchpad FET?

> And there is another and very strong reason: all the software and the
> examples now done for the MSP430 can be easily ported to the MPE ARM
> LITE - probably not possible with any other compiler solution as far
> as I know.

I expect this is possible with eForth. 4e4th is based on Camelforth
which at the moment doesn't appear to run on the ARM, but run on various
other cpus so maybe it can be ported to the ARM someday.

> I had mentioned this hardware a year ago - the resulting comments
> showed how wide the interest and the wishes go. Well there are enough
> Arduinos and Pis out there.

I agree this seems like a really nice project for teaching MCU
electronics.

> Using LP - fine, but who would give us 1000 Launchpads for free for
> this project -

Well you could ask TI about it... FWIW they are having a sale on the
FRAM MSP430 Launchpad that has an LCD display. But, using a ready-made
board is more for teaching programming than electronics.

> and the electronic badge would be a bit large and heavy to carry
> around. And you cannot put it in your pocket.

Do you mean the electronic badge from the Noisebridge page I linked?
I've seen them and want one myself sometime. It's really cool and you
can easily put it in your pocket when you're not wearing it.

The people taking the Noisebridge class do have to pay for those kits
themselves, which gives a bit more flexibility about what can go into
them. If your Scout event has to give away all the hardware for free,
it's understandable that your possibilities are much more limited.

> Well the Pong idea is brilliant, can you please expand on the hardware
> implementation and the software approach you are offering please.

I was imagining something like the GA144 architecture, where each node
would have 4 connections to its orthogonal neighbors. Originally I
thought of just passing data, but (like the GA and per some of Bernd P's
posts) it would be really cool to connect the ports up to the Forth
interpreter, using software UARTs if necessary. The MPE interpreter
apparently has multitasking, which could be useful for that.

The cute thing about this is the nodes wouldn't have to know their own
coordinates. They'd all run exactly the same code and start with the
same data. One of them would have an additional connection to an
outside terminal. There could be a command like

: LED-ON ( x y -- ) ... ;

which would turn on the node's LED if x and y are both 0. Otherwise it
would adjust x and y and pass the command to a neighboring node, i.e.
8 5 LED-ON on Jane's node would send "8 4 LED-ON" to Jane's node's
rightward neighbor and so on, so eventually the node 8 upward and 5 to
the right of Jane's would turn on its LED.

It could also be cool to have hypercube wiring instead of the horizontal
grid. I guess both of these make the wiring much more complicated than
your broadcast bus idea though.

You'd want to have a header on the board so each kid could wire up his
or her own node to its neighbors on the big panel with solderless
breadboard jumpers. The header would also make it easier to connect up
the board to other devices.

> Our plan is to build a 1024 bit unit with an LED each - bit
> adresseable. Any shape is possible as the TicTac Boxes are just
> mounted on the shape required.

I didn't know TicTac boxes were involved, or that they could hold the
board and batteries. Sounds nice.

I guess you were thinking of a giant broadcast bus rather than some kind
of fanout scheme, so ok, I guess that's doable.

> Build a software UART but not standard 8 bit, a lot longer, 1024 bits

This doesn't seem like a great idea. I'd go with standard 8 bit. The
nodes could still all listen to it for data that interested them. You
could send Forth commands like $25 BLINK to tell node #25 (hex) to blink
its led, or something like RLEBLINK to broadcast a 1024 bit RLE encoded
bit stream, where each node would blink its led if the appropriate bit
was set.

> A test hardware consisting of around 32 units will be built for
> software testing soon.

Nice. Maybe you could make the initial ones on protoboards:

http://www.adafruit.com/products/1608 (soldered)
http://www.adafruit.com/products/65 (solderless)

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> As you can see, FTDI has already donated USBtoTTL cables - so the
> scouts can start programming in Forth - at the event or later.

Did they give you 1000 cables? If not, it occurs to me, maybe you could
implement software USB like the Digispark and similar tiny *duinos do.
There are various implementations around, including I think on
adafruit.com. So you'd be able to use a USB cable with no FTDI chip.
You could put a micro usb connector on the board for that, and also use
it for power, turning the batteries into a user option.

[JUERGEN]

On Sunday, June 21, 2015 at 6:39:39 PM UTC+1, Paul Rubin wrote:
> JUERGEN <epld...@aol.com> writes:
> > As stated before - MPE's MSP430 LITE and 4e4th.
>
> Ah, ok, I wasn't completely understanding this earlier.
>
> > The LITE version was especially done by MPE after many discussions to
> > have a commercial product, but foc to start with. And it is resident,
> > just add a terminal. Umbilical is possible with it as well.
>
> Do you (or Stephen) happen to know the code size for the resident
> interpreter on the 2553? Is it possible to compile to flash from the
> interpreter on the 2553 directly, without the Launchpad FET?

You can use INCLUDE - or reflash via LP

>
> > And there is another and very strong reason: all the software and the
> > examples now done for the MSP430 can be easily ported to the MPE ARM
> > LITE - probably not possible with any other compiler solution as far
> > as I know.
>
> I expect this is possible with eForth. 4e4th is based on Camelforth
> which at the moment doesn't appear to run on the ARM, but run on various
> other cpus so maybe it can be ported to the ARM someday.

Everything is possible, but somebody (other probably) has to do it. Can I start a project with a deadline without having a delivery plan ? No. Good ideas can only help us on future projects - I rather stick to what I can see and get hold of now.

>
> > I had mentioned this hardware a year ago - the resulting comments
> > showed how wide the interest and the wishes go. Well there are enough
> > Arduinos and Pis out there.
>
> I agree this seems like a really nice project for teaching MCU
> electronics.

Thank you - and it could hardly be more minimal and scalable:
Absolute: PCB - Chip - R - C - C - R - LED
Interface; add the header or headers
Mobile: add the batteries
Enclosed: add the TicTac box you just enjoyed, and put it in your pocket
PC programming: add your USBtoTTL cable
External IO: stick it into the IO headers or solder on
Plus Shield: add a shield with buttons, more LEDs and an LDR as analog IO
Plus_Custom: hat you can think or and share with others
Flash in the MMT: that we had done before as seen on www.forth-ev.de
FLASH IN MYCO, a little simulated Micro : start programming by just using the 3 buttons and 5 LEDs - no PC required
in the works: Start programming in Forth using a minimal word set to understand how the micro works, using the same shield or connect directly to the board

.

>
> > Using LP - fine, but who would give us 1000 Launchpads for free for
> > this project -
>
> Well you could ask TI about it... FWIW they are having a sale on the
> FRAM MSP430 Launchpad that has an LCD display. But, using a ready-made
> board is more for teaching programming than electronics.

I tried to be realistic and start the project in a way that I can follow it through successfully.

>
> > and the electronic badge would be a bit large and heavy to carry
> > around. And you cannot put it in your pocket.
>
> Do you mean the electronic badge from the Noisebridge page I linked?
> I've seen them and want one myself sometime. It's really cool and you
> can easily put it in your pocket when you're not wearing it.

No, this is our badge, you see it in the PDF on Forth-eV

>
> The people taking the Noisebridge class do have to pay for those kits
> themselves, which gives a bit more flexibility about what can go into
> them. If your Scout event has to give away all the hardware for free,
> it's understandable that your possibilities are much more limited.

Exactly.

>
> > Well the Pong idea is brilliant, can you please expand on the hardware
> > implementation and the software approach you are offering please.
>
> I was imagining something like the GA144 architecture, where each node
> would have 4 connections to its orthogonal neighbors. Originally I
> thought of just passing data, but (like the GA and per some of Bernd P's
> posts) it would be really cool to connect the ports up to the Forth
> interpreter, using software UARTs if necessary. The MPE interpreter
> apparently has multitasking, which could be useful for that.

You just discovered a secret. Longer term the idea was to emulate a G1 with a suitable interface.
Can you point out where such an interface can be found? I just planned something like the TransputerLink, or in the beginning just serial interfaces.

>
> The cute thing about this is the nodes wouldn't have to know their own
> coordinates. They'd all run exactly the same code and start with the
> same data. One of them would have an additional connection to an
> outside terminal. There could be a command like
>
> : LED-ON ( x y -- ) ... ;
>
> which would turn on the node's LED if x and y are both 0. Otherwise it
> would adjust x and y and pass the command to a neighboring node, i.e.
> 8 5 LED-ON on Jane's node would send "8 4 LED-ON" to Jane's node's
> rightward neighbor and so on, so eventually the node 8 upward and 5 to
> the right of Jane's would turn on its LED.
>
> It could also be cool to have hypercube wiring instead of the horizontal
> grid. I guess both of these make the wiring much more complicated than
> your broadcast bus idea though.

All possible with this hardware (within limits, so we do an SGA1k ( Scouts GA with 1k nodes)

>
> You'd want to have a header on the board so each kid could wire up his
> or her own node to its neighbors on the big panel with solderless
> breadboard jumpers. The header would also make it easier to connect up
> the board to other devices.

Implemented or prepared for already

>
> > Our plan is to build a 1024 bit unit with an LED each - bit
> > adresseable. Any shape is possible as the TicTac Boxes are just
> > mounted on the shape required.
>
> I didn't know TicTac boxes were involved, or that they could hold the
> board and batteries. Sounds nice.

We needed an enclosure - and I found this solution
Two AAAs and a little PCB fills it. ( or 2 boards and a coin cell )

>
> I guess you were thinking of a giant broadcast bus rather than some kind
> of fanout scheme, so ok, I guess that's doable.

The only reliable and fault tolerant solution for now

>
> > Build a software UART but not standard 8 bit, a lot longer, 1024 bits
>
> This doesn't seem like a great idea. I'd go with standard 8 bit. The
> nodes could still all listen to it for data that interested them. You
> could send Forth commands like $25 BLINK to tell node #25 (hex) to blink
> its led, or something like RLEBLINK to broadcast a 1024 bit RLE encoded
> bit stream, where each node would blink its led if the appropriate bit
> was set.

I kindly disagree. Direct addressing can only be done in roughly
Guess 5 bytes per addressing x 1000
1kUART is 1k bits, so very roughly 5 times faster, if I calculated correctly 10 frames per second - moving graphics
or just to dream as there would not be time enough now:
2 combined frames ( or 2k UART ) gives 5 frames per second and 4 levels of brightness - slow scan TV, which would make picture generation easier using a camera or video signal

>
> > A test hardware consisting of around 32 units will be built for
> > software testing soon.

CORRECTION: a 16 node unit plus the related repeater has been built over the weekend. I will try to have a picture put up on the MMT website.
No prototype boards but using last year's MMT boards.
So it is time for the software department now to get programming to test it.
A second node probably next week.

[JUERGEN]

This question cannot be serious, teasing for example?
a) 1000 USBto TTL cables, that is a value of 20 000 Dollars
b) where are the 1000 PCs coming from to connect the cables to? And where do you put them, 250 additional tables and a hall to be rented.
An additional power consumption of 1k x 50 watts = 50kW
... plus 150 to 250 extention cables to power them - and a very large socket.
c) you could not have a the boards close enough to have a display

[Alexander Skobelev]

Thanks! I was looking for a global link that would turn the whole site
to the English and missed the local one.

[Stephen Pelc]

On Sun, 21 Jun 2015 10:39:36 -0700, Paul Rubin
<no.e...@nospam.invalid> wrote:

>Do you (or Stephen) happen to know the code size for the resident
>interpreter on the 2553?

It's 12 kb with the tools for comfortable use with the supplied IDE
that includes editor, terminal emulator and command tool (for the
cross compiler).

> Is it possible to compile to flash from the
>interpreter on the 2553 directly, without the Launchpad FET?

Yes.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
>> 4e4th ... maybe it can be ported to the ARM someday.
> Everything is possible, but somebody (other probably) has to do it...

> Can I start a project with a deadline without having a delivery
> plan ? No. Good ideas can only help us on future projects

Right, I wasn't suggesting you do such a port, just that it's something
to know about if you have an ongoing in Forth for the MSP430.

I also notice that amForth now runs on the 430:

http://amforth.sourceforge.net/

This is a very well documented system that runs on the Arduino and
claims "AmForth implements an almost compatible Forth 2012 indirect
threading 16bit Forth." But, I've never used it and the 430 port is
newer and (for now) possibly less developed.

>> it would be really cool to connect the ports up to the Forth
>> interpreter, using software UARTs if necessary.

> Can you point out where such an interface can be found? I just planned
> something like the TransputerLink, or in the beginning just serial
> interfaces.

I just meant wires connecting the cpus together through gpio and bit
banging, since there's just one hardware uart per chip.

Actually a REALLY crazy idea might be an all-to-all spread spectrum
broadcast network. You'd connect an analog pin from each chip through a
resistor to a giant backplane (aluminum foil sheet maybe). Then you'd
pulse messages to the backplane according to a spreading sequence
generated from the target address. The target would listen to the
backplane with a software autocorrelator. The bit rate would have to be
pretty low.

>> TicTac boxes

> Two AAAs and a little PCB fills it. ( or 2 boards and a coin cell )

Nice, somehow I thought those boxes were smaller, but I haven't looked
at one lately.

>> I guess you were thinking of a giant broadcast bus

> The only reliable and fault tolerant solution for now

The GA1K scheme sounds potentially workable.

>> > Build a software UART but not standard 8 bit, a lot longer, 1024 bits

>> RLEBLINK to broadcast a 1024 bit RLE encoded bit stream

> I kindly disagree. Direct addressing can only be done in roughly
> Guess 5 bytes per addressing x 1000
> 1kUART is 1k bits, so very roughly 5 times faster,

You'd need 10 bits to address 1024 nodes individually, but the idea
wasn't to send a separate address with each bit. It's just to send the
1024 bits as 128 8-bit bytes with a normal uart, rather than a special
software uart that collects all the bits synchronously. That lets you
use the hardware uart on the chips. Also in the case of normal graphics
where most of the leds are on or off, RLE (run-length encoding) can
compress the 1024 bits by quite a lot.

> if I calculated correctly 10 frames per second - moving graphics

If you want to display video then the transmission speed matters, 30 fps
x 1000 bits = 30k bits/sec, or with 3-bit greyscale (PWM dimming) 90k,
and maybe the uart can run at 115k, so there's a chance.

For the Pong game I was imagining something more like a cellular
simulation. The 4(?) nodes displaying the "ball" would move the ball by
informing their neighbor in the appropriate direction that the ball was
moving to them. Eventually the ball would hit a node with a paddle and
bounce. The paddle nodes would also move up and down by local
communication. This is more in the G1K spirit, I think. You wouldn't
have to send anything to all 1024 nodes simultaneously, though there
would have to be some kind of "reset" message that you'd send to
initialize the board at the start of the game. It's ok if that
propagates through the network at fairly low speed, like 100's of msec
to reach all the nodes, before the game starts.

[Matthias Koch]

Make sure to wire a red or yellow LED with both pins to the microcontroller. So you can measure brightness and implement a reactive light for geocaching at night, which might be most interesting for the audience. Also this opens up the possibility for optical communication with Ledcomm (http://mecrisp.sourceforge.net/ledcomm.htm) and you can create beautiful-looking flashing pattern synchronisation sequences as seen in swarms of fireflies naturally.

Some ideas with "light in and light out":

http://tinkerlog.com/2009/06/25/64-synchronizing-fireflies/
http://interactive-matter.eu/blog/2008/10/01/how-was-your-day-darling/
http://reaktivlicht.de/index_EN.html
http://www.merl.com/publications/TR2003-35

I would take care of making this waterproof (centrifuge tubes!) and choose to have the reactive light mode for default and a swarm behaviour for art if many of the circuits encounter.

Matthias

[JUERGEN]

Thank you very much for your inputs.
Short term the TicTac with sticky tape around the top will protect it. I had it under water already - I had to try it.

Thank you very much for the links. Is there any code we could re-use?
All the interfacing is there, and we have additional LEDs.
Depends just on the additional time available at the event - or afterwards.

Ideal setup for GeoCaching I can see.

I had to define a minimum version though, so it works at the event, and everything else is extension.
The Reed contact was planned already - it was actually part of my first design many many years ago - used as sensor for mains short circuit protection, either flashing for 1h as the LED version or a version two was actually a 200V flash light - all sealed and hanging on a 100kV wire for many years...


... and the 128 x 8 byte telegram is a very good option - the HW setup does not change.

We now have just to find a way to make the nodes adressable - so software can he reloaded onto each unit ...

And it could definitely be a used as a GA 1024 simulator, just add a couple of wires to define the matrix 2D, 3D ...

[foxaudio...@gmail.com]

<SNIP>

I did this once with small boards, RS422 and the EASY-A protocol by Randy Dumse.
Every boards sits in a loop waiting for CTRL A ( 1) If they read CTRL A they wait for an integer that is their ID. If they see their ID, they just run Quit and the Forth interpreter is ready waiting for source code.
If they don't see their ID integer they go back to waiting for CTRL A.

I have posted this before but here it is again.

<pre>
( EASYA.MAX a simple networking protocol for MaxForth )

DECIMAL

( the Id address 'me' could be coded as a word that gets a number from)
( EEPROM or a set of switches on a port. )
( In this case it is the VARIABLE UNIT# stored in battery RAM. )

01 CONSTANT ^A

VARIABLE SELECTED ( flag varible to tell the system)
( that God is talking to it. :- )
VARIABLE UNIT# 002 UNIT# !

: me ( -- c ) UNIT# @ ;

HEX
: TX-ON ( -- ) PORTA C@ 10 OR PORTA C! ;
: TX-OFF ( -- ) PORTA C@ 10 NEGATE AND PORTA C! ;

( just like in Forth you end communication by re-starting the interpreter)
( loop. In Forth it's called QUIT. )
( Here it's called ETX [end transmission] )
: ETX
TX-OFF ( tri-state the RS422 TX chip )
( MULTI-IO ( enable multi-tasking I/O )
FALSE SELECTED ! ( we're not selected )
BEGIN ( this is the entire protocol )
BEGIN
KEY ^A = ( wait for ^A )
UNTIL
KEY me = ( then check for your own ID )
UNTIL ( loop until above is true )
TX-ON ( enable RS422 transmitter chip )
TRUE SELECTED !
^A EMIT me EMIT ( reply with ^A and my ID # )
QUIT ; ( run the Forth interpreter )
( now the node can interpret ANY forth )
( word. )

( to end the session the host simply sends the text command ETX and )
( the node hangs up and waits for the access sequence again. )
( ***********************************************************************)
</pre>

[Matthias Koch]

> Thank you very much for your inputs.
> Short term the TicTac with sticky tape around the top will protect it. I had it under water already - I had to try it.
>
> Thank you very much for the links. Is there any code we could re-use?
> All the interfacing is there, and we have additional LEDs.
> Depends just on the additional time available at the event - or afterwards.

See ledcomm-launchpad.txt in the mainstream release package of Mecrisp. The other ideas are not yet implemented in Forth.

> Ideal setup for GeoCaching I can see.
>
> I had to define a minimum version though, so it works at the event, and everything else is extension.

Fine.

> The Reed contact was planned already - it was actually part of my first design many many years ago - used as sensor for mains short circuit protection, either flashing for 1h as the LED version or a version two was actually a 200V flash light - all sealed and hanging on a 100kV wire for many years...
>
>
> ... and the 128 x 8 byte telegram is a very good option - the HW setup does not change.
>
> We now have just to find a way to make the nodes adressable - so software can he reloaded onto each unit ...
>
> And it could definitely be a used as a GA 1024 simulator, just add a couple of wires to define the matrix 2D, 3D ...

Sorry ? What ? I am slightly confused. Maybe posting a schematic of the actual hardware you wish to solder on the event would be a good idea.

Matthias

[JUERGEN]

\ Check in Courier, this is the absolute minimum, but still nicely extendable
\ for beginners - powerful enough to start with, programmable via LP
\
\ (TOP VIEW MSP430G2553)
\ VCC-(+3.3V)---------[01 20]- 2uF to Plus (GND)-VSS
\ -P1.0--[02 19]--P2.6
\ -RXD-Serial->-P1.1--[03 18]--P2.7
\ -TXD-Serial-<-P1.2--[04 17]--Test -( programming )
\ P1.3--[05 16]--RESET R to +, C to GND
\ P1.4--[06 15]-- P1.7
\ P1.5--[07 14]--P1.6 270R + LED to GND
\ P2.0--[08 13]--P2.5
\ P2.1--[09 12]--P2.4
\ P2.2--[10 11]--P2.3
\
\ 2 x AAA battery plus this HW in a TicTac Box as
\ Flashing LED to represent the heart beat of the one who built it
\ ( just occurred to me later it looks like ET )
\ all RXs tied together via 1k each to the master module or LP.
\
\ IOs could be used as bit banged UARTs or SPIs for
\ interprocessor communication as discussed in the thread
\
\ Via the shield you can extend it for example to be MMT - see www.forth-ev.de
\ Just add 3 switches and 4 R + LED combinations and a loudspeaker.
\ Then you can drive even up to 4 RC servos as shown with MMT
\
\ (TOP VIEW)
\ VCC-(+3.3V)---------[01 20]----------------(GND)-VSS
\ -AN1 - -P1.0--[02 19]--P2.6 OUT2 -470R-LED-GND
\ -RXD-Serial->-P1.1--[03 18]--P2.7 OUT3 -470R-LED-GND
\ -TXD-Serial-<-P1.2--[04 17]--Test -( programming )
\ -S2-----------P1.3--[05 16]--RESET Switch S1 --
\ AN2-------- P1.4--[06 15]-- P1.7 S3-------
\ --Sound-Out-- P1.5--[07 14]--P1.6 PWM OUT-----------
\ >(R to +) IN0 P2.0--[08 13]--P2.5 OUT1 -470R-LED-GND
\ >(R to +) IN1 P2.1--[09 12]--P2.4 OUT0 -470R-LED-GND
\ >(R to +) IN2 P2.2--[10 11]--P2.3 IN3 -- (R to +)---<

Is this clear enough now Matthias?

The smallest version in DIL has just 12 x 4 pads, one end of these 4 pins are:
GND - Plus - RX - TX to connect to terminal - TEST and Reset just used for programming via LP. Uses FTDI USBtoTTL cable to connect to the PC.
Or with just battery connected as flashing unit.

One other requirement that would be nice but somebody still has to do it:
CLONING.
When the kids have written something they can then just copy the complete 430 code to another one - using the same 6 pins needed for programming - but generated by the master chip via 4 IOs. The Slave does not know where the signals come from and does not care. According to TI this is possible, all of the data seems to be in the relevant application note. No Launchpad required then anymore.
- Or I could always have a backup chip.

The other option might be using a unit to do a bit banged USB in a second chip...

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> One other requirement that would be nice but somebody still has to do

> it: CLONING.... The other option might be using a unit to do a bit

> banged USB in a second chip...

The LEDCOMM idea is brilliant for that. If I understand it correctly,
it doesn't need any more hardware (or maybe 1 more resistor), but the
LED has to be on an analog pin so you can track its forward voltage
fluctuating according to light exposure.

[JUERGEN]

I suggest P1.4 as input.
What is the hardware setup, and a suggested LED that can be reliably replicated?
Maximum resistor value? We are battery driven here, could use a switched output though.

And Matthias, can you please post code to output a Byte and Input a Byte,
I assume there are more that would like to look at it.
And for easy testing,to run on the same controller:
IN3 to set low to start the process
PWM as LED out,
P1.4 as input

As phase 2 then running on two controllers.

[Matthias Koch]

Paul Rubin schrieb:

No analog input needed, any digital pins are suifficient for that, given they have an input hysteresis. MSP430 pins are current limited, so it works without resistor in this case.

Matthias

[Matthias Koch]

Ledcomm is a synchronous bidirectional protocol, pulses are exchanged the whole time. The algorithm is hooked to a timer interrupt, with a default of 244 us, and inserts data into the stream of pulses.

No resistor is needed for MSP430G2553, my favourite LED is Kingbright L-53SRC-F. You should choose a pair of red high-brightness LEDs in clear housing with narrow angle, GaAlAs is fine. You need a direct bandgap semiconductor for Ledcomm in which emission and excitation spectrum overlap. Short: The LED needs to be sensitive to its own wavelength. My experience is that it works with high-brightness red and yellow LEDs, but not with green and blue ones, because they seem to be indirect bandgap semiconductors. You should stick to red because they can operate at lower voltage.

Matthias

This code with German comments is part of the Mecrisp release package and available under GPL3:

compiletoflash

: Sendedatenholen ( -- Daten true | false ) key? dup if key tuck emit then ;
: Datenempfangen ( Daten -- ) emit ;
: Verbindungsanfang ( -- ) ." (Up) " 1 p1out cbis! ; \ Verbindungsanzeige nach Bedarf anpassen
: Verbindungsende ( -- ) ." (Down) " cr 1 p1out cbic! ;

1 constant Anode
2 constant Kathode

: Strahle ( -- )
Anode P2OUT cbis!
Kathode P2OUT cbic!
Anode Kathode or P2DIR cbis!
;

: Lauschen-Vorbereitung ( -- )
Anode P2OUT cbic! \ Sperrschichtkapazität
Kathode P2OUT cbis! \ durch Verpolung laden
Anode Kathode or P2DIR cbis!
begin Kathode P2IN cbit@ until \ Warten, bis die Kathode geladen ist
Kathode P2DIR cbic!
;

: Lauschen-Nachbearbeitung ( -- Flag )
Kathode P2IN cbit@ not \ Ist die Kathode entladen, ist es hell
;


18 constant Synchrondauer

8 variable Strahlzaehler
0 variable Verbindungsdauer
0 variable Lauschzaehler
0 variable Lichtmuster
0 variable Sendedaten
0 variable Datenregister

true variable Zustand ( Hell oder Dunkel ? )

: msb? ( x -- x Flag ) dup 0< ;

: HolePuls ( -- )
8 Strahlzaehler ! \ Null-Puls, wird auch im Ruhezustand gesendet.

\ Verbindungsdauer prüfen, beginne erst zu Senden, wenn die Verbindung auch sicher besteht.
\ Belasse es im Falle einer gerade laufenden Synchronisation dabei, Ruhezustandspulse abzugeben.

Verbindungsdauer @ Synchrondauer =
if

Sendedaten @ ?dup if \ An bestehender Übertragung weiterarbeiten
msb? if 4 Strahlzaehler ! then \ Eins-Puls erforderlich ?
shl
dup 0= if 12 Strahlzaehler ! then \ Wurde gerade die Merk-Eins herausrotiert ? Übertragungspuls !
Sendedaten !
else \ Neue Daten holen und vorbereiten
Sendedatenholen
if
?dup if ( Daten-zum-Senden )
4 Strahlzaehler ! \ Bei neuen Daten ungleich Null wird die führende Eins gesendet

msb? if \ Ist das MSB schon die führende Eins ?
shl 1 or \ Eine Merk-Eins reinrotieren, die nicht übertragen wird
else
shl 1 or \ Eine Merk-Eins reinrotieren, die nicht übertragen wird
begin
msb? \ So lange schieben, bis die führende Eins herauspurzelt
swap shl swap
until
then

Sendedaten ! \ Fertig geschobene Datenbits zum weiteren Senden bereitlegen
else 12 Strahlzaehler ! \ Für eine Null genügt ein Übertragungspuls
then
then
then
then
;

: Bitmustererkennung ( -- )
Verbindungsdauer @ Synchrondauer <>
if \ Verbindung besteht erst nach 18 mal Zublinkern stabil.
1 Verbindungsdauer +!
Verbindungsdauer @ Synchrondauer = if Verbindungsanfang then
then

Lichtmuster @
%1111111111100 and \ Übertragungspuls wird mit 11 bis 14 Basiszeiten erkannt
dup %1111111111100 = if drop Datenregister @ Datenempfangen
0 Datenregister ! \ Datenregister muss gelöscht werden,
else \ da die Daten aus mit variabler Länge übertragen werden

%111111100 and \ Null-Puls wird mit 7-10 Basiszeiten erkannt
%111111100 = if Datenregister @ shl Datenregister !
else Datenregister @ shl 1 or Datenregister !
then \ Eins-Puls wird mit 3-6 Basiszeiten erkannt.

then
;

: Taktlauscher-init ( -- )
0 Sendedaten ! \ Keine Daten zum Herausrotieren und Abstrahlen ! Wichtig !
Verbindungsdauer @ Synchrondauer = if Verbindungsende then
0 Verbindungsdauer !

Zustand @ if
\ Für einen hellen Taktlauscher
HolePuls
Strahle
else
\ Für einen dunkelen Taktlauscher
0 Strahlzaehler !
1 Lauschzaehler !
Lauschen-Vorbereitung
then
;

: Taktlauscher ( -- )
Strahlzaehler @ ?dup
if \ Strahlzähler ist nicht Null
-1 Strahlzaehler +!
1- if
Strahle
else \ Gerade Null geworden
32 Lauschzaehler !
0 Lichtmuster !
Lauschen-Vorbereitung
then
else
Lauschen-Nachbearbeitung
1 and Lichtmuster @ shl or
dup Lichtmuster ! ( Neues-Lichtmuster )
%11111 and
%11100 = if
Bitmustererkennung
HolePuls
Strahle
else
-1 Lauschzaehler +!
Lauschzaehler @ if Lauschen-Vorbereitung
else Taktlauscher-init then
then
then
;

: ledcomm ( -- )

Anode Kathode or p2dir c! \ Ausgänge für die Ledcomm-LED und die Verbindungsanzeige
65 p1dir c!
64 p1out c!

Taktlauscher-init
['] Taktlauscher irq-timera0 !

$10 $0162 !
1953 $0172 !
$210 $0160 !

lpm0 \ Enable Interrupts and switch off CPU
;

: bright ( -- ) true zustand ! ;
: dark ( -- ) false zustand ! ;

compiletoram

[Matthias Koch]

> Is this clear enough now Matthias?

Thank you for the schematics. How do you implement networking/communication with this setup ? As far as I recall, you wished to make an art or multi-node display installation which would at least require to keep the nodes in sync.

Matthias

[Matthias Koch]

> And Matthias, can you please post code to output a Byte and Input a Byte,
> I assume there are more that would like to look at it.

To get a feeling for Ledcomm, you can try it on various Launchpads and other chips. Mecrisp and Mecrisp-Stellaris packages contain implementations for MSP430G2553, MSP430FR4133, MSP432P401, LM4F120/TM4C123, LPC1114FN28 and STM32L152. All implementations are compatible to each other and across architectures.

Additionally, Ledcomm found its way into ChibiOS: https://github.com/klpauba/LEDComm and http://klpauba.github.io/LEDComm/

Matthias

[JUERGEN]

For now we go minimalist here as well:
One resistor on RX and the other side all connected.
So just 2 wires to al of them: Ground and RX protected.
They get their personal number when programmed the first time. If something goes wrong or the battery is empty - they are off - but do not disturb the rest.
Simple but fail safe.
More complex will be tried later or if there is time.
As said, a 16 unit test panel is ready.

And the plan is to have the systems - or how many might be left after the event, via Bluetooth or WiFi connected to the Internet later - the spare time limit will dictate what happens when.

And anybody who asks can have a go at controlling them...

[Matthias Koch]

JUERGEN schrieb:

With the same hardware you could use the "scurry wire" bus. See wuseldraht-scurrywire-0.1.tar.gz on mecrisp.sourceforge.net for more details. It is a field bus I developed for greenhouse applications that can supply power, using a data and a ground wire and you can run a node discovery. But unlike 1-Wire it is capable to deliver much more current, multiple power injection points are possible and it can handle large bus capacitances. If you add a silicon diode as 1N4148 to not overload the internal protection diodes, you could also charge the nodes while they are on the bus.

I will leave today afternoon for two weeks, best wishes for your project !

Matthias

[Matthias Koch]

JUERGEN schrieb:

By the way, Ledcomm can sync to a bright spotlight, too ! It will be an one directional communication this way, but if the nodes are Ledcomm enabled and if you can quickly modulate a powerful LED spotlight with suitable colour, you can transfer data to all nodes at once. This might help as bus wires and waterproof are difficult to achieve together.

Matthias

[JUERGEN]

Have a nice holiday - and you will probably find here what we have achieved in the meantime.
We wil hopefully try the first 16 or 32 Multiprocessor system this weekend.

[Paul Rubin]

Matthias Koch <matthi...@hot.uni-hannover.de> writes:
> By the way, Ledcomm can sync to a bright spotlight, too ! It will be

> an one directional communication this way, but... you can transfer

> data to all nodes at once.

This is really neat. The one thing disappointing about ledcomm is that
it runs at such low bit rates, like 30 bps according to the ChibiOS
page. I had thought its mechanism was different and that it used the
LED as a photodiode, capable of very fast detection. I still wonder if
there's a way to do that. Photodiodes are normally reverse biased (I
had forgotten or didn't know that earlier) so you'd have to use two or
maybe three IO pins to handle both the forward and reverse modes:

pin o----resistor---o(pin)o----led||resistor----o pin

with another resistor across the led, making a voltage divider with the
first resistor. The first and third pins would be digital so you could
forward or reverse bias the led by toggling them. The middle pin is an
analog input that would detect when the led is generating some current,
by measuring the voltage change. I have no idea whether this would be
sensitive enough though.

I know Forrest Mims wrote a lot of old stuff about using leds as
photodetectors. I'm not sure if it was similar to ledcomm, or worked
some other way.

[JUERGEN]

Forth INC and GreenArrays have been convinced to support this project as well. Thank you very much to both of them. As soon as we had time, the updated Prospectus with Forth IC and GreenArrays in it as well will be to see at Forth-ev.de as before.

So our project with the 1000 scouts is basically wrapped up and finacially secure now.

MPE had been in this projeect from the beginning. The MSP430s will be running VFX LITE on the chip.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> Paul, thanks for the input. Please send your High Speed implementation
> and as well a description of the HW and SW to achieve it.
> That will be brilliant at the event. Swap SW quickly.

Sorry, I'm just the idea man.

[JUERGEN]

[JUERGEN]

Including now Forth and GreenArrays - Anybody who wants to see the latest status of the supporters of this scouts project, see www.forth-ev.de and click on the sublines with the links to the PDFs

[JUERGEN]

We are one week away from the event - all parts have been donated ( except for the TicTac boxes ) so the 1024 scouts can start soldering soon and will own their "beating Heart". A 16 processor cluster has been tested - so high hopes to get the 1024 multiprocessor cluster up and running - 1024 MicroBoxes with batteries connected and controlled centrally to light up as 32 x 32 bit LED Array - no it is not a giant torch, we only have about 10mA per LED.
A 16 bit cluseter has been tested as proof of concept.
See as well other post about Cloning an MSP430 for programming.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> We are one week away from the event - all parts have been donated (
> except for the TicTac boxes ) so the 1024 scouts can start soldering

The TicTac boxes sound like the hardest part--you can't even buy empty
ones as far as I know.

[Mark Wills]

On Wednesday, 17 June 2015 22:53:37 UTC+1, JUERGEN wrote:
> How can we promote the Forth language usage?
> Go to the Young Generation,
> or maker fares
> and next to the Coder Clubs
> and schools

Might be worth contacting BBC Click, if you haven't already.
This would be *right* up their street.

[JUERGEN]

Hi Mark,

as all parts are in now ( ALL donated except for the TicTac Boxes, bought 800 just now) I could send the email and data to bbc click! Thanks for the reminder.

[JUERGEN]

... and Paul and I are of to the biggest (Forth) event,
building 1024 Microboxes running MSP430LITE
and flashing away during the week
and hopefully the big Network on the last day 2 x 2m about and all controlled centrally.

Not a small event:

https://scontent-lhr3-1.xx.fbcdn.net/hphotos-xft1/v/t1.0-9/s720x720/11160687_10153138014683822_5371919774601269244_n.jpg?oh=1dbf295915460961723b1f2e89f92e1a&oe=5650C438

and
https://www.facebook.com/peakcamp

not really small, and we as part of the IET are one of the activities there.

And for some more technical information:
http://www.forth-ev.de/wiki/doku.php/en:projects:microbox:start

[JUERGEN]

On Tuesday, July 21, 2015 at 9:02:29 AM UTC+1, Mark Wills wrote:

Done that, no reaction yet - might be too much confusing their MicroBit message ...

[Howerd]

Hi Juergen & Paul,

Have a great time!!!
Its a pity I can't be more involved (this time)...

Keep us updated with progress :-)

Best regards,
Howerd

[Mark Wills]

Have a great time!

[JUERGEN]

And we had a great time:
https://scontent-lhr3-1.xx.fbcdn.net/hphotos-xfp1/v/t1.0-9/s720x720/11752546_829415317176752_9034608098612206729_n.jpg?oh=bc3bd61ce26c6db089821806a7c56c41&oe=564255BA
5 days of mostly beginners soldering MicroBoxes together, which then were the "Beating Hearts" in a TicTac Box. For more and the final display panel video see:
https://www.dropbox.com/sh/89mtusui90tz5dv/AADTlLJIs5TuvpQQglarr5KBa?dl=0
And for more technical info see
http://www.forth-ev.de/staticpages/index.php/20150518223732910
and
http://www.forth-ev.de/wiki/doku.php/en:projects:microbox:start.
About 460 MicroBoxes built and running MPE MSP430LITE - ready to connect to a terminal and start programming Forth. Let's see what happens.