BML GPIO-14 USB Board for PCs


2018.03.18 : BML project for using a $2 FTDI FT260Q for adding 14 bits of GPIO to any PC via USB with no device drivers required.


Ever miss the simple days of using a PC’s LPT1 parallel port to bit-bang GPIO over 8 output pins and 4 input pins of the DB-25 connector? I sure do.  My first design project as a BSEE graduate in 1993 was to design a LPT1 controlled test fixture for the Motorola MDT-9100-T data terminal (shown below).  Those were the days. By multiplexing 12 parallel port pins into 74HC dip CMOS latches and transceivers my test jig tested all the IO signals of the MDT-9100s 386sx motherboard. All of the diagnostic software could be written in C on my Windows 3.1 desktop thanx to this versatile interface. Those were the glorious simple days of computing.  Sigh…. Then USB came along and killed the wonderfully easy parallel port interface.

But wait, FTDI has recently introduced a low cost and very versatile USB chip called the FT260Q. It is unique in that it requires no device drivers. It provides up to 14 IO pins that can be used for driving LEDs, reading switches, interfacing to LVCMOS circuits all while requiring very little support circuitry.  This open source Black Mesa Labs’ project  describes the DIP-18 breakout board for the FT260Q which may be built for under $5.




The 24 x 19 mm 2-layer PCB may be ordered here from OSH-Park for just about $3 for 3 PCBs.




[ Bill of Materials ]

Qty-1 : 768-1268-ND : FT260Q-T IC USB TO UART/I2C 28WQFN : $1.83
Qty-1 : 240-2390-1-ND : FERRITE BEAD 600 OHM 0805 : $0.11
Qty-1 : 609-4613-1-ND : CONN USB MICRO B RECPT SMT R/A : $0.42
Qty-2 : F4239CT-ND : TVS DIODE 24VWM 150VC 0603 : $0.65
Qty-3 : 445-4112-1-ND : CAP CER 10UF 6.3V X5R 0603 : $0.06
Qty-2 : 399-7918-1-ND : CAP CER 47PF 50V C0G/NP0 0603 : $0.10
Qty-3 : 445-5111-6-ND : CAP CER 0.1UF 25V X7R 0603 : $0.10
Qty-4 : Resistor 4.7K 5% 0603
Qty-2 : Resistor 33 ohms  5% 0603
Qty-1 : Resistor 1 Mohm  5% 0603



The FT260 is a USB device which supports I²C and UART communication
through the standard USB HID interface. This is very cool as it means it should work with any USB host platform without requiring any special device drivers. See the FTDI Application Note AN_394 User Guide for FT260 for details on programming the FT260Q, also the datasheet.

To send and receive HID reports from Windows ( or Linux ) in the Python environment, the module hidapi is needed. Download the appropriate hidapi Python WHL for your platform from this link .  For example, at BML, currently running Python35 on 64bit Windows10, so downloaded both hidapi-0.7.99.post21-cp35-cp35m-win_amd64.whl and hidapi-0.7.99.post21-cp35-cp35m-win32.whl .

  1. Upgrade pip via “python -m pip install –upgrade pip”
  2. Install WHL via “pip.exe install hidapi-0.7.99.post21-cp35-cp35m-win32.whl”

With hidapi installed, you should now be able to run this example script from BML that will configure all the FT260Q pins as GPIO outputs and toggle them as fast as possible.  Note the USB HIDAPI interface to HID-Class devices isn’t “bare metal” blazing fast. This sample Python toggles all the GPIO pins every 300-400uS, or about 1kHz. For Windows, the HID API interface requires all reports be 64 bytes in length, so the example Python here always pads reports with trailing 0x00’s to be exactly 64 bytes long. Untested, but padding the reports under Linux should not be required and may be considerably faster than Windows.

[ ]

import hid;

h = hid.device();# See, 0x6030) # FTDI FT260Q device ID

print("System Status");
rts = h.get_feature_report( report_num = 0xA1, max_length = 255 );
print( [ "%02x" % (each) for each in rts ]);# list comprehension
h.send_feature_report([0xA1,0x02]+[0x00] +[0x00]*61 );# GPIO ON, I2C OFF
h.send_feature_report([0xA1,0x03]+[0x00] +[0x00]*61 );# GPIO ON, UART OFF
h.send_feature_report([0xA1,0x05]+[0x00] +[0x00]*61 );# GPIO3 ON, Int OFF
h.send_feature_report([0xA1,0x06]+[0x00] +[0x00]*61 );# GPIO2 ON
h.send_feature_report([0xA1,0x07]+[0x00] +[0x00]*61 );# GPIO4,5 ON 
h.send_feature_report([0xA1,0x08]+[0x00] +[0x00]*61 );# GPIOA ON 
h.send_feature_report([0xA1,0x09]+[0x00] +[0x00]*61 );# GPIOG ON 
h.send_feature_report([0xA1,0x41]+[0x00]*8+[0x00]*54 );# GPIOE,H

# 0xB0 : GPIO Write/Read Request 
# Byte-0 : 0xB0
# Byte-1 : GPIO[5:0] Value
# Byte-2 : GPIO[5:0] Direction 0=Input 1=Output
# Byte-3 : GPIO[H:A] Value
# Byte-4 : GPIO[H:A] Direction 0=Input 1=Output

# Output Loop : Configure all 14 GPIOs as Outputs and toggle them
while ( True ):
    h.send_feature_report( [0xB0, 0xFF, 0xFF, 0xFF, 0xFF ]+[0x00]*59);# Toggle
    h.send_feature_report( [0xB0, 0x00, 0xFF, 0x00, 0xFF ]+[0x00]*59);# All GPIO pins

# Input Loop : Configure all 14 GPIOs as Inputs
h.send_feature_report( [0xB0, 0x00, 0x00, 0x00, 0x00 ]+[0x00]*59);
while ( False ):
    rts = h.get_feature_report( report_num = 0xB0, max_length = 255 );
    print( [ "%02x" % (each) for each in rts[0:6] ]);# list comprehension

[ GPIO Pin Power Up Defaults ]

Not all pins powerup in GPIO tri-state mode. If powerup condition is important, BML recommends using the non-tristate pins as inputs with series resistors between your circuit and the FT260Q.  The tristate pins you should be able to pull high or low on powerup with appropriate (1K) resistor.

0 - Hard Low
1 - Tristate
2 - Tristate 
3 - Tristate - pulled up
4 - Hard High
5 - Tristate
6 - Tristate

7 - Hard Low
8 - Tristate
9 - Tristate
10 - Tristate
11 - Tristate
12 - Hard Low
13 - Tristate

[ Future Plans ]

Black Mesa Labs has plans to use this IC as both a SPI PROM programmer and UART interface to future FPGA boards. The low cost, small size and minimal external components ( no crystal, PROM, etc ) make this an ideal IC for low cost educational FPGA development boards from Black Mesa Labs. Next tutorial on using the FT260Q will make use of the internal UART capable of 12Mbaud. Look for future Xilinx Spartan7 boards from BML with a FT260Q embedded for both PROM programming of a bootloader and UART interface for Mesa Bus transfers at 12Mbaud.

[ EOT ]

BML GPIO-14 USB Board for PCs

BML USB 3.0 FPGA interface over PMOD

2017.12.19 :  Black Mesa Labs is presenting an open-source-hardware USB 3.0 to FPGA PMOD interface design.  First off, please lower your expectations. USB 3.0 physical layer is capable of 5 Gbps, or 640 MBytes/Sec. This project can’t provide that to your FPGA over 2 PMOD connectors – not even close. It does substantially improve PC to FPGA bandwidth however, 30x for Writes and 100x for Reads compared to a standard FTDI cable based on the FT232 ( ala RS232 like UART interface at 921,600 baud ). A standard FTDI cable is $20 and the FT600 chip is less than $10, so BML deemed it a project worth pursuing.


