CYC1000 decoding PWM

Finally got back to CYC1000 board, been working on C++ interface to fast serial with the FTDI and FPGA, its working at 20Mpbs via USB.  The biggest issue was getting TTY to respond faster that 10ms.  So, on Linux one simple way is to use setserial command for low latency, i.e.
setserial /dev/ttyUSB0 low_latency

Now, it is possible to process receive/transmit faster then 10ms. So, using Avalon Master, able to send Read/Write commands at a maximum round trip of 2ms. The issue is still Linux, at the FPGA measure 2us round trip (send/process/transmit)

Connected up my old HK-T6A receiver to the CYC1000 and able to decode 6 channels of  PWM and send back to the PC at 10ms.  It takes 20ms for the HK-T6A to cycle over the 6 channels. So, 10ms is a good poll rate. 

One way to get rid of polling is to use a Avalon stream and send PWM with out sending a read request.

So, the next step is to get PWM generation complete then should be ready to merge with Linux based BetaFlight.  See how responsive it is. 

I was able to add a transistor on the Orange PI Zero Plus2 so, now the H5 is running at 1.7Ghz per core without throttling.   The goal is to have BetaFlight running and sending packets to the FPGA at 400Hz. 

Might have to go around tty and use to the FTDI API.  But, I might ditch the how project and use a Zynq processor. Maybe the QMTECH board. Maybe some can send me one ;)  Instead of using USB, now just have PWM encode/decode in the FPGA block.  I have a DSHOT written, but, first simple PWM.  Then, move to DHSOT once the latency of 2ms can be reduced to 300us or so.

I'm still working on ditching Avalon and moving forward to use a RISC-V processor to serialize/de-serialize packets.  I'm thinking of trying the SweRV Core EL2, for size and simplicity.

Remote debugging via GDB using VSCode

Slowly making progress on getting Betaflight working on Linux on an orange PI zero-plus2 board. 

During porting I've been using VSCode, it is a nice tool works on Linux and Windows.  Also, with some configuration allows me to xcross debug Betaflight via gdb on the orange PI board.

How is this done?  First need to create a configuration to start the gdb on the host, in my case it is Ubuntu running on x86 processor.  Here is the launch.json:

{

"name": "C++ Launch gdbserver",

"type": "cppdbg",

"request": "launch",

"program": "${workspaceRoot}/obj/main/betaflight_LINUX.elf",

"miDebuggerServerAddress": "192.168.1.20:9091",

"args": [],

"stopAtEntry": true,

"cwd": "${workspaceRoot}",

"environment": [],

"externalConsole": true,

"linux": {

"MIMode": "gdb",

"miDebuggerPath": "aarch64-linux-gdb",

},

"osx": {

"MIMode": "gdb",

"miDebuggerPath": "aarch64-linux-gdb",

},

"windows": {

"MIMode": "gdb",

"miDebuggerPath": "aarch64-linux-gdb",

}

}

So, this will is the aarch64-linux-gdb that was compile using build root and the ARM target file Betaflight_LINUX.elf file.

On the target, Orange PI Zero plus 2, I use ssh to start a gdbserver session.  Using the following command: # gdbserver :9091 obj/main/betaflight_LINUX.elf 

this allows the host to attach to gdbserver to debug the app on the target. 

I use rsync to copy changes from x86 to orange pi.  So, after finding the issue, edit the code using VSCode, cross compile, rsync the start gdbserver. 

I was going to add ssh to the launch, but, I tend to forget to do rysnc.   Post any questions.

Oh, using gdb and VSCode allows you to set break points in SRC and debug on the remote target.  Nice, the only issue is restarting a debug session requires you to manually restart gdbserver on the target. 

If you have questions let me know.   Right now debugging why IMU is not being found using SPI. 

CYC1000 example using Python and Fast Serial.

Updated the github for CYC1000 project (example_project).  The project has the following features:

• Uses Serial port using Avalon byte protocol to access the Avalon master.
• The Serial port is using the FTDI Fast serial mode, the FGPA Clock is 12Mhz, so the bus is running at 6mhz. 
• Mapped two Avalon slaves:
• LEDs
• APA102 Blinkt LED bar

The Python example is able to toggle either the on board LED or the Blinkt LED bar.

Moving forward to PWM decode.

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.