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

Jan2016 release

Tue Feb 09, 2016 8:01 pm

A slightly longer list of changes thanSimon could fit into the main blog posting-

Aside from the usual small bugfixes, minor speed-ups and another tick in the VM we have :-

Painter

Speed up opening of dialogues such as the painter to prevent onset of narcolepsy in impatient small people.
Properly support the painter with gridding so that painting under large magnifications works cleanly.

Sound input

Sound recorder functionality much improved. A Pi with a usb sound card (and configured properly, which require some considerable explanation by someone that knows about it) can now record sounds to add to scripts. A serious error when attempting to record where there is no such hardware attached is now politely handled. Being able to record also means the two sound related tiles ‘loudness’ and ‘load?’ work at last.

Displaying

Allow double-size display in Presentation Mode on 720 line HD monitors (by arranging buttons in column at side instead of row above the stage)
Fix large menus that break into a set of sequential menus so they do not cause un-selectable entry problems when the initial menu is opened well to the right of the screen. This could be an issue particularly with choosing a MIDI instrument to use.
Font scaling option added to the .scratch.ini file. Add a line
“fontscale=1.3”
to scale font by factor 1.3 and so on. Advise against much outside the range 0.7 to 2 to avoid really ugly layout problems on most displays.
The .scratch.ini file now handles some poor formatting cases without raising errors.

GPIO

Add CamJam Edukit3 motor board support to gpioserver; set ‘AddOn’ to ‘EdukitMotorBoard’ and use as per RyanTek motor board.
Fix gpioserver ‘autostart’ variable usage. A script that has a variable named ‘autostart’ will autostart as long as the value is non-0.
Add basic ability to vary the PWM frequency in the gpioserver. Uses the wiringPi soft-pwm capability and is subject to its limitations; the new command ‘pwmrate’ accepts a range between 10 and 1000. Using 10 permits a range for the ‘pwm’ command of 0-1000, using 1000 allows 0-10. This ought to help driving some motors, apparently.

Things that didn't make it this time -
Servo control via pwm; I can't come up with a way to do this using wiringPi as yet.
Ultrasonic sensor; it can be made to 'work' with plain gpio but needs much better handling to be any use. Still thinking about it.
Sudo-less gpio; it looks like it should be possible with newest wiringPi but not yet confirmed and fully tested.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5790
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Jan2016 release

Tue Feb 09, 2016 8:04 pm

Regarding sudo-less GPIO, yes, it seems like nuscratch CAN do it, but doesn't yet because the launcher script doesn't set the relevant environment variable and remove the sudo wrapper.

I've had an experimental build which didn't use sudo at all, but didn't have any testers, so it didn't make it into the image.

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Jan2016 release

Wed Feb 10, 2016 6:38 am

Thanks for this post, Tim. It's a shame that you haven't found a way to add the ultrasonic sensor yet. That and servo control are, for me, the 2 must have items for use in primary school robotics with Scratch. I was quite excited when I saw that the EduKit is now supported, but sadly it seems (and I really don't mean this to come across a harsh as it looks when I typed it, I appreciate the hard work that you're putting into this project), that it adds nothing extra, as it functions the same as the RyanTeck board.

Anyway, please keep up the great work that you are doing on Scratch. One more thing that would be nice, though, is a 'Broadcast AllOff' block, which is really helpful when working with lots of leds.

Thanks again.

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

Re: Jan2016 release

Wed Feb 10, 2016 6:54 pm

Forris wrote:Thanks for this post, Tim. It's a shame that you haven't found a way to add the ultrasonic sensor yet.
Yup. It's a bit tricky to do cleanly. We need to claim two gpio pins and to avoid clashes with other devices it needs to be possible to specify which two. Then the dratted sensor works by requiring a busy-wait loop, which is death to an interactive UI, so at the least it needs to spawn a low-level thread. And the repeatability is terrible (in my experiments my office apparently jumps from 1.4m to 7m wide, which isn't technically impossible but is quite unlikely) so one has to do several measurements, throw out apparently obvious outliers and average the remainder. I suppose one could do a sort of running average in this background thread... hmm. Maybe.
Forris wrote:That and servo control are, for me, the 2 must have items for use in primary school robotics with Scratch.
I understand and would very much like to get it working soon. Servos are a problem when using wiringPi right now because the pwm code therein simply can't manage the frequency response needed. A new servo-pwm api is needed somewhere. I'm assuming you also understand the current limitations involved; some of the cheap servos out there pull a bit more than is helpful even on the control line.
There are some pretty neat servo-control HATs too that would be good to support.

