david_wallis
Posts: 41
Joined: Thu Jul 05, 2012 8:21 pm

GPIO Programming and Interrupts

Thu Jul 05, 2012 8:29 pm

Hi,

I'm new to programming in C.. (normally do programming/scripting in vb.net, vbs and more recently powershell (Can see a windows theme here)

Howevr I've been trying to slowly pick it up since first reading about the raspberry PI as until I heard about them I was hacking a Linksys Router running DD-WRT to get a 'low cost' linux platform with network connectivity.

I have a number of uses for the raspberry pi, but a couple in particular require the use of interrupts on the GPIO's, I dont really want to have a messy infinite loop wasting cpu cycles, so would rather write a daemon that deals with it and just runs a function when a pin either goes high or low...

So I have seen there are some firmware 'patches' to the kernel to enable this, and then dom saying that he would add it, so the question is how the hell do I tell whether I need to apply the fix?

I have done this:

wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && chmod +x /usr/bin/rpi-update
sudo apt-get install ca-certificates
sudo apt-get install git-core
rpi-update

And has anyone got any sample code they could ping across or pass a link to so I can see if get this working further than a few flashing LEDs that I have at the moment :D

Thanks in advance!

david_wallis
Posts: 41
Joined: Thu Jul 05, 2012 8:21 pm

Re: GPIO Programming and Interrupts

Wed Jul 11, 2012 9:40 am

Anyone?

secretagent
Posts: 36
Joined: Wed Mar 07, 2012 10:09 am

Re: GPIO Programming and Interrupts

Sun Jul 15, 2012 3:26 pm

There is an example that works on the pi here: https://www.ridgerun.com/developer/wiki ... int-test.c

david_wallis
Posts: 41
Joined: Thu Jul 05, 2012 8:21 pm

Re: GPIO Programming and Interrupts

Sun Jul 15, 2012 7:22 pm

Thankyou very much I will take a look and see if I can get this working :)

kenters915
Posts: 1
Joined: Wed Jul 18, 2012 2:25 am

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 2:30 am

Does the example work with the newest version of raspbian without any patches (for interrupt support)? Thanks for any help. I would try it myself, but I'm waiting for another SD card to come and am curious.

User avatar
Grumpy Mike
Posts: 886
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 3:16 pm

secretagent wrote:There is an example that works on the pi here: https://www.ridgerun.com/developer/wiki ... int-test.c
You sure that uses interrupts, it looks to me like it just does polling.

User avatar
[email protected]
Posts: 1979
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 3:28 pm

Grumpy Mike wrote:
secretagent wrote:There is an example that works on the pi here: https://www.ridgerun.com/developer/wiki ... int-test.c
You sure that uses interrupts, it looks to me like it just does polling.
The poll() system call waits for an event on a file descriptor. Your program stops running and the kernel takes over, allowing other "stuff" to run until the kernel itself sees the event, then it un-stalls your program and lets it run.

Simples.

There is a degree of latency involved as this is Linux we're dealing with, not some proper "hard" real-time opeprating system, but it achieves a similar effect - letting Linux run other stuff while your program waits for the interrupt.

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
jbeale
Posts: 3350
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 4:04 pm

I'd like to learn more about how I can use GPIO interrupts from C programs on the R-Pi, in general. Is this a good reference, "Linux Device Drivers, 3rd Ed." http://lwn.net/Kernel/LDD3/ or is there any tutorial online which might be more relevant?

User avatar
Grumpy Mike
Posts: 886
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 5:08 pm

[email protected] wrote:The poll() system call waits for an event on a file descriptor. Your program stops running and the kernel takes over, allowing other "stuff" to run until the kernel itself sees the event, then it un-stalls your program and lets it run
So if you have to suspend your program while the kernel handles an interrupt isn't that just defeating the whole purpose of having an interrupt in the first place. It is in my book. Why not simply pole if that is all it is going to do?

User avatar
[email protected]
Posts: 1979
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 5:21 pm

Grumpy Mike wrote:
[email protected] wrote:The poll() system call waits for an event on a file descriptor. Your program stops running and the kernel takes over, allowing other "stuff" to run until the kernel itself sees the event, then it un-stalls your program and lets it run
So if you have to suspend your program while the kernel handles an interrupt isn't that just defeating the whole purpose of having an interrupt in the first place. It is in my book. Why not simply pole if that is all it is going to do?
I don't know - why not? That's up to you - but it all depends on what you are trying to achieve...

