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 Sent from Yahoo Mail on Android On Fri, Jun 12, 2020 at 1:52 PM, Mark A. Yoder<[email protected]> wrote: 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
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 andThe 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 Sent from Yahoo Mail on Android On Thu, Jun 11, 2020 at 9:47 AM, Mark A. Yoder<> wrote: An interesting suggestion. The trick then is figuring out what background most 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 Sent from Yahoo Mail on Android 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 exampleshere[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 https://groups.google.com/d/ msgid/beagleboard/5815c826- 3d03-4763-8399-3e6293f6ba28o% 40googlegroups.com. -- 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 https://groups.google.com/d/ msgid/beagleboard/e705baeb- 415c-448d-886a-92e4179e8dc7o% 40googlegroups.com. -- 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/dd2d5b88-d9ef-4ea0-82c0-0660151bb473o%40googlegroups.com. -- 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/1016767745.138193.1592015891996%40mail.yahoo.com.
