On 8/8/2017 10:11 AM, Clark Sann wrote: > > But why did TI blather on and on about the printf_support switch and the high > and low level IO drivers in the PRU C Compiler manual?
Because you can get printf working if you add a UART or other means to get data out of the system. > What do you do to get diagnostic info while debugging PRU firmware? My typical methods: * "Twiddle" pru output pins at various points in the code. Note that if you've got a good 'scope or logic analyzer (I'm typically using an Agilent MSO with 16 digital channels), you can shift out data values with a single pin, so it can be more useful than just "LED" style debugging. * Dump data into a chunk of shared memory (typically one of the PRU data RAMs) and examine it from the ARM side. * Use a debugger to single-step the PRU code. I typically use the HAL based one provided with Machinekit but there are now several others available. Regardless, debugging on the PRU is much harder than debugging code on the ARM side. -- Charles Steinkuehler char...@steinkuehler.net -- 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/e5397db0-ee22-e884-a2d5-893936dea0df%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
