timrowledge
Posts: 1273
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Scratch to hardware API: call for discussions

Wed Feb 26, 2014 1:50 am

There's a bunch of interesting hardware add-ons that people are driving form Scratch. The only ones with built-in support are WeDo (no actual idea if that works on a Pi) and the original MIT/PICo sensor board.

It seemed to Eben and me that we ought to try to gather together as many interested parties as possible and see if we can agree on an approach to doing better. The Pi has some unique capabilities and needs, and so a lot will necessarily be Pi specific - but if we limited ourselves to perfectly universal things there wouldn't be much point.

Who is interested? Who *ought* to be interested but doesn't frequent this forum regularly and needs a direct invite?

What sort of capabilities would be useful? What do you need that can't be done right now?

In principle we can extend the Scratch blocks repertoire, add new UI doohickeys (like the ScratchBoard watcher only specific to your requirements) or even extend the VM plugins.

Even the sky is not the limit; seriously, Squeak is used in space! So could Scratch be...
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

User avatar
mikronauts
Posts: 2716
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 2:41 am

I think Scratch should be extended with easy to use blocks for I/O.

From my admittedly cursory examination, I do not find the "broadcast" blocks to be intuitive enough for Scratch's target market - namely K-7

For robotics, the turtle like commands should be extended to controlling a bot, not a pen on a graphics screen.

It should be possible to have easy to use blocks for:

- digital input
- digital output
- motor control
- servo setting
- distance sensor reading
- generic analog input

Ideally, there should be an easy to use way to extend Scratch without people having to become experts in its VM.

In my case, I'd love to extend Scratch to support my RoboPi board, and other upcoming products.

If there was an easy way for me to do that - as in it won't take more than a few hours, or at most a couple of days, per product, I could see spending time doing that.

I simply don't have the time to get very familiar with the guts of Scratch and extend it.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

timrowledge
Posts: 1273
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 3:08 am

To partially quote -
mikronauts wrote:
Ideally, there should be an easy to use way to extend Scratch without people having to become experts in its VM.
I simply don't have the time to get very familiar with the guts of Scratch and extend it.
You don't need to - that's what I'm here for.

If we can get a good idea of what would help as many people as possible then we can make a good start. Very product specific things might involve careful persuasion of Eben about their value. Or money. That often works.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

User avatar
mikronauts
Posts: 2716
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 3:24 am

I posted the generic ideas in my post, none of those were for any specific board.

Probably the best would be skeleton/sample implementation of those ideas that could be customized easily.

Unfortunately third party vendors (including myself) for Pi products do not have even a tiny fraction of Broadcom's market capitalization... http://www.wikinvest.com/stock/Broadcom ... talization so while providing money to the foundation would be an incentive for the foundation, small companies cannot afford it.

Unfortunately I've had extreme difficulty in establishing communications with the foundation.
timrowledge wrote:To partially quote -
mikronauts wrote:
Ideally, there should be an easy to use way to extend Scratch without people having to become experts in its VM.
I simply don't have the time to get very familiar with the guts of Scratch and extend it.
You don't need to - that's what I'm here for.

If we can get a good idea of what would help as many people as possible then we can make a good start. Very product specific things might involve careful persuasion of Eben about their value. Or money. That often works.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 7:30 am

Where to start :)
1. Add/change blocks in Scratch - its no longer Scratch. So either name change or VERY special permission from MIT to continue to use name Scratch which they have NEVER given before to ANYONE :)

Once you add extra blocks into Scratch the .sb file would become incompatible with Scratch 1.4 standard and projects couldn't be copied to other computers or uploaded to the main Scratch site.

So we'd lose a lot compatibility.

Politics aside - the best way would to to write an API thingy in the squeak image so that people (such as add-on board builders) could easily add in support for their products either by themselves or getting a friendly squeak expert to do it for them.

Or we could run with BYOB and align with Snap! team instead of Scratch - it has advanced blocks - builders could create their own blocks and we could use existing broadcast mechanism with background handler in a more "programmer friendly" language.

