An Axiom: You just can't make your unmanned vehicle of any use until all its actuators respond correctly. Which means there should be enough means, i.e. PWM ports in ardupilot's case ,to control them correctly. How can this be achieved on a linux machine(BeagleBone (Black))with just six PWM channels. You don't just want your unmanned vehicle to travel (well you may require more than six channels for doing that too), you require PWM for many things and we can start our list with operating camera gimbal. Software PWM on a Beaglebone is close to unthinkable, even 20-50us of latencies in toggling PWM pin can lead to your beloved vehicle's devastation, and can even cause harm to you and people around you.One way is to add another hardware to generate as many PWMs as you want. This can be the way then, you might wonder. However, it is rather better if you can do everything with as few things as possible. So here comes the PRUSS(Programmable Remote Unit Subsystem) in the picture. There are two PRUs in am335x microprocessor , lets call them PRU0 and PRU1. The beauty of this system is that the three cores: ARM core, PRU0, PRU1, act as conjoined triplets. Except the general purpose registers, each and every part of there memory is mapped to each other's memory. For example I can very easily access GPIO peripheral belonging to ARM core via PRUx and toggle them, leaving linux kernel running on ARM core asking to itself "who is trying to play with my things?" but it will never know. Well, i guess you all agree its not a pretty thing to do. Don't worry we will not trouble our sweet kernel as there is another tool which PRUSS technology has got in its arsenal: All the bits of General Purpose register R30 are mapped to physical pins. So there you go, you just got 32*2 i.e. 64 pins waiting to be acting as PWM channel with resolution as low as 4ns. Also, If you don't mind troubling linux kernel and a few 100ns latencies are fine by you, you can convert each and every GPIO pin into a PWM channel(but i don't think anybody will be required to go that far).Many of you might have started asking questions to yourselves, well why not just port ardupilot to PRUSS cores rather than ARM core seeing it is so powerful? PRUSS is no doubt a very fast core running at 200MHz but it has very little memory, only 4Kb Program and 8Kb Data RAM: you can't even fit in a printf code with floating point support into PRU's PRAM. PRUSS in beaglepilot system is being utilised like our Spinal Chord. They will do any menial recursive tasks like generating PWM or may be if required collect and pass timestamped sensor data but they can't be utilised for major data crunching or storing purposes. Therefore any task which has very small memory requirements but require not only hard realtime but also very narrow execution time is to be thrown towards PRU to handle.So I guess this post, at-least in part, answers some of the questions like: Why use BeagleBone Black platform? How PRU is useful to the Beaglepilot project? But leaves you with the question: How it is actually being implemented inside Beaglepilot? I'll leave you all with this question until next time.Regards,Siddharth Bharat Purohit
An Axiom: You just can't make your unmanned vehicle of any use until all its actuators respond correctly. Which means there should be enough means, i.e. PWM ports in ardupilot's case ,to control them correctly. How can this be achieved on a linux machine(BeagleBone (Black))with just six PWM channels. You don't just want your unmanned vehicle to travel (well you may require more than six channels for doing that too), you require PWM for many things and we can start our list with operating camera gimbal. Software PWM on a Beaglebone is close to unthinkable, even 20-50us of latencies in toggling PWM pin can lead to your beloved vehicle's devastation, and can even cause harm to you and people around you.One way is to add another hardware to generate as many PWMs as you want. This can be the way then, you might wonder. However, it is rather better if you can do everything with as few things as possible. So here comes the PRUSS(Programmable Remote Unit Subsystem) in the picture. There are two PRUs in am335x microprocessor , lets call them PRU0 and PRU1. The beauty of this system is that the three cores: ARM core, PRU0, PRU1, act as conjoined triplets. Except the general purpose registers, each and every part of there memory is mapped to each other's memory. For example I can very easily access GPIO peripheral belonging to ARM core via PRUx and toggle them, leaving linux kernel running on ARM core asking to itself "who is trying to play with my things?" but it will never know. Well, i guess you all agree its not a pretty thing to do. Don't worry we will not trouble our sweet kernel as there is another tool which PRUSS technology has got in its arsenal: All the bits of General Purpose register R30 are mapped to physical pins. So there you go, you just got 32*2 i.e. 64 pins waiting to be acting as PWM channel with resolution as low as 4ns. Also, If you don't mind troubling linux kernel and a few 100ns latencies are fine by you, you can convert each and every GPIO pin into a PWM channel(but i don't think anybody will be required to go that far).Many of you might have started asking questions to yourselves, well why not just port ardupilot to PRUSS cores rather than ARM core seeing it is so powerful? PRUSS is no doubt a very fast core running at 200MHz but it has very little memory, only 4Kb Program and 8Kb Data RAM: you can't even fit in a printf code with floating point support into PRU's PRAM. PRUSS in beaglepilot system is being utilised like our Spinal Chord. They will do any menial recursive tasks like generating PWM or may be if required collect and pass timestamped sensor data but they can't be utilised for major data crunching or storing purposes. Therefore any task which has very small memory requirements but require not only hard realtime but also very narrow execution time is to be thrown towards PRU to handle.So I guess this post, at-least in part, answers some of the questions like: Why use BeagleBone Black platform? How PRU is useful to the Beaglepilot project? But leaves you with the question: How it is actually being implemented inside Beaglepilot? I'll leave you all with this question until next time.Regards,Siddharth Bharat Purohit
Comments
Thanks Sid!
Great explanation Sid!
Thx for educating us on that with a very clear explanation! Will you continue to post other episodes in the same vein?
Excellent Explanation of PRU interaction with ARM core, looking forward to next installment.