I've done a fair amount of stuff on getting Scratch controlling the Raspberry Pi GPIO
http://cymplecy.wordpress.com/scratchgpio/

and even got it working so that you can run Scratch 1.4 on a PC/Mac and control the Raspberry Pi pins using your desktop/laptop
http://cymplecy.wordpress.com/sidrpi/

What would be nice would be if someone could write the interface between Scratch 2.0 running on a PC/Mac remotely controlling the GPIO pins on the Raspberry Pi

Throwing this out there form someone to bite

Simon

I've started looking at extensions but have just put it down the list of things behind some other stuff I'm doing. I was just using graphical feedback for the extensions I was playing with but yours would be a nicer route to explore. I shall certainly have a try but unfortunately it won't be anytime soon.

SimpleScratch wrote:

remotely controlling the GPIO pins on the Raspberry Pi

Over what connection?

Over what connection?

WiFi preferably

Simon

Well made my first extension here http://scratch.mit.edu/discuss/topic/43915/ and it took a day, although most of that was working out that Scratch has a bug and doesn't support the “w” commands properly at the moment So will take a look at this. Have seen a few programs that expose the GPIO as a web service, any preference as to which one to use?

Well what would be absolutle spiffing would be if you could assume a standard 1.4 RSC/Mesh session and translate blocks into 1.4 broadcasts/sensor value updates.

Then that would be two birds with one stone.

If you could get something up and running just doing the basics then we'd be off to the races.

If not possible to do this then any other (Python preferable) Raspberry WebGPIO prog interface would be OK as far I'm concerned

Simon

http://cymplecy.wordpress.com/scratchgpio/

Well have found my Raspberry Pi, dusted it off and updated it. Installed WebIOPi. Have successfully talked to the pi from my extension which is nice. One potential problem is that the response from the pi is very slow. Scratch will be polling it 30 times per second. May have to keep the connection open and try connecting that way if it is problematic. Anyhow the WebIOPi documentation is not as nice as I'd like and not having used the GPIO pins then perhaps you can save me some time. If you see here https://code.google.com/p/webiopi/wiki/RESTAPI the API has get/set functions and get/set values. What are the GPIO numbers that are typically used? The first example they give is ◦To get GPIO 0 function : HTTP GET /GPIO/0/function which I tried and it returns “UNKNOWN” which is also not mentioned. I changed the 0 to 17 and got “IN” which is expected.

Great stuff !

That WebIOPI looks to be using the Broadcom numbering scheme as opposed to physical pin numbers
http://elinux.org/Rpi_Low-level_peripherals#Introduction

Any chance of try out your extension please ?

Simon

SimpleScratch wrote:

Great stuff !

That WebIOPI looks to be using the Broadcom numbering scheme as opposed to physical pin numbers
http://elinux.org/Rpi_Low-level_peripherals#Introduction

Any chance of try out your extension please ?

Simon

You will be the first when it is complete. Just after clarification on what would make sense in terms of new scratch blocks. Looks like will need to use menus for certain inputs e.g. to reference pins/gpio numbers “GPIO1”, “GPIO2” or “Pin1”, “Pin2” etc.
Are there just 8 Input/Output's ? In which case “GPIO1” to “GPIO8”.
What I'm trying to get at is that the GPIO stuff is horribly configurable and rather than having to cater for lots of different options, what is the simplest? For example it would be much simpler having a Boolean reporter block for GPIO inputs rather than a reporter which wasn't Boolean but returned “high”, “low”, “other” because the GPIO may be in PWM mode or something else.

I've been working on ScratchGPIO for 2 years and I wouldn't say it was complete so an alpha version would be great

I would just try and set pins to in or out to start with and set of read their state.

The “main” GPIO numbers to use are 17,18,21,22,23,24,25,4 which correspond to pins 11,12,13,15,16,18,22,7 as these have no alternative function and are “safe”

PWM etc can come later

Simon