I think this thread
http://www.raspberrypi.org/forum/viewto ... ratch+tony
has all the current main players mentioned but there is W.H.Bell https://pypi.python.org/pypi/RpiScratchIO and of course the Pi-Face team have already got a directly modified image as well as the original Python handler that my code is derived from.

Simon
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

bantammenace2012
Posts: 122
Joined: Mon May 28, 2012 12:18 pm

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 10:36 am

Unfortunately this is starting to leave me behind a little as I see the Scratch section of the forum becoming more and more a developer's area. Perhaps its time to have two sections in the Forum: one for developers and one for end users/beginners ?

wrt. Lego Wedo, its a drum I've banged before, I like the noise it makes so here I go again. I, like many schools, have already invested in Wedo. We have a number of Wedo USB hubs, motors and sensors which work with Scratch on the RPi. There are other Wedo sensors such as the Light that afaik do not currently work in Scratch but do work with Lego's own Wedo software. Similarly the Lego Wedo software can run two motors (ideal for robots) whilst Scratch on the RPi currently will only run one motor. Big respect to Kahuziro Abe who has previously "squeaked" an RPi Scratch image to run two Wedo motors, so I know it can be done. I have requested this in the past I know. Once Tim's version is officially released I will be contacting Kahuziro Abe to sprinkle his magic dust over it again. I can't afford to leave my Wedo kit on the shelf and invest in the new kit to go down the GPIO route.
Perhaps a good starting point would be to have a look at getting all the Wedo sensors working with the RPi Scratch version in the same way, or better than, they work with Lego's Wedo software ?
If you haven't already invested in Wedo then the GPIO/ Simon Walters approach will be cheaper and more rewarding but maybe the time, skill and commitment required to get up to speed with this may be a hurdle too many for some ?

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 11:00 am

I, like many schools, have already invested in Wedo.
How many is many :)
The Lego Wedo kit is lovely but like all technical Lego, is expensive. But at least its a LOT cheaper than Mindstorms :)

Equivalent GPIO driven hardware is a factor of 3 times cheaper still though.

Lego is the Apple of the maker world - very nice but very expensive for what it does :)

I'd love to have it in my schools due to its ease of assembly and familiarity but not at current price levels

Simon
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 1:05 pm

Perhaps its time to have two sections in the Forum: one for developers and one for end users/beginners ?
I think I've heard something in the wind that says some sort of new website/forum thingy may be coming along for educational use so that would probably sort that issue out at least

Simon
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

bantammenace2012
Posts: 122
Joined: Mon May 28, 2012 12:18 pm

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 1:08 pm

Simon I don't see it as an either or situation. Why is there not room for both Wedo and the excellent stuff you have been doing?
I appreciate where you are coming from but Apple does not necessarilly mean bad (I don't believe i've just typed that!).
Not everyone has got the ability or commitment that you have shown and i'm just a little wary of throwing the baby out with the bath water or cutting one's nose off to spite one's face (at least not at the same time).
I don't know how many many is but the fact is that I, and perhaps its just me (?), would like to be able to use my Wedo stuff with Scratch on the RPi just as I can using the Lego Wedo software on my PC.
kind regards as ever.http://www.raspberrypi.org/forum/postin ... 47322dc792#

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 1:50 pm

Maybe I've misunderstood but your looking for enhancements to Scratch to make it work with more stuff than it currently does?

