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

* 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

Regardless, debugging on the PRU is much harder than debugging code on
the ARM side.

Charles Steinkuehler

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to