3.14 Beaglebone and PRU

Spent the weekend getting 3.14.19 and builtroot up and running.  For the past month I've been using 3.17 version from kernel.org.  But this version did not support uio or remoteproc without some patches.  The beaglebone Debian is moving to using the kernel from TI 3.14.19, this kernel has patches for remoteproc support for PRU.

So, what does remoteproc support do?

• The kernel will auto load PRU0 and PRU1 if there are images in the /lib/firmware directory.  Here is a snippet from kernel boot:

[    4.141922]  remoteproc0: wkup_m3 is available

[    4.146591]  remoteproc0: Note: remoteproc is still under development and considered experimental.

[    4.156581]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

[    4.171128] pruss-rproc 4a300000.pruss: creating platform devices for PRU cores

[    4.179184]  remoteproc0: powering up wkup_m3

[    4.183806]  remoteproc0: Booting fw image am335x-pm-firmware.elf, size 154768

[    4.196764]  remoteproc1: 4a334000.pru0 is available

[    4.202978]  remoteproc0: remote processor wkup_m3 is now up

[    4.209029]  remoteproc1: Note: remoteproc is still under development and considered experimental.

[    4.218660]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

[    4.230579]  remoteproc1: failed to load rproc-pru0-fw

[    4.236211] pru-rproc 4a334000.pru0: booting the PRU core manually

[    4.242935]  remoteproc1: powering up 4a334000.pru0

[    4.248576]  remoteproc1: request_firmware failed: -2

[    4.253862] pru-rproc 4a334000.pru0: rproc_boot failed

[    4.259804] pru-rproc: probe of 4a334000.pru0 failed with error -2

[    4.267368]  remoteproc2: 4a338000.pru1 is available

[    4.272810]  remoteproc2: Note: remoteproc is still under development and considered experimental.

[    4.282292]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

[    4.293770]  remoteproc2: failed to load rproc-pru1-fw

[    4.299574] pru-rproc 4a338000.pru1: booting the PRU core manually

[    4.306039]  remoteproc2: powering up 4a338000.pru1

[    4.311536]  remoteproc2: request_firmware failed: -2

[    4.316818] pru-rproc 4a338000.pru1: rproc_boot failed

[    4.322460] pru-rproc: probe of 4a338000.pru1 failed with error -2

The kernel attempts to load rptoc-pru0-fw and rproc-pru1-fw.  At this time, there is no files, so it fails to load.

One other important issue, is, capemgr is not supported.  There is a nice project at github I'm going to start to use the the config-pin to setup digital lines for LEDs and interrupt from BMP180.  

• using uio the firmware needs to be in tow parts, data and binary.  Now, using remoteproc, it can be in the elf file format. 

• There are a couple of projects that use PRU remoteproc to DMA messages between the A8 and PRU.  

For this project, it will be a simple shared memory access from userspace to PRU memory to read a list of PWM decode values.

I'm using the github 3.14 branch and using the defconfig bb.org_defconfig.

The plan over the next few blogs to to get a simple PWM decode app connection to a hobbyking receiver. 

Here is a quick diagram.   

Quad copter (BeagleBone and Teensy 3.1)

I've started two quad-copter projects:

• Teensy 3.1 as the flight controller
• HobbyKink 250  kit 
• Triple Axis Accelerometer and Gyro break out
• Triple Axis Magnetometer Breakout
• HK transmitter and receiver
• Baseflight and Baseflight-configuration

The second quad-copter:

• BeagleBone (white)
• Old IMU from Sparkfun
• Flight firmware is BaseFlight and a clean port of MultiWii

The Teensy/250 quad is flying well, the motors in the kit are a little to under power to lift anything but it is a great way to learn the software and quad-copter basics.  Will show more pictures and a basic tear-down. 

The BeagleBone (white) has a lot of advantages out of the box, i.e simple debugging via gdb on board, lots of memory, and easy of developing on Linux.  BaseFlight-Configurator application reports the loop time in microseconds, it is a little more jittery then Teensy 3.1 but within reason. Will report the actual numbers soon.

The basic interfaces for beaglebone:

• I2C: Sensors and LCD interface
• This is up and working and plotting in the GUI.
• PWM decode input
• Using PRU (starting to code this now)
• Using the PRU keeps the Linux code clean.  Maybe after this is done, try to see if it can be done using a kernel driver.  
• PWM generation for ESC control
• This is using the internal ehwpwm via the sys
• Serial Port
• 115200 to Baseflight-configurator
• Using buildroot
• Linux 3.16
• Enabled SMP with realtime scheduler
• (Will update to use new buildroot, just added the pru package)
• Since cape-mgr is not supported in the new kernel, will provide a device tree and simple start up scripts. 

The goal is to re-code the loop and break it up to several loops using discrete timerfd for each loop and libev as the interface.  General coding for this has started, but, since the basic polling loop is working, the only big block to do is the PWM decode.  

The goal of porting to the BeagleBone is to then port to the Edison Intel board.  But, Intel has no RTOS support for Quark processor.  Once this is done, it should be easy to port Baseflight and run it on the Quark and keep the Atom processors Linux, to do Vision and flight navigation.  

More to come.... 

The tractor

Finally got it all together:

The goal was to use a phone or tablet to control the RC car/tuck/tractor via a web browser using touch events via WIFI.    This way, only one app is needed, no need to learn IOS, Android, or worse NOOK API.

So, to do this, the phone/tablet would need to be a hot spot or the RC "tractor" needs to be a hot spot.  iPhone/iTouch don't support being a hot spot, plus being a hot spot does drain the battery life.  So, the RC tractor needs to be a WIFI hot spot/access point.  Most newer USB WIFI dongles support SoftAP mode in the hardware.  Linux also provides support for this via hostapd.  More about this later..

Parts list
- Chassis
- Motor controller
- SBC (Linux single board computer)
- Battery pack
- USB Hub
- USB Wifi stick (Belkin) supports softAP

Controller
- Web Server
- daemon task to process  httpXMLRequests (There is a way to resolve the CORS issue)

Update:
- Changed the Wifi to a bluetooth USB.  This makes it easier to control outside in the sun.

Here us a very basic wiring diagram:   Changed the web client app to use the cwiid interface and use a basic wiiremote with classic controller.