Jonvii
Posts: 15
Joined: Fri Apr 07, 2017 11:06 am

Hardware interrupts using C

Sat Apr 15, 2017 1:53 pm

Hi everyone,

I'm trying to program an interrupt when an INPUT GPIO event have occurred without using the OS. I know how to detect that event but no how to try it.

I have this ideas:
- When i press the button of my circuit attached to INPUT GPIO 17 pin, i detect this event with GPEDS register (Physical address 0x3F200040).
- The ARM base register is in the 0x7E00B000 virtual address.

I have clear that i need to configure from this adrress. But how i could do it?

Thank you.

User avatar
joan
Posts: 15971
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Hardware interrupts using C

Sat Apr 15, 2017 2:55 pm

Under Linux interrupts are handled by Linux.

Will you be using Linux?

Jonvii
Posts: 15
Joined: Fri Apr 07, 2017 11:06 am

Re: Hardware interrupts using C

Sat Apr 15, 2017 7:38 pm

joan wrote:Under Linux interrupts are handled by Linux.

Will you be using Linux?
Hi joan,

Yes, i'm using my Rasperry Pi under Raspbian. I can't handled interrupts directly without using OS?

Thank you for your reply

User avatar
joan
Posts: 15971
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Hardware interrupts using C

Sat Apr 15, 2017 7:52 pm

Linux handles GPIO interrupts. You can ask for your userland process to be notified after the interrupt has been handled by Linux. Typically your userland process will be told between 50-100µs after the interrupt.

Typically you would use the C system poll() function to be notified about GPIO events.

I think the bcm2835 library might use/may have used the EDS register at one time.

http://www.airspayce.com/mikem/bcm2835/

steven1977
Posts: 89
Joined: Fri Sep 02, 2016 7:39 am

Re: Hardware interrupts using C

Sun Apr 16, 2017 7:08 am

i've heard that sometimes the raspberry doesn't react that fast on interrupts and that it lags in some cases up to 500ms.
Anyone else heard this problem?
Visit my blog : https://pirobotblog.wordpress.com

User avatar
joan
Posts: 15971
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Hardware interrupts using C

Sun Apr 16, 2017 8:21 am

steven1977 wrote:i've heard that sometimes the raspberry doesn't react that fast on interrupts and that it lags in some cases up to 500ms.
Anyone else heard this problem?
500ms would be pretty exceptional but is certainly possible, I have heard of 1000ms+.

