I would not be nearly as far along if I did not have Mark Yoder's PRU Cookbook! I'll take a look at the TI documentation.
Right now, I'm working with some examples from GA Tech and the compiler running in Cloud9 IDE is balking at a __far definition in pru_cfg.h. I'm searching the GCC documentation and web for some fix for this. I suspect there must be a compiler switch to cause it to accept these but I don't know what it is or if that's even the solution. Any help would be appreciated! Walter On Friday, April 9, 2021 at 3:49:59 PM UTC-4 darre...@gmail.com wrote: > 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 <wal...@edenconceptsllc.com> > 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 >>> <wal...@edenconceptsllc.com> 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/tpnmuczy8b...@public.gmane.org> 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 beagleboard...@googlegroups.com. >>> 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 beagleboard...@googlegroups.com. >> > 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4bfa5f0d-a436-486e-9875-cf75b409ced6n%40googlegroups.com.
