I have been coding an energy metering application, where I forward the time between two rising signal edges.
Currently this is achived by a Kernel module receiving the interupt and storing in a cyclic buffer.
This is read from userspace and then forwarded to the monitoring station (Splunk HEC).
Lately trying to get comfortable with the PRU I felt this needs unloading to it.
I have not been able to locate information how to assign an external header pin to an inbound PRU interrupt line?
Does anybody have an idea hot to achieve that - or even some demo code?
What I also could add: The documentation am335xPruReferenceGuide.pdf in figure 2 clearly states identifyable names, e.g. “pr1_pru0_pru_r30[15:0]”.
The thing I seem to need is somewhate mysteriously named “Events from Select
Peripherals”.
One of P8/P9 1-46.
To generate the external Interrupt for the Kernel I am currently using
config-pin P9_12 in+
The current kernel module does a request_irq(), where the interrupt service routine copies ktime_get() into a cyclic buffer. And offers a reader interface to copy and empty the buffer into user space for furtther processing.
For better precision I should like to offload that onto the PRU: A free running counter which on interrupt arriving on some P8/9 is copied into a cyclic buffer.
Then possibly followed by a watermark triggered interrupt from PRU into kernel…
I do not find the right document for electrically mapping the P headers into the PRU.
Some demo code might help as well.
So you’re not talking about external pins, but pins at the on-board headers.
Therefor you can control the GPIO subsystems [0-3] by the PRUSS over the L3 bus, dealing with some latency.
More easy and free of latency is using the direct PRU-GPIO pins. But the config-pin support for that feature isn’t that well (ie you cannot set pull-up/down resistors).
BTW: Why do you analyse the frequency (period length). It’d be more accurate to measure voltage and current and integrate the energy (by the PRU).
Short explanation why:
Smartmeters have 2 IR outputs: One issues SML records every second specified in BSI TR 03109 1.
The other one is a test IR output issuing - a two ms pulse at a rate 1 pulse per 0.1 Wh.
So consumption equals the inverse of the distance between two rising pulse edges.
Finally found it, which I did not expect, usually I am doing MAXes or STMs: That thing is so extremely small and stripped down, it just does not have any inbound interrupt processing.
E.g. mentioned here PRU interrupt program
Verified with the instruction set documents: No such thing as an RTI.
But I can still implement it as a polling task with possibly a bit of debouncing.