EM099 » Bus Spider: flexible open source hacker multi-tool
We intend to develop Bus Spider — a better tool for DIY and hacking projects that involve serial communications.
Bus Spider is inspired and heavily influenced by Bus Pirate (http://dangerousprototypes.com/docs/Bus_Pirate).
We design Bus Spider in a way that will extend functionality and solve issues of original Bus Pirate.
https://github.com/miet-riscv-workgroup/de10-nano-bus-spider
Different sensors and controllers are used during development of electronics. In most cases these controllers use serial interfaces (UART, SPI, I2C) for communication. It is useful to test them sending commands and analyzing results. However, in most cases PC does not have corresponding interfaces.
The well-known Bus Pirate v3 device developed by Dangerous Prototypes resolves this issue. It's a cheap and universal device. It can be connected to regular PC via USB and provides ability to use several most common serial interfaces. Communication with Bus Pirate is performed through serial console.
Unfortunately, Bus Pirate v3 has several issues:
These issues are caused by the limited specs of PIC24FJ64GA002 16-bit Microchip microcontroller used in Bus Pirate v3.
There is Bus Pirate v4. It has better throughput than Bus Pirate v3. Alas, it seems that Dangerous Prototypes abandoned Bus Pirate v4 firmware development and it never reached stable state.
This project proposes to create Bus Spider — a superior device based on the FPGA board.
We are using FPGA to implements a SoC with RISC-V compatible core PicoRV32. The SoC is being developed in MIET. Embedded software rewritten from scratch will provide the same well-approved serial console interface as the Bus Pirate's.
In our project we will consider the experience of the Bus Pirate creators trying to preserve usability of original device. We plan to add hardware JTAG controller and a logical analyzer in the future.
1. Bus Spider provides network features for remote development;
2. Bus Spider partially preserves mature Bus Pirate protocol;
3. Bus Spider is expandable: user can add specific interface if necessary.
We are inspired by open software development workflow and principles. Bus Spider is developed in way we find as close to modern open software development as possible. We hope that Bus Spider project can inspire others to perform open hardware development in manageble and maintainable way.
The first prototype of the Bus Spider was based on FT2232 breakout board and CoreEP4CE6 (see Fig.1 and Fig.2). With this prototype we were able to evaluate our sketch design.
Fig.1
Fig.2
Bus Spider contains two subsystems: Linux subsystem to implement network features and microcontroller subsystem to implement interface controllers and protocol. This division allows to run Linux on HPS with better performance and at the same time isolate and encapsulate interface related hardware and software.
User can connect to Bus Spider over network and perform various interactions with connected electronic devices. User can use I2C, UART, SPI and GPIO independently (see Fig.3).
Fig.3
Controlled device can be either «simple» or «complex» one. «Simple» devices are peripherials controlled by one of listed interfaces. «Complex» devices are processor boards with network capablities. In this case Bus Spider can be used as network server if connected electronic device need it (e.g. connected device is processor board). If you need additional ethernet then you can use VLAN-enabled switch (Fig. 4).
Fig.4
The Bus Spider is designed to use full potential of FPGA:
Bus Spider has high level of system integration: Linux host and Bus Spider implemented in the same FPGA device; Linux is running on HPS for better performance.
Using FPGA makes Bus Spider lifespan longer in comparision with controller based solutions. Both hardware and software can be updated on later development stages and in maintence period;
Using FPGA makes Bus Spider expandable by end user. It is possible to add more functions appending existing IP cores including IP cores provided by Intel Quartus Prime design software;
Using FPGA makes Bus Spider scalable. It is possible to increase number of interfaces or even number of Bus Spiders on the same FPGA device!
Bus Spider has multiple parts: two subsystems, each with multiple IP-cores, linux bootloader, linux kernel and device tree, RISC-V bootloader, RISC-V software and more. To be able to maintain such project we decided to use git source control system. Every hardware and software component sources are stored in separate git repo. The main de10-nano-bus-spider git repo unites separated component repos with git submodule mechanism.
To be able to maintain IP dependency and automate hardware project compilation we decided to use FuseSoC by Olof Kindgren. FuseSoC uses description files for IP-cores and produces project files for different CADs. FuseSoC also automates build and simulation of project. Please see the de10-nano-bus-spider-dev-flow.md page for our development workflow details.
To be able to work on Bus Spider remotely we designed remote control device to be able to control power and communicate with DE10-Nano. We built it of off-the-shelf modules.
We have not used any commercial IP-blocks so Bus Spider stays as close to completely open hardware as possible in the reality of modern FPGA development. Same goes for software tools – aside of Quartus every used software package is open source and free.
The main function of the Bus Spider is to provide remotely accessed interface to serial communication controllers.
To use Bus Spider you need to perform several steps:
Currently Bus Spider RISC-V SoC design has following characteristics:
Quartus Prime report data:
Bus Spider consists of two SoC subsystems – HPS with ARM® core and Bus Spider SoC based on PicoRV32 by Clifford Wolf (see Fig. 5). Such division allows to run Linux on more powerful core and keeps Bus Spider peripheral controller and firmware isolated, ready to use in another, different systems.
Fig.5
HPS with running Linux handles network connections and provide wide range of high level functions and services to user. HPS communicates with Bus Spider SoC via UART and GPIO controllers which are implemented in FPGA logic and are accessible by HPS through HPS-to-FPGA bridge (see Fig. 6). GPIO is used to provide hard reset for Bus Spider SoC.
Fig. 6
Linux host controls Bus Spider SoC over UART interface using Bus Pirate user interactive protocol. Another UART controller of Linux host subsystem is directly connected to UEXT connector bypassing Bus Spider SoC. This provides fast link and keeps simplicity of software at the moment.
Bus Spider SoC consists of PicoRV32 RISC-V compatible core, automatically generated wishbone switch, internal instructions/data memories, UART and GPIO controllers (Fig. 7). Currently GPIO controller is used to provide I2C and SPI interfaces in bit-bang mode. At the moment only user interactive mode is supported so there is no need for high speed communications. We plan to add hardware serial controllers after implementation of machine communication protocol.
Fig. 7
Bus Spider SoC memory map is shown in the following table:
| base | top | slave | ip core |
|---|---|---|---|
| 0x0000_0000 | 0x0000_ffff | bootrom | wb_bootrom |
| 0x4000_0000 | 0x4000_ffff | sram | wb_ram |
| 0x9000_0000 | 0x0000_001f | uart | uart16550-1.5.4 |
| 0x9100_0000 | 0x9100_0007 | gpio0 | wb_gpio |
| 0x9100_0100 | 0x9100_0107 | gpio1 | wb_gpio |
PicoRV32 RISC-V core is configured in RV32IMC mode (RV32I base ISA, extension M (integer multiply/divide instructions) and extension C (compressed instructions)).
Icarus Verilog and GtkWave were used for Bus Spider RISC-V SoC simulation and debug (see Fig. 8).
Fig. 8
We have developed software emulator for Bus Spider RISC-V SoC on top of qemu to speed up RISC-V SoC firmware development.
To simplify the connection of UEXT modules to DE10-Nano the special adapter board on base of prototype PCB was created (see Fig. 9).
Fig. 9
At the moment the Bus Spider demonstrates functions similar to ones provided by the Bus Pirate. The Bus Spider proves that using FPGA SoC for such device was definitly right idea and will allow us to avoid MCU based Bus Pirate limitations.
The Bus Spider is not mature project. There is much more work to be done but through Innovate FPGA competition we were able to move from prototype to managable open source project and plan out our next steps. Now, when the Bus Spider project is up and running we are planning on gradually improve and extend it to get better performance, solid documentation and wider range of features.