I'm 100% sure it wasn't doing this before because I worked through the exercises in Mark Yodre's PRUCookbook and this command
config-pin P9_31 pruout worked before Now it gives debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/05blocks/code$ config-pin P9_31 pruout ERROR: open() for /sys/devices/platform/ocp/ocp:P9_31_pinmux/state failed, No such file or directory I get the same error when I execute this as root. On Friday, April 16, 2021 at 6:43:46 AM UTC-4 Walter Cromer wrote: > Yes. It’s throwing an error when I do that. I don’t think it was before > but I could be mistaken. I can’t even query the options with > configure-pin. It makes me wonder if the pins I’m choosing are in use by > something else like video or audio. I will check this today. > > > On Thu, Apr 15, 2021 at 4:00 PM Darren Freed <[email protected]> wrote: > >> 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 <[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/CAMRnUvDf16iYJoqN_xZo%2BJMKF%2Bso6oUdLPKXKEwaqrCjK4a8Ng%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/beagleboard/CAMRnUvDf16iYJoqN_xZo%2BJMKF%2Bso6oUdLPKXKEwaqrCjK4a8Ng%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > Thanks, > > Walter Cromer, MS, PMP, PMI-ACP, CSM > Chief Idea Officer and Founder > Eden Concepts LLC > w: http://edenconceptsllc.com > m: 865-719-8881 <(865)%20719-8881> > -- 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/d3c744b5-d7f5-471c-bfec-7efe890b1f15n%40googlegroups.com.
