User avatar
DougieLawson
Posts: 35831
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 9:21 pm

timrowledge wrote:
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.
The GPIO pins need root access. Your average scratch user doesn't need or desire that level of complexity. Running a daemon (with root privileges) that can act for a non-privileged user is bound to make life easier for everyone.
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: 1275
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Scratch to hardware API: call for discussions

Wed Mar 05, 2014 10:46 pm

DougieLawson wrote: The GPIO pins need root access.
Ah; I didn't know that. I'd forgotten just how annoyingly awkward unixy systems can make life... RISC OS is *so* much easier for this sort of thing but that isn't going to suddenly make everyone use it. Oh well. If a daemon is what is needed, that is what we will have to use.

I see I'm going to have to go and search out the makers of hardware add-ons to ask them to take part here.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

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

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 12:22 am

OK, trying to make a list of plausible hardware, scanning back-issues for MagPi - I'm sure I've missed a lot. Suggestions to round out the list?
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

User avatar
FLYFISH TECHNOLOGIES
Posts: 1750
Joined: Thu Oct 03, 2013 7:48 am
Location: Ljubljana, Slovenia
Contact: Website

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 12:28 am

Hi,

Ok, I saw a "broadcast call" for a discussion... Instead of discussing about some details, let me stay focused on a big picture.

As a part of new chip development (it is going to be announced in the upcoming days, if you're very curious, a draft datasheet is already available here: http://www.flyfish-tech.com/FF32/FF32_datasheet.pdf) I brainstormed also about Scratch, hardware identification, protocol standardization, add-on conflicts, etc. Since this thread deals with these subjects, let me write my brief opinion which is a result of the mentioned brainstorming.

Current situation (hardware):
- there is a "small million" add-ons already on the market,
- the boards are "dumb" ones with discrete logic, drivers, etc. and "smart" ones built around microcontrollers,
- GPIO pins are used freely, there are no limitations in their usage (what is reflected in add-ons),
- boards stacking is nice (specially from marketing perspective), but it can (and do) cause conflicts,
(- number of USB add-ons is very limited)

Facts:
- existing boards cannot be ignored,
- it would be a pain to maintain Scratch hardware support on per-board cases,
- a generic solution would make sense.

My proposal:
- start a discussion about "standardization" of hardware supported by Scratch,
- boards fulfilling the requirements would get a "Scratch compatible" label,
- Scratch would be extended to support "standardized" hardware.

Side effects:
- vendors will be motivated to get "Scratch compatible" label,
- due to proper general software support, "old and non-compatible" add-ons will start to fade out from circles using Scratch,
- as a result, you might improve situation where add-ons would start to follow some guidelines.

Misc item to be taken into consideration:
- can USB add-ons act as an early bird, because the collision with existing add-on boards is not applicable ?


This is my quick response to this discussion... I'm looking forward to further messages. :-)


Best wishes, Ivan Zilic.
Running out of GPIO pins and/or need to read analog values?
Solution: http://www.flyfish-tech.com/FF32

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

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 1:47 am

FLYFISH TECHNOLOGIES wrote:My proposal:
- start a discussion about "standardization" of hardware supported by Scratch,
- boards fulfilling the requirements would get a "Scratch compatible" label,
- Scratch would be extended to support "standardized" hardware.
Well, yeah, apart from the labels that is pretty much what I started this thread for. And of course we're only really talking a bout Pi Scratch here.

And I'll reiterate that whilst the current handling of socket based messages is a very clever trick, we can potentially do so much more. Yes, some people will want to stick to vanilla Scratch for compatibility. Others will want to add all sorts of new capabilities. We can make a system able to do both. We can rebuild it. We can make it faster, better, stronger. We can make the worlds first six million dollar Scratch...
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

User avatar
FLYFISH TECHNOLOGIES
Posts: 1750
Joined: Thu Oct 03, 2013 7:48 am
Location: Ljubljana, Slovenia
Contact: Website

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 2:31 am

Hi,
timrowledge wrote:Well, yeah, apart from the labels that is pretty...
I see main advantage of the label in a single (not so obvious) reason - you can read here many "help me" messages where people are asking questions without being aware/able to describe their system/configuration first. This label would give very straight-forward answer if/how the add-on is supported.
timrowledge wrote:And of course we're only really talking a bout Pi Scratch here.
Yes, of course... :-)


