On Fri, 9 Apr 2021 11:15:49 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
<walterc-2dFtBuzUeF/tpnmuczy8bueocmrvl...@public.gmane.org> wrote:
>1 - start / stop reading the sensors - considering just flipping a bit in a
>memory location both can access for this. ARM will have write access, PRU
>will just monitor it. (I don't really know how to do this yet. Still
>learning.)
Well, since the PRU doesn't have asynchronous interrupts, using a
polling loop on the interrupt bits, that's probably reasonable -- though
I'd hope that RPMsg (since TI pushes it these days) should be usable
without a polling loop itself.
Especially if you can test for an incoming message between actually
reading an ADC sample.
>2 - raw data collected about the event by the PRU doesn't really have to be
>accessed by the ARM in normal operation. (For R&D, we'd probably like to
>have it though.) Every sensor reading has to have its corresponding
>timestamp but all this data can be tossed once it is consumed. The PRU
>will need to be able to do some statistics on it like mean, mode, std. dev.
Which probably need to be transferred to the Linux side -- another
RPMsg message block? <G> Using the same channel as #3 below, just different
message contents (or same message for both?)
>3 - if conditions are met, the PRU needs to tell the ARM. considering just
>flipping a bit in a memory location the PRU can write to and the ARM can
>only read from for this.
>
Ugh... Polling loop sucking up CPU cycles on an OS that already adds
potential process swapping when the loop eats all cycles of a quantum...
Just feels like attempting a (blocking) read on an RPMsg channel would
be cleaner. Linux side waits for PRU to send some message without eating
cycles. However ...
https://www.kernel.org/doc/html/latest/staging/rpmsg.html
... seems to rely upon a callback function for return data on the channel.
Example is too brief to really understand the API -- which does not seem to
have explicit RECV (to complement the SEND calls). Makes it a touch
confusing to me... Is the callback "active' from the moment the channel is
created, or only when a SEND operation was performed (since the channel is
considered bidrectional, I'd expect the callback to be active from the
start -- so either side can act upon a message sent by the other).
--
Dennis L Bieber
--
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/bjn37gptcvkq383mq75qovi2ti3lk6n1ls%404ax.com.
