[squeak-dev] re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Doug Jones djsdl at frombob.to
Tue Dec 24 03:40:07 UTC 2013


On 12/23/2013 07:23 AM, Bob Hartwig wrote:
> What makes the Micro Python board more attractive than the BeagleBone
> Black, which is just as open, and orders of magnitude more capable?  I
> understand the appeal of targeting really tiny hardware like 8-bit
> microcontrollers, but I don't understand the appeal of this
> middle-of-the-road board.  But I may be missing something.
>
>      Bob
>

Targeting the BeagleBone Black would be good too.  I like that hardware.

The Micro Python is a different class of computer.  It has no video out, 
no graphics processor.  It doesn't come in a ball grid package that I 
couldn't possibly solder onto a board.  It can achieve much lower power 
consumption levels.  I suspect nobody will ever get Linux running on it.

It has an open source software distribution running on it that boots 
from bare metal all the way to a high-level language command line, 
perhaps in less than 20,000 lines of code (I haven't actually counted, 
but I wouldn't be surprised given how long it took him to write it, and 
anyway I like that magical number).  Does the BeagleBone Black have that?

Spoon has the potential to run on really small hardware.  Getting it 
running on an Arduino would be a real challenge, given the tiny amount 
of RAM that chip has, but doing it with 192KB of RAM might be achievable 
without excessive pain.

Seems to me this kind of hardware occupies a Spoon sweet spot.  It's not 
so small that the port would be really hard;  it's just big enough to do 
everything a minimal Spoon machine needs to do, while still being 
accessible to people who don't have a lot of money to spend on it. 
Hobbyists can even build their own without needing to call a PCB board 
maker.

The Arduino has opened up a whole new class of computing to people.  We 
can buy them cheaply or build them.  We can easily make new designs with 
new functionality.  We can use open tools on it.  Now it's in a zillion 
3D printers and lots of other things.  But it's slow, memory is quite 
limited and it's programmed in a fairly low-level language.

Now we can step up from the Arduino to something only a little more 
expensive, but still very accessible to individuals and small shops. 
Substantially faster, more RAM, floating point hardware, and 
programmable in high-level languages.  And still with Arduino's 
collection of programmable IO pins.

The big barrier we kick down with these is the language barrier. 
Letting the user program it in Python opens the platform up to a whole 
new group of users who aren't comfortable with the low-level languages 
on Arduino-class machines.  And if it can do Python, it can do other 
languages.

So that's the idea:  Put Spoon on the smallest machine it will 
comfortably fit on, hopefully with way less than 20,000 lines of code in 
total.  Get a bunch of them talking to each other, and to the bigger 
machines already running Spoon.  See what ideas people come up with for 
using it.








>
>
> On Mon, Dec 23, 2013 at 8:27 AM, Bert Freudenberg <bert at freudenbergs.de
> <mailto:bert at freudenbergs.de>> wrote:
>
>     On 2013-12-23, at 15:02, Nicolas Cellier
>     <nicolas.cellier.aka.nice at gmail.com
>     <mailto:nicolas.cellier.aka.nice at gmail.com>> wrote:
>
>      > 2013/12/23 Bert Freudenberg <bert at freudenbergs.de
>     <mailto:bert at freudenbergs.de>>
>      >>  don't be surprised if the fallback code suffers from bitrot. It
>     is never executed on regular VMs with all the primitives in place.
>     Having recently implemented a minimal VM I did discover those bugs ;)
>      >
>      > Yep, I saw at least one when I failed to change some primitive
>     and made it accidentally fail.
>      > For better testability, we could isolate the fallback code under
>     a separate method, but that would consume a bunch of selectors and
>     somehow be contradictory with a principle of economy - less is more.
>
>     For testing you could temporarily set the CompiledMethod's primitive
>     index to 0.
>
>     - Bert -
>
>
>
>
>
>
>



More information about the Squeak-dev mailing list