Once this is done- its no longer Scratch :( as projects with the additional blocks would no longer load into normal Scratch 1.4 or Scratch 2.0

So these enhancements would only be for Lego WeDo owners.

And not for the rest of users using PiBrella, PiGlow, Ladderboards, BerryClips and all the Motor Controller boards etc etc.

How much has your school invested in WeDo BTW
Simon

PS I feel your frustration by the way - there are many things I'm frustrated by that no-one else deems important :)
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

bantammenace2012
Posts: 122
Joined: Mon May 28, 2012 12:18 pm

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 6:12 pm

Si, thanks for the reply.
I think I now understand the idea behind the API.
My understanding is that the intention is for Scratch on the Pi to do everthing that Scratch elsewhere will do, but out of the box, nothing more.
Any requirements for additional functionality such as BYOB and Wedo will then be the responsibility of others to produce ?
Please tell me I'm correct so I can stop banging on about this and start to learn Squeak.
btw. it is me personally who has invested in Wedo, not any particular school. My apologies if it read that way.

ghp
Posts: 1399
Joined: Wed Jun 12, 2013 12:41 pm
Location: Stuttgart Germany
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 8:23 pm

Hello,

difficult discussion. But useful. Think there will be people asking for bit banging from scratch to GPIO (and only the support of board XYZ is the future), and others (like me) asking for a clear definition of architecture.

Current situation is
  • we have scratch 1.4 on RPi, and same version 1.4 on other platforms. Code is exchangeable between these versions.
  • mesh network (socket implementation) allows connection of hardware of all types. Hardware implementers can provide 'driver applications' to whatever needs they have. The loose coupling of scratch/squeak with hardware drivers ensures scratch stability (kids are helpless when faults arise).
  • there are quite a few hardware boards around, piface, gertboard, guzunty, just to name a few. And I did one for my own purpose too. Variety is large, as well as the number of libraries as RPIO, RPI.GPIO, wiring. And you need GPIO, SPI, I2C, serial and whatever you can think of to drive these hardware things.


Usage of scratch
  • scratch is perfect for starters in programming.
  • scratch is a high level presentation- and controller-engine. In general, people will not do complicated, large or fast things in scratch.
  • - it is difficult to have software layers in scratch and to build 'hardware abstraction'. At least its a challenge for newbies in a scratch workshop which lasts 40 hours.
  • scratch code should handle high level things like 'red-button-pressed' or 'x-poti-value' or 'light-on'. The translation to whatever hardware GPIO directions, interrupts, or voltage levels should be provided by a 'hardware abstraction layer'.
I would define the following goals.
- rule#1: scratch code should run an RPI as well as on the windows scratch 1.4. Not all school kids will have a Pi at home, but most of them have a windows machine somewhere and can continue work from school at home. For scratch, there are lots of tutorials around, for whatever is special on RPi you need your own tutorials, translations, explanations. And it opens a migration path to a more perfomant platform (scratch going to windows) and leave the IO-stuff on RPi.
- rule#2: I would not like to have a 'scratchForPiface' or 'scratchForGertboard' or 'scratchForMyBestAnd ShinyFancyBoard'.

Aside from the 'keep things the same as they are', there could be changes not affecting rule#1:
What I would like to have in scratch
- improve mesh network handling.
  • add a command line switch which supresses the ok-dialog on enabling remote connections. Without this option same behaviour as since ever. It is an incredible procedure to change this inside scratch/squeak (remember that scratch users usually are new to computers and programming).
  • add a mesh command (remote to scratch) 'capabilities' which reports
    commands available on remote client
    commands send by remote client
    value-names which can be send to remote client
    value names which can be transmitted by remote client.
    when scratch receives this command, it could populate the broadcast pulldowns and the sensing values, as well as create the global variables (if not yet available).
  • kids do not always understand the performance burden of fast changing global variables or frequent broadcasts to mesh network. So when the 'capabilities'-command is implemented, scratch could filter the stuff going to the socket.
  • and get rid of these scatchBoard defaults then.
Some things which could be improved, but violate rule#1:
- remote communication is scattered to various places. You have sensing values, broadcasts and 'when I receive broadcast' and global variables. Sometimes I dream of 'remote broadcast', 'remote_receive', 'remote_variables (out)' and the existing sensing values then named 'remote_variables (in)' all located in one section of the 'sensing tab'. This clearly violates goal#1. But would give a clearer view of remote communication.

One possibility to improve hardware interfacing is the definition of a scratchClient framework. Connect/reconnect, configuration, local to physical names translation, support of different gpio libraries, reusable adapters, reusable device handlers, monitoring.

In my implementation of a mesh client framework 'scratchClient', quite a few of these framework needs are implemented.

What would be another area to invest is USABILITY
- undo with 50 levels
- file input field for save dialog is displaying names longer than some 20 characters in a smart way.
- copy/paste between scratch instances.

tldr: keep it modular, exchangeable and 'to the standards'.

Regards, Gerhard

timrowledge
Posts: 1273
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 8:58 pm

simplesi wrote:Where to start :)
1. Add/change blocks in Scratch - its no longer Scratch. So either name change or VERY special permission from MIT to continue to use name Scratch which they have NEVER given before to ANYONE :)
Not a matter I'm interested in discussing - it's above my pay-grade, irrelevant to technical discussions and very, very boring. Somebody else can sort that part out.
simplesi wrote:Once you add extra blocks into Scratch the .sb file would become incompatible with Scratch 1.4 standard and projects couldn't be copied to other computers or uploaded to the main Scratch site.
Yes, adding new blocks and expressions would mean losing 1.4 compatibility, No, that would not mean being unable to copy to other computers; remember, Squeak is portable beyond most languages wildest dreams and the current alpha version of NuScratch runs on any modern Squeak VM on any machine capable. Windows, Macs, unix/linux, RISC OS, whatever.

