Share it with others! So what you are up to do these days?
#2503 by Nils Roos
Fri Jul 17, 2015 10:47 pm
If I provide some framework, would you be able to fill in the blanks ? Things like:
  • generating the interrupt signal from the GPIO in the FPGA and resetting it after the interrupt was serviced
  • a kernelspace IOCTL function that blocks on a workqueue
If not, it's gonna take a while for me to prepare it ...
#6746 by Dazza101
Tue Nov 29, 2016 6:45 am
Hi Nils!

I would love to get my hands dirty with interrupts. Are there any plans to enable interrupts triggered by pins on the extension connector?
I am dealing with a very time sensitive radar application and require knowledge of when a pin has been pulsed. I then need to write an interrupt service routine in my C program to control what happens during the interrupt and call other functions. Does this sound possible in a short time frame?

Thank you for your continued hard work.

Kind Regards
Darryn Jordan
#6753 by Nils Roos
Tue Nov 29, 2016 10:55 pm
Hi Darryn,

when you say C program, are you talking about a bare-metal application or a linux userspace program?

In linux (and other popular OSs), only kernel modules can receive interrupts, and the interrupt handlers can not call functions from userspace.
If you need sub-microsecond precision for the occurence of the pulse, your best option would be to do it in the programmable logic - have a free running counter and capture its value into a buffer when the event happens. This could be supplemented by an interrupt handler that reads the stored value and makes it available to the userspace application.

But interrupts themselves don't offer truly reliable time performance on modern processors, even in bare-metal applications.
#6754 by Dazza101
Wed Nov 30, 2016 9:42 am
Thanks Nils,

I'm talking about a linux userspace program. Wow that seems like quite a bad limitation of modern processors :o
So if I understand you correctly, I would have to write an interrupt handler in a kernel module which would make the counter buffer available to the userspace. Then I would have to poll for new data from the userspace? Eeee... :(

I basically just need a function to be called in the userspace when an (extension connector) pin is triggered.

Thanks for your input!
#6757 by Nils Roos
Wed Nov 30, 2016 4:11 pm
Wow that seems like quite a bad limitation of modern processors

It's fallout from all the optimizations that modern cores employ. For example, the time it takes for your interrupt handler to be executed depends heavily on whether the handler is already in the instruction cache or not. These kinds of things introduce a large uncertainty into the predictable time performance of code. It's generally pretty fast thanks to these mechanisms, but not predictable. Additionally, the interrupts from the programmable logic are somewhere in the middle of the priority spectrum, so it may well be that other interrupts are serviced before the GPIOs - or your handler gets interrupted itself.

Event-driven callbacks are not supported by the C runtime in this area. The POSIX compliant way of doing these things is to call blocking system functions like select() with a list of events you are interested in, and they will return when an observed event arrives - or a timer expires, optionally. You can do that in a dedicated thread which examines the result of select(), calls your callback and then calls select() again. Or you use polling like you suggested.

Who is online

Users browsing this forum: No registered users and 1 guest