New FPGA boards

I'm constantly looking for new SBC and FPGA boards.  Here are a couple links:

• Alchitry: Digital Design Simplified Xilinx Artix 7 XC7A35T-1C  and iCE40 
• Cora Z7-10 Z7-07S Zynq boards 
• MKR Vidor 4000 board
• CYC1000 with Cyclone 10 FPGA, 8 MByte SDRAM
• MAX1000
• If local to US Arrow also stocks this board. 
• SBC
• Renegade Elite
• RK3399 Rock chip processor.  Quad-core A53 and Dual-core A72.

Xilinx and MiniZed board

Finally have a simple demo running on the PL (programmable logic) blinking the Red and Green LED.

Getting up to speed using Zync-7000 and Vivado (GUI) tool takes some time to get up to speed on.  Several weeks ago I took the the SpeedWay class, that was a great way to get an overall overview and help get a start on the MiniZed board.

Here is the led.c verilog (yes simple)

module led
#(
    parameter WIDTH = 24
   )
   (
    input wire Clk,
    input wire Reset,
    output  LED_G,
    output LED_R
    );
   
 integer counter = 0;
 reg LED_G_reg=0;
 reg LED_R_reg=0;
 
 assign LED_G = LED_G_reg;
 assign LED_R = LED_R_reg;

 always @(posedge Clk) begin
    /* if (Reset ==1 ) begin
        counter <= 0;
        LED_R_reg <=0;
        LED_G_reg <=0;
     end
     else */begin
 
            counter <= counter+1;
            LED_R_reg <= counter[23];
            LED_G_reg <= ~counter[23];
        end             
  end

endmodule


Some tips

• Linux with Wayland causes Vivado crash.  To work around this use X, hope they will fix it.
• Using a constraint file you must declare the output on the net list.  If not the block will not be generated.
• The Zynq PS clocks are used to drive the PL, so, must have a simple ARM program or init script to start the clocks.
• The MiniZed board is nice to use, low cost and has a lot of features to start learning FPGA or ARM (Linux or RTOS(FreeRTOS))

I can do a simple hello tutorial if requested.

Next steps:

1. Create a SWO trace/Serial Wire Viewer (SWV) demo on STM32 use using debug messages. Validate it is working using a logic anaylzer 
2. Create FPGA code to decode the Manchester bit stream and send it via DMA to the ARM-9 Cortex on the 

FreeRTOS trace HW/SW with nw.js application

While working on CleanFlight Linux with a I/O micro-controller for extra peripherals, there is no straight forward way to get performance, trace, and general information about the state of the firmware on the micro-controller.


Goal:

• Provide an open source solution to get metrics on the firmware using traceSWO port.

Implementation:

• Use FreeRTOS trace messages and send them out one of the channels of SWO port
• Also allow setting ETM tracing
• Create a GUI (nw.js) and command line tools to parse and show trace data from FreeRTOS
• GUI will show live line/bar charts of Task performance and I/O
• python tools to parse/mine data allows custom reports.

I have several GD32F103C8 red boards, use these to decode the SWO and send trace information to nw.js application.

Thoughts? suggestions? 

Cleanflight port to Linux (LinuxFlight) status

Created a new CLI (command Line Interface) module based on C++ and uses msgProtocol for subscribing/publishing messages.  This allows components (bash shell) or transports (UDP/TCP (Configurator)) to use the CLI at the same time.  So, now one instance of CLI can process messages from anywhere. For example: Linux has bash shell so, it would be nice not to startup Configurator to get basic info.  Use the bash shell

Here it is:
LinuxFlight>help
status - show status
help
tasks - show task stats
version - show v
LinuxFlight>status

System Uptime: 274 secondsVoltage: 0 * 0.1V (0S battery - NOT PRESENT)CPU Clock=500MHz, GYRO=MPU9250, ACC=MPU9250, MAG=AK8963
Stack size: 790724, Stack address: 0xc10b0CPU:0%, cycle time: 23226, GYRO rate: 43, RX rate: 282, System rate: 10Arming disable flags: TH
LinuxFlight>tasks

LinuxFlight>tasksTask list             rate/hz  max/us  avg/us maxload avgload     total/ms
00 - (         SYSTEM)     10       3       1    0.5%    0.5%         0
01 - (            PID)    444   22177     523  985.1%   23.7%      1270
   - (           GYRO)    889
02 - (          ACCEL)    997   21337     723 2127.7%   72.5%      1822
03 - (       ATTITUDE)     99     327      14    3.7%    0.6%         5
04 - (             RX)    143     166      36    2.8%    1.0%         9
05 - (         SERIAL)    101      87       4    1.3%    0.5%         1
08 - (BATTERY_CURRENT)    149      41       2    1.1%    0.5%         0
09 - ( BATTERY_ALERTS)      4       7       2    0.5%    0.5%         0
10 - (            GPS)     99     129       6    1.7%    0.5%         2
11 - (        COMPASS)     39   22825     756   89.5%    3.4%       158
14 - (      TELEMETRY)    255      39       2    1.4%    0.5%         0
15 - (       LEDSTRIP)    101    2522      74   25.9%    1.2%        30
RX Check Function                   0       0                         0
Total (excluding SERIAL)                      3239.9%
LinuxFlight>


Next is to get the battery voltage reporting and figure out the issue with the loading.

Might have to try the RT kernel but, first load LinuxFlight on to its own processor.  Also, might have to remove CPUFREQ it is known to impact realtime performance.