Best wishes, Ivan Zilic.
Running out of GPIO pins and/or need to read analog values?
Solution: http://www.flyfish-tech.com/FF32

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

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 4:33 am

FLYFISH TECHNOLOGIES wrote: I see main advantage of the label in a single (not so obvious) reason - you can read here many "help me" messages where people are asking questions without being aware/able to describe their system/configuration first. This label would give very straight-forward answer if/how the add-on is supported.
An interesting point.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

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

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 7:13 am

Hello,

a label "scratch approved hardware" is a nice idea. It would lead to the following situation:
- the 'scratch approved hardware' will sell. And only this. Kids and teachers will avoid shaky ground.
- it will stop innovation. New chips on the market, new approaches will need time to be supported, get the label and find their way to be sold.

In order to have an 'open access', the 'remote sensor protocol' needs to be supported in parallel. Example: the usual RPi.GPIO python library is well supported, but does not allow on stable PWM pulses to drive servos If you need this, you use RPIO-library, with some drawbacks in flexibility. There is no way to foresee all the needs users have.

"Scratch approved" does not guarantee it works in all situations.
When problems are reported here about 'the board XYZ does not work', then in most times it is missing understanding of electronics, of power supplies and/or badly designed client software. Younger kids are very creative, but structured analysis of problems in linux rights, socket problems ('I have two scratch instances open and my client no longer connects '), and buggy software is not their strength. And interpreting text on screen into appropriate action is also difficult. And not each school has an electronics/software engineer with oscilloscopes, logic analysers and thirty years of experience.

Let me bring back my idea of adding a 'capabilities' command to 'remote sensor protocol', which allows scratch to filter out all variables and broadcasts the hardware is not needing ( improves performance) and allows scratch to display the sensors in a neat way (alike the build in 'scratchboard display').
Remote clients could send their capabilities to scratch when connecting. This includes known broadcast names (scratch to hardware), (hardware to scratch), variables name, also in and out.
When this command is not issued, behavior is as current situation.

Regards,
Gerhard

User avatar
williamhbell
Posts: 291
Joined: Mon Dec 26, 2011 5:13 pm
Contact: Website Twitter

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 11:11 am

Hi,

Following requests from local schools, a flexible I/O interface for Scratch was created:
https://pypi.python.org/pypi/RpiScratchIO/
http://www.themagpi.com/issue/issue-20/ (pages 36-39)

since then documentation on how to add any additional device has been written. This is as simple as writing a new class that is then included in the PYTHONPATH. This documentation will appear in Issue 22 of the MagPi, as well as on the PiPy page for the project.

The next steps of the proposal are to create two deb packages:
(1) RpiScratchIO - run as described in Issue 20, but with an optional Python GUI to create the configuration file.
(2) RpiScratchIOd - a server to start RpiScratchIO when Scratch is running with remote sensor connections enabled. The user would then be able to configure the backend using the Python GUI mentioned in (1).

The user can run the daemon on a different device from the Scratch session and can use vanilla Scratch. Aliases could be used to make the protocol even more simple.

Best regards,

Will

User avatar
FLYFISH TECHNOLOGIES
Posts: 1750
Joined: Thu Oct 03, 2013 7:48 am
Location: Ljubljana, Slovenia
Contact: Website

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 11:58 am

Hi,
ghp wrote:a label "scratch approved hardware" is a nice idea. It would lead to the following situation:
- the 'scratch approved hardware' will sell. And only this. Kids and teachers will avoid shaky ground.
- it will stop innovation. New chips on the market, new approaches will need time to be supported, get the label and find their way to be sold.
... and later in your message your idea goes directly into this direction - when you're introducing "capabilities command" etc. ;-)