e.g. you might have several programs running at once - if one of them were to actively poll via a loop in the program for an IO pin to become a certain value, then it will eat CPU cycles, depriving other programs of those cycles... So, having the program wait on a interrupt will stop that program running, allowing all those cycles to be shared between everything else that's running.

It's a bit of an oddty though - here we are on a multi-user, pre-emptively multi-tasking operating system now - not a little microcontroller like an ATmega where you have everything to yourself - of-course if you're writing just one program to run on the Pi then it's probably no different, but the Pi can do more than that... Or it can allow single program to capture an event smaller than a program mght otherwise be able to detect - the hardware can be programmed to trigger on an egde, so a tiny pulse that a program polling it might miss will be recorded and actioned as soon as possible.

(Although you can capture and poll for those edges without interrupts - the hardware is quite versatile)

So it's one more tool avalable to you.

An example I'm going to do soon is to use it to count pulses from an encoder connected to a robot I'm working on. I will run a separate thread to my main program which will wait for the interrupt and increment a global variable until it matches a pre-set value, then it will turn the motor off and signal the main program.

Meanwhile the main program will be listening for commands via a wireless interface and exchanging other telemetry with the base station..

So you can get awy from the whole "big loop" type of programming for these sorts of things by creating lots of autonomous and asynchronous tasks.

Although that in itself can sometimes be a challenging thing to comprehend - however at least you have the tools to-hand!

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4247
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 6:26 pm

If your program is well behaved and waits on interrupts and doesn't take huge swaths of time, you can wack its priority all the way up to Real-Time and make it highly reponsive. If you tried that with a big loop program you'd hang the machine and none of the infrastructure would work. Your polling routine only works while the program has a timeslice; it will be less responsive than if you made it interrupt driven.

User avatar
Grumpy Mike
Posts: 886
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 8:27 pm

OK so turning back somersaults you might have a legitimate use for this pseudo interrupt system but it is not a real interrupt is it.
A real interrupt will allow interaction asynchronously with the main foreground task. At it's simplest to change a variable on the fly being used by your main program. You seem to be confusing the ability to detect edges which you can easily do with the latch system with the need to actually interrupt the processor.

It seems like you are forever making excuses about this system and why it can't do the simplest of things because it is doing all this stuff that you don't want at the same time.

This is yet another disappointment / disillusionment with this system. Maybe Linux was a mistake in the first place for a system with GPIO capabilities.

User avatar
[email protected]
Posts: 1979
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 9:35 pm

Grumpy Mike wrote:OK so turning back somersaults you might have a legitimate use for this pseudo interrupt system but it is not a real interrupt is it.
A real interrupt will allow interaction asynchronously with the main foreground task. At it's simplest to change a variable on the fly being used by your main program. You seem to be confusing the ability to detect edges which you can easily do with the latch system with the need to actually interrupt the processor.

It seems like you are forever making excuses about this system and why it can't do the simplest of things because it is doing all this stuff that you don't want at the same time.

This is yet another disappointment / disillusionment with this system. Maybe Linux was a mistake in the first place for a system with GPIO capabilities.
Hey Mike,

No need to be so grumpy!

Linux isn't perfect for GPIO, but it's fine for the stuff we need to use it for on the Pi - ie. getting people back into poking at the hardware at the real bits & byes level!

However, It is a real interrupt. It can allow interaction asynchronously with the main foreground task, it's just that the mechanisms involved are not the same as the mechanisms applied to an old Beeb or ATmega.

I'll post some examples here soon as I'm working on an easy to use extension for my wiringPi library, but hang in there - your breakout borad is a great little project which I want to build myself - looking forward to the old Mike Cook articles again!

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4247
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 9:40 pm

Sorry Mike but it sounds like you want a microcontroller or at least a bare-metal OS.

The task is blocked until the interrupt happens and is then marked as eligible to run by the interrupt routine, and if you have the privileges set right then it runs as soon as the interrupt routine exits. Literally the return from interrupt may very well be to your task. It has all the advantages of a real interrupt and all the advantages of user-mode code and only increased latency as a disadvantage.

