PRU, BBBlue, and ArduCopter


I was rehashing a BBBlue-ArduCopter build from years ago and I noticed that the Mainline RT kernels after 4.19.x all have a difference in PRU enablement.

For now, I am reverting back to 4.19.x until the .dts on file gets updated to allowing the PRU to be used.

I am wondering:

  1. Is there some installation issues w/ the PRU via DTS?
  2. If there are installation issues w/ the PRU via DTS, are there people working on this effort?

If neither seem correct, does anyone need help w/ updating?


Hi Seth,

for the 5.x kernel, try the ti-rt because this already have the PRU enabled, instead the bone-rt

1 Like

Hello @Juvinski ,

Thank you. Sound reasoning. How you knew, no clue. That you know, awesome! I just erased that kernel to add the bone-rt kernel. I will revert back w/ apt.


P.S. Life saver as usual…thank you again and again and again. There was a fellow on the ArduPilot discourse. He thinks I am AI since I cannot get it to work and I keep having issues. Ha. I guess all my posts sound the same?

1 Like

The master @RobertCNelson, I was having trouble with bbblack and pru and he explained this difference :slight_smile:
I have some points regarding ardupilot.
First, disable the ins_fastsample for the imu and change the sched_rate for 300hz instead 400.
With this changes I could run pocket, blue and black(bbbmini) with success.
There are a thing with spi - the spi reading at 400hz the load average for all beagles are impossible - I created a post with help about dma with spi but not help at all.
Another thing is, I’m using dshot with ardupilot - if you want, with dshot I could use several esc with dshot that was not working with pwm pulses - plus no sync problems anymore :slight_smile:

1 Like

Hello @Juvinski ,

I will keep in mind the SPI frequency on the BBBlue and change it too! Thank you for the tip.

I think the RCPassThru and the correct driver for the PRU will prove valuable.


P.S. I read some of the docs. on ArduPilot. I think the RCPassThru is a method in which the PRU source can understand the frequency in which things need to be allocated and the BBBlue Servo Headers can then be used. I keep going on over docs. but…

  1. This is the first time I heard of the ins_fastsample for the imu. I will change it to 300Hz from 400Hz.

  2. I am using the BBBlue only so far. Six years in and my dreams are crushed. Ha. Back to the bench!

The rcinput is complicated.
Regular rc - subs, ppm - the reading is done in the ecap peripheral on the pru-is a peripheral that read pulses, put it on the shared memory and then send to the ardupilot rc input engine to decode the packets.
With blue there is a rcinput using the one uart to read the pulses.
All things as “ PassThru” with beagles didn’t work for me once there are a lot of stuffs in the more deep layers. For instance, I tried to use the crossfire receiver with a beagle and didn’t work, looking the code there is some adjusts that must be made in ardupilot code, maybe this passthru need some code modifications too.


Thank you again for your input. Willy-Nilly, this means nothing and I completely understand, I think using the PWM outputs on the Servo Headers is needed but I am not sure what exactly to put in the 1 - 4 options for the blue on Mission Planner.


P.S. I have currently tried everything except for RCPassThru. I will not try RCPassThru now. Thank you. I hate to cuss. So, I will refrain. I will not cuss. I have been on the case for eight years it seems and I keep getting further away for each release of the kernels from and the binaries of ArduCopter from the ArduPilot binary site.

I think it is just me. I think it is in fact just me. I keep hearing of people using it and w/ success. There is a secret that I do not know about currently.

I tried and I quote:

Bone-rt (Mainline) w/ both of the above kernels

More Recently…

Bone-rt (Mainline) w/ both of the above kernels

I have also tried:

the binaries from the official blue binary from ArduPilot
Native Compilation

And w/ each of those kernels in the above, two blocks that are highlighted, I have tried all three of the necessary tools (Native, Cross, Binary) to get the blue working out-of-the-box.

I will try the imu frequency change and try it again. I am not upset or tired of it. I am just thinking that, for instance, sometimes the PRU is this or that and the Servo Headers are populated in a .dts file w/ Power available from that Servo Header Pins, there are some small instances of brakes where things just do not go together well, and then there is (of course) me.

I only know so much. I read the docs. at times. I do other things too. Anyway, thank you for supporting the BBBlue and the ArduCopter/ArduPilot source. I really appreciate all I have put you through to this day and you have taken it quite well. I really do appreciate it.



@Juvinski , I use to get a lot closer to flying inside at my old home compared to now. Now, currently, I am way off base.

I can get GPS to work. This is nice. I can see myself and the house I reside in on Mission Planner. All fine and dandy.

Now, w/out the motor test on the Optional Hardware testing in Mission Planner, I get nothing. No movement, no errors, nothing.

