We are running Debian Linux Buster kernel 4.19.x (yes, still on that, no time to update right now).
We are writing in C.
We currently setup and read the ADC with PRU code written in C successfully and have done so on this prototype system for several years.
Now, we need to read one channel of the ADC with C code running simultaneously with the PRU code. They do not need to communicate with each other. We have very little room left to add code to the PRU code and the ARM side is a good place for this new code anyway because it has more memory for the data and floating point capability.
The channel to be read by the ARM will not also be read by the PRU. They are truly independent data in our process.
Before wasting a lot of time trying this, is this doable?
Don’t take this to Court, but aren’t the channels MUXED into a single ADC?
I could foresee a scenario where you’d suddenly be infighting for the same resource…
There is definitely only one ADC, it’s the touchscreen controller (TSC) if you dig into the TI documentation for AM3358 SOC. In our application so far, the PRU C code configures the ADC channels to be read and triggers their conversion. I fear you are correct so it may be wisest to have the PRU code just plug the value for this channel into a shared memory location that that ARM code can retrieve. But then, there is the potential for a conflict between writing and reading! We may have to design and add and small daughter board with an I2C-based ADC on it to read this one input to avoid any possibility of a conflict. We already use such a device to read multiple supply rail voltages, load cell outputs so it won’t be hard to add this. It would be ideal not to have to though!
I don’t think it has to come quite to that.
You might be able to use the “doorbells” on the PRU to get the attention of the ARM
processors to schedule the reception in an orderly fashion.