I spent most of yesterday reading TI's documentation and the Beaglebone Black SRM in detail and believe I have a much better handle on how this works now. My plan is to allocate memory space in pru0's RAM for the data storage and then have an ARM program read it from there
Thanks for link Ignore my question about missing posts its my Android Tablet from Samsung email client That SRM doesn't talk about "allocate memory space in pru0's RAM for the data storage and then have an ARM program read it from there" Did you read something that describes doing this? Also that SRM says TI doesn't support PRU rather wierd. Your statement lead my to believe some TI docs gave you an *epiphany* can you explain? If there are any docs like this in my experience they come from E2E not .org Ive got several boards at home and a jtag and a fresh ccs install I plan on revisting this soon Thx Mark On Thursday, April 15, 2021 at 9:13:19 AM UTC-5 [email protected] wrote: > I think this is a better version. Than what I posted a few minutes ago ( > Ideleted that post). > > > https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual > > > > On Thursday, April 15, 2021 at 9:55:41 AM UTC-4 lazarman wrote: > >> Beaglebone Black SRM >> >> Have not seen this can you share a link >> >> Thanks >> >> 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 Thu, Apr 15, 2021 at 8:15 AM, Walter Cromer >> <[email protected]> wrote: >> >> I'm sticking with remoteproc for now. I spent most of yesterday reading >> TI's documentation and the Beaglebone Black SRM in detail and believe I >> have a much better handle on how this works now. >> My plan is to allocate memory space in pru0's RAM for the data storage >> and then have an ARM program read it from there. Our production solution >> does not need to share this data with the ARM side. We only need this >> during R&D so I'm not worried about the two sides clobbering each other on >> the production system. >> >> But, now, of course, nothing that used to work is working! I had started >> out with the PRUCookbook and had P9_11 blinking an LED. Now, nothing. >> dmesg shows the PRU starting and stopping and the firmware file in >> /lib/firmware is new based on ls -l output so I'm fairly certain that the >> code got compiled and copied over to the right directory. The PRUCookbook >> example that blinks USR3 works and I can change the blinking frequency and >> change it to blink USR2 instead and all that works. But the example to >> blink P9_11 won't and neither will another one to blink P9_27. The only >> thing I know I changed is that the PRUCookbook directories were all owned >> by root and group root. They weren't originally like that but got changed >> somehow. Yesterday I did a *chown -R debian:debian* on PRUCookbook to >> change them so Debian could edit files in those directories. I wouldn't >> think this would matter since all the real remoteproc action happens in >> other directories. >> >> I also started working with CCS some and trying to get it going. >> Somewhere along the way, something deleted all the files and folders in my >> local WIndows machine's Documents folder. I'm running anti-virus and >> anti-malware on the WIndows box. >> >> Just when I thought I was going to start really moving forward!!! >> >> On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote: >> >> lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2: >> >> I thought he had an unacceptable delay reading ADC from ARM? >> Just trying to understand how libpruio fixes this and if it did why even >> bother with PRU? >> >> >> In RB mode libpruio fetches ADC data at accurate timing (no delays) in to >> a ring buffer. The ARM can read/evaluate the data later. >> >> @Walter >> Inspired by lazarman, just another thought: perhaps you don't need a PRU >> mainloop at all. Perhaps you can meet your needs by ARM code using the >> libpruio trigger features in MM mode. >> >> 1. Configure your trigger event (up to four events can get chained >> up). >> 2. Open valves. >> 3. Start MM mode, synchronously waiting for trigger. >> 4. Close valves. >> 5. ?Perhaps evaluate pre-trigger values? >> 6. Repeat from step 2. >> >> -- >> >> 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/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/11c39bb9-4891-4271-8374-ae76f00f9e17n%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/7859e8ce-e2e6-437f-a89b-d78d50b2d811n%40googlegroups.com.