Measured Data Transfers comparing FT600 to FT232:

USB 3.0 to FT600 at 100 MHz: Writes=1,384 KBytes/Sec, Reads=567 KBytes/Sec

USB 3.0 to HUB to FT600 at 100 MHz: Writes=416 KBytes/Sec, Reads=187 KBytes/Sec

USB 2.0 to FT600 at 100 MHz: Writes=279 KBytes/Sec, Reads=131 KBytes/Sec

USB 2.0 to FT232 1×6 0.100″ at 1 Mbps: Writes=43 KBytes/Sec, Reads=5 KBytes/Sec

Wait, what?  Measured in KBytes not MBytes per second? Is BML to blame? Only partly. This BML project utilizes 1/4 of the LVCMOS bandwidth possible of the FT600 to both make the IO fit across PMODs and also work with existing Mesa Bus Protocol IP.  The FT600 has 16 data pins capable of 200 MBytes/Sec but 1/2 the data pins are deliberately tossed to fit within 2 PMODs ( 3 PMODs wouldn’t be practical ).  Existing Mesa Bus Protocol IP is used – which transfers ASCII nibbles (0-9,A-F) instead of binary, so the maximum logical throughput is reduced another 2x to 50 MBytes/Sec.  Observed transfers are just over 1 MByte/Sec.  This means if all 16 pins were used and a binary protocol transfer instead of ASCII, rate would be about 5MBytes/Sec – still away off from 200 MB/s . So what is going on? This is a perfect application for the SUMP2 Logic Analyzer from BML.  Instead of wiring up the iceStick, SUMP2 was instantiated directly in the FPGA along with the FT600 interface ( this is really what SUMP2 is designed for, a free open-source replacement for Xilinx ChipScope and Altera SignalTap. SUMP2 supports capturing 32 compressed events and up to 16 non-compressed DWORDs into on-chip FPGA block RAM ). Below is a PNG screen dump of SUMP2 capturing the FT600 FIFO status flags (RXF,TXE) and the FPGAs control signals ( RD,WR ). What is immediately apparent is that the majority of the time ( ~154uS out of ~160uS ) the FT600 doesn’t have any data for the FPGA. RXF is sitting low even though Python is trying to send data as fast as possible.


Within a 10 ns clock cycle of RXF asserting, the FPGA asserts RD and converts the Mesa Bus Packet into a local bus burst ( with about 350ns of pipeline latency ). The observed distance between the 32bit lb_wr pulses is precisely 8 clocks, the fastest possible ( DWORD = 4 Bytes x 2 ASCII Bytes per Binary Byte = 8 clocks ).  Clearly both the FT600 and the FPGA design are working as fast as possible with what is coming down the USB 3 pipe.sump2_0010.png

So, the truth is that the majority of the time ( 154/160us = 96% ) the PMOD interface is sitting idle even though Python is trying to write and read from the FT600 as fast as it can. Clearly the USB 3.0 pipe is not full. Who is to blame? Is it Python? Windows? Intel Chipset? Don’t know. Would it be faster on Linux? Hopefully. Would compiled C be faster than Python? Probably. Would we ever achieve 50 MBytes/Sec? Probably not. FTDI Application Note AN_386 goes into some detail, there is a lot of software between the user software and when the electrons finally hit the USB 3.0 cable.

Is just over 1MBytes/Sec a disappointment? Yes.  A show stopper? No. Using the FT600 is still the fastest way (BML is aware) of inexpensively getting data from a PC into any FPGA without instantiating a PCI Express IP core and building a PCI Expresss plug in card. 30x and 100x improvements on Writes and Reads is substantial.

2017.12.20 – Update, an acquaintance on Twitter has reported using an FT600 with a proper C client over an FMC connector (all 16 pins, 100 MHz,  binary transfers ) of 185 MB/s ( out of 200 MB/s total ). That is excellent news and proof that Python is most likely the bottleneck. Based on his results, the BML dual-PMOD board should be capable of 1/4 that ( 8bit, ASCII ) or 46 MB/s. Github link to C source is here.

2017.12.21 – Update – another acquaintance on Twitter has reported achieving 240 MB/s using FT601 ( 32bit ) and C on Linux. His USB interface software is on Github here.

Now that performance explained – About the design, let’s begin:

[ Software Setup ]

Step-1) Download and install FTD3XX Device Driver from .  For example, for Windows, download and run FTD3XXDriver_WHQLCertified_v1.2.0.6_Installer.exe

Step-2) Download and install Python module for D3XX from  For example, unzip, “%cd D3XXPython_Release1.0” and then “%python install”

Step-3) Create a directory for your script and copy FTD3XX.dll and FTD3XX.lib from unzipped D3XXPython_Release1.0 folder.

[ Hardware Setup ]

Board design.  The board is a 2-layer PCB that is available either via Gerber download or direct purchase from OSH-Park here ($10 for Qty-3). The board consists of the FT600 chip from FTDI, 3 LDO regulators, a 30 MHz crystal and a bunch of 0603 and 0805 passives ( 10uF, 0.1uF, 18pF, 10K, 1.6K, 33 ohm, Ferrite Bead ).


FPGA Hardware setup is a bunch of Verilog IP.  I/O timing over the PMODs was tight, so a PLL is used to remove clock tree insertion delay on the 66/100 MHz clock provided by the FT600. Xilinx Spartan3 LVCMOS 3.3V 8mA Fast IO buffers were required to run at 100 MHz. Since actual throughput doesn’t really get impacted, it is recommended to run at 66 MHz unless a 100 MHz clock is needed for other reasons. The clock from the FT600 is software selectable to be either 66 MHz or 100 MHz and the clock automatically shuts off when USB sleeps during inactivity. Thankfully, it turns on 100’s of ms prior to data transfers, allowing for PLLs to lock if needed.  WARNING: An annoying feature of the FT600 is that using the FTDI configuration program you can select to keep the FT600 clock on always – but what isn’t mentioned is that if you select this option, the device will no longer work with USB 2.0 – at all.

File_000 (12)_cropped.jpeg

