BBAI accessing PRU UART

70 views
Skip to first unread message

Mark A. Yoder

unread,
Jun 9, 2020, 5:00:21 PM6/9/20
to BeagleBoard
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

Dennis Lee Bieber

unread,
Jun 9, 2020, 10:14:27 PM6/9/20
to Beagleboard
On Tue, 9 Jun 2020 14:00:21 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user "Mark A. Yoder"
<mark.a.yoder-Re5J...@public.gmane.org> wrote:

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

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...



--
Dennis L Bieber

Mark A. Yoder

unread,
Jun 10, 2020, 12:51:19 PM6/10/20
to BeagleBoard
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



On Tuesday, June 9, 2020 at 10:14:27 PM UTC-4, Dennis Bieber wrote:
On Tue, 9 Jun 2020 14:00:21 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user "Mark A. Yoder"

Mark Lazarewicz

unread,
Jun 10, 2020, 7:44:04 PM6/10/20
to beagl...@googlegroups.com
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 


On Wed, Jun 10, 2020 at 11:51 AM, Mark A. Yoder
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/

On Tuesday, June 9, 2020 at 10:14:27 PM UTC-4, Dennis Bieber wrote:
On Tue, 9 Jun 2020 14:00:21 -0700 (PDT), in

gmane.comp.hardware. beagleboard.user "Mark A. Yoder"
<mark.a.yoder- Re5JQEeQqe8AvxtiuMwx3w@public. gmane.org> wrote:

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

        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...



--
Dennis L Bieber

--
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...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/5815c826-3d03-4763-8399-3e6293f6ba28o%40googlegroups.com
.

Mark A. Yoder

unread,
Jun 11, 2020, 10:46:50 AM6/11/20
to BeagleBoard
An interesting suggestion.  The trick then is figuring out what background they need to solve it.

--Mark


On Wednesday, June 10, 2020 at 7:44:04 PM UTC-4, lazarman wrote:
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 


On Wed, Jun 10, 2020 at 11:51 AM, Mark A. Yoder
<> wrote:
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/

On Tuesday, June 9, 2020 at 10:14:27 PM UTC-4, Dennis Bieber wrote:
On Tue, 9 Jun 2020 14:00:21 -0700 (PDT), in

gmane.comp.hardware. beagleboard.user "Mark A. Yoder"
<mark.a.yoder- Re5JQEeQqe8AvxtiuMwx3w@public. gmane.org> wrote:

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

        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...



--
Dennis L Bieber

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

To view this discussion on the web visit

Mark Lazarewicz

unread,
Jun 11, 2020, 11:50:10 AM6/11/20
to beagl...@googlegroups.com
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




On Thu, Jun 11, 2020 at 9:47 AM, Mark A. Yoder
An interesting suggestion.  The trick then is figuring out what background most they need to solve it.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit

Mark A. Yoder

unread,
Jun 12, 2020, 2:52:02 PM6/12/20
to BeagleBoard
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



On Thursday, June 11, 2020 at 11:50:10 AM UTC-4, lazarman wrote:
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




On Thu, Jun 11, 2020 at 9:47 AM, Mark A. Yoder
<> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit

Mark Lazarewicz

unread,
Jun 12, 2020, 10:38:35 PM6/12/20
to beagl...@googlegroups.com
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 

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

To view this discussion on the web visit
Reply all
Reply to author
Forward
0 new messages