I’ve decided to start to use the GIT Source Code Management system… So hoe better to learn about it than to jump in at the deep end and actually use it for a project… So to that end, I’ve moved wiringPi to it and setup some simple hosting for it – mostly for my own convenience, but also to allow others who’re using GIT to quickly obtain updated versions and so on.
I’ll eventually be putting links from the main downloads site I’m using to the GIT repository, but until then, a quick look and it can be found here.
One of the issues on the Raspberry Pi is that I’m now seeing a lot of people coming to it from a traditional microcontroller background and trying to use the same ides on the Pi as they use on the microcontrollers – and promptly falling into a trap, or getting wildly unexpected results.
One of these areas is timed-delays. On a microcontroller, you can often simply loop for a number of times and get the result you desire… On the Pi, your program can be pre-emtively interrupted by Linux doing something else, it can be stalled by the GPU accessing memory and probably several other things. So timing loops in software is generally not that useful (Not to mention the CPU usage they consume – again, not an issue on a microcontroller without an operating system, but under Linux, it’s wasteful if you have something else to do!)
So… Linux provides a standard set of system calls – the issue is that you have the overhead of calling them – and that overhead can be quite variable, it depends on the system call and what it needs to do. The standard delay call, nanosleep(2) will sleep for at least how long you tell it, plus any operating system overhead and that comes to at least 20 to sometimes over 100 microseconds.
So.. when we need accurate short delays in the order of microseconds, it’s not always the best way, so to combat this, after studying the BCM2835 ARM Peripherals manual and chatting to others, I’ve come up with a hybrid solution for wiringPi. What I do now is for delays of under 100μS I use the hardware timer (which appears to be otherwise unused), and poll it in a busy-loop, but for delays of 100μS or more, then I resort to the standard nanosleep(2) call.
A quick look at the wiringPi code to see what I’m doing:
I’m using the count-down timer and polling for the IRQ event (it doesn’t generate an IRQ, we’re just polling for the completion event here) This avoids any issues with having to take into account counters that wrap over.
This isn’t perfect though, and it can still take longer than we want it to, but for small delays it should be a lot closer to what we want than just calling the standard nanosleep(2) routine.
This will be in the next version of wiringPi which I’ll publish in a day or 2.
I recenty ran a 2-day course for someone who was keen to learn more about Linux, C and the Raspberry Pi.
Teaching isn’t new to me, I’ve run courses on my telephone systems, various aspects of Internet operations for people like web design companies and even used to teach something called Engineering Computing during my years at Napier, so to run a 2-day course in my office wasn’t hard and turned out to be a very rewarding experience for both myself and my student!
So what did we do? Started with getting more to grips with the Linux command-line, the use of pipes and redirection. Demonstrating that programmers are lazy (ie. command and filename completion!) We then went on to look at C programming. My student had been doing some C already, but wanted to learn a bit more. Variable scope – the difference between local and global variables. Static variables and so on. We moved on to separate compilation and linking files together – how we can use header (.h) files to give the compiler “hints” about how to call a function in another file.
We also moved on to some of the wiringPi functions too. Talked about concurrent programming and had a brief introduction to threads (with the simplified thread library inside wiringPi).
So a very worthwhile 2 days – it’s always good to share knowledge and meet more like-minded people too, and I’ve just sent my student some homework 😉
Hot on the heels of the PiFace, to add to my collection of Raspberry Pi interface boards comes the Mini PiIO Protoboard from DTRONIXS.
Photos
Mini PiIO Protoboard
Ladder game built on Mini PiIO
Top photo is the base board sitting on a Raspberry Pi, the 2nd one is the board made up with a minature version of my Ladder game.
First impression
It’s tiny!
It sits directly on-top of the Pi on the GPIO connector. The other end is sort of floating in space and like the PiFace, I’d strongly suggest putting some sticky-backed foam or felt pads to stop the board shorting out anything on the Pi (Which it did once when I was building this project on it, fortunately only rebooting the Pi…)
Kit and Assembly
It came as a kit of parts, PCB, GPIO connector, the 2 long edge connectors, a short 5-pin connector and some surface mount components to make up an independent 3.3v regulator fed off the Pi’s 3.3v supply.
Assembly was strightforward, although I did solder on the additional 5-pin connector, then realised nothing actually connects to it, and it stops the little breadboard from fitting, so had to unsolder and remove it.
The long pins down each side carry almost identical signals… Starting at the end furthest away from the GPIO connector, there is 5v, 0v, GPIO pins 17, 18, 21, 22, 23, 24, 25 and 4, then 0v and 3.3v. After that the 2 sides are different – the side nearest the edge (SD card) carrys the serial and I2C port pins and the opposite side carries the 5 SPI interface pins.
One thing I really like about the board is that the GPIO pins are actually labelled 0 through 7 – and they correspond directly with the wiringPi pin numbering scheme!
The 3v connections can be jumpered to come from the on-board regulator or the Pi’s own 3.3v supply.
And a little note about putting the breadboard on – it comes with a sticky-back, but if you are careful, then you can align the holes in the bradboard with the edge connectors, then it’s possible to plug in some DIL chips directly into the GPIO pins which may save a little bit of wiring.
Using it
As a quick experiment, I assembled a miniature version of my ladder gameusing a 10-segment LED bargraph display chip and assembly was quick and straight forward – the original used 12 LEDS but I only had 10 LEDs in a convenient package, so had to modify the program a little.
Conclusion
So if your after something to help you quickly get a few LEDs and switches going, or to experiment with a single DIL chip interface, then this little board is certainly one to look out for! It makes the main 8 GPIO signals easily avalable on both sides of the board with power and ground on both sides too which can make wiring signals to either side relatively easy.
The separate 3.3v regulator can be used to take some of the load off the Pi’s 3.3v supply – probably essential if driving something that’s going to take more than a few 10’s of mA.
Other than putting some sort of isolation between it and the Pi, the only minor issue I have with it is that like the PiFace board, it won’t fit into the SKPang cases I’m using although I’m pretty sure I could modify the pillars on the SKPang cases to take one, other than that it’ll very probably be the first protoboard I’ll reach for when trying out something small.
PiFace is a peripheral IO device for the Raspberry Pi. It was announced at the recent Cambridge Raspberry Jam event so I bought one for the princely sum of £30.
It’s designed to fit on-top of the Pi and has an identical footprint with cut-outs to accommodate the Composite video, Ethernet and USB ports. It takes 3.3v and (optionally) 5v from the Pi itself, although there is provision for a separate supply to power the output relays and buffers. While the driver chips will support up to 20V, the relays are designed to only run at 5V, so the external supply needs to be 5v. My board was not fitted with this socket.
Photos
View of the PiFace fitted onto a Raspberry Pi
Top View of the PiFace fitted to a Raspberry Pi
These photos show the PiFace fitted to a Raspberry Pi. The 9 screw terminals at the bottom/front of the photos are the output pins (Power is the pin on the left), the 2 sets of 3-way screw terminals are the relay outputs and the set of 9 at the top/back are the inputs with 0v being the one on the left, closest to the composite video output.
The PiFace leaves all ports accessible on the Raspberry Pi itself, with the obvious exception of the GPIO port. It uses power and the SPI bus on the GPIO only. It does not make the other GPIO pins available for use.
2 of the outputs are connected to relays which are capable of switching 10amps and 230volts… That’s a 2Kw load however I would not personally like to try to switch anything close to that with those little screw terminals.
Fitting
The PiFace itself is supported only by the large capacitor on the Raspberry Pi board as well as the GPIO connector. If you were to exert a little too much force on the PiFace, it’s possible you may damage the capacitor and also short circuit some of the PiFace’s pins on the HDMI connector. One of those sticky felt pads on the PiFace at the location of the HDMI connector is helpful.
It’s probably not recommended anyway, but do not try to fit the PiFace to your Raspberry Pi when the Pi is turned on – they do it in one of the videos but it caused my Pi to reboot – presumably due to a power spike going through the board.
What You Get
PiFace gives you 8 buffered input pins (with 4 switches on-board connected to 4 of these pins), and 8 buffered output connections. 2 of the output connections are connected to mechanical relays.
You can use the 2 buffered outputs in parallel with the relays, but they will obviously click on/off when you use them. The relay outputs have an LED wired in parallel with the relays and there are 2 other LEDs on the output pins, so with the 4 buttons and 4 LEDs (with the relays clicking away), it’s possible to do some very simple experiments right away.
GPIO
The GPIO is handled by an MCP23S17 SPI/GPIO interface chip. This provides 16 general purpose IO pins with the PiFace dividing them into 8 inputs and 8 outputs.
The Input pins have a 330Ω series resistor and the MCP23S17 is capable of applying internal pull-up resistors making it easy to detect signals that pull to ground such as simple switches without any additional components.
NOTE: Like the GPIO on the Raspberry Pi, the MCP23S17 is a 3.3v chip. Do not attempt to connect it to systems generating more than 3.3v outputs.
The outputs are driven via a standard ULN2803A darlington driver chip.
There is no support for the interrupt capability of the MCP23S17 although this could be achieved by soldering a wire from its interrupt output pins to 2 of the Raspberry Pi’s GPIO pins.
Software
There isn’t any 🙁
At least none that I could find, other than references to a new SPI driver for the kernel, and as I’m using one of Chris Boot’s kernels with his SPI driver installed, (which I think is now back-ported to the official kernel released by the foundation), so I didn’t think there was much point pursuing that line of attack… So armed with the circuit diagram, the MCP23S17 data sheet and some time, I wrote a version of wiringPi to work with the PiFace board. Details here including a software library and demonstration program.
Conclusion
It’s a nice little board. Relatively easy to use, but with no software supplied, could be quite daunting to use! Hopefully someone will produce and publish a Python, scratch, etc. libraries to enable it to be used easily, but until then, there’s wiringPiFace.
I’m somewhat disappointed that there is no way to disable the 2 on-board relays. I wanted to drive 8 LEDs and detect a switch with it to hopefully use it to drive a copy of Mike Cooks Magic Wand the buzzing from the relays is too much to bear and I really don’t want to un-soldering them, so a couple of jumpers would be handy on the next revision…
I feel that the inputs could have been handled better – especially for something intended for classroom use – with e.g. opto-isolators to allow for a range of input voltages from 3 to 12v for example. That would make it much more robust and versatile in a classroom environment… Probably add to the cost, and possibly board size too though, so I can see where a compromise may have been made, however the MCP23S17 is socketed and replacements cost under £1 in the UK.
Also, the circuit diagram shows 2 jumpers that are not fitted to my board – they are attached to the chips address-select lines. The manual for the MCP23S17 says that these pins must be strapped either way, even if they are not being used, so I soldered on some 0.1″ headers and put on a couple of jumpers. I’m hoping this is just an oversight on my early production board… It’s also hard-wired to the Raspberry Pi’s first SPI chip select output – again, a jumper would have been nice, but given that you can’t connect anything else to the Pi when this is connected it’s probably a moot point.
And the inability to connect anything else to the Raspberry Pi’s GPIO connector is somewhat frustrating. I can’t use the PWM output, can’t use the serial port, can’t use the I2C port, nor can I use any of the other GPIO ports that the Pi provides. Maybe one day we’ll see some sort of stacking “shield” arrangement like Arduinos have, however…
The mounting is a little flimsy, I’d like to see a proper spacer pillar in the underside of the board, just to stop it wobbling, although even a sticky-backed felt pad over the HDMI port would be a good start.
I feel it is much less capable than the Gertboard, but at the same time it’s also much simpler and might just be the thing to enable some easy control applications for demos, and even with the 2 relays the ability to drive some low-voltage motors – that combined with its size might just make it a good little board for a floor-crawler robot of some kind. A control board for my PiTrack project? Now there’s a thought…
I’ll put up another article or 2 if I have time about the Cambridge Raspberry Jam event held on the 14th of July 2012… However…
One of the things that struck me was a comment from Eben that he had a box of 200 Raspberry Pis (for sale) and he noted how easy it was to carry it and made a comment about the potential computing power.
It struck a note with me, as some time back (1988-1995!) I worked for a UK based supercomputer company called Meiko Scientific and one of the projects I worked on was a 256-node supercomputer installed at the Lawrence Livermore National Laboratories in California… (It was one of Meikos CS2 units – Computing Surface mk 2)
This is a picture of that Supercomputer, which at the time was the fastest supercomputer on the planet:
The Meiko CS2 at LLNL
Now, without knowing what you’re looking at, it’s hard to get an idea of how big that is… The cabinets are 2 metres high. The whole is arranged into bays of 3-module widths (4 bays) and 2-module width (the smaller one on a diagonal in the middle). It’s that big “L” shape due to the nature of the cabling between the modules – it goes diagonally under the floor. (The middle sections of each bay is a set of network switches) The stand-alone black boxes are RAID arrays with (from memory) 20 x 4GB drives each.. (they were later moved inside some of the modules, but at that time the mechanicals weren’t in-place)
This was 1993/1994 or thereabouts.
Inside that, amongst other things are 256 compute nodes. 4 to one of the smaller modules that you see. Each smaller module is rated at up to 1 KW in power consumption terms. Those compute modules were about 14 inches square and contained a dual-processor sparc at 66MHz and 128MB of RAM. It ran a variant of Solaris. It booted over the network, but each node also had a local 1GB SCSI drive. (There was an additional control bus and “stuff” associated with that to give us node control like power, monitoring and console which added a little to the board, as well as the high speed data network)
So think about that for a moment… A single Raspberry Pi is probably faster than each of those sparc boards. (and at 700MHz vs 66MHz, it’s a lot faster!) The Pi also has double the RAM. The CS2 boards did have a blisteringly fast (for the time) communications network – 750Mbits/sec with a very low latency between nodes. A lot faster than the Pi’s max. of 100Mbits/sec. into a switched Ethernet network, however I could build an equivalent “supercomputer” based on 256 Raspberry Pis, put it under my desk and power it from a 13A socket. And that’s just using the ARMs – not even thinking of the GPUs…
Still – it’s somewhat interesting to think that Eben can carry a box of 200 Pi’s representing something that 20 years ago was simply incomprehensible to think about at the time.
(Minor update to change network speeds to bits/sec!)
Chatting as you do about “stuff” on the Raspberry Pi, someone on the #raspberrypi IRC channel mentioned LEDs and driving them. Subsequently someone else on the raspberrypi.org forums was asking about then too… And so another little project was born…
So off to my (now usual!) online store, SKPang and a 4-digit, 7-segment display module found its way into my order. (Actually, since it has decimal points, then technically it’s an 8-segment display, but for some reason they’re always referred to as 7-segment displays!)
Raspberry Pi with 7-segment LED display
There are many strategies for driving 7-segment displays – I’ve chosen to use one of the lower-level ones, doing more in software than in hardware to keep the hardware design simple – so as you can see here, it’s almost as simple as it can get. We have 8 GPIO outputs going to the 8 segments of the display (white + yellow wires) and 4 GPIO outputs going to the individual digits common line. (the black and green wires) This is a common anode display, so the anodes of each of the 8 LEDs in a digit are connected together.
To drive the display, we start by setting all GPIO pins to outputs, set the 4 digit GPIO pins to logic zero and the 8 segment GPIO pins to logic 0. Now we need to light up the display one segment at a time…We do this by selecting the digit and driving it’s common connection to logic 1 (this is the common anode), then drive the segments one at a time to logic 0 to illuminate them, pause for a brief period of time (I’m using 500 μS here), then turn it off by setting it to logic 1 and moving on to the next segment. 4 digits, 8 segments per digit, 500 μS per segment means that the total scan time will be 16mS, or just over 60 times a second. That ought to be fast enough to eliminate flicker.
To increase scan frequency, we could light up more than one segment, but as they are all going via the same resistor then the segments will get dimmer the more we turn on… To prevent this, we could use 8 resistors, however then the combined current of 8 GPIO pins being fed from one GPIO pin would be too much for the Pi’s SoC. We could then use a seprate drive transistor to boost the current, but we’re trying to keep things as simple as possible here…
So, we illuminate each segment of each digit in-turn and if we do it fast enough then our persistence of vision will fool us into thinking they’re all turned on all the time.
So now we have a problem… How do we scan through the segments fast enough while at the same time allowing our program to run? And, what happens if, while scanning the segments, Linux decides to go off and so something else? (Linux is a pre-emptive, multi-tasking, multi-user operating system, after-all!)
This is when we really need a real-time operating system, and while there are some patches to the Linux kernel, they’re not standard in the Pi kernels, and even if they were, they still might not be suitable for use here – to do it “properly” really does require very tight control over the hardware, interrupts, peripherals and so on, and I am not convinced that Linux will give us all that control.
However, there are some simple things we can do to improve things – to the point of making a task like this relatively easy and do-able.
This first thing we can do is tell Linux that we want to have a higher scheduling priority and that we want to be considered for real-time scheduling too. We used the sched_setscheduler() system call to effect this. It’s not perfect – a higher priority process can interrupt your program (and if you want to maintain things like keyboard entry and allowing other programs to run, then you must allow this!) but it’s a good way to give your program a good boost.
The other thing we can do is to use Posix Threads and run what’s effectively a 2nd program concurrently with your main program, and have that 2nd program (although it’s actually a function inside your main program rather than a 2nd program) manage the LED updates.
As long as the LED display routine calls delay() every now and then, then the rest of the system will carry on which the display is kept updating. (It can use other methods to de-schedule itself, but calling a wait function is easiest – I actually call delayMicroseconds() in the display code).
All that remains is to establish a way to communicate between our main program and the display routine and I use a simple global variable here: A string array which I can write to in the main program and read from in the display routine – we don’t need any fancy locking, etc. for something as simple as this.
Even after that, setting the real-time priorities and running the separate display thread, I still see the occasional flicker or glitch on the display. It’s probably no real issue for a display, but imagine if we were driving a stepper motor… One reason I still maintain that Linux is really not the right tool to do that form of “hard” real-time control, but for LED displays? it’s OK.
Any down-sides? Well the overhead of keeping the display updated is between 15 and 20% of the CPU usage on my Pi! So it has to be said that the Raspberry Pi really isn’t the right device to be driving such a display, but it’s good to know that if we had to then we can.
And I’m sure some of the tricks in my program will be useful in other applications. You can find the software here.
So after a conversation on IRC where the general gist was that apache was bloated and slow vs. lighttpd, I thought I’d try a little experiment today – see how long it might take to compile up Apache, PHP and MySQL and get it going on a Raspberry Pi… Then stick a wordpress on it.
(And in-case you found this looking for a comparison, sorry – I don’t have one, lighttpd may well be smaller & faster than Apache, but I’ve not done any tests myself – I was just interested in how well or badly my “usual” apache/mysql/php setup I employ on my server fared on the Raspnerry Pi)
So I decided to compile them from sources – which is what I often do anyway rather then use the Debian supplied versions – mostly to see how long it would take doing it that way, but also to try to only compile in the modules/features, etc. that I needed – hopefully to make it as “lean” as possible while still maintaining enough functionality to run WordPress.
My Pi was running Raspbian with a 3.2.21 kernel, and the memory split at 244MB.
Versions of the “AMP” stack are: Apache: 2.2.22, MySQL: 5.1.61 and PHP: 5.3.10.
MySQL took some 2.5 hours to compile and resulted on about 260KB of swap being used. Apache was a bit quicker at 1.5 hours, but surprisingly it used a little more swap – up to 680KB. The configure and compile for PHP took it up to nearly 900KB. (however I did start up MySQL during this phase to finish the installation of it, but shut it down once I’d finialised the installation)
Watching the system with ‘top’ while it was compiling, it seems the GCC compiler doesn’t really need much more than 60-80MB of RAM, so the few little things that got swapped out are really just making more buffer space – so I imagine the compiler and associated programs stay cached in RAM for the duration while will speed things up somewhat. The bottleneck really seems to be the CPU, so I doubt putting the files on USB drive, NFS, etc. would make any difference to it all – the system runs at >95% CPU running gcc for a good few minutes for each file, so optimising the few seconds of disk IO doesn’t really seem worthwhile.
Typical of top during PHP being compiled:
KiB Mem: 222744 total, 185080 used, 37664 free, 10000 buffers
KiB Swap: 131068 total, 868 used, 130200 free, 71484 cached
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND
14053 root 20 0 83580 73m 6904 0 R 98.1 33.6 3:00.28 cc1
The whole process is very reminiscent of installing the LAMP stack on an older server – a PIII/800MHz many years ago. (And I had about the same amount of RAM then too!)
… Some time later and it’s running.
And so what can I say… It’s slow. I’ve tweaked the apache config somewhat and it’s still slow. What makes it slow… It seems to be a conbination of lots of things – PHP is quite large, so that eats up some RAM. MySQL likes to do fflush() operations which make the underlying filesystem somewhat slow. (however using phpMyAdmin on the server was OK, so maybe wordpress really is a bit big and bloaty afterall!)
Next week (if I have the time and enthusiasm!) I’ll start to try some of the newer servers and configurations and so on… Watch this space, but don’t hold your breath!
Thanks to Keith Wright for diligently testing it and pointing out bugs for me – fixed some issues in the gpio command, and while I was at it, I added in 2 new functions to it to allow for easy exporting/unexporting of the /sys/class/gpio interface – so now you can write a little script to do the exports for you, then run your own program that uses that interface (e.g.) a Python, shell, or php script, then un-export them afterwards, all without needing to be root (or use the sudo command)