But MIT have thrown away 1.4 compatibility anyway. It's not the only important thing.
simplesi wrote:Politics aside - the best way would to to write an API thingy in the squeak image so that people (such as add-on board builders) could easily add in support for their products either by themselves or getting a friendly squeak expert to do it for them.
That's pretty much what we're after working out; what support would be good, preferably as near-universal as we can work out, loadable when wanted. Maybe an external system connecting to the broadcast events is best; maybe not.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

tonychang-uk
Posts: 94
Joined: Mon Jun 18, 2012 1:42 pm

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 11:30 pm

if Scratch support as our hardware support list, that's will be very nice for every one
We already done the hardware support list as below
1.4hub/7hub i2c RTC & Temperature sensor, AD/DA, EEPROM
2. i2c 8,16,32,64,128 GPIO board
3. spi 16,32,64,128 GPIO board
4. GPIO relay, DC Motor, stepper Motor ,
5. GPIO 16x2 LCD ,20x4 LCD , 84x48 LCD
6.i2c 16x2 LCD, i2c 20x4 LCD
7. i2c PWM/servo board, 16x16 ,24x16 LED matrix
8. 1-Wire DS18B20 Temperature Sensor
9. i2c BMP085 Barometric Pressure/Temperature/Altitude Sensor
10. Ultrasonic Distance Sensor
11.spi mcp3002/mcp4802 AD/DA
12. Maplin USB Robot ARM control
13. New i2c & GPIO LCD command
14. DHT22 Digital Temperature & Humidity Sensor
15.IR- Line Hunting sensor, IR -Flame sensor
16. 6 DOF (Degrees of Freedom) Servo Robot Arm
17. IR- PIR Motion sensor
18. i2c PWM LED & GPIO LED control
19. IR remote control set

software for scratch detail
http://www.pridopia.co.uk/rs-pi-set-scratch.html

tonychang-uk
Posts: 94
Joined: Mon Jun 18, 2012 1:42 pm

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 11:38 pm

bantammenace2012 wrote:Si, thanks for the reply.
I think I now understand the idea behind the API.
My understanding is that the intention is for Scratch on the Pi to do everthing that Scratch elsewhere will do, but out of the box, nothing more.
Any requirements for additional functionality such as BYOB and Wedo will then be the responsibility of others to produce ?
Please tell me I'm correct so I can stop banging on about this and start to learn Squeak.
btw. it is me personally who has invested in Wedo, not any particular school. My apologies if it read that way.
We do lots hardware support, standard i2c GPIO, SPi GPIO, input/output
support detail http://www.pridopia.co.uk/rs-pi-set-scratch.html

tonychang-uk
Posts: 94
Joined: Mon Jun 18, 2012 1:42 pm

Re: Scratch to hardware API: call for discussions

Wed Feb 26, 2014 11:42 pm

[quote="timrowledge"]There's a bunch of interesting hardware add-ons that people are driving form Scratch. The only ones with built-in support are WeDo (no actual idea if that works on a Pi) and the original MIT/PICo sensor board.

It seemed to Eben and me that we ought to try to gather together as many interested parties as possible and see if we can agree on an approach to doing better. The Pi has some unique capabilities and needs, and so a lot will necessarily be Pi specific - but if we limited ourselves to perfectly universal things there wouldn't be much point.

Who is interested? Who *ought* to be interested but doesn't frequent this forum regularly and needs a direct invite?


