Programming paradigms for physical computing and IoT
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 132 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/44979 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
SoftwareComa BerenicesWindow functionPhysical computingoutputFunction (mathematics)Library (computing)Programming paradigmMultiplicationHierarchyDeclarative programmingProcedural programmingEvent horizonSource codeProcess (computing)Data conversionInverter (logic gate)Graph (mathematics)BefehlsprozessorInternetworkingGoogolCategory of beingOpen setReading (process)Computing platformInclusion mapInterior (topology)Software testingRAIDExpandierender GraphMusical ensemblePrice indexRepository (publishing)Installation artComputer hardwarePoint cloudHacker (term)FreewareAreaoutputSemiconductor memoryRevision controlMultiplication signDatenausgabegerätSource codeJoystickDemonPiDifferent (Kate Ryan album)PlastikkarteBootingControl flowTouchscreenAuthorizationMobile appQuicksortGreatest elementProcess (computing)Computer architectureBuildingSubsetImplementationTerm (mathematics)Connected spaceIntegrated development environmentPhysical systemGame controllerVariable (mathematics)Personal identification numberAndroid (robot)Network socketDatabaseInstance (computer science)Single-precision floating-point formatRoboticsWhiteboardCommunications protocolAngleDemosceneLibrary (computing)Slide ruleComputer hardwareDistribution (mathematics)ArmReading (process)BitProjective planeCategory of beingRepository (publishing)Computing platformVirtual machineTransport Layer SecuritySoftwareState of matterAdditionData miningPoint (geometry)Server (computing)Row (database)Programming paradigmData conversionCodeOcean currentSocial classLaptopThread (computing)Arithmetic meanInterface (computing)MultiplicationMiniDiscSelf-organizationExterior algebraPosition operatorProcedural programmingSeries (mathematics)HierarchyFactory (trading post)Remote procedure callCartesian coordinate systemPhysical computingPower (physics)Data structureSet (mathematics)Presentation of a groupArithmetic progressionComputer programmingMathematicsMessage passingRight angleMixed realityCASE <Informatik>Connectivity (graph theory)Stability theoryGroup actionLevel (video gaming)Single-board computerWeb pageGoodness of fitDot productIP addressDistanceHydraulic motorCalculationForm factor (electronics)ProgrammschleifeReal-time operating systemProgrammer (hardware)Interrupt <Informatik>Functional (mathematics)NamespaceComplex numberTelecommunicationWeb browserLattice (order)ThumbnailRandom number generationSoftware testingStructural loadComputer fileGraph (mathematics)Network topologyObject (grammar)Line (geometry)BefehlsprozessorAreaUltrasoundMatching (graph theory)CoprocessorPulse (signal processing)Scripting languageAxiom of choiceGame theorySubject indexingBoilerplate (text)Food energyEvent horizonHacker (term)Real numberGoogolInstallation artSuite (music)1 (number)Ideal (ethics)Electronic mailing listIterationLoop (music)Negative numberBoolean algebraInverter (logic gate)NumberIntegerComplete metric spaceView (database)DialectFlow separationDampingMicrocontrollerBounded variation2 (number)System callGreen's functionRepresentation (politics)Touch typingVideo GenieType theoryStatement (computer science)PlanningConfidence intervalDefault (computer science)CurveError messageWindowGastropod shellSmoothingWaveRule of inferenceGateway (telecommunications)Front and back endsCombinational logicSineRandomizationInteractive televisionGeometric quantizationForm (programming)Boolean functionTupleFunction (mathematics)Remote administrationSound effectBlock (periodic table)Direction (geometry)Scaling (geometry)Computer animation
Transcript: English(auto-generated)
00:05
Hi everyone, I'm Ben. I work for the Raspberry Pi Foundation. This talk is kind of an idealism based on an existing library for the Raspberry Pi and I want to see the idea of it being taken further and moving forward into other areas.
00:24
So the Raspberry Pi is a single-board computer that provides you a set of GPIO pins. These pins allow you to connect up to electronics and real-world applications and devices. And they're a simple interface to programming devices and reading values and sensors
00:43
and controlling things in the real world. Prior to the library that I created, there were several low-level libraries which you just talked to the pins. If you've ever used an Arduino or something like that, you do a lot of kind of turning pins on and off and reading the state of pins.
01:00
The way my library GPIO0 works is implementations within device classes. So you create an instance of an LED for instance and it provides you all the things that you want in human terms to an LED to be able to do. So an LED is just a light, so you have on, off, toggle, blink,
01:21
you can read its value as well and things like that. So that's just a really simple example. And this all kind of stemmed around some myself and my friend Dave Jones created this library together. It was inspired by Dan Pope's Pygame 0, which is a zero boilerplate version of Pygame for making games with Python.
01:43
And we took the same kind of idea. So we wanted to minimize the amount of code you have to write to make something happen. So in Pygame 0, in just a few lines of code, you can get something on the screen that you can control with the keyboard and move around. And your implementation of your game becomes very centered around the actions
02:02
of what is going on in the game, the actors in the game, not about implementation of how these things should work in an underlying sense. And the same applies here with GPIO. So rather than writing out your implementation or copy and pasting an implementation of how to read something complicated like an ultrasonic distance sensor,
02:23
you send off a signal and wait to have a signal back on a different pin and you're reading pin values and doing calculations. You actually just create an instance of a distance sensor device and you read its value or read its distance.
02:40
And they all have... So it was intended for use in education because we used to teach with a low-level library, teaching teachers how to do physical computing. And there's an awful lot of code that you had to write to be able to just do the basics. And it was very difficult for them to have the confidence to actually move forward and do more complex projects.
03:02
But if you can write in a Pythonic way with simple guessable API, commonly used names and sensible default values, it's a simple introduction that allows you to progress along a smooth learning curve and we went for a kind of a multi-paradigm approach,
03:22
which is one of the things I'm going to be focusing on in the talk. So there isn't just one way to do something like a procedural way. There's various different methods you can use. The same way in Python you can start doing while loops and if statements and move on to writing your own classes or writing your own functions or using functional tools and things like that.
03:44
And it's very extendable. So if there's a device that you've got that we haven't got an implementation for, it's very simple to build on existing classes and write your own or even write other devices that perhaps aren't tied to GPIO pins, but have them be controlled in the same way
04:01
or control other things in the same way. So GPIO0 supports all the kind of basic electronic components and a few sort of add-on boards and more specialized components. There's a huge device hierarchy, so everything kind of builds on other things.
04:21
So looking at what I consider the four main different paradigms. So in the most basic sense, if you want to have an LED light up when you press a button, this is one way, a really great way, to introduce a teacher who's new to this or a child who's new to this or any beginner is to write a while loop that has an if statement.
04:41
So if the button is pressed, turn the LED on, else turn it off in a while loop. And if that's all your script is doing, it doesn't matter that you'll stick there in a while loop. A slight variation on that is to use procedural but with a blocking. So rather than continuously asking if the if and going one way or the other, you wait for the button to be pressed
05:01
and it will just sit and block at that point until the button is pressed, then turn the LED on, wait for it to be released and turn it off, which has its benefits as well. You kind of have a control flow rather than continually asking. And then you have an event-driven approach. So you assign an action to the button being pressed and the button being released.
05:24
Now this does exactly the same thing but using callbacks. So a threaded callback would be fired to fire the LED.on function. You can provide any function. It doesn't have to be a GPS error. So it's just something that's callable. So you can write your own custom function, have it fire that when you press a button or something as well.
05:46
And the final example, so you'll see each of these has reduced the number of lines needed. But this one kind of takes a bit of explanation. In a way, it's much simpler in that there's just one line defining the behavior. So you're setting the source of the LED. So it's saying from the LED's point of view, where do I get my values from?
06:04
And the button.values is an iterator yielding its current value continuously in the background. So the way that values work, so we have every device has a .value property. You can read whether it's an input or an output device.
06:21
So here I'm creating not an LED but a PWM LED, which is just an LED component that you want to be able to control the brightness, bringing it up and down from 0 to 1, not just on, off. So an LED's value would be true or false, but a PWM LED value is a float 0 to 1.
06:42
And now I can run LED.on then read the value again, and I've got 1.0. I can also just set it to 0, and that's the same as running LED.off. So you can't set, say, a button's value. It has to be pressed for the value to be changed. But an output device, you can have its value set.
07:00
But you could always read the value of an input device. So if you create a PWM LED, for instance, and a potentiometer, so a rotary dial, which also has a value of 0 to 1 as you slide the dial around, you could read the LED value and see that it's 0. Read the potentiometer value, and it's that sort of roughly around halfway.
07:24
And what you could do is you could say LED.value equals the pot value. So you set that once. The LED brightness is now set to that sort of roughly half brightness, but whatever the potentiometer is at that particular time. And then what you find yourself doing is putting that in a loop to say,
07:41
well, I want it to continuously update. And that's where the idea of having source and values came from. So output devices have a dot value, a dot values, which is an iterator constantly yielding the current value. And then any device that can have its value set also has a source. And you can just pipe that straight into there
08:03
just by setting the source property to equal any iterator, to be honest. You give it a list of values and a delay, and it will iterate over them. But if you give it another devices dot values, it will constantly iterate over those, keeping those two devices paired, essentially.
08:22
And so you end up with this. So an LED and a button paired up in that way. You can also process the value in between. So you could take the set of values and apply a function to each value before you pass it into the source. So if you wanted to, say, do the opposite of the LED is lit up by the button press,
08:44
you could have the LED is on until I press the button and then it goes off. You could negate that with a function in between. We actually provide a set of common tools for things like that that you would want to do. You can write your own custom functions which do this. It's all bog standard, just passing values around with iterators.
09:02
But we provide a bunch of source tools within gpr0.tools, such as negated and various others. So if you've got a value that's, say, 0 to 1, but you need to turn it into a Boolean, then you just pass it through the Booleanized function. You can clamp, invert, negate, delay them, quantize them, smooth them, scale them.
09:25
You can do all sorts, and you can combine these as well. You can even have some source tools which combine multiple sets of values. So you could have two input devices which some function takes those two values,
09:40
does something to them, and passes it into an output device. And there's things like, other combining tools are things like all, any, average, multiplied and summed. So you could have, for instance, an LED that's only lit when two buttons are both pressed.
10:02
You could have the all values, the and of those two buttons. And you can also provide artificial sources. So have a function which gets passed into the source, but it's not coming from a GPIO device. It's just coming from some function that isn't connected to a device. So things like if you wanted to pass in cos values or sine values or random values,
10:25
or define your own function that just provides a set of values from some artificial source. We also provide a few other classes which we call internal devices, which have all the same properties that the other GPIO devices have, the other device classes.
10:43
But these are not artificial, but they're just not related to GPIO things. So time of day, for instance, here's an example. So I've got a pet tortoise at home. We've got a lamp, a heat lamp that needs to be on for a certain amount of time during the day. And the lamp is connected to something called an EnerGenie socket,
11:03
which is a remote control socket that you can send a radio signal to and it will turn on and off the actual wall socket from the Raspberry Pi. And that's just controlled by a few GPIO pins. So here I create an instance of an EnerGenie, connection to an EnerGenie socket, which I call lamp.
11:21
That's the representation of what it's controlling. It's controlling the lamp. I've got a daytime object, an object I'm calling daytime, which represents the hours between 9 a.m. and 6 p.m. So the time of day object is a bit like a button in that it's either active or it's not active,
11:42
the same way a button is either pressed or not. It's the same kind of idea. But it's just like a button that is pressed for those hours of the day and then released. So this is one example of how you could use that to control a lamp using daytime. Another one. So we have CPU temperature.
12:03
So you can read the CPU temperature of the device, like the temperature of the Raspberry Pi. And we have something called LED bar graph. So that's when you've got a series of LEDs in a row. And you can have them controlled arbitrarily.
12:20
So you have an LED board and you just say you could turn them on in any interval. But if you want them to act like a bar graph so they can only go from one end up to the other, being lit up, then use the LED bar graph, which is a really effective way. If you've got, say, 10 LEDs in a row and you pass in the value 0.5,
12:41
it will light the bar graph up to half of the LEDs. So here I'm using the LEDs will always be representative of the current CPU temperature of the Pi. So you could visualize the temperature rising as you do stuff with applications on the device.
13:01
Another one. So ping server. Again, it's either active if it can do a successful ping or inactive if it can't. So here I'm using source delay, which delays how often it should be reading that. So I only want it to ping Google every 60 seconds. So I've set the green to match the Google values, but it's only looking every minute.
13:25
And then the red is rather than coming from another input device, it's just negating whatever the green is. So either the green LED is on or the red LED is on according to whether it can access Google. And you can define your own. So this is one way of doing it is actually providing a class that subclasses the internal device class
13:45
and just implements how it reads its value. So here's just reading from a file that just contains an integer. So you could have some sort of interface that writes to a file, either writes a 0 or a 1,
14:00
and sets some LED to match whatever there is in that file, for instance. You could also implement this as a function that just yields that value as well, but it's just an alternative. So there's a separate library written by Martin O'Hanlon called Blue Dot. So this comes with an Android app for your phone that you get a big blue dot on the screen.
14:27
And you can either use it like a push button, so when you press the button on the app, it's Bluetooth connected to your Pi, and you can read whether the button is pressed or not in real time. But it also acts like a joystick as well. So you can rotate your finger around the D-pad and retrieve the X and Y and the angle and things.
14:45
So you can use it to do simple things like you could control an LED just by pressing the Android app, or you could use it as a D-pad to control, say, a robot. And it's really simple to do that because Martin uses the same kind of style of API as GPI 0 does,
15:04
so it plugs in really well together. So you create an instance of your blue dot connection. Here's the exact same examples of the LED and button I did before, but the button has been replaced with this blue dot controller, exactly the same API. So you've got, if the blue dot is pressed, turn the LED on.
15:21
Wait for press, when pressed, and then source and values. He implemented the source values thing. So GPI 0 is a cross-platform library. So it's distributed via an app in Raspbian and a bunch of PPA and obviously through PIP.
15:42
So you can run it on Raspberry Pi operating systems and access the GPIOs directly. You can also run it on PC and Mac, and there's various reasons you would do that. So one thing we did was initially we built the library on top of the low-level library I mentioned that we used to use to teach kids and teachers how to do stuff, which is RPI GPIO.
16:05
The guy who wrote that library, Ben Croston, he wrote it as a way to control his beer brewing process. He runs a beer brewing business, and he sponsors PyCon UK often because he used Python to do that.
16:24
And he wrote the library, which is what we ended up using as a teaching tool, which is really cool, a way of something like that coming out of the community. But we built on top of that initially, and it was just directly tied to RPI GPIO. The GPIO was just an abstraction on top. But then later on, we made a way of providing multiple swappable backends.
16:45
So you can say, well, actually, I want to use the GPIO 0 API, but this particular library underneath because it has this feature or this other thing that I like. So there's a couple of other libraries. One in particular is PyGPO I'm going to go into next, which allows remote connections,
17:02
which is a really useful way of being able to control things from your PC over the network onto another Pi. We provide a native pin implementation just bundled with GPIO 0 that's quite limited and experimental, but it's just a way if you don't have one of those other pin libraries, you can just use that, and mock as well.
17:22
So we have a test suite in the library that just mocks. There's no actual pin interactions going on, just purely mocks it purely in Python, which is really useful for both in our test suite and for personal testing as well. You can validate that your code runs without having access to a Raspberry Pi.
17:41
So here's an example of how mock works. So you just set the pin factory, as we call it, to mock in an environment variable, run your Python shell or your Python file, and you write exactly the same code that you would on a real Raspberry Pi. There's no warnings or errors or anything. The underlying pin object that's connected to the device is just a mock pin, which just stores the pin state in memory.
18:06
So that's just flashing an LED and reading its value, not very interesting. The next one just demonstrates that you can connect mock devices together. So you can verify that if you have a mock button and a mock LED,
18:20
your LED's value should change according to the button value, which you can tell to drive high and low to simulate the button being pressed, which is quite useful. So the Pi GPIO library is a really good library written in C. The author's name is Joan, and she does a really good job of implementing all sorts of different GPIO
18:46
and other communication protocols for Raspberry Pi in this library, a really well documented library as well. The way that it works is it runs on the Raspberry Pi as a daemon that can accept socket connections.
19:02
So you can give it remote commands. If you open up, give it permission to, then you can have it receive commands from another device. So if you run with these environment variables, setting the pin factory and the IP address, then you can actually have the exact same code you would run on a Pi but running remotely.
19:23
So give it an IP address and it will run. If that Pi is running Pi GPIO and actually accepting connections, then you can just write the same code and it will do that over the network. Another way you can do it instead of using the environment variables is create your factory objects in line in your code, which also means you can have multiple ones.
19:43
So you can control multiple devices over the same sets of pins but on different Pis within the same script. So you can have a sensor on one Pi in one room controlling a device in another room.
20:01
So it's an example of blinking an LED on a remote Pi. So the default pin factory, unless you set it in the environment variables, is on the Pi itself. So this script is being run on a Pi. So the LED here on pin 22 is the Pi's own pin 22.
20:22
But the button is on another Pi's pin 22. So the LED and the button are on different devices there. But one is explicitly set to another pin factory, which is a remote Pi. One is just the local pin. And another use for this is we provide an x86 distribution of our Linux distribution, Raspbian.
20:46
So we call the Raspberry Pi desktop for x86. So you can run this on your PC and Mac, either live boot it from a disk or stick or actually install it on your machine. And the good thing about this is it's a bit like an educational distribution, but for programming.
21:02
So you've got all the programming tools and things that come with Raspbian, the stuff that we want Raspberry Pi users to have access to. You have all that installed and ready to use. This also means you get the GPIO libraries and things like that. Now, obviously, if I hadn't told you what I've just gone through about the remote pins and things, you would think,
21:23
well, there's no point having access to those because you're on a PC. You don't have access to the pins. But a new addition allows you to plug in a Pi Zero, which is the smaller form factor, cheaper version of the Raspberry Pi. And you can just plug it in with a USB cable and no SD card.
21:41
So you don't actually have to install Raspbian on the SD card. You can just boot it over USB using OTG, and you can tell it that you want to access the GPIO pins. So when you plug it in, this dialog pops up. Oh, you've plugged in a Raspberry Pi. What do you want to do with it? If you say you want to use it as a GPIO board, it will boot a copy of Raspbian into the RAM on the Pi Zero from your PC,
22:08
boot it, run the Pi GPIO daemon, and then it's provided as an IPv6 gateway to the device. So you can create a pin factory on the reference to the IP address the same way you would a remote Pi,
22:24
but it's actually just going down the USB cable. So it's a nice way of kind of doing sort of plug and play Raspberry Pi GPIO stuff just from your PC. This is also provided in a PPA for Ubuntu, so you can install that and run it on Ubuntu.
22:42
And we're looking into getting this ported to Windows and Mac as well at some point so that you'd be able to do GPIO things directly from your PC and Mac without installing or live booting the Raspberry Pi desktop, which you can do now. This is a really cool way of doing it. It means things like code clubs and coded dojos and Raspberry Jams and things
23:03
have an easier way of getting access to being able to run workshops doing this kind of thing, the physical computing GPIO stuff. And so one of the ones to go onto was the idea that you could use this kind of interface, this simple interface, this Pythonic API, and these different programming paradigms
23:23
that have been provided for the different ways of accessing and describing what is going on in your system that could be used elsewhere, regardless of how it's implemented. You could provide something like a garden light class, which control the actual physical light in your garden
23:42
attached to, say, a motion sensor and a light sensor. So here's an example where we use the combining source to all values to say, well, take the negated light values, so it means read it whether that is dark. And so when there's darkness and motion, both darkness and motion, then the garden light should be on.
24:04
And that's just a one line thing describing the behavior of that system. But you could write it using one of the other paradigms as well, the idea that it doesn't matter how you talk to your garden light or your light sensor or motion sensor,
24:20
but that implementation could just be within the class, and you provide these. As long as you provide like Blue Dot, as long as you provide the API that GPIO devices have, so the value, the values, the source, the is pressed and when pressed and all that kind of thing,
24:43
then you have the ability to write code like this. So there's a series of devices you can get with Z-Wave controllers, they're called, that a lot of people have increasingly in the home for controlling various things around their house,
25:01
so things like their alarm system or their irrigation system, scenes in different rooms, the kind of things you get with Hue light bulbs and that kind of thing, smart devices around the home that are on the same protocol called Z-Wave. So you have a server that's on your network and talks to all these devices.
25:24
So a friend of mine has taken the idea of GPIO and this kind of interface and written an AsyncIO implementation of the source values kind of protocol, which means that you can declare in simple Python terms how you want the things around your house to behave.
25:43
So he has rules set up for things like I want the bathroom lights to come on when he's got things like humidity sensors and light sensors and timings and various other things that he just decides how he wants them all to behave in his house.
26:01
The good thing about the AsyncIO implementation is that it's sort of push-based rather than continuous polling. So whereas in GPIO 0, every time a source is set, it's actually running a background thread, so there's lots of threading and message, very simple threads just passing data values around,
26:28
but it just means that they're constantly being sent regardless of whether they've been updated or not. So if you're polling, let's say we had a light switch implementation, it's constantly sending off, off, off, off, off to the lights,
26:42
whereas if you do it push-based, then not until you press the button and change the setting of the light that it sends over the new value. It would be interesting to investigate implementing this kind of implementation into GPIO 0.
27:02
We currently still support, we have Python 2 and Python 3 support for GPIO 0, which will probably die out soon, so we wouldn't be able to use AsyncIO without deprecating that. And also that as AsyncIO has developed and matured over the last few Python releases,
27:26
once we get a stable AsyncIO that will work on Raspbian, on the version of Python that ships with the current version of Raspbian, we'll be in a position where we'll be able to do that, so it'll be something to look forward to in the future.
27:43
So you can find more about GPIO 0 on GitHub, it's on the rpydistro organization, and on readthedocs, so dpi0.readthedocs.io. And just another thing I wanted to talk about, this could be a talk of its own,
28:01
but I've just limited it to just the one slide. Pywheels is another project I've worked on with Dave. It's a Python package repository that automates, builds of all the PyPy releases, so every package, every version of every package on PyPy, we build an ARM platform wheel so that they work on the Raspberry Pi,
28:23
and they're built on Raspberry Pi hardware in the mythic beast PyCloud. A server hosting company has an actual rack of Raspberry Pis. We automate all the builds of all the packages as they come out, and we have a few manual builds, like we build OpenCV ourselves offline and import those,
28:42
and the TensorFlow team at Google are actually providing us with their own custom builds of TensorFlow, so you can pip install TensorFlow on a Pi, and you get it as quick as that. So the problem this solves was that it used to take a very long time to install packages on Raspberry Pi because you had to build everything from source
29:02
because the wheels that are provided are for other architectures. So we natively compile all of these on Raspberry Pi hardware and provide the repository. So there's multiple Pis in the rack that are doing the building, and there's a Postgres database that just keeps up with what has been built
29:22
and what has been attempted, and then provides them all in the repository index. And then there's just one single Raspberry Pi that receives all the requests and just dishes out files as they're requested. It's pre-configured in Raspbian to use this as an additional index to PyPy,
29:42
so obviously when it has a choice between a source distribution from PyPy and a matching platform wheel from PyWheels, it goes for PyWheels, so reduces your install time right down, which is really useful for Raspberry Pi users.
30:01
But that single Raspberry Pi hosting the packages is currently serving around 300,000 to 400,000 wheels a month, and it's holding up really well. And just to finish off, I just wanted to talk about a few of the programs that we run at the Raspberry Pi Foundation. So Raspberry Jams is the name for independently organized community events
30:22
that are held around the world. They're kind of family-friendly events, so they're not just workshops for kids, like the kind of things that people in this room could go along and work on projects or even take your kids along and meet other kind of makers, electronics enthusiasts, hackers and engineers and other programmers and all sorts of beginners as well.
30:44
They're really great fun events. They're a mix of kind of, some of them are like meetups, some of them are kind of more like a conference where they have speakers and talks and presentations. Some of them are kind of, allow you to drop in and do workshops or work on your own projects. So yeah, if you head to RaspberryPy.org, the Jam page has a map and calendar of upcoming events.
31:03
And also Coded Dojo is another program we run which is for under 18 kids, so that's a way that you could join in by volunteering as a mentor and actually help teaching kids in a kind of a youth club to learn programming skills
31:20
across any technology on Raspberry Pis or on laptops using microbits or anything. And if there's no existing dojo in the area you live, they're really easy to set up and just a few people volunteering some time, a couple of hours once a month, something like that would be a great way to provide the kids in your area
31:43
a way to learn some programming skills and get interested in using and learning technology. And finally, I'm presenting a poster just through in the main room there today. So if you want to come and read more about the Raspberry Pi Foundation
32:02
and the Raspberry Pi and Python world and come and talk to me and I'll answer any questions you've got or discuss anything with you. And that's all. Thank you. Thank you so much.
32:20
So we have some time for Q&A. Thanks for the talk. You showed these four alternatives for interacting with the IO pins. Is there any relevant concern about power consumption or any relevant difference among them?
32:43
There will be. I won't say there isn't any, but in my experience, it's not really caused any problems. So I think at one time I noticed there was something running where there was something like 25 LEDs on a Christmas tree
33:01
and each of them had had their source set to the random values, so they all sort of sparkled. Because each one of them was generating random numbers in a background thread and there were 25 of them and it was actually running on a Pi Zero. So it was 700 megahertz, which is the chip that was in the Pi One. So a very, very weak processor compared to what we have with the Pi Three and Three Plus today.
33:25
It worked fine, but if you tried to open a web browser on the Pi at the same time, you'd have really struggled. It would have been eating up a lot of RAM, but you have to do quite a lot to make that work. And it's very simple to refactor the code in that example to run more efficiently,
33:41
just by setting the source to, say, a 26 tuple of random values rather than each of them doing it in their own background thread, for instance. But yeah, it's not really been a problem. I mean, blocking is quite a good way when you've got those while loops. I mean, people do that all the time in projects because it's the easiest way that they think of to have something continuously update.
34:02
So they're constantly checking something, not even putting a sleep in it. It's fine. I think I prefer the blocking way just because it feels like you're just restricting the amount of stuff that needs to happen. But yeah, it's a good question, but not a horrendous concern.
34:21
Some people probably not like the idea of that many threads going on, but they're very, very simple threads. They're not doing loads of stuff in the global namespace or anything like that. They're just having one very small job just to pass messages around. Hi. So thanks for sending us this GPIO0.
34:42
I see that it provides a lot of great structure for the applications for the software on Raspberry Pi. But my question is, as you actually mentioned yourself, Raspberry Pi is quite powerful. And maybe for some users it's too powerful, actually, and using too much power. Do you think that you could possibly run the same library or maybe strip down, for example, MicroPython devices?
35:07
Because this is actually my use case, which I would very like to go with. Yeah. So I'm going to call on Carlos in a minute. So the API to the on the MicroPython API for the micro bit, we kind of there's a group of people that worked on that.
35:29
And I remember in the early days, actually, conversations with Damien George around that API was kind of what led me to towards devising something nicer API like this.
35:43
And that API is quite nice. It's not got some of the features that this has because you don't have the resources available to do the background threading thing. I don't know if MicroPython supports threading, does it? No.
36:04
So you couldn't do some of those callbacks and things. So you will see kids writing MicroPython scripts on the micro bit that are just doing the while loops all the time. And things like the way that we use properties quite heavily. So setting properties is quite, usually you see getters and setters and things like that, even in Python.
36:22
I really, really like being able to use that style to just declare something. So the same way you would set a equals one, I want to be able to say the LED value should be true or should be something like that. So I really like being able to do that as well as use the methods and things.
36:45
But I don't think you can really get away with doing that with properties in MicroPython as well. But I think you can get quite close and you just don't have the luxury of being able to do a lot of that stuff. But yeah, you can make some nice APIs that use some of the beginner stuff that I showed you.
37:06
Thanks. Okay. Thanks a lot Ben. You showed a function in the middle between the inputs and the outputs in effect. And you showed quite simple ones, but presumably you could have really
37:24
complex ones where you're doing machine learning processing or something quite complex. Exactly, yeah. And how complex can you get and still have this stuff working in real time? I mean some of them are more complex in that the Energenie lamp is kind of controlling mains power.
37:46
So actually it's still very simple and you're just turning a few GPIO pins on, it sends a signal to the socket and actually turns. But that doesn't have to be a lamp, that's a glorified LED in a way in that you're just still turning a light on. It just happens to be more powerful, a light, and it's a heat lamp.
38:03
But that could be controlling something more critical like some sort of machinery or something. But I mean there are some really interesting GPIO components that you can use, things like ultrasonic distance sensors. So you could have, if this was the sensor I could be waving my hand in front of it and you can graph the
38:22
value of the distance because it's constantly reading how far away the object is by sending a SONAR pulse and reading the value back. And it just means you can do some interesting things like that, like how many LEDs you light up according to how close you get. Or tell the motors of a robot to stop when they get to a wall.
38:43
There's an example I wrote for Blue Dot controlling a robot. So actually having a little robot with just motors and sensors attached to a Raspberry Pi on wheels on a little chassis. But using the Blue Dot, so you pass in the coordinates of where your thumb is on the dot.
39:00
Pass those in and sort of clamp them and apply a couple of functions, I forget what they were now. Clamp them and scale them I think so that they're in the same thing that your motors. And you're not just passing in go forward and go backwards, you're passing in speeds of the left and right motor. It's still very simple but it's sort of a progression towards showing you what you can do.
39:26
There's all sorts of different electronic components that you can control things like LCD screens and all sorts of different sensors. A lot of the examples are just LEDs and buttons which is the most simple thing to explain it with.
39:44
You can do some really interesting stuff with other components. And you can write your own classes for instance that control something else entirely and use the same kind of API. Coming back to the question of polling versus blocking.
40:03
I was wondering if the Pi's GPIO pins support hardware interrupts and whether you guys have used them or are planning to integrate them. I believe so. I think there's a certain amount of, because it's happening in Linux, you're not talking to a microcontroller.
40:23
So there are system level interrupts. I think that's how they're implemented. I don't touch the underlying libraries really but I believe so. There certainly are ways of doing complete system interrupts at that level. I think we have time for one last question.
40:44
Okay, I think we're fine. Thank you so much.