If you need absolute minimum latency, then yes you may need to write a kernel-mode driver. And be careful about scribbling all over everyone's code-space, and have a whole lot harder time debugging it, and separate your program into foreground and background within the driver model, and worry about re-entrancy and how much time you are stealing from the HDD and Ethernet drivers, etc. etc. But your program will only see that variable you set when it next runs, which might be many microseconds after your optimised interrupt routine has set it. So you still need a high-priority task, and now it is taking precious CPU time from the other tasks. Or your interrupt routine implements a queue of events and your program picks them up at its own pace, which still gives you increased latency.

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: GPIO Programming and Interrupts

Wed Jul 18, 2012 9:52 pm

I think you will have two main groups of people using the R-PI, those that want to turn it into a media center or desktop and those that want a real-time device.
Linux is well suited to only one of theres groups, that's why you have the bare metal sub forum.

Most of the posts i have read by Grumpy Mike, i agree with and the grumpy part may come from living in Manchester.
We are always under a black cloud :( .
Batteries not included, Some assembly required.

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4247
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 7:09 am

There are many sorts of real-time. Within the strict meaning of the term, a web server is a real-time application. Real-Time is defined as any application with a constrained response time, be that an hour or 10ns. Bare metal is not the way to go for a (L)AMP stack of course.

Linux is a good solution for real-time down to about 100ms, and with care it could be used down to maybe 10ms. There are solutions such as RTLinux that will take it down to around 200us. A bare metal OS with a scheduler, USB and Ethernet stacks would go down to maybe 1us. A dedicated bare-metal application might manage to get down to 100ns. Below that you need an FPGA.

There are a great number of applications that require real-time responses no faster than 10ms, including almost all of the user interface and control scenarios, and for those Linux is a perfectly adequate solution. If you want to do something like controlling the speed of an electric motor to within 1rpm under rapidly varying load, then you need RTLinux. If you need to do signal processing then bare metal is the way to go.

(RTLinux is probably not available (yet) for the RaspPi.)

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 1:01 pm

rurwin wrote:There are many sorts of real-time. Within the strict meaning of the term, a web server is a real-time application. Real-Time is defined as any application with a constrained response time, be that an hour or 10ns. Bare metal is not the way to go for a (L)AMP stack of course.

Linux is a good solution for real-time down to about 100ms, and with care it could be used down to maybe 10ms. There are solutions such as RTLinux that will take it down to around 200us. A bare metal OS with a scheduler, USB and Ethernet stacks would go down to maybe 1us. A dedicated bare-metal application might manage to get down to 100ns. Below that you need an FPGA.

There are a great number of applications that require real-time responses no faster than 10ms, including almost all of the user interface and control scenarios, and for those Linux is a perfectly adequate solution. If you want to do something like controlling the speed of an electric motor to within 1rpm under rapidly varying load, then you need RTLinux. If you need to do signal processing then bare metal is the way to go.

(RTLinux is probably not available (yet) for the RaspPi.)
Yes, i know real-time does not mean fast, but real-time OS's must be able to guarantee that within a time frame to service a request.
Linux can not do that within a time frame that would be needed for a lot of tasks.
Which is the other half of the user base i mentioned above.
Theres nothing wrong with linux its a great OS, i use it 95% of the time, but no OS or type of OS is a best for everything solution.
Or would you like linux on your ABS ?.
Batteries not included, Some assembly required.

User avatar
[email protected]
Posts: 1979
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 2:18 pm

OK. s promised I've got something now into wiringPi to help handle interrupts in user-land. These are real interrupts, your main program can run away and the interrupts are delivered asynchronously to the function that's running concurrently with your main program to handle interrupts.

it's not quite the same as we'd do it in bare-metal land, but it's about as good as it can get in Linux land - without going to the effort of having a "proper" hadd real-time kernel. I've not yet put together a release of wiringPi with it in, (later tonight) but I have a demo program for you to have a look at here:

http://unicorn.drogon.net/wfi.c

The key points are that the function waitForIt is run concurrently with the main program - that function then calls the waitForInterrupt() routine and this stalls until the interrupt is delivered - the kernel deschedules the task, allowing the main program to continue (in it's infinite loop, waiting for the counter to change). When the interrupt happens, the main task is interrupted and the waitForIt function is allowed to run. This is a true asynchronous interrupt of the main program.

If you run it as root, then the piHiPri() function will work too (otherwise it's ignored) and the waitForIt function will run at a higher and real-time prirotiy guaranteeing that nothing will interrupt it while it's running (unless those tasks are running at an even higher priority)

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4247
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 5:04 pm

DexOS wrote:Or would you like linux on your ABS ?.
For robustness reasons, no; there's far to much going on in Linux that is not mathematically proven, but that is another argument. However on a pure real-time basis, then yes I imagine Linux could cope.

The circumference of a wheel is about 1m. At 100mph that's 44 revolutions per second or one every 22ms. I don't know how many pulses per revolution the sensors generate, but it isn't likely to be many. So 1ms response should be sufficient even if you wanted to catch the raw sensor pulses and that is probably achievable with great care and an almost bare machine. But almost certainly in all existing systems the sensors capture the speed of each wheel; that's just a counter counting pulses. It is even possible to make the sensors a little more intelligent so that they detect and latch slip. Ultimately you would only need to detect slip fast enough to apply the brake-pumping function and that is only around 10Hz as anyone who has felt them operate could attest. 10Hz is easily achievable in Linux. You could wind it up to 100Hz and have a complex algorithm with varying profiles of brake activation, so the brakes were applied gently until they detected slip and then backed off, but simpler is probably safer.

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 6:15 pm

I'm interested in interrupts but might settle for polling. My balancing robot will need to check its posture about every 7ms so the question for me is:

Should I have one big infinite loop which gathers info from all the sensors and then makes decisions based upon that data, or can I have interupt driven sub-routines that take care of dedicated tasks as they are required.

I'm not familiar with the Pi's architecture, but I suspect that any interupt driven approach relies on an underlying infinite loop aka the kernel, which might be a false economy if I intend to eventually migrate my code onto the bare metal.
Ostendo ignarus addo scientia.

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4247
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 7:18 pm

There is no infinite loop in the kernel; the "interrupts" will be implemented with real interrupts.

If you have an infinite loop, then either it runs at normal priority and you miss stuff while other processes are running, or it runs at high priority and the rest of the machine hangs.

I would design that robot with three levels and three tasks.

The first (foreground) task would wait on the really important events that need handling with minimum latency. So edge trigger the inputs and poll for all of them in one place with a big switch statement after the poll. Then wrap that in an infinite loop and put the priority up to Real-Time.

The second task would also run at real-time priority and would sleep for maybe 10ms and then do a few ms of testing and reacting to inputs which were not so urgent.

Finally the third (background) task would run at normal priority and would handle the stuff that does not require a hard real-time response, including the human interface and such.

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4247
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 8:50 pm

When I said the foreground task should poll I meant it should use poll(), ie it should suspend waiting for the OS to trigger it.

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 9:42 pm

I cant see how that's possible without an overseeing program to allocate prioraties that's running all the time?

What am I missing?

Is it to do with the Pi having a CPU and a GPU ?

Surely otherwise if it has one processor it can only truely do one thing at a time...?
Ostendo ignarus addo scientia.

User avatar
[email protected]
Posts: 1979
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 9:56 pm

pygmy_giant wrote:I cant see how that's possible without an overseeing program to allocate prioraties that's running all the time?

What am I missing?

Is it to do with the Pi having a CPU and a GPU ?

Surely otherwise if it has one processor it can only truely do one thing at a time...?
Yes, it can only do one thing at a time and if it decides to do that thing for more than 7mS then your robot is going to fall over.

I'd still use a separate controller for a balancing robot - I really think you're going to struggle with Linux on the Pi - even running your program at a high/real-time priority - it'll just take something else to slow it down just a little bit and it's game over. There's lots you can do to help it, but there is still going to be that fear of something just taking a bit too long...

You may get somewhere with the "proper" real-time versions of the Linux kernel, but even then, I'm not sure.

What I do know from my multiplexed 7-segment LEDs is that running a process at a high/real-time priority is still going to be prone to the occasional interruption - I saw the display flicker from time to time, indicating my high priority routine was being interrupted by something higher priority, or the kernel was doing something it thought it needed to.

an interrupt every 7mS ought to be do-able though - most of the time...

I will benchmark the response time in my interrupt handler system above - once I've worked out just how - it might invovle a 2nd Pi toggling a GPIO pin...

-Gordon
--
Gordons projects: https://projects.drogon.net/

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: GPIO Programming and Interrupts

Thu Jul 19, 2012 10:03 pm

That would be much appreciated!

I am intending on using linux as only an intermediate solution before hopefully going bare metal....
Ostendo ignarus addo scientia.

Return to “C/C++”

Who is online

Users browsing this forum: No registered users and 6 guests