Bringing GPIO Server and ScratchGPIO together
- Without being big-headed – I’ll just state that ScratchGPIO is THE standard way of controlling pins on a Raspberry Pi up till now.
- This article is 100% intended to HELP people/pupils/teachers/kids/authors/resources etc etc etc transition and show the world that people CAN co-op 🙂
This is going to me typing as I’m thinking since speed is of the essence before people get their minds entrenched
The official GPIO server is out but I’d like to get ScratchGPIO and it aligned as soon as possible before we have another unnecessary 927
ScratchGPIO | GPIOServer | Does something need doing | |
Pin numbering | uses pins and BCM | only uses BCM | No |
PWM | The community came up with “Power” for PWM – we made it 0-100 (as 100 is easy/rational big number for kids and works well as pseudo percentage syntax) | using PWM0-1024 | I think so |
PWM | Experince has shown LEDs need high freq – motors need low freq so it has “Motor” as lower freq PWM mode | Just high | I think so |
config pins | assumes 11,13,13,15,18 as outputs – rest as inputs | no default | Not really |
config pins | Any pin set to on or pwm is automatically set as an output | require explict configxxxout | Would be nice if GPIOServer didn’t easy to add dummy syntax that ScratchGPIO can ignore |
I am able and FULLY willing to change ScratchGPIO so that is handles both syntax methods until GPIOServer catches up with functionality but I strongly feel that after 3 years of people using ScratchGPIO it would be a bit criminal to have major differences 🙂
I’ve added my comments to the forum. I had to look up the #927 but it’s a good one!
I’ve really enjoyed using ScratchGPIO and it’s released a freedom in using the connections that I didn’t have with Python – as a teacher I’m too busy to remember complex syntax at times.
Thank you for the energy you’ve put into Scratch development. I’m also on the edge of considering Buggle or ScratchCrumble for school Textiles GCSE, but that’s a whole new ball game!
I saw – thanks – I just want us (me and foundation) to sepearate out personal antipathy from a balanced discussion and co-operation on stuff for the kids – its like divorced parents behaving badly !!!
I admit to only having a little experience of using ScratchGPIO myself – but I’ve met many enthusiasts of ScratchGPIO. *Anything* that broadens access to using GPIO should be welcomed. I’m sure that enthusiasts of ScratchGPIO will continue to use it.
You’ve certainly put forward some convincing arguments for why things work the way they do in ScratchGPIO. I hope that eventually the best features of each of the two will be merged into one unified solution.
It’s tough watching from the sidelines when you see your friends not getting on – you want to bring them together and see them settle their differences. This shouldn’t be about personalities, it should be about solutions to problems 🙁
100% agree – I “some negative word” them – they “some negative word” me – who cares – lets get it right for the children 🙂
Simon – I’ll be brutally honest with you. I like you. I like you a lot. You have a certain charm to you – you’ll already know that not everyone gets that or feels the same way I do. Very much like me as well; admiring you requires an “acquired taste”. It’s highly likely that those who don’t know you very well may misjudge your intentions.
You’ve worked on some fabulous projects and your ScratchGPIO session that you ran at the Raspberry Jamboree this year was superb – parents and children taking part were highly engaged and managed to accomplish a lot in a short space of time.
ScratchGPIO has many fans which is clear for me to see.
I also have other friends working on other projects (some in this field) and while I champion any projects you work on that are for the benefit of learners, I can’t endorse, defend or condone behaviour which only serves to upset others; others who also believe that their project is also going to make a difference.
As your friend – I’d encourage you to focus your effort on developing and sharing great projects and keep your feelings about other personalities for the pub. 🙂
Pro tip – A project shared on github allows others to contribute to the development 😉
Why in the world did they re-invent the wheel? I MUCH prefer ScratchGPIO’s implementation. Where are the blocks with the server? Why doesn’t it load all the pins into the dropdowns? Instead it seems like just complex variable and event linking. The more this try’s the model the Arduino, the better and easier it will be for people to use.
Politics/need to be in control when talking about Raspberry
Scratch 2 has never really supported external hardware and doesn’t understand Scratch 1.4 projects with non-standard sensor-messages – that project should never have been uploaded as it just causes confusion
I strongly support your opinion. For one, I’ve been using ScratchGPIO (a slightly modified version) with a school ever since version 1, and the simple fact that people’s projects won’t work with the “official” version without going through all the code is a big disappointment for me.
Then there are the small things with the “official” one that may make sense to a computer scientist, but certainly not to people who are just learning to program. The pin numbers and having the motor speed go up to 1024 spring to mind for this.
For the moment, your version is the one I’m going to keep using!