Don't get me wrong, if a hardware support is added, then some guidelines/rules need to be introduced that things fit together.
And this leads to "compatible" and "non-compatible" hardware fact. You cannot avoid this. With a label you just easily mark the board that its support by Scratch is to be expected.
Alternative to this label are "compatibility lists" - you, as user, identify the board and check on the list(s) if you can expect it to work. But... these lists are nothing but the label in a bit more "democratic" form (with its pitfalls that anybody can add items ;-) ). To put this back onto organized track, it would then make sense to have an "official hardware compatibility list".. and here we go - you're labeling the hardware, where the label is present somewhere remotely in this case.
ghp wrote:"Scratch approved" does not guarantee it works in all situations.
I agree; give me any board and I can make it not to work... ;-)
The label reduces set of possible issue sources... and this fact leads to thinking what is so special about your setup that causes hardware not to work - is it power supply, do you have long wires, etc.
ghp wrote:Let me bring back my idea of adding a 'capabilities' command to 'remote sensor protocol'
This idea is not bad, but has an important trap - you're always one step behind the "standardized parameters". As a vendor, you need to wait for the set of possible features to be updated before you can implement them and release the hardware. (Alternative is that vendors use their creativity for new features also in "capabilities introduction", what leads to de-standardization.)
We have seen many cases in the past where "slow standardization" caused various vendors to push their solution... Consequently, you had (a kind of) various variations of standards' extensions. Sometime later, just one existing solution became adopted as standardized. Remaining deviations were compatible with their older features, but not with latest, etc... Total confusion (and a good lesson what to avoid here).

I'm going to compose my detailed view to this subject (with focus on solution and use cases) into a draft document. In messages like this only a fraction of the overall picture can be highlighted in details. Expect this draft in the upcoming days...


Best wishes, Ivan Zilic.
Running out of GPIO pins and/or need to read analog values?
Solution: http://www.flyfish-tech.com/FF32

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

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 12:29 pm

ghp wrote:a label "scratch approved hardware" is a nice idea. It would lead to the following situation:
- the 'scratch approved hardware' will sell. And only this. Kids and teachers will avoid shaky ground.
- it will stop innovation. New chips on the market, new approaches will need time to be supported, get the label and find their way to be sold.


... and later in your message your idea goes directly into this direction - when you're introducing "capabilities command" etc
think this is not a contradiction.
As defined, the remote network protocol can be extended and unknown commands should be silently ignored.
So adding new commands will not be a problem, when ignoring them does not matter.

Case 1: a new scratch version understanding this command will use these informations to filter broadcasts and values send out to remote network socket (performance optimization) and possibly build up a view on which values a remote hardware driver can send. So its not 'incorporating' hardware functions into scratch, it is a possibility to import hardware meta information (and only the scratch relevant parts as the value names in/out and the broadcast names in/out).
Case 2: old scratch uses new driver. Capabilities command will be ignored. It is working as before. This needs to be tested, of course, as I would not like to have fancy exceptio popups all the time.
Case 3: new Scratch with old driver, not sending these informations. It will work as before, continuously updating its internal sensor and broadcast names when they arrive.

Regards,
Gerhard

An example makes it clear:

Example setup: A client software is working with some hardware and will operate a mechanical device.

The device controls a motor, a display and aquires motor temperature and fill level of a stack.

Broadcasts from scratch to the outside are 'motor_start', 'motor_stop'.
Broadcasts from outside to scratch are 'work_complete'.
Sensor values from outside to scratch are 'amount_of_work_remaining' and 'motor_temperature'.
Values send from scratch to outside are 'operator_display_text'.

In object oriented terminology, the client software has an interface definition towards scratch, providing these methods.

A capability command for this example could look like:

capabilities
broadcast.out='motor_start';'motor_stop'
broadcast.in='work_complete'
value.out='operator_display_text'
value.in='amount_of_work_remaining';'motor_temperature'

This command announces meta information about the interface, it does not contain information about the implementation inside the client software or the type of hardware involved.
And the naming used is not given by a scratch developer, but by the device implementing person/group.

We should not start a discussion on the precise format of a command like this (at least not now), it is just an abstract sample.

I assume, that the client software is mapping logical scratch-names to 'hardware stuff'. It is either hard coded for a specific purpose, or will have its own configuration.
The type of hardware connection used, say GPIO, SPI, I2C, TTY, Network, USB driven device or whatever combination of it, is encapsulated inside the client software.

If someone decides to switch the implementation from GPIO to SPI, from vendor A to vendor B, the scratch application code and the scratch code remain unchanged. This is the advantage of having interfaces and implementations.

So far the description of this example.

The benefits of this concept are

Performance: If someone uses a lot of public, fast changing variables, these are all sent out to remote sensor network, although the client software sitting there will discard them. With the 'capabilities', scratch can filter only
these needed by remote client software.
Kids usually do not worry about variable scope, and only complain that 'this is so incredibly slow'.
Usability: inside scratch, incoming broadcasts are registered and offered in the selection box of the 'when I receive'-hat. When a broadcast never has happened so far, you have to type it in, typos included.
Similiar topic with incoming sensor values.