CleanFlight on Linux using micro-controller for PWM/LCD

Finally have micro-controller sending PWM from a HK-T6A to Linux version of CleanFlight. 

Created a new protocol (protocolMsg), allowing to route messages between software components over UDP or within the app via message bus.

For example, CleanFlight has a PWM parallel RX IO software block and PWM RX driver block.  The PWM RX driver block was replaced with a PWM client protocolMsg handler, the micro-controller is a PWM server protocolMsg handler.  The messages are routed via UDP over USB.  

The goal is to update CleanFlight  CLI and msp to handle message processing from multiple transports, i.e. serial, UDP, TCP. 


CleanFlight Configurator is proper showing receiver status. USB/UDP is running at 28Kb/s for RPM messages.

To Do list:

• validate new Linux serial driver
• a simple libevent shim (same as UDP/TCP shim)
• used for GPS
•  validate new lcdStrip Shim
• allows routing LCD strip messages (LED RGB) to be routed to micro-controller.
• write dshot  shim
• allow sending sdhot motor messages to micro-controller

OrangePI Zero overlay and uboot/armbian

The Armbian has good documentation about how to use device overlays for their uboot scripts.  I wanted to dive a little deeper and understand some of the basics and still use buildroot.

Boot process of uboot, there is a file on the FAT partition boot.src, this is a binary file generated by mkimage.  The source file is in board/orangepi/orangepi-zero boot.sh:
setenv fdt_high ffffffff
setenv load_addr "0x44000000"
echo "Boot script loaded from ${devtype}"

setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait

fatload mmc 0 $kernel_addr_r zImage
fatload mmc 0 $fdt_addr_r sun8i-h2-plus-orangepi-zero.dtb
fdt addr ${fdt_addr_r}
fdt resize 65536
setenv processorName sun8i-h3-
setenv overlays i2c0  spi-spidev
for overlay_file in ${overlays}; do
    echo " looking for  ${processorName}${overlay_file}.dtbo"
    if fatload mmc 0 ${load_addr} ${processorName}${overlay_file}.dtbo; then
        echo "Applying user provided DT overlay ${overlay_file}.dtbo"
        fdt apply ${load_addr} || setenv overlay_error "true"
    fi
done


bootz $kernel_addr_r - $fdt_addr_r

So, what happens is the device tree overlays are merged in uboot with the dtb file loaded for the board using fdt command line tools.  This allows to change the board dtb without always recompiling it.

Post any questions you have.   So, spi and i2c are now using device tree overlays.

Here is the overlay for SPI:
/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun8i-h3";

    fragment@0 {
        target-path = "/aliases";
        __overlay__ {
            spi0 = "/soc/spi@01c68000";
            spi1 = "/soc/spi@01c69000";
        };
    };

    fragment@1 {
        target = <&spi0>;
        __overlay__ {

            #address-cells = <1>;
            #size-cells = <0>;
            status = "disabled";

            spidev@1 {
                compatible = "linux,spidev";
                reg = <0>;
                spi-max-frequency = <1000000>;
            };
        };
    };

    fragment@2 {
        target = <&spi1>;
        __overlay__ {

            #address-cells = <1>;
            #size-cells = <0>;
            status = "okay";

            spidev@2 {
                compatible = "linux,spidev";
                reg = <0>;
                spi-max-frequency = <25000000>;
            };
        };
    };
};


so, this completes the task of using overlays.  Next DHCP and zeroconfig.

Also, have a modification to EEM USB handler, to improve performance.  Also, thinking of adding a way to use several packets at once based on the size of the packet.

Merge latest changes from Cleanflight

Updated the repo with the latest CleanFlight changes, the merge compiled and ran on x86.  I'm in the middle of updating OrangePI buildroot to use some patches from Armbian and start using device tree overlays.  This makes it easier to add I2C etc without changing the orangePI zero DTS. More on that in the next couple of posts.  i.e basic device overlays using uboot via fdt commands.

Cleanflight configurator is working, the imu processing was not enabled, so, now the graphic is now updating.  

Also move the process to a core, using cpu isolation   (via taskset, etc) to reduce jitter.

Also, working on using dnsmasq as a dhcp server with mdev, this allows I/O board to get a IP address and try zeroconfig/DNS-Based Service Discovery.  The goal is to use names, instead of hard coded IP addresses, so when moving to WiFi networking there will not be a conflict.   Confusing?  I'm too ;)

Updated the I/O EEM packet handling to increase the performance, takes about 23us per 64 byte USB packet.  The goal is to have a 512 UDP packet take less then a 1ms. 

Looked at the GPS handling, right now, GPS parsing is handled on the I/O card, tho goal being to reduce processing in the main loop.  Still looking at the code and how RTH and stabilization process the GPS information.

Tasks Order:

• Update Kernel/u-boot to use overlays
• 4.13 kernel is booting along with u-boot (Now)
• updating boot.src to process device tree overlays  (in progress)
• Dynamic IP addressing 
• Test DHCP server first
• Add zeroconfig with MDNS on lwIP 
•  
•  Retest EEM USB Ethernet
• Add LED API 
• Cleanflight uses two LED APIs will use the basic one, i.e 3 LEDs and test the speed of UDP updating LEDs from Linux
• Add PWM reciever API
• The I/O is processing PWM from receiver, will forward this info onto Cleanflight  validate the configurator is working.