Re: [beagleboard] File writing from PRU

['Mark Lazarewicz' via BeagleBoard]

Been using emulators for 32 years in industry if you exclude debugging linux( 
printf is common) and look at bare metal or RTOS which many hard real time 
systems use you save time. IMO toggle gpio and printf is like erasing and 
programming eepeoms 30 years ago. Sure it works for applications but for low 
level bring up I won't work for a company that doesn't supply me a jtag. If 
your app uses the serial port your sol using printf. I recently worked at a 
company used an esp8260 Wi-Fi SoC project failed it took forever to reflash and 
once we added in the serial protocol printf was not possible. the lack of jtag 
killed the project. If your a student I get $90 of your own money may seem a 
lot but look at as an investment in your future every one uses jtag outside the 
linux community for RTOS and high end jtag like lauterbach used by ARM, TI etc 
etc cost thousands if dollars why do you think TI makes a cheap jtag and CCS 
support? Because for DSP ARM OMAP real world projects in successful products 
selling millions of units like the one I'm working on at work using omap138 
Greenhills RTOS on the ARM and sysbios on the 687x DSP of omap and btw we use 2 
PRUs this got to market quickly because of jtag. I will say this product is now 
debugged by loading binaries for DSP and ARM from a flash filesystem via 
telnet. T it took years to get that stable using you guessed it Greenhill sling 
shot jtag for ARM and CCS and jtag for ARM bootloader and DSP debug. I wasn't 
there when they debugged the PRUs its loaded from a c file by arm as is the DSP 
via shared DDR 
If you Google debugging the PRU with CCS you will find a tutorial for the bone 
PRU using CCS.Get the skills employers use to deliver products quickly I bet 
you never look back. I Probally have a dozen jtag for a dozen micros 
I buy them as a learning aid to hit the ground running on any new processor I 
use. These SOcs are way to complex and life is way to short to wiggle gpios.If 
you can't find the wiki I mentioned just ask 
Cheers
Sent from Yahoo Mail on Android 
 
  On Tue, Aug 8, 2017 at 5:07 PM, Clark Sann wrote:   Mark,

So what can I do with it if I get one? I’m programming the PRU in C, can I 
inspect variables and insert breakpoints?

Clark
> On Aug 8, 2017, at 4:56 PM, 'Mark Lazarewicz' via BeagleBoard 
>  wrote:
> 
> That sounds like a perfect justification to spend $90 on jtag

-- 
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/967BAFEF-EEB2-49CB-AB41-97A20CAF29AF%40icloud.com.
For more options, visit https://groups.google.com/d/optout.  

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

Re: [beagleboard] File writing from PRU

[Clark Sann]

Mark,

So what can I do with it if I get one? I’m programming the PRU in C, can I 
inspect variables and insert breakpoints?

Clark
> On Aug 8, 2017, at 4:56 PM, 'Mark Lazarewicz' via BeagleBoard 
>  wrote:
> 
> That sounds like a perfect justification to spend $90 on jtag

-- 
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/967BAFEF-EEB2-49CB-AB41-97A20CAF29AF%40icloud.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] File writing from PRU

['Mark Lazarewicz' via BeagleBoard]

That sounds like a perfect justification to spend $90 on jtag

Sent from Yahoo Mail on Android 
 
  On Tue, Aug 8, 2017 at 3:35 PM, Clark Sann wrote:   
Thanks, Charles, for the great ideas. 

I definitely agree with you that debugging on the PRU is hard. I’ve been 
working on a problem on and off for weeks. I’ve solved it now but had decent 
debugging tools it would have only taken a few minutes. (Or if I knew C 
better!) It’s like trying to play tennis with a bag over my head.  Lucky for 
me, I don’t get paid for this stuff.

Today I got RPMsg working. I’m now using it to send commands to the PRU and to 
retrieve rudimentary diagnostic data. So I hope to pick up the pace a little 
bit. The PRU certainly has a steep learning curve!

I’ll also look into your suggestions. Thanks again!

Clark

> On Aug 8, 2017, at 11:08 AM, Charles Steinkuehler  
> wrote:
> 
> 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 a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/hM0UojPprcY/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

-- 
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/0F280D4F-A9C9-4A8E-922A-DCCAC6034C1D%40icloud.com.
For more options, visit https://groups.google.com/d/optout.  

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

Re: [beagleboard] File writing from PRU

[Clark Sann]

Thanks, Charles, for the great ideas. 

I definitely agree with you that debugging on the PRU is hard. I’ve been 
working on a problem on and off for weeks. I’ve solved it now but had decent 
debugging tools it would have only taken a few minutes. (Or if I knew C 
better!) It’s like trying to play tennis with a bag over my head.  Lucky for 
me, I don’t get paid for this stuff.

Today I got RPMsg working. I’m now using it to send commands to the PRU and to 
retrieve rudimentary diagnostic data. So I hope to pick up the pace a little 
bit. The PRU certainly has a steep learning curve!

I’ll also look into your suggestions. Thanks again!

Clark

> On Aug 8, 2017, at 11:08 AM, Charles Steinkuehler  
> wrote:
> 
> 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 a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/hM0UojPprcY/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

-- 
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/0F280D4F-A9C9-4A8E-922A-DCCAC6034C1D%40icloud.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] File writing from PRU

[Charles Steinkuehler]

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.

Re: [beagleboard] File writing from PRU

[Clark Sann]

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 beagleboard+unsubscr...@googlegroups.com.
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.

Re: [beagleboard] File writing from PRU

[Charles Steinkuehler]

On 8/7/2017 10:55 PM, Clark Sann wrote:
> I need some help from someone who has succeeded in getting the PRU to write 
> files onto the host's file system. I have tried two methods:
> 
> 1. Using open, fputs, fprintf, etc. This does not work for me. First of all, 
> unless I set the printf_support flag to minimal, even a simple program with 
> only 
> a single print statement uses more instruction memory than the BeagleBone PRU 
> has. Even if I set the flag to minimal, I do not find that any files have 
> been 
> written.
> 
> 2. Using the low level drivers described starting on page 124 of the PRUC 
> Compiler V21 User Guide. I also cannot get these functions to write a simple 
> file.
> 
> If anyone has succeeded in getting either of these methods to write a simple 
> string to a file, would you please consider posting some sample code?

You cannot write to anything like a file directly from the PRU.  The
best you could do is enable the PRU UART and craft a version of the C
library that would let you do printf() or similar to a console.

If you need to save data into a file, you will have to pass it from
the PRU to the ARM at which point you can do anything available via
Linux (print to console, write to file, send via Ethernet, etc).

-- 
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/e57bbb0b-5c9b-0391-74eb-a33627da9da1%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.