unexpected "low speed" of PRU 1

CCS/JTAG works for me . I have used FPGA arm cores and ESP32
My position and opinion is unique in this group
I see no value in a PRU UNLESS every peripheral is used on DSP/ARM and you need more peripherals
I have seen that done in a RTOS on ARM DSP PRU omapL178 very complex Motor controller from an industry leader
They also used TI Picolo for QEP and several other small processors
Beyond having assembler run in 1 instruction on PRU a dedicated SoC with an RTOS or barebones is much more powerful and determinism on FDA and DO178B and Centelec systems use dedicated processors to achieve this

Nick from TI has a two PRU very simple PID motor controller reference design but its not true control theory and not fault tolerant like the product I worked on. This PRU is a toy compared to the ARM core or a DSP its resource limited and its instruction set is limited especially to run MATLAB

I did download PRUDEbug sorry for being negative it reminds me of desperate Linux programmers using GDB or even nworse yet the initial ESP32 had no jtag just serial debug

Maybe Im an old stubborn old man but Printf killed that ESP32 project very slow getting good debug info out

For custom board bring up JTAG is a must.
I worked on a Military 8 core PowerPC application debugging the multiple core SOC boards in a VME rack say 4 boards we used print logs to debug

Guess what all the consultants went home very rich $$$$$ it took years to validate this and it wasnt life critical it was mission critical so testing was extensive

My new research project CCS/ debugging ARM code over ethernet yikes it uses GDB server LOL

Thanks for informing me about PRUDEBUG I will try it to remind myself it is better than using LEDS to debug PRU.
CCS is also used to automate V&V test cases using gel files

In all fairness there are many ways to skin a cat whatever ones feels comfortable with I get that but when your custom board wont boot GDB is useless

Mark

Hi Mark,

prudebug did help a lot. I’m missing a good debug environment for PRU development.
Up to now it’s time consuming try&error.
It’s more easy to use FPGA on top of Raspberry or use ESP32, 2. core for dedicated high speed functions. At the end I want to use the CPU in my own hardware, Beaglebone is my “emulator” and debug environment.
The big value of the Sitara CPU are the PRU units. Think prudebug should be enhanced.
Have a great day

Kasimir

:+1:
Kasimir
PS try out ddd in top of gdb …
easy to use, simple and efficient

Thanks for future research.

Unfortunately GDB won’t work when your board doesn’t run.

For cost sensitive products using a OEM board isn’t always an option.

In high volume pennies make a difference that’s why ESP32 it’s low cost and is popular and I’m sure it now has a JTAG but yes GDB is an option on it although 3 year’s ago it was serial port only.

When you get handed a board that’s radically different from reference design and it doesn’t work or your designing a bootloader on a project that’s a billion dollars what’s a $100 for a JTAG.

Certainly you would not give a hardware engineer a new design and not buy him an oscilloscope or logic analyzer.

Just a different perspective may not apply for some