We're designing it the way you suggested. The nice thing is that basically the control logic has already been written in C on the ARM side. Now, I just need to get it ported to the PRUs and create the communications between the PRUs and a new ARM app that supervises everything from the user's point of view. Meaning, taking inputs like start, stop and giving feedback by turning LEDs on and off. And it needs to take in some basic system configuration data from the cloud periodically that the PRU will consume to adjust it's operation.
I am making progress. Part of my problem was using Cloud9 for development. That's where all my ARM development has been so far. I have CCS installed on my Windows 10 machine and started working through TI's PRU Hands On Labs. Unfortunately, the very first one doesn't work because their document is written for CCS running on Linux. Step 6 says to delete the linker file and add it back with Project->Add Files but that's grayed out. I've asked TI about that. But I got it to compile by writing on the Beagle using nano and compiling it there. I've ready a lot of TI documentation today and learned a lot. Here's one more thing I am struggling with though. It's a mental block I think. I'm used to controlling GPIOs on the ARM side using sysfs. It appears that on the PRU, we use __R30 instead but I don't understand how that works. I read through it this morning and it still isn't sinking in. If anyone can help make this clearer, I'd appreciate it. On Tuesday, April 13, 2021 at 11:25:08 AM UTC-4 lazarman wrote: > Walter > > Your best bet. > > Run your whole control loop on the PRU that's as realtime as you get. Use > a foreground background loop. Use the ARM like a PC with Linux to access > the system via ethernet. > > You could also run control on ARM without linux but this way you have all > the resources of Linux to access the system. > > This assumes your output's from control loop are accessable from PRU. > > The point is Linux can only run slow control loops and this way you don't > have to debug the delay. > > This wasn't obvious to me before as all the hard realtime systems I work > on run an RTOS on ARM it has all the resources of Linux but cost $$$$$. > > In our system we did that on the DSP the PID did the math on a fast DSP. > > ARM is just a gateway to outside world. > > Myself I'd debug the PRU with JTAG and CCS you can see exactly what's > going on and dump these registers from CCS. > > Some people like printf but with a PRU based system you are essentially > doing barebones. > > There's videos on PRU development doing this online. > > Loading code via rproc and using printf is like burning and erasing an > eeprom to test your changes. You wait 45 minutes for it to erase try your > code and do it again. > > Not for me. > > 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 Tue, Apr 13, 2021 at 9:54 AM, Dennis Lee Bieber > <dennis....@gmail.com> wrote: > > On Mon, 12 Apr 2021 13:08:48 -0700 (PDT), in > gmane.comp.hardware.beagleboard.user Walter Cromer > <walterc-2dFtBuzUeF/tpnmuczy8b...@public.gmane.org> wrote: > > >What's really throwing me is the + between what looks like two macro > >values. Normally, we see the + on the right sign of the equals, right? > >Or am I forgetting something I used to know!? > > > > Why? Take into account the ()s. > > From what I can tell, this is adding the ADC register offset to the > base address of the (?) wakeup register block, which is passed as parameter > to HWREG (no doubt some macro that sets up actual access to the SoC > registers and returns a pointer or some such), and then assigns 0x02 into > the register so indicated. > > > -- > 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+unsub...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/44cb7gtf6pl4d4j3e6oqo57g5n0hobi29c%404ax.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/768e7840-c4d7-49c5-9b91-6a2b07020ff0n%40googlegroups.com.