Forris wrote: I was quite excited when I saw that the EduKit is now supported, but sadly it seems (and I really don't mean this to come across a harsh as it looks when I typed it, I appreciate the hard work that you're putting into this project), that it adds nothing extra, as it functions the same as the RyanTeck board.
Yup, but different gpio pins, which is quite important! I wish people would co-ordinate a little on this. There are now several dual motor boards to support, some using pinA->direction, pinB->speed and others using pinA->forward speed, pinB->backward speed (and don't you mix them up!) Why this madness! Make it stop!
Forris wrote:Anyway, please keep up the great work that you are doing on Scratch. One more thing that would be nice, though, is a 'Broadcast AllOff' block, which is really helpful when working with lots of leds.
That might be even trickier; we'd need to be able to reliably track exactly which pins we have control over (which is a big problem currently since you could be running several programs that access gpio via a variety of libraries, all thinking they have control) and which are outputs in order to be able to turn them off. You can tell I'm a real engineer by the way this sort of thing worries me...
I guess an approximation to sanity might be plausible by trusting our list of pins set as outputs by Scratch but I can't help thinking of the chaos ensuing as a simple 'gpioalloff' turns off the atmospheric cycling units on the ISS.

And as always - if you need more capabilities, and especially if you're a teacher wanting them for lesson plans, contact the foundation and request, nay *demand*, them. That gets turned into my time, which gets turned into new features.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Jan2016 release

Fri Feb 12, 2016 1:15 pm

Hi Tim, thanks for the (very detailed) response.

I must admit to only understanding about 60% of what you said, but I have faith that you can get the job done. I do understand what you mean about different boards doing the same things, but in different ways. I'm sure that it's too late now, but maybe there should be some sort of standard (similar to HAT, I suppose) that board developers have to adhere to if they want their board to be supported in the built-in version of Scratch.

Also, I think that your main problem is that you're playing catch-up with what has been before (most notably Simon's ScratchGPIO), which offers all of the features that the 'official' version is current missing. I'm sure many people think, because I know I have, that if one version already supports certain hardware, why can't anything that succeeds it also support it. Now, reading through the documentation and your original posts again, it is plain (even to me) that you have approached the whole thing from a different start-point.

From your replies to my last post, I also see that you are not able to treat Scratch in isolation. You are obviously concerned with how it affects other programs that may also be using the GPIO. However, from my perspective, primary age kids will only be using one piece of GPIO-control software at a time, and these kids are the main users of Scratch.

I would be interested to know what your criteria are for prioritising what functions you need to add next. Is it just on the basis of 'if you ask (or 'demand') hard enough then you will try to add it, or do you have a roadmap in place for where you want Scratch on the Pi to go?

As I said before, I appreciate the work that goes into this although most of it is above my skill-level. I promise to try to understand any reply that you give!

As an aside, I am not a teacher, although I am currently helping the IT teacher in my son's primary school to introduce Pi's into the school. I held a bit of a show-and-tell for the Digital Leaders group yesterday to give them some ideas of what the Pi can easily do, all of it based around Scratch (2 using GPIOserver, 2 ScratchGPIO), and I will be starting an after-school club in September. But mostly, I'm just a enthusiastic parent that has been telling anyone that would listen about how cool the Pi was since it was first released.

Thanks.

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

Re: Jan2016 release

Tue Feb 16, 2016 2:07 am

Forris wrote:Hi Tim, thanks for the (very detailed) response.
You're welcome - I try to be reasonably detailed and complete when explaining because this stuff will sit on the net for years and undoubtedly get found by someone missing all the prior context. It's like writing comments properly; assume someone completely new to the discussion will need to understand.
Forris wrote:Also, I think that your main problem is that you're playing catch-up with what has been before (most notably Simon's ScratchGPIO), which offers all of the features that the 'official' version is current missing. I'm sure many people think, because I know I have, that if one version already supports certain hardware, why can't anything that succeeds it also support it. Now, reading through the documentation and your original posts again, it is plain (even to me) that you have approached the whole thing from a different start-point.
Yup, there's some of that. Simon supports whatever he feels like supporting, as and when he has time from his day-job; I do this *as* my day job and so priorities are quite different. People are paying and want *their* stuff doing. I have ideas about what I'd like to add or extend and I push them whenever I get the chance but requests from actual users always help in getting agreement.

Forris wrote:As an aside, I am not a teacher, although I am currently helping the IT teacher in my son's primary school to introduce Pi's into the school. I held a bit of a show-and-tell for the Digital Leaders group yesterday to give them some ideas of what the Pi can easily do, all of it based around Scratch (2 using GPIOserver, 2 ScratchGPIO), and I will be starting an after-school club in September. But mostly, I'm just a enthusiastic parent that has been telling anyone that would listen about how cool the Pi was since it was first released.

