I/O processor status

Completed PWM input decode and sending results via USB.  For the first pass I'm using a HK-T6A transmitter/receiver.

Overall Status:

• I/O processor:  GD32F103 (red pill board) 
• Interprocess commuinication via USB complete
• Receiver PWM decode
• GPS decode
• Next is to do PWM for motor control
• Standard PWM out
• Support one shot125
• Need validate USB jitter and performance
• Out should be less then a 1ms
• In should be no more then 2ms
• Cleanflight
• Update IPC using USB
• Add socat for CleanFlight Configuration Web Tool
•  open a TCP/IP port in CleanFlight 
• use socat on Linux to forward MSP packets.

CleanFlight port to PI Zero

Finally have MPU-9255 and MS5611 sensors working and a simple CLI on the command line.  It is simlar to CLI via serial port or CleanFlight configurator.

Here is the output:
linuxflight>tasks
Task list          max/us  avg/us rate/hz maxload avgload     total/ms
 0 -       SYSTEM      29       0       9    0.5%    0.5%         0
 1 -     GYRO/PID     748     145     848   63.9%   12.7%       743
 3 -       SERIAL      71       1      93    1.1%    0.5%         1
 5 -           RX       0       0   2147483647    0.5%    0.5%         0
linuxflight>tasks
Task list          max/us  avg/us rate/hz maxload avgload     total/ms
 0 -       SYSTEM      31       0       9    0.5%    0.5%         1
 1 -     GYRO/PID     886     176     801   71.4%   14.5%      5864
 3 -       SERIAL      73       1      88    1.1%    0.5%         9
 5 -           RX       0       0   2147483647    0.5%    0.5%         0
linuxflight>

I'm going to switch to linenoise for controlling line processing to allow up and down errors etc. 

Need to fix how average is calculated, but making progress.  Need to reconnect the I/O processor to get GPS, pwm out, s.bus in, and S.Port.

The goal is to use socat where configurator is running to expose a virtual serial port and forward the packets to "LinuxFlight".

Still working on CPU performance and getting GPIO to trigger for gyro-sync.

Here is top:

Here is the CLI on the PI Zero:

The command line is using boost ASIO.  Goal is to add the socat protocol so configurator can still access and configure "LinuxFlight" ;)

Yes, I'm thinking of forking the code, due to the amount of changes to the core.  Right now, there are very minimal.

Progress PI Zero Flight controller

I have BetaFlight ported to the PI Zero, but opted to move to CleanFlight due to the latest code check-in.  There are several APIs that are abstracted to make porting to Linux easier. The basic idea is to use LINUX #define to comment out micro-controller specific code and add XXX_linux.c drivers for SPI, I2C, serial, pwm, etc.   Still going to stick with boost ASIO for scheduler, still based on timers (timerfd). 

The SPI communication to the GD32F1 is progressing:

• GPS handling, moved baud rate, GPS update rate to GD32F1
• Simplifies command/processing and speed
• Working on PWM decoding (PPM/PWM)
• Working PWM encoding 4 outputs

Have SPI working with MPU-9255 at 8Mhz from the PI Zero.  

Still pending:

• Cannot find any more "red" GD32F103 board might have to move to another board
• Transmitter
• Turnigry 9xr pro?
• Radiolink at 10
• The main difference between the two are:
• Telemetry s.bus vs i2C 
• Have to buy another receiver Radiolink to have s.bus and i2c telemetry (R9DS) which is another $13.
• Radiolink is not open source but many ports and docs on decoding i2c for telemetry. 
• Radiolink has sliders 9xr pro does not
• HK shipping costs and pricing changes. 
• Thoughts?

Progress on I/O processor for PI Zero/Orange PI

Made progress this week on I/O processor:

1. PI zero CPU usage is down to 2% 
1. Using DMA 64 byte packets 
2. Sending two packets for one transaction 20us apart
1. SPI rx/tx buffers are sent each clock, so, two transactions are needed., first transaction is CMD (Write/Read) elements the second is the response with the read data.  
2. Updated I/O processor to use FreeRTOS v9.0.0.0
1. Fixed interrupt priority issue causing lockup
2. Adding I2C for LCD
3. Need to test GPS serial 
4. Adding PWM generation 

Here is a trace of a single transaction (CMD)/Response.  It takes .261ms to complete a CMD.  The I/O processor can process the command and re-trigger the DMA in less then 30us (Channel 04)

PI zero vs GD32F103 DMA SPI Transfers

I would have never have guessed that a 106Mhz microcontroller can run circles around 1.xGhz ARM11 using SPI DMA transfers of 256 bytes.

So, what I'm I talking about?

• GD32F103x is running at 106Mhz and using DMA for SPI and is configured as a slave.
• PI Zero is a Master (maybe is using DMA transfers) SPI.  
• SPI rate is 12Mhz (Close)

So, here is a logic analyzer trace:

Channel 4 is the GD32F103 raising the pin high at the top of the loop and lowering the pin after the DMA is configured waiting on the PI.

Using top to monitor CPU usage on the PI Zero:  spiExample, is taking 41% cpu usage (ouch).

