Beaglebone Black SRM Have not seen this can you share a link Thanks Mark Sent from Yahoo Mail on Android On Thu, Apr 15, 2021 at 8:15 AM, Walter Cromer<walt...@edenconceptsllc.com> 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. - Configure your trigger event (up to four events can get chained up). - Open valves. - Start MM mode, synchronously waiting for trigger. - Close valves. - ?Perhaps evaluate pre-trigger values? - 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/11c39bb9-4891-4271-8374-ae76f00f9e17n%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/582729532.1375228.1618494919152%40mail.yahoo.com.