What could be misunderstood: "But then I cant send a command like 'light_on' to the outside". The device attached in the example does not have 'lights' defined. There is no use to send it to the examples device, as there is no need for it.
If you have a different device with lights, you will need either a different client software, of if you use a generic one you will reconfigure it. But you will also need some rewiring with cables, connectors, mechanical stuff.

User avatar
FLYFISH TECHNOLOGIES
Posts: 1750
Joined: Thu Oct 03, 2013 7:48 am
Location: Ljubljana, Slovenia
Contact: Website

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 3:30 pm

Hi,
ghp wrote:As defined, the remote network protocol can be...
As I wrote before, I'm going to compose a draft document describing my perspective. It will be focused on:
1) hardware part of this subject (how to generalize/standardize add-on boards)
2) required handling on the software side:
a) by a software running locally or anywhere on the network,
b) what needs to be run locally by a RasPi this board is attached to.

On the hardware side I'd like to highlight what and how to achieve this, where on the software side my plan is to cover only what is to be done.


Remote network protocol is just one piece in this puzzle. I'm not capable to discuss about it with you without knowing what is your idea about other crucial parts of the complete story (and what would be impact of any potential change). For example, you're briefly mentioning drivers... I'd need more information to get the whole picture...


Best wishes, Ivan Zilic.
Running out of GPIO pins and/or need to read analog values?
Solution: http://www.flyfish-tech.com/FF32

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

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 8:42 pm

timrowledge wrote:OK, trying to make a list of plausible hardware, scanning back-issues for MagPi -
...
I'm sure I've missed a lot. Suggestions to round out the list?
RoboPi

http://www.mikronauts.com/raspberry-pi/robopi/

Just got the C interface running on Linux :)
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

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

Re: Scratch to hardware API: call for discussions

Thu Mar 06, 2014 9:30 pm

another board:
http://github.com/Guzunty/Pi/wiki

Virtual devices:
When looking for boards, please do not forget 'virtual devices', e.g. a text to speech adapter, or a quadrature encoder, or a stepper motor driver.
Text to speech is great fun, using e.g. festival as backend.
Quadrature encoder is using two gpio with photointerrupters, combing the measured values to a counter.
Stepper drivers have four gpio outputs and an internal status counter.

Basic pattern is some software logic, and using a number of hardware resources, e.g. GPIO or SPI attached pins.

Regards,
Gerhard

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

Re: Scratch to hardware API: call for discussions

Fri Mar 07, 2014 8:38 am

Hello,

let me add another three or four points to the discussion.
- remote connections
- hardware independance
- testability
- replay

Current separation of scratch and scratch client software, connected by remote sensor network allows some nice usage scenario:
Remote scratch. I have multiple RPi running here, each of them has different hardware attached. On one of the installations, there is my adapterBoard I use in school, and on another an attached breadboard currently hosting an atmega328 with a frequency counter in it.
As I have only one monitor on the RPI-scratch-workplace, I run scratch on the monitor installation and the scratchClient software on the machine where my current hardware experiments are running. No fiddly rewiring required. Just to use the 'remoteHost' command line switch on my scratchClient software.

Hardware independance. The scratchClient software could run also on X86 windows or linux machines, driving fancy things there. Of course, there will be no GPIO, SPI or alike, but I could imagine to have printers, plotters, monitor arrays, other fancy things attached needing more CPU resources, hardware resources than RPi will have. I agree, no longer kids-projects then...

Testability. Complex setups are difficult to analyse. In a school situation, 15 kids in classroom, 90 Minutes, you have at most 5 Minutes (and this is very optimistic) to hear a description of a problem, analyse the reason, try to reproduce and best case fix it. I found the log output of my scratchClient very useful, showing the broadcasts and value events on screen to quickly find out whether all the events assumed to arrive are really there and in correct spelling.

Replay. For unattended demonstrations, displays, showrooms, you can record events from remote sensor protocol and replay them. No hardware setup needed. No special actions in the scratch application code.

Regards, Gerhard

User avatar
TonyD
Posts: 447
Joined: Thu Sep 08, 2011 10:58 am
Location: Newcastle, UK
Contact: Website

Re: Scratch to hardware API: call for discussions

Fri Mar 07, 2014 1:53 pm

Here's another board to add to the list:

RPi-X SensoRPi

