As I get a better understanding and experience this may change, but right now I don't think it can handle the volume of data we need to move between systems. And, that volume is only needed during R&D. The production system will not need to keep that data.
So, my plan is to instance arrays on the ARM side and use RPMSG to pass the addresses to the PRU. The PRU code will translate that to ARM addresses. As the data is collected it will be stored in arrays local to the PRUs (in the 8k or 12k memory spaces). When the time-sensitive data collection is completed, the PRU array will contain the data. Then we'll just copy it over the ARM addresses. My assumption is that since the ARM instances the arrays in memory, Linux will not overwrite those locations so they'll be 'safe'. I'll probably use RPMSG to alert ARM that the data is going to be transferred and wait on an 'ack' from the ARM before copying it over. Seems like it should work. On Friday, April 16, 2021 at 3:01:56 AM UTC-4 lazarman wrote: > Hello TJF > > Looks very powerful and code is very generic and well thought out. I > thought you couldn't code?🤣 > > I'm on tablet forgive my laziness where are the ADC examples located in c > language if possible > > Looks like you support multiple languages nice. > > > I'm guessing below reference you mentioned is the am335x TRM or are you > referring to the ARM intellectual property for ADC? > > It's also possible to directly write to the step configuration in > AdcSet::St_p > <https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/class_adc_set.html#a5963b11e6b966423547162d856cc0049> > by > writing to the member variables Confg and Delay. See ARM Reference Guide, > chapter 12 <http://www.ti.com/lit/pdf/spruh73> for details on ADC > configurations. > > Thanks. Did you write this library? It's quite a bit to wrap ones mind > around. How long dis this take to develop. > > I've got a basic understanding of how RPMSG works I'd like to understand > how libpruio handles the data exchange. > > I'm wondering why Walter isn't using RPMSG he's talking about using the > other unused PRU memory to store data and have ARM read it. I'm trying to > see if that's doable for my own understanding. Certainly would not be good > if that PRU loaded code from ARM. The Linux part I'm unfamiliar with. From > my reading it sounds like starting PRU is manually done from linux command > line. > > Loading and debugging PRU code seems to me to be slow and time consuming > compared to jtag. > > Lastly in the unlikely event a modified libpruio example crashes what is > the debug mechanisms beyond dmsg saying dude you crashed go recompile and > reload. Are console output echoed back. > > Thanks in advance also any data sharing examples in libpruio? > Mark > > > Sent from Yahoo Mail on Android > <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> > > On Fri, Apr 16, 2021 at 12:47 AM, TJF > <[email protected]> wrote: > > > [email protected] schrieb am Donnerstag, 15. April 2021 um > 18:35:20 UTC+2: > > So, STEPENABLE lets me enable the steps that I want to be executed. (I > missed that concept before.) > > So if I had an application that had a sensor A that needs to be read every > 10ms and sensor B that only needs to be read every minute, I could wire > channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor > B and assign it to step 2. > > Then at startup, when I want to read both sensors, I enable steps 1 and 2 > but not 3-16. This saves time on the read as channels 3-7 aren't needed > and steps 3-16 aren't needed so I don't use them. Then after the initial > read when I don't need to read sensor B until a minute passes, I can change > STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only > sensor A would be read. Then at one minute intervals, I change STEPENABLE > so steps 1 & 2 are enabled and when read is triggered, sensors A and B are > read. > > There're 17 steps, one charge step and 16 sample steps. Each step > configures not only the multiplexer (chanel 0-7), but also an open delay > and a sample delay, as well as an avaraging number. That's explained at > AdcUdt::setStep() > <https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/class_adc_udt.html#a243d91f0b7b7a29ada9bc14364c3284f>, > > including a hint where to find further information in the ARM TRM. > > In order to write to the STEPENABLE register you've to stop the sequencer, > write the new value and restart the sequencer again. This is 3 times L3 > operation, which need at least 3 PRU cycles each (perhaps more in case of > heavy travel). How do you what to ensure accurate ADC timing? > > The outnumber of step registers isn't thought of macroscopic asymmetry (in > your case sample channel A and B at 10 ms and ignore the B value for a > minute). It's made for microscopic asymmetry, ie when you want to sample A > twice as often as B. > > -- > 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/def726b2-31f2-469b-a9fc-70fc429ffa59n%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/def726b2-31f2-469b-a9fc-70fc429ffa59n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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/36b51d01-0f46-44e0-89df-90489d42cec4n%40googlegroups.com.
