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'.