I think if we can get a common set of the popular chips supported such as ADC: MCP3008/MCP3004, port expanders: MCP23017/MCP230s17, motor drivers: L293D/L298 etc. would be a great start
Tony

User avatar
joan
Posts: 14198
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Scratch to hardware API: call for discussions

Fri Mar 07, 2014 2:26 pm

DougieLawson wrote: ...
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.
The source of pigpiod is part of the pigpio zip/tar. It's just a simple wrapper around the pigpio library.

I can understand that pigpio may not be suitable going forward for Scratch. There may be conflict between pigpio's use of DMA for timing and the attempts to accelerate general graphics processing with DMA.

However I do think that your idea of a gpio daemon has merit. I certainly wouldn't dismiss the idea out of hand. Properly implemented it would be language agnostic and get rid of the need to use sudo to access the gpios. There is little the existing libraries provide which couldn't be provided by a daemon.

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

Re: Scratch to hardware API: call for discussions

Mon Mar 10, 2014 8:35 pm

There's some interesting ideas popping up here; I must admit I hadn't thought of the remote devices aspect the Gerhard mentioned.

I've emailed or otherwise contacted every maker of Pi add-ons I have been able to find. More candidates would be welcome if you know any. I'd hate for us to do a load of work and find out we missed being able to include some really cool widget I just didn't hear about!
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

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

Re: Scratch to hardware API: call for discussions

Tue Mar 11, 2014 12:57 pm

Hello,

Summary:
I went the other way round yesterday: when people complain about their cards not working, why not look into the details and find out whats wrong.
As I found quite a lot of piface people's complaint, I looked into this.
What I found is a flaw in the piface scratch_handler, published on https://github.com/thomasmacpherson/pif ... handler.py

Conclusion: there is a need to better understand sockets and scratch remote sensor protocol, more than the need to bring support for nice cards into scratch itself.

Regards, Gerhard

Details:

The handling of remote sensor protocol is imho not correct. Here the original code snippet:

Code: Select all

        while not self.stopped():
            try:
                data = self.scratch_socket.recv(BUFFER_SIZE)
                #length = struct.unpack(
                # '>i',
                # '%c%c%c%c' % (data[0], data[1], data[2], data[3])
                # )[0]
                data = data[4:] # get rid of the length info
                #print 'Length: %d, Data: %s' % (length, data)

            except socket.timeout: # if we timeout, re-loop
                continue
            except: # exit on any other errrors
                break

            data = data.split(" ")
            
            if data[0] == 'sensor-update':
                data = data[1:]
                print 'received sensor-update:', data
                self.sensor_update(data)
 
The problem is, that there is an assumption that in each block of data arriving, there is a complete data record. Unfortunatley, there isn't. It is not guaranteed, that sockets transmit blocks, but sockets just transmit a stream of data. Unfortunately, on the receiver side, the record length is thrown away. In my experiment, I found multiple records in one block, and long records spread on multiple blocks. This snippets explains the observations people mentioned here: it works for small amounts of data, but then after some time it stops, as it looses sync.

Just to give an example on how better code looks like, here a snippet from my scratchClient.

Code: Select all

        while not self.stopped():
            try:
                #
                # get the bytes from the socket
                # This is not necessarily a full record, just some bytes.
                # 
                chunk =  self.scratch_socket.recv(BUFFER_SIZE) 
                #
                # no data arriving means: connection closed
                #
                if len(chunk) == 0:
                    scratchClient.event_disconnect()
                    break

                data += chunk
                #
                # there are multiple records possible in one 
                # received chunk
                # ... as well as the data could not be long enough for a full record.
                #
                # need at least 4 bytes to identify length of record.
                #
                while  len(data) >= 4:
                    recordLen = (ord(data[0]) << 24) +     \
                                (ord(data[1]) << 16) +     \
                                (ord(data[2]) <<  8) +     \
                                (ord(data[3]) <<  0 )                
                    #            
                    if recordLen > 512:
                        logger.debug("unusual large record length received: {len:%d}".format(len=recordLen))   
                    #
                    # are there enough bytes in data for a full record ?
                    # if not, leave the loop here and wait for more chunks to arrive.
                    #
                    if len(data) < 4+recordLen:
                        break   
                    
                    record = data[4: 4+recordLen]
                    logger.debug( 'data recvd from scratch-Length: %d, Data: %s' , len(record), record)
                    self.processRecord ( record )
                    #
                    # cut off the record from the received data
                    #               
                    data = data[4+recordLen:]
                    #
            except socket.timeout:
                # if logger.isEnabledFor(logging.DEBUG):
                #    logger.debug( "No data received: socket timeout")
                continue
            except Exception as e:
                logger.warn(e)
                scratchClient.event_disconnect()
                self.stop()
                continue