You are talking about very rare events, perhaps one in a million interrupts (of that order at least, I don't have any stats to hand).

User avatar
gordon@drogon.net
Posts: 2024
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK

Re: Hardware interrupts using C

Sun Apr 16, 2017 8:48 am

steven1977 wrote:i've heard that sometimes the raspberry doesn't react that fast on interrupts and that it lags in some cases up to 500ms.
Anyone else heard this problem?
Part of the issue is that you're just saying "the raspberry". The issue is that it's a complex beast. Do you mean the hardware or the Linux kernel, or getting a signal from the hardware through the kernel to your userland code, or are you using bare-metal, another Operating system, or... ?

So rather than just post speculation/rumours/FUD, can you give an example of what it is that you're actually looking to do with the Pi?

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

User avatar
PeterO
Posts: 6095
Joined: Sun Jul 22, 2012 4:14 pm

Re: Hardware interrupts using C

Sun Apr 16, 2017 9:01 am

joan wrote:
steven1977 wrote:i've heard that sometimes the raspberry doesn't react that fast on interrupts and that it lags in some cases up to 500ms.
Anyone else heard this problem?
500ms would be pretty exceptional but is certainly possible, I have heard of 1000ms+.
You are talking about very rare events, perhaps one in a million interrupts (of that order at least, I don't have any stats to hand).
Single threaded code that writes a lot of data to an SD card is going to suffer some looooong pauses !
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

LdB
Posts: 1706
Joined: Wed Dec 07, 2016 2:29 pm

Re: Hardware interrupts using C

Sun Apr 16, 2017 1:50 pm

Most non RTOS O/S behave that way when the USB or Drive access is used in that way, there is nothing unique about Raspbian in that regard. If you are doing stuff that is that time critical you shouldn't be dealing with it that way in the first place.

You can improve the Raspbian response times by about 50% if you are prepared to build the kernel yourself. The default build uses CONFIG_PREEMPT, building with CONFIG_PREEMPT_RT improves by changing the tasking to more in the RT line.

There are a number of linux RTOS available on the Pi that will be better at low latency, predictable response to external events but ultimately this sort of RTOS behaviour was not one of the design criteria behind the Pi.

If you look at things like some beagleboards they have a programmable real-time unit (PRU) so they can guarantee a response time to an I/O interrupt that is a whole lot of hardware that the Pi doesn't have. That extra hardware comes with a cost, a space occupancy and additional software support.

I am sure we would all love the Pi to be everything to everyone but at the end of the day they could only squeeze so much into the design for the price and it is a pretty good all rounder. So it comes down to is the response adequate, if it isn't you could try some of the RTOS options or driver or baremetal it. However ultimately if you are getting down there the question you should ask is the Pi the right choice of hardware.

For the record the normal driver response is about ten to twenty times faster than user space .. usual quoted numbers
Jessie user space: tmin =179 us tave = 280us tmax = 511us
Jessie driver space: tmin = 6us tave = 12us tmax = 43us
You will have to look around for quoted response times for some Pi RTOS systems.

User avatar
joan
Posts: 15971
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Hardware interrupts using C

Sun Apr 16, 2017 2:23 pm

LdB wrote: ...
For the record the normal driver response is about ten to twenty times faster than user space .. usual quoted numbers
Jessie user space: tmin =179 us tave = 280us tmax = 511us
Jessie driver space: tmin = 6us tave = 12us tmax = 43us
You will have to look around for quoted response times for some Pi RTOS systems.
The user space figures seem too high to me, I usually get timings of 50-100µs between a GPIO level change and the userland process waiting on poll() being run.

LdB
Posts: 1706
Joined: Wed Dec 07, 2016 2:29 pm

Re: Hardware interrupts using C

Sun Apr 16, 2017 3:12 pm

Those I measured on my batch of 10 odd Pi1's running at full 700Mhz, it's faster on the Pi3's when they are running 1.2Ghz I was scratching around for my paperwork I wrote down. I was naughty and didn't give board and clock speed. If your response is for a full speed Pi3 it looks about right just considering the base clock speed. Basically you have the same linux code needing to do the same clock cycles it's just faster on a Pi3 by almost 50%. To get worst case you need to fully load the CPU(s) did you do that?

I probably should be careful with the term worst case because as the poster discussed above noted there are a couple of hardware stalls that apply. So lets say worst case with the CPU at 100% with no hardware stalls in place.

I actually looked up the OP doesn't say the board but he has an address of 0x3F000000 so it's a Pi2 or Pi3 so it will be faster.

As a CNC designer I flirted with using the Pi for a controller but I couldn't get the numbers to be workable with the servo response I wanted which is why I was measuring it and looked at options.

User avatar
joan
Posts: 15971
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Hardware interrupts using C

Sun Apr 16, 2017 3:31 pm

The graphs I have are August 2014 which I think predates the Pi2/3.
20140817102708.png
20140817102708.png (49.29 KiB) Viewed 26994 times
The above shows a comparison between C interrupts (C red, wiringPi green) and pigpio sampling in blue.

The time scale is meant to be the microseconds between the GPIO event and the userland notification. pigpio sampling is worse because it batches reports once a millisecond.

Of course I could have screwed up my timing. When I get a chance I'll redo the experiment.

LdB
Posts: 1706
Joined: Wed Dec 07, 2016 2:29 pm

Re: Hardware interrupts using C

Sun Apr 16, 2017 4:40 pm

Oh now I am going to have to make a pretty graph :-)

Is that with O/S just idling?

I didn't test that because it was unrealistic conditions for what I was looking at. I had the USB drive (butterfly reading), Ethernet packets in transfer and FPU calculating and graphics being presented because that is normal load for a CNC app.

I will do a run with O/S just idling on latest Raspbian and see what it looks like.

User avatar
joan
Posts: 15971
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Hardware interrupts using C

Sun Apr 16, 2017 5:16 pm

LdB wrote: ...
Is that with O/S just idling?
...
Yes, apart the programs needed for the test (and standard background processes) nothing else would have been running. I would only be interested in comparative figures between the interrupt methods I was testing.

fivdi
Posts: 533
Joined: Sun Sep 23, 2012 8:09 pm

Re: Hardware interrupts using C

Sun Apr 16, 2017 7:39 pm

joan wrote:The graphs I have are August 2014 which I think predates the Pi2/3.
20140817102708.png
The above shows a comparison between C interrupts (C red, wiringPi green) and pigpio sampling in blue.

The time scale is meant to be the microseconds between the GPIO event and the userland notification. pigpio sampling is worse because it batches reports once a millisecond.

Of course I could have screwed up my timing. When I get a chance I'll redo the experiment.
I'm surprised you didn't also mention the pigpio gpioSetISRFunc function (http://abyz.co.uk/rpi/pigpio/cif.html#gpioSetISRFunc) which doesn't batch reports which in turn results in far lower latency.

User avatar
joan
Posts: 15971
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Hardware interrupts using C

Sun Apr 16, 2017 8:25 pm

fivdi wrote: ...
I'm surprised you didn't also mention the pigpio gpioSetISRFunc function (http://abyz.co.uk/rpi/pigpio/cif.html#gpioSetISRFunc) which doesn't batch reports which in turn results in far lower latency.
I only showed the graph to support my view that the latency was about 50-100µs. The only graphs I had were from when I was looking at pigpio sampling delays so I thought I needed to explain what the graph was showing, but the sampling side was really an aside. The gpioSetISRFunc() latency will also be in the 50-100µs range.

Jonvii
Posts: 15
Joined: Fri Apr 07, 2017 11:06 am

Re: Hardware interrupts using C

Tue Apr 18, 2017 12:15 pm

If i understood well, there are two solutions for using interrupts handling directly the hardware:
1. Change to another OS that can allow me to set up directly the interrupt vector table and my interrupt service routine
2. use Raspbian and manage the interrupts with the OS.

Correct me if anything is wrong.

User avatar
gordon@drogon.net
Posts: 2024
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK

Re: Hardware interrupts using C

Tue Apr 18, 2017 12:27 pm

Jonvii wrote:If i understood well, there are two solutions for using interrupts handling directly the hardware:
1. Change to another OS that can allow me to set up directly the interrupt vector table and my interrupt service routine
2. use Raspbian and manage the interrupts with the OS.

Correct me if anything is wrong.
3. Stick to Linux (under Raspbian, etc.) and write a kernel module to directly handle the interrupt.

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

LdB
Posts: 1706
Joined: Wed Dec 07, 2016 2:29 pm

Re: Hardware interrupts using C

Wed Apr 19, 2017 5:51 am

That is a very personal answer Gordon, as in what you would based on your knowledge set. I am a bit more cautious with advice when I give it.

Jonvii those are two of the 3 options the third is use a different hardware/software which may already have what you want. The Pi is a great low cost board but it is not a solution to everything.

The question comes down to what realtime response do you need and what other things are required ... that is what are you really trying to do. You started this post about a pressed button in human like times and now we are talking about not fast enough response and we don't have a clue why.

For example if you were just counting high speed pulses it would be trivial to place a counter circuit on a board and connect it to the PI. Certainly a lot simpler than any of our other suggestions because ready made designs and boards probably exist. The question is what pulse and what speed response are you after.

Whatever the case I would think out more clearly what specification you are after before you waste a lot of time on something that might not work.

Jonvii
Posts: 15
Joined: Fri Apr 07, 2017 11:06 am

Re: Hardware interrupts using C

Wed Apr 19, 2017 12:39 pm

LdB wrote:That is a very personal answer Gordon, as in what you would based on your knowledge set. I am a bit more cautious with advice when I give it.

Jonvii those are two of the 3 options the third is use a different hardware/software which may already have what you want. The Pi is a great low cost board but it is not a solution to everything.

The question comes down to what realtime response do you need and what other things are required ... that is what are you really trying to do. You started this post about a pressed button in human like times and now we are talking about not fast enough response and we don't have a clue why.

For example if you were just counting high speed pulses it would be trivial to place a counter circuit on a board and connect it to the PI. Certainly a lot simpler than any of our other suggestions because ready made designs and boards probably exist. The question is what pulse and what speed response are you after.

Whatever the case I would think out more clearly what specification you are after before you waste a lot of time on something that might not work.
Hi LdB,

I'm doing my degree final project with this board to see if it can replace Nintendo DS which uses ARM9 and ARM7 (with different OS). The project is based in handling an ARM processor to access the registers and using different modes of communication such as polling or interrupts.

It's a project for students, so there are more inportant things like knowing how to access or using this modes than the response time.

thanks for your reply.

User avatar
joan
Posts: 15971
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Hardware interrupts using C

Wed Apr 19, 2017 2:52 pm

Do you thing treating one interrupt in isolation will help make a judgement?

I would be modelling the number of events per second (inputs and outputs) which need to be handled by the game system and considering the maximum permitted delay for each and the whole.

LdB
Posts: 1706
Joined: Wed Dec 07, 2016 2:29 pm

Re: Hardware interrupts using C

Wed Apr 19, 2017 4:26 pm

I agree with Joan but beyond that not sure how to tell you that Nintendo DS emulator on the PI has already been done on both Linux and Baremetal via emulators. You are a bit late to that idea.

https://github.com/retropie/retropie-se ... intendo-DS
https://arstechnica.com/gaming/2017/04/ ... -retropie/

You can baremetal most of the emulators if you want more speed .. follow what Peter Lemon did with the Gameboy
https://github.com/PeterLemon/Raspberry ... MU/GameBoy

The where what and how of the emulator is where you need to concentrate that is the thing that chops all the CPU power. However there are lots and lots of emulator code that have been done over the years. I have played with DuoS it's pretty easy to work with in fairly flexible c++ code.

You will also want to keep an eye on this PI forum posting
viewtopic.php?t=54357

Jonvii
Posts: 15
Joined: Fri Apr 07, 2017 11:06 am

Re: Hardware interrupts using C

Wed Apr 19, 2017 7:17 pm

LdB wrote:I agree with Joan but beyond that not sure how to tell you that Nintendo DS emulator on the PI has already been done on both Linux and Baremetal via emulators. You are a bit late to that idea.

https://github.com/retropie/retropie-se ... intendo-DS
https://arstechnica.com/gaming/2017/04/ ... -retropie/

You can baremetal most of the emulators if you want more speed .. follow what Peter Lemon did with the Gameboy
https://github.com/PeterLemon/Raspberry ... MU/GameBoy

The where what and how of the emulator is where you need to concentrate that is the thing that chops all the CPU power. However there are lots and lots of emulator code that have been done over the years. I have played with DuoS it's pretty easy to work with in fairly flexible c++ code.

You will also want to keep an eye on this PI forum posting
viewtopic.php?t=54357
Hi,

I think i have explained myself wrong. I dont want to emulate DS inside the Raspberry but i would like to use Raspberry Pi to replace DS which we used to use in one subject.

I created this post to know if i could program the things i have explained above (Interrupts, timers...) directly handling the registers (without OS) no matter how much time it cost responding.

Thanks.

LdB
Posts: 1706
Joined: Wed Dec 07, 2016 2:29 pm

Re: Hardware interrupts using C

Thu Apr 20, 2017 1:55 am

Yes the interrupts are actually relatively trivial under baremetal programming it's just everything else that isn't :-)

Lets put it in perspective what you are doing is probably 20 lines of code in baremetal you have to set the IRQ source from the GPIO registers, You need to route that Irq to the Arm and enable the Irq on the Arm. All that code exists and will have been done by multiple sources and I can happily give you it.

The problem is you have no screen, no keyboard, no drives you have to provide code for all that as well and that is massively more than the 20 lines of code you are talking about. Doing this on linux is a walk in the park compared to that.

So if you look at my article doing a basic baremetal play around
https://www.codeproject.com/Articles/11 ... he-Pi-part

I am having to provide code for the screen, the fonts, the SD card, the FAT32 and the bitmap drawing and it goes on and on because I have no O/S. I have to provide everything which I released in that on the SmartStart system to simplify it all down for novices playing around in baremetal.

If that is the level of the programming subject you are teaching then yes you can baremetal the Pi but I am not going to lie to you and say it's easy for a novice. To get to that point took me several weeks to do and I do that for a living.

If you want something in between and ok with pascal as the programming language you could look at Ultibo which sort of neatly straddles the divide between the baremetal and linux extremes. It's low enough to do what you want but at least has all the hardware access available without needing your own code.

Jonvii
Posts: 15
Joined: Fri Apr 07, 2017 11:06 am

Re: Hardware interrupts using C

Thu Apr 20, 2017 2:48 pm

LdB wrote:Yes the interrupts are actually relatively trivial under baremetal programming it's just everything else that isn't :-)

Lets put it in perspective what you are doing is probably 20 lines of code in baremetal you have to set the IRQ source from the GPIO registers, You need to route that Irq to the Arm and enable the Irq on the Arm. All that code exists and will have been done by multiple sources and I can happily give you it.

The problem is you have no screen, no keyboard, no drives you have to provide code for all that as well and that is massively more than the 20 lines of code you are talking about. Doing this on linux is a walk in the park compared to that.

So if you look at my article doing a basic baremetal play around
https://www.codeproject.com/Articles/11 ... he-Pi-part

I am having to provide code for the screen, the fonts, the SD card, the FAT32 and the bitmap drawing and it goes on and on because I have no O/S. I have to provide everything which I released in that on the SmartStart system to simplify it all down for novices playing around in baremetal.

If that is the level of the programming subject you are teaching then yes you can baremetal the Pi but I am not going to lie to you and say it's easy for a novice. To get to that point took me several weeks to do and I do that for a living.

If you want something in between and ok with pascal as the programming language you could look at Ultibo which sort of neatly straddles the divide between the baremetal and linux extremes. It's low enough to do what you want but at least has all the hardware access available without needing your own code.
Hi,

I just have found a Bare metal code which handles the system timer of the Pi. the code is in the link attached bellow:
http://www.valvers.com/open-software/ra ... -in-c-pt3/

I'm gonna try it when i finish my holidays and i would like to handle the Interrupts like the system timer is used above. What do u think about it?

Thank you

Return to “C/C++”