Thanks Charles. I agree that it seems to be impossible to write to the ARM file system. I wanted to do it to get better diagnostic information while I am debugging my PRU firmware. I'm finding that turning on outputs when I reach certain sections of firmware is growing tiresome. I might try enabling the UART and using it to send messages to me.
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? What do you do to get diagnostic info while debugging PRU firmware? I know of a few methods: 1. Turn an output on or off when a certain section of code is reached. (I do this but is is certainly primitive.) 2. Put a value in a register. Halt the PRU and inspect the registers. (I haven't tried this yet.) 3. Go into an infinite loop when a certain section of code is reached. (This sounds really weird but I think TI actually advised this as a potential debug method.) 4. Buy a JTAG and use CCS. (This is supposed to provide some type of breakpoint.) 5. Enable the PRU UART and send out diagnostic messages. (This seems promising.) 6. Use RPMsg to pass debug strings to the ARM. (This also seems promising.) Clark -- 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/f0f2004d-f09e-4eb5-8601-606a78a50afe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