Design files are here on my public dropbox. They include example Python for testing Write/Read performance, Bill of Materials, Gerbers, Layout files, Layout Screen Shots and example Verilog test design working on a Xilinx Spartan3. A future blog post will go into details on using Mesa Bus Protocol for virtual 32bit PCI like register reads and writes both from user Python and with bd_shell.exe – a Windows .NET app written in Powershell that provides a useful command line interface for writing, reading and scripting register access over a Mesa Bus Protocol link ( either FT600 dual-PMOD or simple FT232 2-wire. A new version of here supports both FT232 and FT600 interfaces for applications like and bd_shell.exe to share access to FPGA memory space using Mesa Bus Protocol over Berkeley Sockets for ICP. SUMP2 works great over the FT600, especially for captures with 16 DWORDs of data at 8K samples – the 100x faster reads makes a huge difference.

Stay tuned for more BML open-source hardware and software projects that utilize this FT600 USB 3.0 interface.  Follow me on twitter @bml_khubbard



BML USB 3.0 FPGA interface over PMOD

SUMP2 – 96 MSPS Logic Analyzer for $22




2016.22.22 : SUMP2 now also available for RaspPi+icoBoard here.

2016.12.13 : Great video on SUMP2 from Bil Herd at Hackaday.

2016.10.31: Thanx to SteveDC, a 3D printed case is now available for SUMP2 here.

2016.10.30 : SUMP2 5V Input shield is now available from OSH-Park for $5. BML can also design similar shields for RS232,RS422/485,LVDS and CAN Bus if there is any interest.

2016.10.24 : Black Mesa Labs has an ongoing mission to develop easy to use and fully capable open-source hardware and software tools that make engineering electronics easier. One such tool is this new low cost open-source logic analyzer called SUMP2 for people who otherwise work in the blind without an oscilloscope or logic analyzer on their bench top.  BML’s 1st incarnation called SUMP1-RLE in 2014 was a 16bit FPGA based logic analyzer that performed real-time hardware compression and decompression. The decompressed data was streamed out over USB using the open SUMP protocol ( hence the name ), allowing it to be used with the excellent Java software from the original 2007 project. The SUMP1-RLE project was later enhanced from just 16 triggerable events to also include 2 DWORDs of “data” ( additional 64bits of non-triggering non-compressed signals ) and advanced triggering options. Including the data DWORDs made SUMP1 a useful tool for complex FPGA development debugging of internal FPGA event nodes and data paths. These new features required new custom software, written by BML in .NET for Windows. The software was functional, but graphically slow and was mostly used for trigger setup and then exporting captured data as VCD files into GTKwave for viewing. SUMP1 also did not scale in width, depth or time, it was fixed at 16 events, 2 DWORDs and a 2^20 timestamp ( 1 Million Samples ) both in hardware and software. In 2016 BML decided to do a complete start-over on the SUMP RLE concept and developed SUMP2-RLE ( or just SUMP2 for short ). New Hardware, New Software. More features, better scaling – introducing SUMP2:


The sump2.v verilog file is designed to work inside any FPGA or ASIC containing block RAM and scales in complexity from 1-4 bytes of events ( 8-32 triggerable and RLE compressible signals ) and 0-16 DWORDs of up to 512 non-compressed data bits. Depth and width of RAM scales on instantiation to best fit a wide range of FPGA technology. The full featured SUMP2 configuration is designed to be used on internal nodes within very large $100 – $1000 FPGAs. In this configuration for analyzing internal FPGA nodes it is very similar to proprietary FPGA vendor solutions such as Xilinx ChipScope and Altera SignalTap. SUMP2 has the advantage of being fully open and also offers RLE compression that can offer 10x – 1000x the time storage of similar FPGA logic analyzers not aided by hardware compression. Duty cycle hardware applications such a pulse-echo radar can readily achieve 5,000x compression using the new RLE engine with 2^32 timestamps. The scalability of SUMP2 also permits it to work in ultra low cost ( sub $5 ) FPGAs such as the Lattice iCE family. The Lattice iCEstick eval board at only $22 with included FTDI USB interface and PROM programming provides for a perfect SUMP2 platform for electronic debugging of Arduino and Raspberry Pi like projects involving 3V serial ports and GPIO. Communication between hardware and software over USB is all done using the Mesa Bus Protocol , an open serial protocol for transferring 32bit PCI reads and writes over UART, SPI and SERDES serial links between computers and FPGAs.




To fit within the iCE40HX1K FPGA, sump2.v verilog RTL design is instantiated for 16 input events, no DWORDs and 1k depth of RLE capture RAM sampling at 96 MHz. The graphical backend software is, a PyGame application used for arming the hardware and dumping and displaying the capture for analysis. Compared to the SUMP1 .NET app, the PyGame SUMP2 version is very fast. Although supports exporting and importing VCD files, it is entirely not necessary to use a standalone VCD viewer such as GTKwave or Modelsim.

A simple example of a Unit Under Test.  Below pictured is a 10 MHz ( 100ns period ) oscillator driving a 74ACT161 4bit counter with a 74HC08 AND gate on the d(2) and d(3) upper bits of the counter. A push button switch to ground with a 10K pullup resets the counter. 8 nodes of interest are connected via Dupont ribbon cable to the iCEstick PMOD header.


Short demonstration video of the PyGame application:

The initial full capture of the reset button being released. The capture represents 4168 samples at 96 MHz using only 1K of RAM by utilizing RLE compression. RAM is hard partitioned 50/50 pre and post trigger.sump2_0003.png

SUMP2 has the ability of masking input events prior to arming which allows for greater RLE time compression. By double-clicking and “Hiding” the clk_10m signal prior to a new acquisition, the highly active clock signal is masked. This next capture without the 10 MHz clock is twice the length, or 83uS.  Also notice the very short reset switch bounce captured. Masking the LSB counter bits would further increase total capture time.


Mouse scroll wheel can be used for zooming in and out in time, allowing for rapid detailed analysis and cursor measurements.


Right-Clicking the mouse launches popup menus for tool selection.


The left side popup allows for selecting a signal and then assigning it as a rising or falling edge trigger.


Steps for building your own open-source SUMP2 Logic Analyzer for the Lattice iCEstick.

What is needed:

  1. $22 iCEstick from Mouser, Digikey or direct from Lattice. ( ICE40HX1K-STICK-EVN )
  2. Free FPGA Diamond Programmer software from Lattice.
  3. Windows Device Driver for the FT2232H USB chip from FTDI ( this may also be included with Lattice Programmer ).

and this free stuff from Black Mesa Labs:

  1. Bitfile for SUMP2 for the Lattice iCE40HX1K FPGA.
  2. – a Python TCP server for communicating to hardware over USB.
  3. – a Python PyGame application. Handles triggers and waveform viewing.
  4. FPGA Design Files ( Optional, only needed if not using prebuilt Bitfile ).
  5. 5V Input shield PCB design in CopperConnection ( Optional ).

And finally, a bunch of text file documentation from Black Mesa Labs:

  1. Installation Instructions
  2. FAQ
  3. Program Launching instructions
  4. Troubleshooting guide
  5. Pinout for connecting flying leads to iCEstick
  6. Change Log for Software and Hardware
  7. Bug Report

EE Times Article by Clive “Max” Maxfield on SUMP2

Hackaday Article by Jenny List

Please enjoy SUMP2, a 96 MSPS 16bit 3V logic analyzer for only $22. Follow BML on Twitter for updates on SUMP2 and other open-source software and hardware projects from Black Mesa Labs.


Nice article ( in Russian ) and SUMP2

SUMP2 – 96 MSPS Logic Analyzer for $22

Mesa Bus Protocol


Enclosed text file ( mesa_bus  ) is the open-source  Mesa Bus Protocol for transferring bytes between CPUs and FPGAs. It is intended to transfer data between 50 Kbps up to 10 Gbps over UART to SERDES links with just a few wires and very little hardware overhead. It is a very small gate foot print byte transport protocol for encapsulating and transferring payloads of higher protocols (0-255 bytes per payload). Think of it like a cross between Ethernet and USB 3.1. The advantages Mesa Bus Protocol has over USB, Ethernet and PCI is that it fits easily within a $3 FPGA and may be bus mastered either by a PC with a FTDI cable or any old ARM/AVR Arduino CPU (or RPi) with just two standard UART serial port pins. As it is ASCII based, Mesa Bus Protocol is also very portable to wireless devices such as Bluetooth SPP and the RockBLOCK satellite modem for the Iridium network .


Have you ever placed a regular envelope inside an interoffice envelope? Mesa Bus is that interoffice envelope. Where Ethernet transfers UDP, TCP, HTTP,etc packets without higher level knowledge – Mesa Bus can transfer SPI, I2C, Digital Video, 32bit LocalBus,etc  from chip to chip without protocol knowledge.  Mesa Bus works with up to 254 devices with only 2 wires between each device. Black Mesa Labs currently uses Mesa-Bus with the Mesa-Logic MCM FPGA and BD_SHELL.exe windows executable, Python, or an Arduino-Zero ( ARM ) as bus master. Payloads have been digital video ( 800×600 at reduced frame rates over a 40 MHz synchronous Mesa Bus link ) and 32bit local bus write and read cycles (PCI-ish) to FPGA registers and also for FPGA flash firmware updates. Mesa Bus Protocol fully supports prototyping embedded software 1st on a PC in a rapid scripting language like Python as it is clear ASCII that may be transported over a standard FTDI cable or Bluetooth SPP connection.





Mesa Bus Protocol

Mesa-Video : 800×600 Digital video for Arduinos over 2-wire serial Mesa-Bus

Mesa-Video : 800×600 Digital video for Arduinos over 2-wire serial Mesa-Bus

[ 08.30.2015 ]


This post describes Mesa-Video, a low cost, low power, small size and fully Open Source Hardware and Software solution for providing 800×600 digital video for Arduino ( and other ) microcontrollers.  Mesa-Video makes it quick and easy to display text and 24bit color graphics from any MCU using a single UART serial port pin. Applications for Mesa-Video are embedded projects requiring video output and embedded developers wanting real time visibility into their system operation. Mesa-Video is the 1st of multiple Mesa-Modules planned. For a quick summary of Mesa-Video and Mesa-Bus, please read the very nice article at Hackaday by Richard Baguley from 09_01_2015.


[ GPU SPI Bus Interface ] On the original EVEy Video board  ( shown above ) the native SPI interface for the FT813 GPU‘s is brought out to a “Nano Bus” header which was then bit banged with Python software on a PC going through a BML Nano3 FPGA (shown below) containing simple GPIO logic. This was perfect for initial board test and GPU bring up, but slow and needing a faster interface to PCs and micro controllers for a final product.


[ The Arduino SPI Problem ] : A major problem with SPI ( and I2C ) on Arduino is that with shield stacking it is difficult to get more than a single shield device on the bus. SPI devices all require a unique chip select and I2C devices all require a unique address. This is all a bit like the pre-PnP era of plugging ISA cards into a DOS PC and having to select IO Port Number and Interrupt line jumpers. Stacking Arduino shields isn’t exactly as Plug-and-Play simple as plugging in  USB peripherals or PCI boards into a PC. A better solution that scales like USB for Arduinos is needed. Black Mesa Labs has created a simple and low cost solution for this called the “Mesa-Bus”.

[ Introducing the Mesa-Bus from Black Mesa Labs ]


The “Mesa-Bus” is a simple and completely open text serial protocol designed for transporting self enumerating SPI and I2C bus traffic over a standard UART serial connection. Electrically the interface is simply LVCMOS 3.3V RX and TX serial on a standard FTDI 1×6 6 pin 0.100″ header. Why UART Serial? Every device from PC to Arduino to 8051 has at least one UART serial port. Arduino’s are especially flexible as with Software Serial any unused IO pins may be turned into an additional serial port. The Mesa-Bus is made possible by a custom BML FPGA bridge design that has an autobauding UART, auto-enumeration logic and a SPI/I2C bridge residing in a low cost ICE40 Lattice FPGA. Why use the FTDI 1×6 0.100″ connector? The 3V FTDI 6pin connector is ideal as it is well known, bread board friendly, provides raw 5V for powering modules and has 4 signal pins, 2 Ins and 2 Outs. The Mesa-Bus utilizes all 6 pins for allowing Mesa-Modules to be easily powered and configured either by a Arduino like MCU or a full fledged PC with a $20 FTDI serial cable. Aren’t UART serial connections too slow? The Arduino-Zero example for Mesa-Video development communicates at 3Mbaud over a single wire, considerably faster than I2C and in the ballpark of traditional 4 pin SPI using just 2 pins on the Arduino.


This small $3 Lattice ICE40LP384 FPGA design below (22x32mm) bridges the “Mesa-Bus” to SPI and allows the EVEy-Video board’s FT813 GPU to interface either to a PC or an Arduino board via the FTDI 1×6 header. The UART sub-component of the FPGA design autobauds to the 1st “\n” character received from the Bus Master and uses that baud rate for upstream ( RDo ) and downstream ( WRo ) communications – allowing Mesa-Bus to scale from high speed 32bit ARM serial ports to simple 9,600 baud bluetooth wireless virtual serial ports. The BML custom Enumerate and Decode Logic inside the FPGA performs bus enumeration so that each device in a Mesa-Bus serial chain is uniquely addressable to the host ( similar to USB enumeration at a high level concept ).  The Bridge Logic bridges the clear text ASCII characters to SPI ( or I2C ) bus cycles specific to the slave device’s requirements on the module. The final Mesa-Video design merges this bridge FPGA design along with the GPU and HDMI converter onto a single board.


[ PC to Mesa-Bus ]

Why support interfacing Mesa-Bus to a PC that already has USB? Having worked on embedded software+hardware development for 20 years, I have found it tremendously beneficial to be able to prototype embedded software 1st on a PC with a scripting language like Python and then port the software to C for the final embedded MPU. MesaBus is designed to support this development flow.  All Mesa-Video software development was done in rapid prototyping using the Python scripting language on a PC. Once all the initial bringup and custom functions were working on the PC, the software was quickly ported from Python to Arduino C and working stand alone from an Arduino Zero board. This flow is a tremendous productivity enhancer as it avoids the compile, download and repeat loop that often needlessly consumes engineering time developing embedded systems. Prototyping in Python also makes software easily portable to RaspberryPi platforms.MesaVideo(1)

What is the point of “Mesa-Bus” – why not just use SPI natively? “Mesa-Bus” aims to solve both the hardware and software complexity of integrating multiple SPI and I2C peripherals by using any readily available 2-pin serial port and transferring everything in ASCII clear text for easier documentation, development and integration. Binary protocols are more bit efficient, but dealing with clear text protocol transfers is much more human efficient in terms of documentation, development and debug ( think XML versus proprietary binary file formats ).  With Mesa-Bus there are no clocks edges, chip selects or I2C addresses to worry about. All Arduinos have at least one serial port and a virtually unlimited number of Soft Serial ports. MesaBus solves the problem of limited number of available Arduino pins ( think 8-pin ATtiny  ) by allowing for device daisy chaining with built in device enumeration. Mesa-Bus isn’t multi-drop ( like RS485 ), but point-2-point like Token-Ring, electrically superior for performance ( less capacitance, shorter wires ). Multiple MesaBus modules connect to a single Arduino ( or other MCU ) serial port and are uniquely addressed automatically based on their location in the chain. Modules are breadboard friendly with their 0.100″ 1×6 male headers and a 4 slot ( expandable to 8,12,etc ) back plane is on the drawing board for compactly connecting multiple Mesa-Modules in a single serial chain in a 1″ x 2″ form factor.

Back to Mesa-Video – here are the two separate boards joined together.


The final PCB iteration combines both designs onto a single 1″x3″ (3cm x 8cm) board with no center connectors for the SPI interface.


[ Video Capabilities ] : Mesa-Video software is a subset of the entire FT813 GPU video capabilities in order to make it quick and easy for novice to expert Arduino developers to display text and limited graphics from their Arduino onto any HDMI ( or DVI ) display. The FT813 GPU is extremely capable, but also complicated and non trivial to get started programming with the entire API from FTDI. Mesa-Video simplifies things by providing a simple UART serial interface on the input and a fixed 800×600 HDMI interface on the output. MesaVideo is intended for displaying real time information ( like live variable status, progress bars, stock quotes, centrifuge status, etc ). Why not just use a RaspberryPi? RPis are great – but they aren’t microcontrollers – they are full fledged Linux workstations with powerup and powerdown requirements ( and memory card corruption issues ) that Arduinos just don’t have to worry about. Mesa-Video fills the niche of when a small Arduino is the right tool for the embedded job ( flying quad-copter?), but a graphic output ( either just for development debug or final product ) is needed.


Below is an example electrical setup of Arduino ZeroPro + Mesa-Video illustrating the advantage of Mesa-Bus over a conventional SPI interface. There are only 3 wires, +5V, GND and TX ( Pin-1 in Arduino parlance, WRi on Mesa-Bus ) connecting the Arduino to Mesa-Video. Mesa-Video is a write-only interface so the RX serial pin doesn’t need to be hooked up.:


First “Hello World” Example Sketch for Mesa-Video. There are no include files, this is everything that is needed to bring up the GPU and display basic text at a specified (x,y) location. The hex strings within brackets are actually SPI bus cycles. Encoding the SPI bus cycles in ASCII text makes Mesa-Bus designs portable, easy to document and highly compressible ( as shown ). The low cost FPGA on each Mesa-Module does all the required conversion from ASCII text to SPI ( or I2C ):


Below is an out of focus picture of the Hello World sketch ( actual text on the LCD looks great – the digital HDMI SVGA signal is perfect ). Basic ( non-painted ) text is available in 1x, 2x or 4x sized VGA fonts:


[ Whats Next ] :   Next step is to assemble the final board that merges the Mesa-Bus SPI bridge FPGA and the GPU+HDMI onto a single board.  Layout of the merged design is shown below in CopperConnection – a fantastic simple to use and low cost layout tool that exports Gerbers ready for OSH-Park.  CopperConnection is as easy to use as ExpressPCB – but it generates Gerbers that can be fabbed out anywhere. Best $50 I’ve spent in a long time. I’ve since upgraded to the $100 “Ultimate” edition that allows me to generate and hand edit ( via custom Python scripts ) the actual board files. Fantastic Tool – check it out over at RobotRoom  free version doesn’t export Gerbers – but is a nice demo.  Below is the merged Mesa-Video design, it is 1″ x 3″ ( 77 x 26mm ).


The FPGA has been upgraded from the 400 Logic Cell ICE40LP384 to the new 4,000 Logic Cell ICE5LP4K. The new and larger FPGA is a game changer for BML as it is only a few dollars more and provides 10x the resources, contains 80Kb of SRAM and also an internal 48 MHz oscillator in a 1cm^2 package that is 2-layer friendly.  To simplify design and manufacturing, the single ICE5LP4K device will be used on all Mesa-Modules going forward. The larger FPGA with SRAM supports an alternative bitstream idea that could potentially turn Mesa-Video into a 4-channel LVCMOS digital logic analyzer ( no computer involved ). The power of open-source is that it turns any project like Mesa-Video into a canvas for others to improve upon. Final firmware design will be EEPROM upgradable over the Mesa-Bus interface – supporting in-field FPGA upgrades from any PC with a FTDI cable.


[ Mesa-Duino-M0 ] : Mesa-Duino ( for short, pictured above – 1st proto ) is an Arduino-M0 compatible derivative that plugs directly into slot-0 of the Mesa-Backplane and becomes the bus master instead of an external board. Total BOM for the assembly is less than $10 – which is pretty impressive for a 48 MHz 32bit ARM CPU with 256KB Flash and 32KB SRAM in a 1″ x 1″ form factor.  The actual Arduino-Zero (.cc) and Arduino-Zero-Pro (.org) contain an Atmel-ICE on-board. The Mesa-Duino design removes the ICE and makes it just the ARM CPU, a FTDI connector for the Mesa-Bus mastering and a micro-USB for firmware upgrades – reducing the BOM item count by like 90% while maintaining compatibility with the Arduino IDE ( ultimate goal – and why ATSAMD21G18 was chosen ).  BML encourages users to use whatever microcontroller they already have for Mesa-Bus mastering – but if you wan’t something really powerful, small and inexpensive – the Mesa-Duino with a 3Mbps hardware serial UART on board is a nice solution. Next board spin will remove the large 2×8 header. If BML can locate someone to manufacture the Mesa-Duino, the intention would be to provide kick back royalties to the Arduino organization for future Arduino development expenses.

[ PCBs also in the queue ] : Along with Mesa-Video, 4 other PCBs have been sent out to fab to begin the Mesa-Module family. All Mesa-Modules heavily reuse the same FPGA layout and are all 1″ wide with identical 1×6 0.100″ right angle header connector for plugging into a FTDI Cable, a Mesa-Backplane or a standard bread board. Cost is very low, with BOM for all below $10.

Mesa-Logic : A general purpose FPGA development board with 4,000 Logic Cells, SRAM on chip and 16 LVCMOS 3.3V IOs ( limited drive strength). The FPGA will be firmware upgradable in the field allowing users to design whatever.


Mesa-GPIO : A general purpose IO module with 16 3V 25mA drivers, 5V tolerant via a PCA9539 IO Port Expander IC. 1.5″x1″ (38x26mm). Mesa-GPIO is a typical example of a low cost Mesa-Module, left 1/2 of the PCB is the Mesa-Bus 1×6 connector and the bridge FPGA, right 1/2 of the PCB is the IC specific to the module and user connector for that IC.


Mesa-ICT : Pogo-pin board for programming FPGA EEPROMs post assembly. 1.2″ x 1″ (30x26mm). The header on the right mates either to the Lattice HW-USBN-2B programmer or the Mesa-Logic module for rapid “self-hosting” EEPROM programming post assembly as a bed-of-nails test fixture. Eight 0.050″ pogo pins hold off FPGA configuration and provide full access to EEPROM for external programming.


Mesa-Backplane : 4 slot back plane that may be cascaded for more slots. 1.3″x0.7″ (33x18mm). Mesa-Bus connections are point-2-point ( WRo to WRi and RDo to RDi ), meaning that cascade depth is limited by the 5V supply current, not the number of loads on the serial bus. Multiple backplanes connect end to end to support 4,8,12, etc modules from a single master.


The 5 boards have been sent out to fab and should arrive around mid September 2015. The ICE5LP4K FPGAs in the 2-layer friendly SG48 QFN 0.5mm pitch package are newly released from Lattice and a reel of 50 have been special ordered from Digikey that are due to arrive 1st week of October. Plan is to hopefully acquire some more ES GPUs from FTDI and begin assembling 3 boards of each design to send out for evaluation by interested parties for potential volume manufacturing.

[ Mesa-Modules ]

All Mesa-Modules will be fixed 1″ wide and length available to grow as needed for each design. Most Mesa-Modules will be 1″x1″ with a BOM cost of under $10 for things like GPIO, H-Bridge, Stepper Motor Controller, RTC, thermal sensor, etc . Converting an existing breakout board design from places like Adafruit and Sparkfun to a Mesa-Module should be easy and only be a $5 adder for the Mesa-Bus bridge FPGA and some BML engineering time.


The Mesa-Video design with 3 ICs ( not counting LDOs ) should have a total BOM cost at around $20-$30. The retail cost would need to stay below $50, which should be possible. Mesa-Bus is a solid and easy to use solution for expanding Arduinos with USB like simplicity. Please reply to this post and write to me what you think and what kind of Mesa-Modules you would like to see.


[ Mesa-Video FAQ ]Intel_P8051

o Does Mesa-Video work with devices other than Arduinos? Yes, it will work with any device with a 3.3V LVCMOS ( or level shifted to ) UART serial port.  Got a Teensy, Intel Edison, or even an old 8051 design that you would like to add video to? Bring it on. The bus master sets the bit rate for all devices. This hasn’t been tried yet, but the Mesa-Bus protocol is asynchronous and clear-text, designed to be portable so it should work great over a wireless Bluetooth serial link like a BlueSmirf. With a wireless link it should be possible to use Mesa-Video as a wireless remote display from a desktop PC or Arduino to a TV ( think home security monitoring, stock tickers, etc ), or place the Arduino in a quad-copter and have it stream live video over bluetooth (or other wireless standard) to a remote Mesa-Video display. Clear text protocols like Mesa-Bus are very portable. Designed around old school ( and versatile ) UART serial communications of a wide baud range, it is very simple to convert from LVCMOS 3.3V serial to RS-232 (single-ended) or RS-422 ( differential ) for long runs of to 1,500 meters ( almost a mile for Luddites like me ). SPI and I2C just aren’t designed for this.


o How difficult is the software to integrate into my design? The complexity of the software depends on how many features you intend to use. BlackMesaLabs provides the basic Level-1 ( Text Only ) and Level-2 ( Text + Limited Graphics ) software in both Arduino C++ Sketch and Python for PC examples. Level-3 software is the full up FTDI development kit available here and makes all of powerful FT813 features available. If all you want is to display some debug text information, my screen shot of the Arduino-IDE is all the software that is required.

o What are the Level-1 text modes? When the display is initialized, 1of3 VGA text display modes may be selected. 1x Zoom for 98×36, 2x Zoom for 49×18 or 4x Zoom for 24×9. The graphic text provided by the FT813 can mix and max varying font sizes.

o What are the Level-1 functions? video_setup(), clear_screen(), clear_console(), print_at() and print_ln(). The function print_at() displays a text string at specified x,y location on the screen. The function print_ln() appends and scrolls a text string on a virtual console.

o What will the Level-2 functions be? Most likely draw_text(), draw_point(), draw_line(), draw_rectangle().


o If Mesa-Bus and Mesa-Video are open-source software and hardware, where are all the design files? All of the design files are safely stored on the Black Mesa NAS. Once a relationship between BML and a board assembler and distributor is established, the appropriate time and location to upload all design files to the internet ( most likely GitHub ) will be determined.


o What is the maximum bit rate of Mesa-Bus? It has been tested at 3Mbps, which is the maximum UART rate of the Arduino M0 hardware. Final FPGA bridge design will be clocked at 48 MHz, which assuming 8x asynchronous serial oversampling, a baud rate of 6Mbps should be possible. FPGA to FPGA serial communication where both FPGAs have the same 48 MHz base clock could potentially work at 4x oversampling, or 12 Mbps. One Mesa-Module idea BML is considering ( which may seem ludicrous on the surface ) is a bitstream for the Mesa-Logic board called Mesa-UART, a FPGA design that would take SPI from a CPU ( at say 20 Mbps ) in SPI binary format and stuff the traffic into a rate converting FIFO which is then serialized using a fast UART for Mesa-Bus mastering at 12 Mbps. This may seem like a lot of work ( and overhead ), but for uCs with slow UART serial ports – this is a viable solution for fast data transfers. Mesa-Logic is very flexible and fully open-source FPGA design meaning that a user specific project could easily be adapted requiring only a new FPGA bit stream ( for example, an 8bit parallel interface with IO strobes from an Apple ][ – level shifted from 5V to 3V of course ).


o May SPI be used instead of Mesa-Bus UART serial protocol with Mesa-Video? Yes, on the final design the bridge FPGA will have a bypass pin that may be tied to GND. This will bypass the FPGA’s UART and Mesa-Bus decoder and pass SPI signals from the FTDI 6 pin connector to the SPI interface of the FT813. In this configuration, the SPI setup and hold timing will vary slightly from the FT813 spec and the FTDI 1×6 connector will no longer be compatible with a FTDI cable or a Mesa-Backplane. This SPI bypass option is an excellent development interface for someone ultimately targeting a FTDI Flat Panel Module ( See Below ) for a commercial application:


o Why Buy Mesa-Video when a 512×512 FTDI 5″ Flat Panel is available for $100? Primary difference is that Mesa-Video drives large displays at 800×600 resolution and simplifies digital video from any Arduino sketch without requiring importing a mountain of libraries and understanding the GPUs programming interface. The EVE FT800 series of chips are very powerful – which also means complicated – even just for basic things. Mesa-Video makes the simple things simple without giving up the full power of the FT813. The full FTDI EVE API is still available to use with Mesa-Video hardware.


o Will a version of Mesa-Video that supports gaming be made available? Excellent question, this FT813 design actually canceled the original BML GPU design called Video-Duino as the FT813 is much smaller and more cost effective than the Spartan6 FPGA based GPU. The FT813 is a fantastic, small and low cost solution for displaying text and primarily static graphics. If there is enough interest, the FPGA GPU design may be restarted using a Lattice ICE5LP4K  FPGA ( low cost and small like the FT813 ). This would either be designed like a 3DFX like graphics accelerator , a GPU that goes between the FT813 GPU and HDMI chip and overlays real time gaming graphics, or possibly standalone FPGA GPU.  Idea is for the design to provide 8×8 Bitmap Textures and Sprites with velocity and collision detection integrated into the FPGA hardware design ( offloading Arduino of real time work ). It would be a fun development platform for 8bit NES like 2D video gaming. Color resolution may need to be reduced from 24bit to 9bit for a small low cost FPGA to handle the interface. Please respond if there is any interest out there for a gaming specific module like this.


o Is this an Arduino shield ( shown above )? No, but it could potentially replace the shield concept as a much simpler, smaller and more robust method for adding multiple peripheral devices to an Arduino. A Mesa-Bus back plane is in the queue that supports 4 slots ( and can cascade to 8,12, etc slots ) and there is also an Arduino Zero compatible Mesa-Zero module. There are multiple low cost Mesa-Modules envisioned, Mesa-Video just happens to be the first.

o Do multiple Mesa-Modules have to be daisy-chained? No, if you are concerned about latency or series circuit aspect – the CPU master may use a separate serial port pair for each Mesa-Module. Arduino’s Software-Serial makes this very easy.


o Is Mesa-Video Low Power? Yes! No promises of powering Mesa-Video  from a single lemon, but using this handy USB Current Meter that measures 5V USB Current in 10mA units, on powerup, with HDMI disabled, it measures current at 0 (so less than 10mA ) and with everything enabled generating video at 800×600 it measures 40mA ( so less than 50mA – Take that nVidia! ). Power-on inrush current has not yet been measured yet. USB 2.0 is rated for 500mA, so a person could theoretically drive 10 HDMI video displays from a single PC over a FTDI cable using 10 Mesa-Video boards daisy chained on a Mesa-Backplane ( think 60″ LCD TVs in a giant 3×3 15’x15′ array…. ). The 0.100″ +5V pin on a 1×6 header is physically rated for 3 Amperes, so the Mesa-Bus has room to grow.


o What is the Mesa-Video resolution and timing and may it be changed? The open-source software for Mesa-Video automatically configures the hardware for 800×600 56 Hz timing per VESA Spec VG900601.  This was selected as the FT813 PLL is able to exactly generate the 36 MHz dot clock for 800×600 and 36 MHz exceeds the 25.175 MHz DVI minimum. The FT813 chip itself may be configured for other frequencies, but this falls outside the scope of Mesa-Video hardware+software. Plug fest tests thus far have shown that computer displays with DVI or HDMI inputs agree and work well with 800×600 input feed regardless of their native resolution and aspect ratio.


o What else is Mesa-Bus good for besides Arduino expansion? Remember the days of the LPT1 parallel port when it was easy to add homegrown bread boarded hardware to a PC? A Mesa-GPIO module can bring those days back. A $20 FTDI cable plus a similarly low cost Mesa-GPIO board with a PCA9539 provides 16 5V tolerant IO pins the PC can interface using any language that can talk to a standard COM serial Port ( Perl, Python, Powershell, etc ). Need more than 16 IOs? Buy a Mesa-Backplane and populate it with 2 or more Mesa-GPIO modules.


o What other Mesa-Modules from BML are planned? Here is the complete list to date:

  • Mesa-Video : 800×600 HDMI/DVI Digital Video.
  • Mesa-Backplane : 4 slots for Mesa-Modules. Cascadable.
  • Mesa-GPIO : PCA9539APW based 16 3V 25mA GPIO pins ( 5V Tolerant ).
  • Mesa-Analog : AD5592 8 Channel 12bit ADC/DAC/GPIO.
  • Mesa-Stepper : L6470H based Stepper Motor Controller.
  • Mesa-Relay : ULN2803A Darlington based 500mA inductive load driver.
  • Mesa-Logic : Lattice ICE5LP4K based 4K LUT FPGA fabric with user IO.
  • Mesa-DeadBug : Plugs into Mesa-Logic for dead-bugging any IC to 16 IOs.
  • Mesa-Memory : 8Mb Flash, 1Mbit SRAM and 16Kb FRAM ( non-volatile ).
  • Mesa-Environment : Temp, Light, Accelerometer, Altimeter, Magnetometer.
  • Mesa-Time : RTC clock and programmable timers.
  • Mesa-Touch : 11 pin capacitive touch sensor ( AT42QT1111 ).
  • Mesa-UART : 6 Mbps SPI to UART bridge for CPUs with slow UARTs.
  • Mesa-Duino : Arduino M0 derived bus master ( 48 MHz 32bit ARM CPU ).
  • Mesa-ProMini : Arduino ProMini bus master ( 8 MHz 8bit AVR CPU ).


Please reply if you know which Mesa-Modules you find most interesting or if you think of something missing. My direct email is available at the very end of the BML Welcome Page. The BML goal is to reuse the same FPGA bridge design and crank out multiple modules.  FPGA reuse greatly simplifies design effort, production assembly, test and firmware programming. Goal is for the Mesa-Modules to retail in the $20 – $40 range, just slightly more expensive than a basic SPI or I2C breakout board. The two CPU boards aren’t required of course ( any board with a serial port will work ), but will be much smaller ( 1″x1″ ) and less expensive than conventional Arduino boards as they won’t have IO ( only the 6 pin Mesa-Bus ). The picture above is the Mesa-Zero proto ( final version won’t have the 2×8 connector on right ).


Something very similar to this Intel Edison UART adapter ( shown above ) with RX and TX swapped would make for a great Mesa bus master too. Edison isn’t really my bailiwick, but would be a great solution for a project needing Wifi or Bluetooth built in. The clear text UART serial protocol of Mesa-Bus makes it simple to switch CPU architectures.


Electrically, RaspPi would work too – Mesa-Video might not make much sense, but the other Mesa-Modules can dramatically increase ( and isolate ) the IO capabilities of a standard RaspPi.VintageRadioShack_Storefront

o Where can Mesa-Video be purchased? Excellent question.  Sadly, probably not at your local Radio-Shack. Goal is for Mesa-Video to be  a completely open-source hardware and software ( like Arduino ), low cost and readily available in volume for all Arduino developers yearning for a video display. Mesa-Video ( along with other Mesa-Modules ) can greatly accelerate the Maker-Movement by making it much easier for artists to implement their Arduino based designs. BML only does initial prototype assembly and is therefore  actively looking for a production manufacturer and distributor such as Sparkfun , DangerousPrototypes, SeeedStudio or Adafruit that might be interested in Mesa-Video and other planned family of Mesa-Modules. The FT813 GPU chip is not available for purchase just yet, so this design is still in pre-production evaluation until October-2015. Please provide feedback and express any interest in a Mesa-Video board and the Mesa-Module family. Black Mesa Labs aims to assist the Maker Movement by Delivering the Future … 2 Layers at a time.


Mesa-Video : 800×600 Digital video for Arduinos over 2-wire serial Mesa-Bus

FTDI FT232H USB 2.0 12Mbps results


[ 01.14.2015 ] Fully evaluated my new USB 2.0 FT232H board tonight. Modified my Xilinx Spartan6 Nano FPGA design to PLL the 40 MHz reference XO to 120 MHz instead of 80 MHz so I could get a perfect UART divisor to 24 MHz for 12Mbaud communication. Then I modified my SUMP.exe application to configure the FTDI DLL for communications at 6 Mbaud and 12 Mbaud instead of normal 921,600 baud. Learning how to communicate to the FTDI DLL from Powershell ( I had to reverse engineer C# example code ) in December 2014 was what started this project to begin with as it allows configuring baud rates faster than Windows COM limits (921,600).  With everything modified I had SUMP measure the event dumps of 8KB FPGA RAMs using the different physical interfaces ( USB 1.0 FT232R vs USB 2.0 FT232H ) and different software interfaces ( Windows COM driver versus FTDI DLL ). My new board is definitely faster ( 3.5x ) but not the 12x faster that I had hoped for. Would it be faster with a C or C# application instead of Powershell? Probably, I’m not about to go down that path though.


USB 1.0 FT232RL COM4 @ 921,600 baud : SUMP Dump took 248ms or 262Kbps. 1.00

USB 1.0 FT232RL DLL @ 921,600 baud : SUMP Dump took 240ms or 273Kbps. x1.04

USB 2.0 FT232H COM4 @ 921,600 baud : SUMP Dump took 257ms or 255Kbps. x0.97

USB 2.0 FT232H DLL @ 921,600 baud : SUMP Dump took 237ms or 277Kbps. x1.06

USB 2.0 FT232H DLL @ 6,000,00 baud : SUMP Dump took 83ms or 790Kbps. x3.02

USB 2.0 FT232H DLL @ 12,000,00 baud : SUMP Dump took 71ms or 923Kbps. x3.53

So, I suspect I may have hit a Windows / Powershell limit at around 900Kbps payload at 12Mbaud using the default asynchronous 2-wire interface.  This probably puts a kabosh on my next board with the FT232H that has the 40MByte/sec 8bit FIFO interface ( 320Mbps theoretical ). I am skeptical I will get any faster than the 12Mbaud asynch serial and its a lot of Verilog writing and debugging to implement the FIFO interface inside the Spartan6 FPGA, not to mention consuming a full Nano x16 bus connector.  I like to follow the Ethernet evolution model of   not changing until you can achieve a 10x improvement.  3.5x improvement is good – but not 10x. I think I may have to make the trade off of rapid SW development in a scripting language ( Powershell ) versus fastest possible HW interface requiring low level compiled code ( C, C++ ), since SUMP transfers RLE compressed data anyways – really, I guess I’m not in THAT much of a hurry as it is transferring the entire event dataset in 250ms at 921,600 baud – which isn’t too bad really, that’s not even enough time to get a cup of coffee.

Question : FTDI just announced the new chip FT600Q that does USB 3.0 Superspeed ( 5 Gbps ) in a MLF56 package.  Do I design a Nano x16 peripheral board for one when they ship end of this month? Maybe – it would be a great technical achievement to get 5Gbps SERDES chip – “Black Mesa Labs – Delivering 5Gbps SERDES on 2-layer PCBs”.  Will it be faster than my new FT232H USB 2.0 ? probably not constrained by Powershell and Windows. Great challenge regardless. Wait and see I suppose…

FTDI FT232H USB 2.0 12Mbps results

USB 2.0 FTDI 12Mbps Serial Converter Board Assembly


[ 01.12.2015 ] Assembled my new USB 2.0 12Mbps UART board today.  Thought I would take the opportunity to blog about the entire process from start to finish – board design, procurement, surface mount assembly and final test.


[ 12.23.2014 ] Started new ExpressPCB 2-layer design for a small 1″x0.5″ board to replace a standard 1Mbps FTDI Cable but run 12x faster using a USB 2.0 chip from FTDI – the FT232H.  All of my previous FTDI board designs have used the FT232R as it is a smaller chip that includes an oscillator and all the USB passives on chip.  The FT232R interfaces to USB at a conservative 12 Mbps versus SERDES 480 Mbps for the FT232H.  The FT232H requires a lot more support circuitry ( 12 MHz precision oscillator, protection diodes and is in a bigger package ).  Expecting a 2-layer PCB to work at 480 Mbps was a huge $3 gamble I was willing to take.


[ 12.26.2014 ] Finished the design ( working on it part time – had other things going on the last few days ). Typical design flow is schematic design and then have a computer autoroute. My flow is quite different in that I manually place components where I think they can be routed using only two layers and also assembled by hand in as small area as possible. Using ExpressPCB version 7.0.2 (only), layout is done manually using a vector drawing program.  Red signifies copper on the top, green copper on the bottom, yellow silkscreen on top for labeling. Designing a PCB like this is very much a challenging puzzle.  After I finish the design, I import the ExpressPCB file into CopperConnection and export a single *.ZIP containing layer Gerbers and Excellon drill files in OSH-Park selected format. This process takes about 10 seconds. I could actually layout my board design in CopperConnection – but I already know ExpressPCB  – so why bother learning a new tool? ExpressPCB is a great service for at work when I need a board fast. When I’m not in much of a hurry, OSH-Park is super inexpensive and high quality.


[ 12.26.2014 ] Uploaded Gerber and Excellon *.ZIP file of design to OSH-Park. The website takes a few minutes and presents a rendering of all the different layers ( Copper, Solder Mask, Silkscreen, Drill holes ). Approve and purchase the design 0.61×1.21 inch (15.39×30.66 mm) 2 layer board for $3.65


Here is an example OSH-Park panel that I found on the web that they showed at a Makerfaire in Portland in 2013. Notice how small all the designs are and how much daylight shines through. Their software does a fantastic job of panelizing multiple small gerber designs. Other low cost PCB places like IteadStudio stick with simple fixed rectangles on a 5x5cm grid and charge on those dimensions even if your design is much smaller. I often look at other people’s OSH-Park designs at flickr site to see how far they stretch the 2 layer and 4 layer capabilities.


[ 01.10.2015 ]  Bare boards arrive in the mail. They usually have rough snap-off edges which are easily filed down with a metal file.


[ 01.12.2015 ] Surface Mount Assembly begins.  My tools are a 10x/30x microscope, a Weller-Ungar 921ZX soldering station with a screwdriver tip, GC Electronics Liquid solder-flux 10-4202, Kester “44 Rosin Core” lead solder 66/44 0.5mm .020″, Chem-Wik 0.075″ solder wick,  Isopropyl Alcohol 99.8% IPA, Cotton Swabs, Dental Pick, Tweezer and “Dexter” leather gloves. I also have a 4″ surplus case fan at the back of my microscope to take away the fumes.


I always start by placing the QFP 1st as alignment is crucial with 0.5mm pitch between pins. Once the package is perfectly aligned ( 10x magnification ) I pour solder flux liberally along the perimeter. Flux is amazing stuff, not only does it perform Jedi mind control on molten lead to seek out copper and avoid solder mask – but it is wonderfully sticky stuff and does a fairly decent job of keeping the QFP from drifting out of alignment.  That said – I always tack down the corners first with just a bit of solder and then pour the solder on thick – rolling across all the leads. End result – complete ugly mess, shorts everywhere – but the leads are all attached to their pads in perfect alignment.


Pass-2 ( you knew there had to be a pass-2, right ? ) – Solder Cleanup.  The wick combined with the flux on the board magically sucks up the excess solder shorting all the leads.  This step gets really hot really fast. I protect myself ( finger tips ) with my Dexter gloves ( thin unlined leather ) so I can position the wick and not burn myself.  I protect the chip by only wicking about 4 pins at a time then pull back and let the IC cool down for a few seconds before proceeding.  Takes patience but perfectly soldering an internally fried chip to a board is a real bummer. I do own a nice hot air reflow station where I can remove bad ICs -but I generally would rather just start a new board assembly from scratch than rework a bad one.


Pass-3 : This pass is optional, but is worth the effort.  Apply lots of IPA ( the kind that makes you go blind – not the tasty beer ) and cotton swab scrubbing to remove all the flux.


Pass-4 : With the QFP clean, I crank my microscope up from 10x to 30x and go around to each pin with a dental pick and check for bad solder joints ( loose pins ) or any shorts. I usually don’t find any, but the time to check is before all the other components are soldered to the board as access to the QFP pins becomes difficult if there are other components around.


Once the QFP is on everything else is pretty straight forward.  I only use 0603 for Bypass caps ( 0.1uF ) and 0805 10uF Bulk Caps and 0805 resistors.  This speeds up assembly as I don’t need to look up each component in the design file, I can tell just by the pad size and what its connected to determine what to place.  For example – I never connect a 0805 resistor between power and ground – so it must be a 10uF bulk cap.  For the small SMT 0603s and 0805s I drop a bit of solder on 1 of 2 pads, then apply to component with tweezer and resolder the 1st pad to the component, then with the component firmly ( fully planar ) attached to the board, I apply solder and the iron tip to the 2nd pad. After this, the 1st pad usually needs some more solder to make a good looking connection.  Thats it – I’m done with assembly!


Before test – I take a moment to reflect and decide what I would do differently to make assembly easier in the future.  For this design the microUSB connector was a problem. It is designed for solder paste and oven reflow assembly as the leads are recessed behind the shield housing.  I was able to solder them eventually, but a little more space between the connector and QFP would have been better. Mini-USB is MUCH easier to hand solder. Another issue I discovered is the shield extending behind the leads unexpectedly results in the shield resting above my 5V trace on the top side.  The solder mask is the only insulation preventing a short from 5V to shield return.  Prior to plugging into my computer, I applied my 5V DC supply to 5V PCB rail and the shield and confirmed no short.  This is OK for a one-off, but I immediately created a new “fixed” version of this design and moved the 5V trace south about 0.010″ to clear the shield. For $3.50 I will probably fab out this “fixed” version and scrap the remaining 2 unstuffed PCBs of Gen-1 if  I decide I need more than 1 unit.  The micro USB connector was the only issue, so moving on….

Time for test. Plug and pray a micro USB cable from my computer into the board.  And look at that! COM5 ready for use.


1st test is to send 9,600 baud to my scope. Bit length is about 100us, or roughly 10,000 Baud.


2nd test to send 921,600 baud to my scope. Now the bit length is about 1us, or roughly 1Mbaud.


3rd and final test, run my Powershell  script that talks directly to FTDI device driver DLL and configure port for 12Mbaud.


Excellent! I’m in business.  I now have a USB 2.0 to 12Mbps UART serial interface into my FPGA designs that is electrically and mechanically compatible with my existing FPGA boards ( that are designed for the industry standard FTDI cable ).  That ends my Black Mesa activity for tonight.  Next tasks are to change my FPGA design for the faster baud rate ( simple divisor setting in Verilog ) and establish Backdoor communications (Register Reads and Writes using BD_SHELL.exe ) and then time SUMP.exe data dumps from FPGA to computer and compare date rates between 1Mbps cable and 12Mbps board. Due to Windows and Powershell limitations – it may or may not be faster.  If it is faster ( like 10x faster ) – my next iteration of the design is ready to be assembled. This uses the same chip, but interfaces using 16 wires over a Nano x16 header instead of the FTDI 2 wire 1×6 connector. Spec says transfer rates should be 40 MBytes/Sec ( 320 Mbps ) – which theoretically would be 27x faster than my existing design that is already 12x faster than my existing FTDI cable. That project is for another day however.


USB 2.0 FTDI 12Mbps Serial Converter Board Assembly