11/25/2018 at 16:50 •
I haven't had much time and things are progressing slowly, but I have made some progress. I was able to add support for the on board flash in circuitpython so that it can be used for the circuitpy drive storage. The code is posted in my github repo: https://github.com/gsteiert/circuitpython
I added a new fpga_helper_express board in addition to the fpga_helper board to keep the option not to use the on board flash for circuitpython. The reason I want to keep this option is because circuitpython will put a file system on the flash that is not compatible with the internal SPI loader in the FPGA, and it will be difficult to share a single flash device with both circuitpython and the FPGA. When this circuit gets integrated on a board with the FPGA, I don't want to require two SPI flash devices. I will need to modify circuitpython to put the binary image on the flash without the file system so the FPGA can load directly from it. This work is TBD.
Another option would be to have circuitpython push the image from flash into the FPGA. The reason I am avoiding this is because many FPGA's from a variety of vendors can load from similar SPI flash that are straightforward to program. If were to push the code into the FPGA using circuitpython, I would have to customize it for every different target, which I would rather not do.
FPGA's with integrated storage are different story, since there is no external SPI device to program. The MachXO2/3 series from Lattice have internal non-volatile storage that can be loaded through JTAG, SPI or I2C. Since the I2C signals are so easy to get to with the qwiic connector, I think I will work to add support to configure the MachXO2/3 using circuitpython. Using the on board flash to cache the image in this case is not as much of a penalty if you are only using this board as a programmer and disconnect it when you are done. You can program as many targets as you want with the single programmer. The extra flash device is more of a burden if you are integrating it permanently.
10/01/2018 at 05:10 •
The board is up and running and software development is making good progress.
The UF2 bootloader and CircuitPython are up and running on the board.
The dotstar LED and QWIIC I2C connector are both accessible through CircuitPython. Here is a link to a video showing the board fading the LED and reading a Qwiic NFCPROM:
09/05/2018 at 03:17 •
09/03/2018 at 05:25 •
I received the boards and they passed the smoke test. Great job MacroFab!
It didn't take too long to get the uf2-samdx1 bootloader running on it:
I started working on circuitpython and seesaw ports, but those will take a bit more time. For now I will focus on the basic uf2 interface to the SPI flash.
08/20/2018 at 00:26 •
As mentioned previously, UF2 was created to make it easier to work with CircuitPython. The boards upon which this circuit is based were designed to run CircuitPython and one of the first steps for bringing up and checking out this board will be to port and run CircuitPython. Having a board like this capable of running CircuitPython could almost justify the project on its own. This will be on of the first CircuitPython boards with any of Qwiic, UEXT, and PMOD connection options, let alone all three. CircuitPython also provides an easier way for FPGA developers create scripts and utilities in an environment that might be easier for them to work with than the native embedded C/C++.
08/20/2018 at 00:12 •
The primary power input for the board will be +5V from the USB connector. This will need to be regulated down to +3.3V for all the circuitry on the board. In the case where the flash memory is populated on this board and it is connected to provide the image to the target FPGA, it should not be necessary to connect the USB cable and the board will draw power from the target board through the PMOD or UEXT connector. To enable two different power sources, a diode is placed in-line with the USB power input and a Pch MOSFET is connected in-line with the PMOD/UEXT power pins. The gate of the MOSFET is connected to a voltage divider from the USB power input so that the MOSFET is off when USB power is present, and enabled when only the PMOD/UEXT power is present. The gate is also tied to PA28 on the MCU so that the controller can detect when USB power is present, and so that it can also override the signal to deliver power from USB to the PMOD or UEXT connectors for additional flexibility.
08/20/2018 at 00:03 •
Here are details on the connector pinouts:
1 VBUS +5V 2 PA24 D+ 3 PA25 D- 4 nc ID 5 GND GND
SSEL PA09 1 1 PA19 RX MOSI PA08 2 2
TX MISO PA10 3 3 PA17 SCL SCK PA11 4 4 PA16 SDA GND GND 5 5 GND GND +3.3V VTGT 6 6 VTGT +3.3V
+3.3V VTGT 1 2 GND GND TXD PA18 3 4 PA19 RXD CDONE PA17 5 6 PA16 CRESET SDI PA10 7 8 PA08 SDO SCK PA11 9 10 PA09 SS_B
1 GND GND 2 VCC +3.3V 3 PA22 SDA 4 PA23 SCL
+3.3V VTGT 1 2 PA31 SWD GND GND 3 4 PA30 SWC GND GND 5 6 PA14 DBG-TX nc nc 7 8 PA15 DBG-RX ID nc 9 10 RESET# Reset
1 VCC +3.3V 2 GND GND 3 PA02 AIN0/AOUT 4 PA03 AIN1/VREF 5 PA04 AIN4/VREF 6 PA05 AIN5 7 PA06 AIN6 8 PA07 AIN7
08/19/2018 at 23:28 •
With a framework in mind and the host controller family selected, the next step is determining what all needs to be connected to the controller. Let's start by listing the features:
- USB connector
- Target Interface (SPI, I2C, UART)
- RGB LED
- Reset button
- In-circuit debug connector
The target interface consists of multiple interfaces and deserves some additional consideration.
The SPI interface will be connected to a serial flash device in parallel with the target FPGA. We can hold the FPGA in configuration reset and load code into the flash device on the target board, or we can load code into a flash device mounted on this board with the target board in configuration reset or disconnected. The SPI programming bus is located at two headers on the iCE40UP breakout board, one pinned out for an Ardvark connector which does not have any power, and one at a dual row PMOD header with power and 4 additional I/O. We will target the PMOD header so we have access to power and the additiona I/O. The Olimex boards connect the programming signals to a UEXT connector. In addition to the SPI signals, the UEXT connector also includes CRESET, CDONE and two I/O in the UART locations. The I2C signals in the UEXT connector are used for CRESET and CDONE, so we will need another connector to get I2C to the Olimex boards. To keep the board area down, I will add a Qwiic connector for the extra I2C port.
Since much of the code will be coming from Adafruit projects, I will use the same RGB LED connections found on the Tricket M0 and ItsyBitsy boards.
The debug connector will primarily be used for development so I will use a small SMT connector on the back side of the board that can be left off in production. There is a standard 50mil pitch 10pin header that is common with ARM MCU's and there is even room for a debug console UART if you follow the MAXDAP pinout from the MAX32625PICO board.
For the extra analog/GPIO signals, I'll include another single row header with an extra power and ground signal.
08/19/2018 at 22:54 •
The goal of this project is to make FPGA development much easier and more accessible, similar to the recent advances in embedded firmware development. We will need to address many of the same issues, like how to conveniently load code into hardware, and how to communicate with a computer, and how to support development on more than one operating system. Fortunately, many of the advancements in embedded firmware development are directly applicable so we can learn from them and apply the best practices.
The most operating system agnostic implementation that I have seen is the cloud based ARM mbed environment. While a cloud based development environment has limitations, the use of USB mass-storage class drag-n-drop for programming is a great idea that is spreading. There is a great summary of the genesis of the UF2 file format at the makecode blog which pretty much covers all the reasons why I have chosen to use this for the programming interface in this project.
The UF2 bootloader was originally implemented on the SAMD21 which is very popular at Adafruit. In addition to the bootloader code, there are many other open source programs available for this MCU (like seesaw and CircuitPython). In order to keep the scope of this project manageable, I will use the SAMD21 so that I can spend less time porting to a new platform, and more time on the critical features.