So, there is a driver, although I do not know the name of this driver that
populates /proc/irq/ , but if you cat /proc/interrupts, you'll easily see
which number correlates to what.
root@beaglebone:~# cat /proc/interrupts
CPU0
16: 39266767 INTC 68 Level gp_timer
20: 118529 INTC 12 Level 49000000.edma_ccint
22: 97 INTC 14 Level 49000000.edma_ccerrint
23: 0 INTC 96 Level 44e07000.gpio
30: 0 44e07000.gpio 6 Edge 48060000.mmc cd
56: 0 INTC 98 Level 4804c000.gpio
89: 0 INTC 32 Level 481ac000.gpio
122: 0 INTC 62 Level 481ae000.gpio
155: 18 INTC 72 Level 44e09000.serial
156: 1431 INTC 70 Level 44e0b000.i2c
157: 33 INTC 30 Level 4819c000.i2c
158: 13 INTC 64 Level mmc0
159: 587731 INTC 28 Level mmc1
167: 0 INTC 75 Level rtc0
168: 0 INTC 76 Level rtc0
172: 2117580 INTC 41 Level 4a100000.ethernet
173: 218976 INTC 42 Level 4a100000.ethernet
181: 0 INTC 111 Level 48310000.rng
183: 41 INTC 18 Level musb-hdrc.0.auto
184: 1 INTC 19 Level musb-hdrc.1.auto
185: 0 INTC 17 Level 47400000.dma-controller
186: 0 INTC 7 Level tps65217
187: 0 INTC 16 Level TI-am335x-adc
The reason why there are no userspace interrupts, is that this would create
context switching between userspace->kernel space->userspace. Needless to
say, this would create a system wide performance problem.
Now, concerning setting a bit flag in memory *somwhere*. I ran into a
similar problem that was all in userspace, where I was decoding a custom
CANBUS protocol, and all of the so called "non-blocking" mechanisms
available through the std Linux libc API, being too slow by far. The reason
I needed this mechanism, was that I have two separate processes,
communicate between each other, in real-time. The CANBUS side of things
decoding messages at 1Mbit/s, the other half, being a web server,
displaying the decoded data, in real-time through web sockets.
Anyway, with traditional non-blocking methods I was able to switch between
these two apps at around 5-8 messages a second. But when I switched to
using mmap() + a structure in memory + a bit in this structure as a locking
mechanism. My message count max shot up to around 1000 messages / second.
Granted, actual new message values were only around 20 a second.
SO basically how I did this was again, I had a structure where one member
was a single bit( 8 bits in storage, but I only used 1 ). After that, this
bit would be either 0 or 1(of course ), and depending what value this bit
was, indicated which process had access to the file. Which access rotation
was a real factor in this given situation. Basically, the first half
process would decode, and write, then set the access bit to allow the
second half access. The second half would read this value, then change the
value back to 0. As implied above, this turned out to be the fastest
mechanism possible by a long shot.
Using the PRU's you would not be able to use POSIX IPC shard memory as I
did, but you can still use mmap() + /dev/mem/ on the user space side of the
application. Which would allow you to communicate with the PRU's through a
specified location in memory.
If this is not clear enough, I can elaborate further. In either case, I'd
be interested in how you dealt with your problem here, and would really
love to see some simplified example code.
On Tue, Mar 7, 2017 at 10:44 PM, ags <[email protected]> wrote:
> I see what you are saying. But (from what I've read) it seems that many
> would also say that you can't *receive* interrupts in userspace. I guess
> that's technically true, but uio does provide a way, through sysfs, to
> determine if an interrupt was fired.
>
> Also from what I've read (I've been doing a lot of reading...) I thought
> that remoteproc was using mailboxes to communicate from userspace to the
> PRU - and was wondering if this "reverse-direction" interrupt mechanism
> couldn't also be supported by drivers (say, by writing to /dev/uio<n> -
> analogous to select()/poll() on /dev/uio<n> to detect an interrupt.
>
> Granted, after going through all that machinery, it may well be faster to
> just set a bit in PRU memory and have PRU poll.
>
> If this is just nonsense, even in theory, then I'd welcome an education as
> to why.
>
> On Tuesday, March 7, 2017 at 8:52:27 PM UTC-8, William Hermans wrote:
>>
>>
>>
>> On Tue, Mar 7, 2017 at 9:45 PM, ags <[email protected]> wrote:
>>
>>> The mechanism for generating an interrupt from a PRU to the A8 (host) is
>>> well-documented. Is there a way to send an interrupt (one of the 64 system
>>> interrupt events documented in the PRU-ICSS literature) from userspace?
>>>
>>
>> No, there are no such things as userspace interrupts, period.
>>
>>>
>>> From reading the TI documentation, the only two that seem to be
>>> candidates are two "mailbox" interrupts. I recall reading something about
>>> a version of the remoteproc (or RPMsg, or virtio) drivers that utilized
>>> these mailboxes, but ultimately abandoned them as they are not available on
>>> all platforms. (that may be incorrect).
>>>
>>> Setting a flag in PRU DRAM or shared RAM is clearly a method that will
>>> work. However, it appears that polling DRAM or shared RAM is a multi-clock
>>> task; if a PRU system interrupt can be generated, it can be polled in one
>>> clock by examining R31 bits 30/31 (if configured correctly). Is this
>>> possible?
>>>
>>
>> I get the feeling however that you're misunderstanding the purpose of an
>> interrupt. An interrupt is a way for hardware to let software know,
>> something has happen that may require attention. Either way you wold
>> probably be better off thinking in the context of setting a bitfield, or in
>> this case, a single bit.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/f49b6ac0-7cc8-467c-8fcf-3060b65dec05%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/f49b6ac0-7cc8-467c-8fcf-3060b65dec05%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CALHSORr58VKn6FGJbSP4WaUyQ0-c2p-%3DN-EZ_2zGbPEh1Yq%3DhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
