I wish William would stop saying this. The PRU is nothing like a CortexM3. The PRU is a proprietary RISC processor created by Texas Instruments with no pipeline and instructions execute in one cycle. The CortexM3 has a 3 stage pipeline and uses an entirely different instructions set.
@Mark Think of Remoteproc as a firmware loader which can start and stop firmware. The communications between PRU and ARM is done via RPMSG which uses a virtual ring buffer (VRING) which allow you to post messages to this buffer and then using interrupts to notify the PRU/ARM that messages are in the buffer. Regards, John > On Jul 12, 2016, at 9:25 PM, William Hermans <[email protected]> wrote: > > One of the things I learned is if you use printf() out of the box you will > run out of instruction memory. > Instead you have to use the --printf_support=nofloat flag on clpru. It uses > a smaller printf library that fits. > > Hi Mark, > > Just thinking of this from an alternative angle. The PRU are essentially a > Cortex M3 with no instruction cache. So in the Linux world, the Cortex > M0/M0+, M3's, and M4's all use the eabi compilers in the gcc camp. Which is > to say, soft float compilers. So that makes sense that using the clpru > compiler that soft float should be made implicit. Well actually, I think it > should be a given. but it makes sense that the clpru compiler should be using > soft float versus hard float. > > > > On Tue, Jul 12, 2016 at 6:28 PM, Mark A. Yoder <[email protected] > <mailto:[email protected]>> wrote: > I made some progress today. I modified one of the BeagleScope examples > (pru_pin_state_reader[1]) to use sprintf() to > send and print debug info to the ARM[2]. One of the things I learned is if > you use printf() out of the box you will run out of instruction memory. > Instead you have to use the --printf_support=nofloat flag on clpru. It uses > a smaller printf library that fits. > > I'm beginning to get a feel for what's happening on the PRU side, but the ARM > is a mystery to me. I'm sure I can figure out mmap() and read the > shared memory, but I don't think that's the proper way to do it. Rather I > think you are supposed to go through the kernel drivers, but I haven't found > any simple examples. > > Does anyone know how the ARM side of remoteproc works? > > --Mark > > [1] > https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru_pin_state_reader > > <https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru_pin_state_reader> > [2] > https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/pru/beagleScope/pru_pin_state_reader > > <https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/pru/beagleScope/pru_pin_state_reader> > > On Monday, July 11, 2016 at 2:58:46 PM UTC-4, Mark A. Yoder wrote: > It looks like the new way to talk to the PRUs is via remoteproc and RPMsg. > > Does anyone have pointers to some good tutorials? Or some good debuggers? > > ZeekHuge has a Google Summer of Code project (2016) > <https://github.com/ZeekHuge/BeagleScope>that has some nice remoteproc > examples, and he > built some nice tools. > > I'm putting together a wiki > <http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg> that shows > how to setup your Bone to run his examples. > (http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg > <http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg>). > I'm open for additions/corrections so we can have a one stop place for those > using the PRUs with remoteproc. > > --Mark > > > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/57a174ab-5696-46fb-b886-80a1d3906eb8%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/57a174ab-5696-46fb-b886-80a1d3906eb8%40googlegroups.com?utm_medium=email&utm_source=footer>. > > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CALHSORpQnt55TsRwck_r4EMNm_kCWwmFXV1aH%3DiBh0HnyYz-MA%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CALHSORpQnt55TsRwck_r4EMNm_kCWwmFXV1aH%3DiBh0HnyYz-MA%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/BD575AEA-D0A6-4B94-93D4-72559A159B8C%40gmail.com. For more options, visit https://groups.google.com/d/optout.
