Have you set the pins with config-pin to pruout or pruin? This caught me out a few times when I was learning PRU.
On Thu, Apr 15, 2021 at 7: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. >> >> 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 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 > <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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAMRnUvDf16iYJoqN_xZo%2BJMKF%2Bso6oUdLPKXKEwaqrCjK4a8Ng%40mail.gmail.com.