Mem: 26956K used, 381340K free, 52K shrd, 1336K buff, 8332K cached
CPU:   0% usr  81% sys   0% nic  15% idle   0% io   0% irq   1% sirq
Load average: 1.41 0.80 0.61 1/97 247
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  244   202 root     R     3412   1%  41% ./spiExample
   71     2 root     SW       0   0%  10% [irq/56-dwc_otg]
   73     2 root     SW       0   0%   8% [irq/56-dwc_otg_]
  130     2 root     SW       0   0%   7% [spi0]
  127     2 root     SW       0   0%   6% [irq/44-DMA IRQ]
  128     2 root     SW       0   0%   5% [irq/45-DMA IRQ]
   72     2 root     SW       0   0%   5% [irq/56-dwc_otg_]
  247   202 root     R     2476   1%   1% top
    3     2 root     SW       0   0%   1% [ksoftirqd/0]
    4     2 root     SW       0   0%   0% [ktimersoftd/0]
   84     2 root     SW       0   0%   0% [irq/81-uart-pl0]
  133     1 root     S    20892   5%   0% /usr/sbin/vcfiled
  148     1 root     S     4144   1%   0% wpa_supplicant -B -i wlan0 -c /etc/wpa
  202     1 root     S     2476   1%   0% -sh
  203     1 root     S     2348   1%   0% /sbin/getty -L tty1 0 vt100
    1     0 root     S     2344   1%   0% init
   99     1 root     S     2344   1%   0% /sbin/syslogd -n
  101     1 root     S     2344   1%   0% /sbin/klogd -n
  201     1 root     S     2344   1%   0% udhcpc -i wlan0 -t 10 -b
  124     1 root     S     2208   1%   0% /usr/sbin/dropbear -R

Need to look into this:

• Is the Pi Zero using interrupts for SPI (according to /proc/interrupts) no, it is only using DMA
• Is it PREMPT_RT kernel? 
• Doing some more testing it is setting a time between two back to back SPI packets.  But, it only lowers the CPU to 18% on the PI Zero.
• The GDF32F103 only takes 62us to copy memory for slave and reload DMA buffers. 

Well, next is to connect GPS, PWM (oneshot and decode) on the GD32F103.

Review, the GD32F103 is a I/O processor handling the following:

• PWM generation for the motors
• PWM/PPM decode RC transmitter
• I2C for LCD (Want to be able see status codes)
• (1) LED on the GD32F103 board for general status. 
• RS232 GPS
• SPI slave device to the PI Zero 
• The poll rate will be about 500hz
• PI zero is running BaseFlight/HackFlight.   

Anyway,  so, this week will be processing GPS, 

New quadcopter under development (Linux/Neo/OrangePI)

Finally have a new quadcopter design:

• Frame; 260mm with LEDs
• Motors/ESCs/props; 2205 @2300kv with 20apm ESC
• Transmitter/receiver Quanum i8 8ch AFHDS 

estimated cost: $215.00

If you notice, there is no Flight Controller; the last one was a Teensy 3.1 with BaseFlight; well this time it will be Linux as Flight Controller OS with micro-controller decoding PPM/PWM and generating the PWM out for the ESC.

Which board?  Udoo Neo will be the first one, the second board will be a Orange PI.  The goal is to use Linux with PREMPT enabled.  Did some initail testing with OrangePI with 4.6-rc4 and was able to generate a 50Hz square wave while running stress-ng, with no issues! 

Using the Neo first because has a A9/M4 the Orange PI will need an external micro-controller.  

So, how to port BaseFlight to Linux?  

1. Basics
1. I2C: will use /sys/class/i2c
2. SPI: Not supported yet; will get into that little latter
3. PWM: (M4 Neo, OrangePI micro-controller)
4. PPM/PWM deocde: (M4, OrangePI micro-controller)
5. Software/Framework
1. Boost ASIO
1. asio offers as async/event loop
1. High performance timers
2. Support for serial events
3. Support for network events
4. Add support for DIO interrupts
2. Boost logging
1. integrated
3. BaseFlight
1. has a single poll loop to process events
1. Will move each of these events to asio event:
1. Serial: for GPS / Baseflight configurator
2. Timer: process loop for FC
3. Network: External WIFI (NEW)

Why not use use Ardcopter or TauLabs?  This is a first pass and will be moving to one of them on the next round. Already have ported BaseFlight to Teensy 3.1; so already familiar with the code.

Which Kernel?  Right now, the Udoo Neo is 4.5 with some patches for RPMSG.  OrangePI, did some testing with 4.6-rc5; but waiting for more patches to go into mainline; so, 4.7.

BaseFlight has been ported to Linux; just debugging I2C; then pull apart main.c /loop and move to boost asio.  Will post the modifications in a few weeks.  Right now, getting Udoo Neo RPMSG working in 4.5.  

Udoo Neo booting mainline v4.5

I've several projects going on with the Udoo Neo that required new version of the kernel; i.e adding several wifi adapters to create a router on different channels and mesh network.

Anyway, to get mainline working, need to move several of the udoo_neoo dt files and edit them.

Using mainline several issues arise:
- Support for HDMI driver; rpmsg, NTSC camera, etc.

For this project I just need rpmsg and NTSC camera.  So, over the next few weeks will be posting how and creating patch files using buildroot to create a bootable Linux image.