Navio+ and RPi2 image


I have been trying to use Navio+ with the new RPi2 image (emlid-raspbian-20160718.img). I tried to run the PPM_decoder example from the Navio git repository (not from Navio2 repo). When I sudo ./PPM in the PPM_decoder directory, nothing happens, but I can see the process running from htop. From what I understand of the code, I’d expect it prompting the values coming from my Rx (Rx PPM signal is ok, and I installed pigpio).
Then I tried to run the python Servo example. There, I get a message saying that /sys/class/gpio/gpio27/direction can’t be found. In deed, the directory doesn’t exist. And when I try to echo 27 > export in the directory /sys/class/gpio, it says something like “Device is busy”. I guess the pin GPIO27 (and maybe others) are already used by routines launched at boot…

So, I wondered :

  • Is my RPI2 image compatible with Navio+ “out of the box” ?
  • Are the examples in the Navio repo of any relevance for my hardware setup ?

And more generally :

  • What does the rcio_worker process exactly do ? Is it necessary to run it with Navio + ? I assumed it would be bound to the presence of the RC-coprocessor on Navio2…
  • What makes the RT patch unnecessary in the newest images ? Is it related to the different RCI/O management of Navio2 ?

Sorry for the fuzzy topic, but I get the feeling my questions are somehow related to each other and I wish to have a better understanding of what’s happening.

Thanks !

Sure, they are all connected! I’ll try to answer them the best as I can.

It’s not the newest. Take a look at the beta.


Yes, of course.

Let’s get to the meaty stuff.

Yes, it’s Navio 2 specific. It doesn’t do anything on Navio. You can blacklist rcio_spi or remove dtoverlay=rcio from /boot/config.txt if you want to.

We run PREEMPT kernels. They can deal with the necessary load quite alright.

Thanks for asking. That is indeed a minor bug on Navio+. It doesn’t really stop you from using with ArduPilot, though. You can also edit /boot/config.txt end remove dtoverlay=navio-rgb. This will stop Device busy errors from showing up and hence make it possible to run the examples.

I hope I made it clear.

Thanks for your answer !

Indeed, I noticed that commenting out dtoverlay=rcio and dtoverlay=navio-rgb in /boot/config.txt solved my problems, but I wasn’t really sure it was good practice to do so.
Could you also explain that we have i2c-dev in/etc/modules and not spi-dev (in the RPI2 RT image, there also was something like spi-bcm2708) ? I guess it has to do with what’s in the /boot/config.txt and the fact that these processes are launched as overlays, if that makes any sense (I’m not a software engineer as you could have guessed) ?


Awesome job figuring out all that by yourself!

These have been set there as default values because that is the least common denominator, so to day, for Navio+ and Navio 2 to make almost everything work as expected. There wasn’t also a proper way to manage differences between the two at runtime at time of the launch. It is also the safest option. So, I guess it’s there to stay. But we’ll add a proper information regarding the topic in our docs. Thanks for noticing!

It boils down to the fact that bcm2709-i2c driver is not fully DT-capable (DT is for Device Tree). That’s why it is essential to load i2c-dev manually. It will be fixed in newer kernels.