Interesting stuff. I am assuming the configuration being suggested is that Scratch 2.0 is running on a PC and not the RPi. Is that a correct assumption? If not, what packages did you load on the RPi to run flash? Keep in mind that the Scratch 2.0 HTTP interface can only talk to localhost, which makes running over wifi interesting to say the least. Snap! does not have that problem since you can specify the IP address in the custom block. Also, Snap! doesn't poll, which may help network congestion. It also does not use adobe flash, so if my memory serves me correctly, it will run (albeit slowly) directly on the PI. I have run Snap! on a BeagleBone Black and it runs pretty well. I have not tried running s2a_fm on the BBB to control an Arduino, but since I am able to control an Arduino over Bluetooth running PyMata RPI or BBB Controlling an Arduino Over Bluetooth on the BBB, s2a_fm should also work. I also ran Snap! on a PC controlling a Yun over WiFi, and it was pretty easy to do Snap!Mobile.

If you have any questions about the HTTP interface, I would be happy to answer if I can.

Simon,
Have you checked out using NodeRed? If I have time this summer I will be playing with it to integrate the Arduino, RPi and BBB since those interfaces are already available. Here is a video of someone using it with Scratch 2.0 that shows promise. Here is the link.

I found some discussion on the topic in this thread. There is an article that one of the posters wrote here.

itchy20 wrote:

Interesting stuff. I am assuming the configuration being suggested is that Scratch 2.0 is running on a PC and not the RPi. Is that a correct assumption? If not, what packages did you load on the RPi to run flash? Keep in mind that the Scratch 2.0 HTTP interface can only talk to localhost, which makes running over wifi interesting to say the least. Snap! does not have that problem since you can specify the IP address in the custom block. Also, Snap! doesn't poll, which may help network congestion. It also does not use adobe flash, so if my memory serves me correctly, it will run (albeit slowly) directly on the PI. I have run Snap! on a BeagleBone Black and it runs pretty well. I have not tried running s2a_fm on the BBB to control an Arduino, but since I am able to control an Arduino over Bluetooth running PyMata RPI or BBB Controlling an Arduino Over Bluetooth on the BBB, s2a_fm should also work. I also ran Snap! on a PC controlling a Yun over WiFi, and it was pretty easy to do Snap!Mobile.

If you have any questions about the HTTP interface, I would be happy to answer if I can.

Correct. The extension will run on a PC which is running Scratch 2 but the extension will talk to the RaspberryPi over a network and control the GPIO that way via WebIOPi. Once this is complete then I shall return to integrating the extension mechanism into the Scratch compiler I have written, there is then a possibility of running Scratch 2 projects including extensions natively on the Pi (assuming the extension will run on the Pi!).

As with all things - time is the enemy

But my idea (wish) was for a Scratch 2 to Scratch 1.4 generic interface - basically so all my ScratchGPIO code would work with just one layer of abstraction but I think its going to take 2 - Scratch 2 extension talking to webserver - and then webserver to Scratch 1.4 broadcasts.

I think the frustration we all feel is the lack of direction from MIT.

They set the standards and we follow but if the standards havie big hole/major bugs then it jsut causes frustration

1.4 protocol/implementation has issues but they are all know/stable and work aroundable

I'll stop now

Simon

Have I got the wrong end of the stick? There's nothing 1.4 here I'm doing. Original brief was

What would be nice would be if someone could write the interface between Scratch 2.0 running on a PC/Mac remotely controlling the GPIO pins on the Raspberry Pi

which is what I'm doing; a Scratch 2 extension on a remote PC to control the Pi's GPIO pins.

Well as an update have got the interface to the pi complete. Just want to know how to present that data to Scratch. Have GPIO0 to GPIO53 but am still wondering whether to use GPIO0-GPIO53 or “better” names like Pin1-26 or pin1-1 to pin2-13 etc. That sort of thing?

Next milestone reached have made 8 reporters GPIO0-GPIO7 as per the physical RPi convention as opposed to BCM one and using the extension can see the inputs change from within Scratch. Don't want to go much further as these conventions may not be what is required!

You can download the extension from here https://app.box.com/s/j1arxqy5zgwgqca71zl3 The zip file contains 3 files, the exe file and dll and the s2e file.
The exe file need to be run as Administator on a PC. I have tested this against WebIOPi 0.7.0 running in a default configuration on the pi.
Forgot to mention. Until I add some sort of configuration option the RPi is assumed to be on the same network and reachable by the hostname rasberrypi which should be the default for a pi (with Raspbian anyway)

Great Stuff :-)

I've got a Raspberry Jam meeting tonight but I''ll try and test as soon as possible

Re pin numbering
I use physical pin numbering in my Scratch 1.4 stuff so that's what I prefer.