We do lots hardware support for scratch standard i2c 23017 & 23008 GPIO, SPi 23s17 GPIO, input/output, & lots sensors
support detail http://www.pridopia.co.uk/rs-pi-set-scratch.html

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Scratch to hardware API: call for discussions

Thu Feb 27, 2014 6:27 am

My understanding is that the intention is for Scratch on the Pi to do everthing that Scratch elsewhere will do
Yes - and if Scratch on RPi doesn't do the same as Scratch 1.4 on a PC/Mac - I'm sure Tim would like to know so he can have a go at fixing it :)
but out of the box, nothing more.
That's what Tim is asking about here - what more is wanted - but I read that he was talking about generic GPIO based peripherals that currently have no built in support within Scratch

Simon
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Scratch to hardware API: call for discussions

Thu Feb 27, 2014 6:49 am

Not a matter I'm interested in discussing - it's above my pay-grade, irrelevant to technical discussions and very, very boring. Somebody else can sort that part out.
Well since your the one Eben is talking to - maybe you could pass it up to him please :)

No, that would not mean being unable to copy to other computers
I meant to Scratch 1.4 running on other computers :)
But MIT have thrown away 1.4 compatibility anyway. It's not the only important thing.
Scratch 2 can load Scratch 1.4 projects which is pretty standard behaviour for an upgraded program so I think "thrown away" is a bit OTT :)
It's not the only important thing.
Of course not but although your not interested in politics/branding etc - that sort of stuff is very important to the Foundation - they are all about branding and piggy-backing on top of Python - Scratch - Minecraft - Wolfram etc.

The fact that these run on the little Pi is VERY important and therefore its a REALLY big decision to throw Scratch away if MIT won't let them use the name after amendments that break .sb file compatibility

Simon
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

timrowledge
Posts: 1273
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Scratch to hardware API: call for discussions

Thu Feb 27, 2014 10:32 pm

One of the possible techniques that can be used to add hardware specific extensions without actually installing them permanently to the system - meaning that the delivered base system would be untouched - is to provide for runtime/startup scripts that tell the image what to load and where from.

We can do this a bunch of ways. It's obviously simple enough to pass in a filename with the initial command line; that could specify a script location (local or remote on the net). That would make it easy to setup with whatever tools are suitable for the specific OS in use. We could potentially allow drag and drop of suitable files but that means having to interact with the UI and maybe that wouldn't be so useful in a school setup where I expect that teachers would want to be able to pre-can a system for the days tasks.

The nice thing about Squeak as an implementation tool is that we can go anywhere from this basic starting point.

The allowed files could be just plain old Smalltalk chunk-format, providing code that gets compiled and executed/installed as appropriate. The upside is total flexibility; new blocks? new sorts of operation? code that uses a new VM plugin to talk to something we haven't even heard of yet? load new stuff, run a demo and quit? No problem.

Or the allowed files could be restricted to some sort of meta-description of a new UI element to provide something like the sensor board watcher but more appropriate, along with some specification of how it works etc.

At the most trivial level one could use the script to load a particular project and set things up for a lesson, saving some 'wasted' time at the start of a lesson.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

ghp
Posts: 1399
Joined: Wed Jun 12, 2013 12:41 pm
Location: Stuttgart Germany
Contact: Website

Re: Scratch to hardware API: call for discussions

Fri Feb 28, 2014 4:48 pm

Hello,

this explanation makes it clearer on what people think of with these extensions.
Most of the discussions so far have been about what people don't want (e.g. go away from scratch standard).

Maybe it would be useful to step back and before talking about implementations to collect the user groups and usecases for extensions and then evaluate whether they are reasonable. Criteria for a later discussion could be like 'portability of stored code', 'are there other means to achieve this', 'what are the risks for stability', 'risk for security', 'runtime performance from scratch to hardware', 'is it scratch any more'.

Just to start:
Users are
- kids (at school, at home)
- teachers (running IT-lessions based on a curriculum or after school workshops)
- engineers, software specialists (supporting schools, or member of 'livelong kindergarden group' :) )
- vendors of hardware boards
- pi foundation, not to forget.