I will try to view some logs soon.


P.S. I will try the kernel and a specific binary (all of them) again. Man, I can feel the blades almost cutting me from four years back when I got it to work accidentally. I got the BBBlue to fly into the tree too.

Setback, yes sir. But, I kept trying. No cussing. I am not the smartest person but I know some things. I saw in kernel 5.10.x-rt, even though the PRU is available, that the Servo Header does not have GPIO80 available for muxing. I can mux it and the system understands the muxing (via .dts files and w/ Linux) but the .dts file for the PRU and the Servo Headers for power were not available.


Let’s go solve this.
First, what receiver are you using ? You will use a gps? Voltage monitoring ? Any i2c device ?
Second, this is more easier. You have 8 outputs on blue, this outputs is mapped as servo1 to 8 inside aeducopter - if you are using mission planner on the servo outputs you can define any output as a motor. For instance let’s say you have the front right motor on servo 1 output you need as motor3 and in the second servo output you connected the front left motor, so the servo2 must be configured at motor 1.

I think we can do this. Answer the questions and I can generate a sd card image with arducopter running with all things setup to you try, what do you think, or maybe we can schedule a discord talk and work toghether on this.


I am just whining and complaining I guess. I would rather not use your personal image for this instance. No offense. I know it is a big deal to get you to “bow down” and accept my plea. I really appreciate it. It is very nice of you.

I have GPS that works w UART2 which I think is /dev/ttyS2, four motors and they have all been mapped in MP to motor1 - 4 that show no sign of life, and the imu (i2c ?) w/ no .dts file for them and no overlays, a FrSky X8R for now w/ no power due to the .dts file not showing power on the Servo Header, and whatever else is on the BBBlue that needs calibration.

For instance, I may use a range finder for landing soon but I can map that out (supposedly).

I am not saying this does not work. I am not saying that you can make me understand it either. I am just saying there needs to be some sort of build process for people like me, the am335x user, who needs support. I saw the 2021 build on the Wiki of ArduCopter for the BBBlue.

As soon as you and whomever else made this work, I was all in. It was/is the neatest thing ever.

But! There is something I am lacking. i2c1 probably. adc maybe. UART2 works. I know this fact.

W/out using the power JST connector on the BBBlue and with using the Servo Header 6v power, how can I achieve powering my Servo Header to power my receiver?

@Juvinski … for the record. Thank you again for admitting wanting to support the cause. I appreciate it, i.e. as I like the am335x, the BBBlue, and I always wanted to fly the BBBlue via transmitter!


P.S. Aw! I will add the i2c2 .dtbo and try the older way again I guess.

@Juvinski ,

I feel like an idiot. I made some posts b/c it was a WIP item I wanted to cash in on . People love to fly around here. Tons of people. Selfish. I know…but.

This is not the end. I am too stubborn to give in just yet. You can already see why people do not want to deal w/ me. I type and type and type. Heartfelt messaging. Did I just type that out? Ha.

Anyway, thank you for putting up w/ me again and trying to make me understand what it is that I am doing that is breaking my build.


Don’t worry :slight_smile:
For me is appearing you have problems with the pru
Have you tried the sample file under tools/Linux_HAL_Essentials/pru/aiopru?

How are you powering your board, usb? Battery connector? Bare?

@Juvinski ,

Sorry to mislead you. I am sorry here. I am not officially working on it tonight. I just thought chatting about it might shed some light on what faults are mine and where I can achieve easier access to the build that works.

I have not tried to use the sample file at /tools/Linux_HAL_Essentials/pru/aiopru .

USB and a 7.4 LiPo is what I have been using for powering the board. My LEDs for the LiPo are not showing either. I think this is a sign of the kernel being used and what was developed at the time.


@Juvinski ,

I do not have uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo available in /boot/uEnv.txt as of now. The uboot_overlay_pru= section does not exist.

I installed and the beeping will not stop on my dev. desktop. I removed the other kernels via apt already.

So, when I get back to it, Mon. night most likely, I will perform the steps you have given so far with the kernel to try, the file /aiopru, and i2c2 (I think).


Hi @silver2row
When you will do the tests call me on gitter and we can try some tests together.
I never powered my blue using the battery just the bare connector on the board.
Have you have some tools , like a multimeter,a 5volts BEC or an esc with bec to power the rail? And a 5 volts servo?

Hello @Juvinski ,

Okay. I will attempt to contact you another day and soon on gitter.

I have a DMM, no BEC, and a 5v servo…


ok, I will be there.
this is to test the servos powering the servos from a BEC and not by the blue power.

1 Like


Not today. I am sorry. Maybe soon. Christmas is coming up on Sunday and everyone and their mothers have me doing something…