thomaspreston
Posts: 5
Joined: Thu Nov 28, 2013 8:33 am

Re: Scratch to hardware API: call for discussions

Thu Mar 13, 2014 9:58 am

timrowledge wrote:OK, trying to make a list of plausible hardware, scanning back-issues for MagPi - I'm sure I've missed a lot. Suggestions to round out the list?
PiFace Digital and maybe even PiFace Control and Display.

There is a primitive (and slightly buggy, as it turns out) scratch handler for PiFace Digital here: https://github.com/piface/pifacedigital-scratch-handler

With the huge number of Raspberry Pi add on boards wanting to talk to Scratch perhaps it would be best to just provide a standard, well documented interface to MESH. Then allow add on board developers to write drivers for their board, similar to how LCDproc works.

Or perhaps even a custom interface is too complicated and we just need better documentation for MESH.
ghp wrote:Conclusion: there is a need to better understand sockets and scratch remote sensor protocol, more than the need to bring support for nice cards into scratch itself.
@ghp Can you suggest improvements for the scratch handler on the issues page, please? Thank you! https://github.com/piface/pifacedigital ... r/issues/3

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

Re: Scratch to hardware API: call for discussions

Thu Mar 13, 2014 8:49 pm

Sockets and the mesh are an excellent way to connect many things. It won't be going away and if there are bug-fixes we can devise to make it better then we'll include them.

But we have some options for making closer integration possible for at least some and probably most hardware add-ons. The best solution may be one or more libraries that can manipulate the GPIO pins and or serial ports, along with some dynamically loadable Scratch blocks to make it nicer to talk to them. Remember, this is Smalltalk. We can do *anything*.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

User avatar
FLYFISH TECHNOLOGIES
Posts: 1750
Joined: Thu Oct 03, 2013 7:48 am
Location: Ljubljana, Slovenia
Contact: Website

Re: Scratch to hardware API: call for discussions

Fri Mar 14, 2014 4:45 am

Hi,
FLYFISH TECHNOLOGIES wrote:As I wrote before, I'm going to compose a draft document describing my perspective...
Here it is: http://www.flyfish-tech.com/pub/Raspber ... abitat.pdf


Best wishes, Ivan Zilic.
Running out of GPIO pins and/or need to read analog values?
Solution: http://www.flyfish-tech.com/FF32

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

Fri Mar 14, 2014 11:06 am

I think we really need to decide/get direction on whether we are going down the Scratch "mod" route or not.

if we are, then its a new ball game and everything is open for discussion.

if not, then we are tied to current packet broadcast mechanism and need to see if a universal common spec is possible.

I see these as 2 major pathways.

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

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

Re: Scratch to hardware API: call for discussions

Sun Mar 16, 2014 8:47 pm

Hello,

universal solutions for eternity can't be reached, at least not in a short time. We should look for low hanging fruit.
Scratch environments will be simple ones. One raspberry, possibly an extension card. There is no need for twenty cards of whatever combination, especially as scratch is not designed to be an universal programming environment for large, complex and fast environments.
When looking for an universal extension board management mechanism, it should not be targeted to scratch only, but for python and all the others too. And then this logic needs to be close to the operating system, not inside an IDE.
It is also true, that people who want to use a complex setup also have the skills needed to handle it.

My preference is the 'remote sensor protocol'. It is stable, well documented and a nice exercise in distributed systems. When a remote client crashes, scratch still runs stable. A good example of loosely coupled systems.

There is need for performance optimization in scratch. This is what the kids ask for. But this is 'under the hood', not changing the user interface nor the backend. There could be other optimizations, as a modern 'undo' feature, autosave or a stable sound system.
Other optimizations could be the 'capabilities'-feature for the 'remote sensor protocol' mentioned earlier in this thread. Transparent and compatible with existing software. This could improve IO-performance by filtering unneeded traffic on the socket.

Summary: keep changes small, invest in performance and usability.

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

Mon Mar 17, 2014 7:26 am

I'm with Gerhard :)

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

Return to “Scratch”