For my project that used a PRU to sample the onboard ADC, I relied very heavily on the TI PRU_ADC_onChip <https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am335x/PRU_ADC_onChip?h=master> example code, along with Mark Yoder's most excellent PRU cookbook <https://markayoder.github.io/PRUCookbook/#_pru_cookbook>. With those two resources, you should be able to do what you're hoping to do.
Good luck! df On Fri, Apr 9, 2021 at 1:00 PM Walter Cromer <[email protected]> wrote: > It's a fairly simple application really and that's what makes it > frustrating! We'll get there! I learn something every day and that's > just fine with me. > > On Friday, April 9, 2021 at 2:54:55 PM UTC-4 lazarman wrote: > >> Plenty of data Walter thanks. >> >> You could write some linux code that reads Data from from PRU ram( I'm >> not sure if there's several ways to get Data beyond remote messaging and >> reading the shared ram directly) factor in delay for new sample's to be >> updated from ADC at least you could ensure that works in your time frame. >> >> If that seems OK >> >> Then use examples for PRU I'm skeptical about needing to use assembler >> it's not the PRU read time that's a bottleneck. >> >> I'd be interested in seeing that PRU to ARM transfer rate it should not >> take alot of time but if Linux is still interfering beyond your needed >> specific time period you will only have one choice but to find what's >> exactly doing this delay and mitigation of that will be your only hope. >> >> Typically a proof of concept fesigh verification like this is always wise. >> >> If using this chip is your only option you'd have one option left but I >> don't think you would like it. >> >> And I'm already well known for suggestioning that option on ARM so I'm >> not going to mention it. >> >> I do understand the value of having a feature rich OS on ARM that's >> royalty free but I've been lucky on the 50 or so projects I've worked on >> this wasn't the issue. >> >> Another project was a Diesel engine controller they did a DVT phase >> first. Design verification Test >> >> I wish I could help on Linux side but I can't there's plenty of people in >> here using Linux so I think you can get more ideas and help. >> >> Not Sure how many have used Linux in actual hard realtime systems. >> >> Your application doesn't sound extremely hard realtime so be interested >> in seeing this have a happy ending. >> >> >> >> >> >> >> >> >> 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 9, 2021 at 1:16 PM, Walter Cromer >> <[email protected]> wrote: >> >> Thanks Dennis. That is in sync with my research. >> >> On Friday, April 9, 2021 at 2:00:07 PM UTC-4 Dennis Bieber wrote: >> >> On Fri, 9 Apr 2021 09:30:53 -0700 (PDT), in >> gmane.comp.hardware.beagleboard.user Walter Cromer >> <walterc-2dFtBuzUeF/[email protected]> wrote: >> >> >> >We are still experimenting but our preliminary calculations lead us to >> >believe a reading every 50 microseconds will be sufficient. We can >> probably >> >get by with 100 microseconds if we have to but I think the BBBw can >> easily >> >sample at this rate, right? >> >> Well, the SoC reference (SPRS717J) indicates that the ADC should be >> capable of 200K samples per second. If I haven't flubbed the math, that >> appears to come down to one sample every 5us. >> >> As I recall, the PRU runs on a 200MHz clock, and PRU instructions, for >> the most, run in one clock cycle. Should be enough cycles per sample to >> handle processing <G> >> >> Of course, it may matter how you have the ADC programmed. >> >> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> >> >> https://groups.google.com/d/msgid/beagleboard/44d5f47f-973d-4b08-bcdb-d93e0e6c3f70n%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/44d5f47f-973d-4b08-bcdb-d93e0e6c3f70n%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/1c1af0c5-207f-47fe-9c47-e97b563bbcecn%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/1c1af0c5-207f-47fe-9c47-e97b563bbcecn%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/CAMRnUvA%2BNs5aj-jHP5Pxz44wfXVxK_MDVApLJ%2BYTT8m5Vdy%2BWg%40mail.gmail.com.
