<<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.
FYI I just successfully built a simple PRU example in CCS on win 8 following TI's PRU Hands On Labs All kinds of examples including complete ADC code following the guide I was not able to import the RPMsg adavanced ccs projects I found They even have ARM RTOS to PRU RPMsg(stoked) may try that with a later version of CCS on win 10 Now the fun part Choosing a board ( I have BB white or black or am335x EVM) actually finding the power cords and then choosing one of 3 jtags I own (USB JTAG on the target over is sweet g FTDI USB Hi-Speed Devices to a JTAG TAP and single stepping through source code and setting breakpoints I cant wait the guide even discussed stopping Linux from hosing jtag The Docs are very good The time I spent I learned alot about the Linker cmd file layout and understand the exact address and memory map of PRU I stopped short of generating a map file I couldnt even imagine putting around manually loading pru code from Linux big time waster Uhmm TI says if you are using a new chip CCS is highly recommended they also punted on VM machine support but its documented for 32 bit windows using Virtualbox and Ubuntu 14.04 or 18.04 LTS that shelves that for my win 10 box BUT I think its time to turn this brand new Windoze 10 laptop into a REAL workstation a dual Boot Ubuntu native install hmm seems like a hassle I could build TI RTOS on win10 maybe do both So many choices very happy with documention I have found on E2E Im expecting jtag on pru redirects print commands to a CCS window but why do that when you can examine and watch variables if CCS/JTAG supports a trace buffer I will be in* Hog heaven* find out tommorrow. Anyway Linux is not required for CCS and its slow and inferior to Windows 10 version Mark On Tuesday, April 13, 2021 at 1:25:06 PM UTC-5 wal...@edenconceptsllc.com wrote: > 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/65260523-1937-4b4f-9ce4-173253452517n%40googlegroups.com.
