Fast Serial FTDI CYC1000 FPGA board

Finally have a simple demo using 50Mhz receive working between the FTDI and Cyclone 10LP (CYC1000 FPGA board)

The goal of this project is to have USB serial working at 50Mhz (TX/RX) and have simple protocol to abstract SPI, PWM decode/encode, OneShot peripherals.

The simple demo shows the RX character value on the LEDs.

Steps:

1. git clone  https://github.com/tcmichals/cyc1000.git
2. start Quartus
3. open the fast_serial_test project
4. compile and load
5. start minicom --device /dev/ttyUSB0 
6. edit the serial port to remove hardware hardware handshaking.  It does not matter what the baud rate is.  Just start typing and the LEDs will change values to the RX chacaters.  The easiest is to use '0', '1' '0' is 0x30 then 1 is 0x31, so only one LED changes.

Also, must change the EEPROM of the FPGA to use opt serial.   For this to work.

More to come.  Next is TX. 

Fast Serial mode FTDI (CYC1000)

Making progress on getting fast serial mode working on the CYC1000.  The first step was to create some verilog code to route signals out to a header to validate the data using a saleae Logic Analyzer, also generate a clock.

Configured port B to opto-ioslate and keep the driver virtual serial port.  This allows Linux to standard serial over USB but the FTDI converts the serial stream into fast serial using the mpsse. 

Learning Verilog with the CYC1000

Finally getting comfortable writing some basic verilog code to walk the LEDs on the CYC1000 FPGA board.

I started with using Quartus WIN10 VM (using VirtualBox) and moved to Linux with Quartus 18.1 Build 625.  Had to over come a couple of basic issues with Quartus on Linux:

1. Renamed /quartus/linux64/libstdc++.so to ./quartus/linux64/libstdc++.so.old for some reason, the library paths are not right when loading, will look at the more in the future.
2. Some of megafunctions lock up, so, resize the dialog before moving to the next option or entering any values.

 I have not tried in simulation, but compiling, loading to SPI Flash or to the FPGA works fine.

The first example was a simple walking LED and has a loopback for the RS232 for the FTDI chip.

The CYC1000 is connected to the Channel A and B of the FTDI FT2232H.  Channel A, is for JTAG and Channel B is RS232/HighSpeed Serial/Or SPI.

To get /dev/ttyUSB0 working, need to change the 51-arrow-programmer.rules to remove deleting the serial interface.

# Interface number zero is a JTAG.
# SUBSYSTEM=="usb",\
# ATTRS{idVendor}=="0403",\
# ATTRS{idProduct}=="6010",\
# ATTR{interface}=="Arrow USB Blaster",\
# ATTR{bInterfaceNumber}=="00"
# RUN="/bin/sh -c 'echo $kernel > /sys/bus/usb/drivers/ftdi_sio/unbind'"

The end project is to use the protocol over the serial interface over USB to control:

• SPI Master
• Controlling a LED strip
• 6 channel PWM decoder
• 4 channels of OneShot 150/42
• 4 channels DSHOT
•  I2C A/D converter 

The RS232 loopback is working at 3Mbps using minicom.  The next project will be getting a Serial RX/TX/FIFO working.

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.