BBAI accessing PRU UART

I see the BBAI has a JST connector for accessing a UART.

Can I access the PRU UART? Do I access it from this JST connector?

–Mark

I believe that is the UART used by u-boot and the kernel -- essentially
a console debug port, though it may be available under Linux (the SRM is
confusing... That connector appears to be UART1, while UART3/5/8/10 go to
P8 and P9, variously, and the PRU UART0 [PRU1 and PRU2] go to P8). No idea
where UART2/4/6/7/9 go...

It turns out I don’t have PRU code for the AI to access it’s UART. There are examples
here[1] for the Black’s am335x, but not the AI’s am5729.

–Mark

[1] https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/

Porting that might be a good class project for your student’s
Mod the offsets if the register offsets have changed between chips in the .h file.
the UART itself is HW IP I bet. If done properly the .c wouldn’t change

An interesting suggestion. The trick then is figuring out what background they need to solve it.

–Mark

Hi Mark

Good point.
EE or CE. In 81 We were handed an MCS51 manual and told to program a digital clock on an Intel eval board that had 7 segment LCD and promised an A if we could get it to work. 6 registers 6 segments. Only one person got it but he was a straight A student.

If it was me I’d do a brief lecture on Memory Maps and porting issues related.
I have to say the 2 classes I enjoyed the most were related to issues you see in real world but generally are not covered in school

One focused on microprocessor pin drive capabilities and
The other was a GE Medical Engineer focused on noise and modeling it in spice for high integrity signals as in used in cat scan A/D

I see a lot of young engineer’s intimidated by the TRM which usually have steps to program Karts perhaps a step by step comparison of these instructions in verbage to the C code along with added comments oh he’s setting this bit and that does this would be helpful to a budding low level microprocessor lover of the future. I’m retired myself don’t have an AI board but could envisio myself porting this at work because my boss didn’t have any work for me.

Those C files look alot like what my last job had gotten from TI to bring up the boot level part of an RTOS based product. They also board support files provided by the BSP/RTOS vendor. The RTOS files were propriety. It’s also good to see them available on within good resources for bare metal type stuff which is what PRU is. I worked with Mark Kraeling at Cummins and then GE we were using NXP ARM when I left for TI he spoke highly of you and of course was a proud alumni but I couldn’t sell him the TI based solutions mainly necause they were RTOS based company. I did point him tobthe fact you were using this platform to teach. You duing9 something that’s awesome I think for our engineer’s

Regards

Mark

Mark:
Got it ported!

It turns out the am572x pru_uart.h has more descriptive names for the fields than the am53xx pru_uart.h did. So DLL is converted to DIVISOR_REGISTER_LSB_ and so on.

Plus I had to find the right pins on the P8 header and get the device tree configured to bring out the pru uart. And make the rx pin is set to an INPUT.

But it’s now working. It’s all documented here[1], but it won’t appear in a nice format until I merge the changes with the master branch.

–Mark

[1] https://github.com/MarkAYoder/PRUCookbook/blob/v2.0/docs/04debug/debug.html

Hi Mark

Awesome news and good to know for future porting projects.I love that kind of work I’m really impressed with the code TI provides for low level and the fact it was easily ported means it was written with portability.

You have uninspired me to dig out one of my many boards and educate myself.

I really miss my job and the feeling I got when I did something like you did.

Bravo!!!

Regards

Mark