I believe you will Walter I just thought it prudent to mention doing some designs validation coding first. I do think the the through put coding could be done quickly on ARM . If you're doing the other code functions on PRU you mentioned your going to face the learning curve anyway you asked about. So you might then try some tests using ADC PRU. Otherwise I'd do the ARM part first Usually there's always away to shoe horn something. Regards Mark
Sent from Yahoo Mail on Android On Fri, Apr 9, 2021 at 2:00 PM, Walter Cromer<walt...@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 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. -- 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/1c1af0c5-207f-47fe-9c47-e97b563bbcecn%40googlegroups.com. -- 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/289459220.203354.1617996778556%40mail.yahoo.com.
