Made some good progress on integrating CYC1000 FPGA into betaflight running on Linux. The CYC1000 is a FPGA performing PWM decode (from cheap RC transmitter), PWM encode (oneshot125 or DSHOT), APA102 led strip and on board LED. Updated betaflight to send requests to CYC1000 to read PWM registers via libftdi1 over USB.
Here is a youtube video of betaflight showing PWM decode and IMU.
Sunday, March 15, 2020
Tuesday, February 25, 2020
Using Fast Opto-Isolated Serial Interface Mode in the FT2232H with CYC1000 FPGA and libftdi1
After learning more about FPGA programming i.e verilog, nmigen, migen, and generating test benches finally got back on finishing the Avalon bus for the quad-copter.
The core gateware is Avalon bus with slave PWM (oneshot125), DSHOT150, slave LED APA102, slave on board LED, slave PWM decoder, and general timer. The master is using Avalon bus master bytes to packet interface over Fast Opt-Ioslated Serial interface. One of the issues I was having was how to communicate from Linux to the CYC1000 board, could do standard serial, the top speed is 2Mbps, so, took the time and implemented Opt-Isolated serial interface at 25Mbps. Reading more about the interface it is half duplex, but, it is still faster than serial.
So, use the standard FTDI driver with Linux with standard tty termios, but after trying to get 1ms round trip packet processing, the CPU usage was high and still slow. I tried setting setserial /dev/ttyUSB0 low_latency, that helped but still high CPU usage.
Next was trying libftdi1, with a latency timer of 0. After a few few mod's to libftdi1, using a 100us timer to generate packets and uses 40% CPU usage. Validated the data stream using LA2016 Logic Analyzer and the rrt is 180us. So, not bad. Next is to move everything on to the orangePI plus2 H5.
The core gateware is Avalon bus with slave PWM (oneshot125), DSHOT150, slave LED APA102, slave on board LED, slave PWM decoder, and general timer. The master is using Avalon bus master bytes to packet interface over Fast Opt-Ioslated Serial interface. One of the issues I was having was how to communicate from Linux to the CYC1000 board, could do standard serial, the top speed is 2Mbps, so, took the time and implemented Opt-Isolated serial interface at 25Mbps. Reading more about the interface it is half duplex, but, it is still faster than serial.
So, use the standard FTDI driver with Linux with standard tty termios, but after trying to get 1ms round trip packet processing, the CPU usage was high and still slow. I tried setting setserial /dev/ttyUSB0 low_latency, that helped but still high CPU usage.
Next was trying libftdi1, with a latency timer of 0. After a few few mod's to libftdi1, using a 100us timer to generate packets and uses 40% CPU usage. Validated the data stream using LA2016 Logic Analyzer and the rrt is 180us. So, not bad. Next is to move everything on to the orangePI plus2 H5.
Saturday, February 8, 2020
First project on Hackster.io
Hacksterio hosted webinar "Mini but Mighty: Motor control Live Build with MiniZed" also Avnet/Hacksterio/Xilinix created a design challenge. After several days of work, entered with a project on Hacksterio. Will find out on 2/18 on the results.
Wednesday, January 8, 2020
PWM encode/decode is working using a FPGA
Tested FPGA based pwm encode/decode. Using Hobby King HK-16A V2 6 channel transmitter and decoding 6 channels of PWM from the receiver.. Encoding 4 PWM with a 1-2ms pulse width to 4 ESCs. The biggest issue generating PWM is to complete the last cycle before apply the next update.
Next step is to integrate into BetaFlight Linux Port, the goal is to be flying in a month.
All the code is on github.
Next step is to integrate into BetaFlight Linux Port, the goal is to be flying in a month.
All the code is on github.
Sunday, January 5, 2020
New logic analyzer
It was time to update to a better logic analyzer, LA2016. I have been using 8 channel original saleae. The LA2016 is a lot faster, 200Mhz and has internal storage with advance triggering.
One of the biggest issues I've been running into is tracing fast digital signals when developing FPGA code. CYC1000 uses Cyclone 10LP FPGA, have used Quartus internal logic analyzer a couple of times to trace/debug designs. But, I still like to have one around, so, the LA2016, so far it has been very handle, with a 1Mhz signal with a pulse width of 15ns was not an issue. But, also still getting up to speed on Verilog, have been working on test benches and verilator C++ test code. This way modeling and formal verification should cover most of the issues I've having debugging designs.
While debugging PWM state machine, the power supply driving my ESC tripped on overload. No, it does not power one, so, have another one on order, 12v 10amp. So, will be a little more careful.
Looks, like the PWM output should be working now, there was a glitch when setting a new PWM value, the duty cycle was going to 80% causing some ESC to stop.
One of the biggest issues I've been running into is tracing fast digital signals when developing FPGA code. CYC1000 uses Cyclone 10LP FPGA, have used Quartus internal logic analyzer a couple of times to trace/debug designs. But, I still like to have one around, so, the LA2016, so far it has been very handle, with a 1Mhz signal with a pulse width of 15ns was not an issue. But, also still getting up to speed on Verilog, have been working on test benches and verilator C++ test code. This way modeling and formal verification should cover most of the issues I've having debugging designs.
While debugging PWM state machine, the power supply driving my ESC tripped on overload. No, it does not power one, so, have another one on order, 12v 10amp. So, will be a little more careful.
Looks, like the PWM output should be working now, there was a glitch when setting a new PWM value, the duty cycle was going to 80% causing some ESC to stop.
Tuesday, December 24, 2019
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.
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.
Monday, November 25, 2019
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:
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.
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.
Subscribe to:
Posts (Atom)