usecase: An interface board XYZ vendor's extension displays specific blocks for start/stop of some machinery. And ABC-vendor uses same names by accident.

usecase: Remote sensor network extension 'capabilities'. Remote client announces its capabilities (variable names, broadcast names) to scratch and scratch will filter in/out to socket based on these information. A designer of a client software could need this.

usecase: In school, a teacher limits the available (visible) blocks to what the current training session is needing. Could stop the kids from playing. Could stop the kids from having fun...

usecase: a startup promotes a new fancy board with 'fully scratch integrated, many new building blocks and a boost of performance'. And they display their branding and lock out other extensions.

usecase: for driving an exotic device, shared memory is used to increase speed and data exchange volume. Data rates of 10000/s can be achieved, thousands of external sensors can be read in and processed.

You see, I am a bit negative today. From my experience in school, most of these scenarios are not needed. And the performance gain from the 'capabilities' proposal will be void when next generation of RPi comes around with octal core and 4GB of memory.

Regards
Gerhard

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Scratch to hardware API: call for discussions

Sat Mar 01, 2014 12:26 pm

Just a bit of info picked up at the Jamboree - a foundation developer has suggested making a background running C++ daemon to monitor if Scratch is running or not -and if it is - then handle any requests from Scratch to communicate to the GPIO pins.

(The assumption being that is someone is running a Scratch program then they are unlikely to be running another program controlling the GPIO pins at the same time)

So additional user friendly blocks could be added to a modified Scratch image that simply use the existing broadcast mechanism to communicate to the handler. This would be the official Scratch mod and a competition could be launched to name it :)

But, a non-modified "proper" Scratch image could still be maintained that is file/GUI compatible with Scratch 1.4 and could retain the name etc. This image could talk to the handler as well if people put the correct syntax in broadcast blocks.

Win-Win? :)

Simon
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

User avatar
DougieLawson
Posts: 35769
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Scratch to hardware API: call for discussions

Sat Mar 01, 2014 1:15 pm

How about having a GPIO server? Then anyone (scratch, python, CGI, whatever) that wants to twiddle a pin simply posts a message to the server and the pin is twiddled and a message comes back with status or results.

How about http://abyz.co.uk/rpi/pigpio/pigpiod.html which does exactly that?
http://abyz.co.uk/rpi/pigpio/python.html

You must be able to call that from scratch with no drastic modifications to the underlying scratch system.
[Note: I needed 50MB of space back so my RPi doesn't have scratch installed.]
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Scratch to hardware API: call for discussions

Sat Mar 01, 2014 1:29 pm

I can see that hardcore (or even medium level) geeks wouldn't want to be going thru someone else's GPIO pins handlers necessarily and might want to retain flexibility of their own or others GPIO interfaces.

But for a Scratch user - that looks like a good basis for what was suggested at the Jamboree - obviously need to thrown in at least I2C and things like 1bit temp sensor and think about SPI as well.

Then the Scratch daemon monitor would only invoke GPIO handling when Scratch was running - leaving the GPIO free for other users to do what they want.
Simon
PS - No Scratch installed - push off and get back to your assembler world :)
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

User avatar
DougieLawson
Posts: 35769
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Scratch to hardware API: call for discussions

Sat Mar 01, 2014 1:55 pm

simplesi wrote: PS - No Scratch installed - push off and get back to your assembler world :)
I ran it once and suffered some embarrassment from my 14yr old. Never again.

We've not got the source code for pigpiod (need to push for that) so I don't know if I2C or SPI or 1-wire would be possible. You wouldn't really want to re-invent the wheel if pigpiod can do the function you should use that. Or push for the author of pigpiod to add those missing hardware/sensor protocols.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

timrowledge
Posts: 1273
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Scratch to hardware API: call for discussions

Sat Mar 01, 2014 6:28 pm

simplesi wrote:Just a bit of info picked up at the Jamboree - a foundation developer has suggested making a background running C++ daemon to monitor if Scratch is running or not -and if it is - then handle any requests from Scratch to communicate to the GPIO pins.
Can't see any reason a daemon would be needed; just fire up the whatever when Scratch is started. A trivial change to the shell script would handle it.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Return to “Scratch”