Thanks.
Good on you; that's what makes all this worth it in the end. I'm helping a local makerspace (yay! Go Makerspacenanaimo.org !) establish a Pi/Scratch lab for youngsters in the hope that Vancouver Island can grow some techie kids.

Oh, and some experiments show that I can drive ServoBlaster from Squeak ok, so I should be able to come up with a usable Scratch interface in the not too distant future.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Jan2016 release

Tue Feb 16, 2016 5:55 pm

Thanks Tim.

It's becoming a little clearer now! I hadn't considered that there would be commercial pressures that have a hand in deciding what your priorities are. I can only hope that they also happen to be what is needed for primary-age kids to make cool projects using Scratch on the Pi, as this surely has to be the prime motivation?

Good news on the servos - fingers crossed!!

Regards, Darren.

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

Re: Jan2016 release

Tue Feb 16, 2016 9:30 pm

For the servo problem, the scratchClient software provides two solutions
- DMA based output based on a modified RPIO library (adjusted for PI2), which is included in download.
- an arduino UNO or NANO solution. The pins are controlled from scratch, allowing analog input, digital in or out, pwm output and servo output. The arduino is connectd by USB. The arduino needs a special sketch, which is in the download tar file. The arduino world (UNO, NANO) is running from 5V, so the IO is also using 5V-level.

See http://heppg.de/ikg/wordpress/?page_id=6 for download.

The arduino adapter already existed. The idea for the servo outputs was raised by someone asking for this feature. He wants to run a workshop for scratch and physical computing, using arduino NANO as external adapter board. Clever idea, as the nano are quite inexpensive (clones on amazon, 5pcs for less than 15€), at least less expensive than most interface boards.

For the ultrasonic distance sensors, there is a a solution which uses an external atmel 328 controller. This combines best of two worlds: precise timing from a microcontroller and flexibility in linux environment. And this setup avoids some complexity in software setup.

Regards,
Gerhard

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

Re: Jan2016 release

Wed Feb 17, 2016 12:14 am

Good points, Gerhard. In general I'd prefer an add-on board to control servos and insulate the power issues etc. I have a fairly sophisticated one from Mikronauts but so far haven't been able to get it working :-(

The good news is that I can now drive a servo from Scratch and do fun things like making it move as a sprite glides across the screen. Just a little more work and we can upload this stuff to one of the Pi's on the ISS and Tim P can control the Canadarm!
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Jan2016 release

Wed Feb 17, 2016 12:31 pm

Tim - great work!

Gerhard - I know that using a separate controller to handle the timing would be the best way to control servos, but my focus is on being able to use 1 or 2 servos and, as it's users will be primary schools, as easily (and cheaply) as possible. Also, as I mentioned to Tim, the modified versions of Scratch that already exist have the ability to control servos without any extra hardware apart from a separate power supply. The same is true of the ultrasonic sensor - yes, there are more elegant and professional ways to interface to it, but I'm interested in cheap and easy, even if this sacrifices resolution.

The great thing, for me, is that Tim's GPIOserver comes as standard in Pi Scratch. So, while I have used Simon's ScratchGPIO a lot, it does require an extra download, and an extra desktop icon, and I'd really like to focus on the making and the coding, and the fun!

User avatar
gatherer
Posts: 14
Joined: Sat Oct 17, 2015 2:31 pm

Re: Jan2016 release

Sun Apr 03, 2016 2:10 pm

Hi,

is it possible with the new Version to use more than one PiFace?

Thanks

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

Re: Jan2016 release

Sun Apr 03, 2016 6:33 pm

No, I don't think so; for a start the pins don't carry through so you can't stack them. You could potentially use one of the boards that sort-of side-track multiple HATs (of course, I can't find any example to offer right now) to solve that part but then the software would need some work.

The Piface uses an SPI connected MCP23S17 port expander, which strictly speaking should mean up to 8 of them could be connected on the one SPI bus. I'm fairly sure the PiFace doesn't provide any way to do that many; from the utterly dismal documentation provided on piffle.org.uk it looks like there is a single jumper that could let you choose from two device addresses.

Assuming that the above is correct it would probably be possible for me to support a couple of PiFaces from Scratch. Not this release though!

Why do you want to use multiple PiFaces? If you happen to have several lying around then I can see the point but it you want to control a bunch of relays there are probably better HATs to choose. What's your project?
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

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

Re: Jan2016 release

Sun Apr 03, 2016 7:26 pm

Hello,
when you solve the connection problem, then with scratchClient it is possible to talk to multiple 23S17-boards. The base address in the scratchClient adapter for this chip is configurable. So just add another config for the second chip, modify base address and sensor/variable names for scratch and it is done.
Regards,
Gerhard

http://heppg.de/ikg/wordpress/?p=402

Return to “Scratch”