Need to install QT
sudo apt install -y qtcreator qtbase5-dev qt5-qmake cmake
Open terminal and use
cd <to where the gowin tools are>
there should be a bin and library dir then
export LD_LIBRARY_PATH=$PWD/lib
cd bin
./gw_ide
Need to install QT
sudo apt install -y qtcreator qtbase5-dev qt5-qmake cmake
Open terminal and use
cd <to where the gowin tools are>
there should be a bin and library dir then
export LD_LIBRARY_PATH=$PWD/lib
cd bin
./gw_ide
The Pi Zeros only have two serial ports, only one can be mapped to the GPIO pin header at a time. So, how to free up the serial port for a user/app to use?
This is for a buildroot generated file system.
The edit cmdline.txt:
root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200
Sipeed is selling a M1s Dock at several places pricing is around $13USD. The main processor, has uses the BL808 which has 3 processors:
(This is still work in progress but wanted to publish it and keep working on it)
The Raspberry PI zero has a good price performance ratio, the 2W even better. I have been working on porting BaseFlight (Flight controller software for STM32 micro-controller) to Linux running on the PI. The code is working with a MPU9250.
The hardware will be a PI Zero or a PI Zero 2W (Still need one), SPI0.0 to the IMU, the SPI0.1 connected to the FPGA. The FPGA will create the signals needed for OneShot, decode 6 channels of PWM (I have an old Transmitter that supports 6 channels of PWM), and LED controller.
Will be using the CS7Mod, its small, has 4 LEDs and 1 RGB. LEDS will be used for status indication for BaseFlight.
So, what will be the communication protocol over SPI? Simple Wishbone bus instructions, Read/Write using address and data.
The WishBone master is interface to the SPI Slave, so the PI Zero will be the master. Here is commands for a read and write
Python is a great tool to create simple/fast test code, combine that with libgpiod, now you can toggle and monitor gpio pins.
In recent Linux kernels libgpiod is a library to write C/C++ and Python to toggle and monitor general purpose pins. There are plenty examples for python. I use buildroot to create a Linux distro, one option under hardware is to install libgpiod and if you have python3 selected now you can write python scripts.
Here is two basic classes gpiowrapper.py:
The EventPin class can be used with asyncio to wait for Edge Triggered GPIO. The key line is adding file descriptor of the event pin to asyncio and perform a callback when the FD is changes and push the event into a queue so await can be used.
Here is a simple blink.py:
Load both files onto the Orange PI Zero.
python blink.py -chip gpiochip0 -opin 1 --epin 0 --event True
This will use PIN11 (GPIO1) for output and toggle at 1 second. Pin13 will wait for Rising Edge trigger. If you connect both pins together then you will get:
# python blink.py -chip gpiochip0 -opin 1 --epin 0 --event True
1970-01-01 00:47:21,419 DEBUG blink.py:60 - <module>() main
1970-01-01 00:47:21,420 DEBUG blink.py:66 - <module>() monitor
1970-01-01 00:47:21,421 DEBUG selector_events.py:59 - __init__() Using selector: EpollSelector
1970-01-01 00:47:21,424 DEBUG gpiowrapper.py:10 - __init__() args chip=gpiochip0 pin=1
1970-01-01 00:47:21,558 DEBUG gpiowrapper.py:16 - __init__() type <class 'gpiod.Chip'> <class 'int'>
1970-01-01 00:47:21,648 DEBUG gpiowrapper.py:36 - __init__() type <class 'gpiod.Chip'> <class 'int'>
1970-01-01 00:47:22,153 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:23,156 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:24,159 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:25,161 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:26,164 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:27,167 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:28,170 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:29,172 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:30,175 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:31,178 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:32,180 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:33,183 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:34,186 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:35,188 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:36,191 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:37,194 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:38,197 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:39,199 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:40,202 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:41,205 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1970-01-01 00:47:42,207 DEBUG gpiowrapper.py:57 - event_cb() event RISING EDGE
1
I have been working on communication protocol to the CMOD-S7 and CYC1000 via the FTDI over USB. One of the issues is round-trip-time. Currently the packet handling is done all by the MicroBlaze. There are to basic packet handling duties the Microblaze performs in the RX/TX data path:
Using just the MicroBlaze, the ping rate is 1.7Mpbs, adding the two AXI stream pushes the rate to 2.7Mbps.
Here is a block diagram from vivado.
This project take some time, the goal is to push the data rate to 12Mbps, maybe add the ADC and temperature sensor, to also push data via AXI stream.
After a several weeks of tweaking, DMA driver and Verilog, AXI Stream serial TX/RX using DMA with the MicroBlaze soft core is working.
Over the past several months I have been using Fast Serial mode with FTDI, but it is only half duplex, if the PC and FPGA try to send messages at the same time, the FTDI chip does some weird things depending on the state if the FDSI and FSDO, worked with tech support, "should only be used with a half duplex protocol".
So, back to standard serial, the FTDI serial interface can support 12Mbps in full duplex, so, it is possible to have the FPGA and PC send async messages. So, how to get 12 Mpbs to the Spartan 7?
Created a axis_serial RTL (In verilog) that can stream TX/RX bytes out to the FTDI chip at 12Mpbs. This is a real simple block, used serial code from Nandland with a AXI stream wrapper. Also this wrapper looks at the incoming bytes from the serial and will raise TLAST for EOP (End of packet) byte. TLAST is connected to the DMA block and this will terminate the DMA and the RX buffer is now filled with a packet.
The DMA driver is packet based, i.e. like Ethernet LWIP example, but in this case it is using a serial stream. This way the microbalze is not processing serial interrupts per byte, but, interrupt per packet.
Configured the clock to be 120Mhz, the current "ping rate" is 1.7Mpbs in one direction, or 3.4Mpbs full duplex. I'm working on offloading the CRC and packet ESC packing to the FPGA. CRC is done, Packing is taking some time. This will be in the TX direction for now, so, the rate should increase to 3.4Mbps in TX direction.
All of the code is in gitub.