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

Quick and Easy Fence Post Replacement


Taking a short break from electronics to document an easy solution for the frustrating home repair of rotten fence post replacement.  Here in Seattle, it is quite common for pressure treated 4×4 fence posts to rot from the ground level down after about 20 years in the humidity. Standard replacement method is to dig out and smash up all of the 24″ concrete base surrounding the rotten 4×4 and replace with new concrete. Two feet ( ~1/2 a meter ) down is a lot of digging ( especially in Seattle clay+rock soil ) and with 3 rotten posts ( and 27 more most likely to fail in the next 5 years ) – I set out on an engineering mission to find an easier – greener – way. This might not seem appropriate for a Black Mesa Labs post – but just like how BML does things very different in electronics from society norm ( example : soldering 45nm QFN FPGAs onto 2-layer PCBs using a $20 hot plate ) – the fence post removal was a full Thomas Edison obsession of doing something different through persistent experimentation. Going into this project I was told by countless people 1) That just isn’t how it is done, 2) It won’t work and 3) Just hire a guy to take care of it. Like all things at Black Mesa Labs,  I was determined to do things different.

Through much trial and error – this is the Black Mesa Lab “Cork Popper” method of fence post removal and replacement without all the digging. This method supports removing the rotten section of 4×4 while retaining the majority ( 75%) of the existing concrete base in place. Keeping the existing concrete also means the new post will be in the same location and plumb as the previous post. Less waste, less effort, faster repair.

Step-1 ) Tear down the fence sections supported by the rotted 4×4 post. A Sawzall with a metal cutting blade that rips through nails makes quick work of this.


Step-2) Dig a hole 12 inches ( 1/3 meter ) down around just two side of the concrete base. This is only 1/2 the depth of the entire concrete base. Once exposed, this concrete will now be like an egg-shell ( assuming it has been in the ground for 20 years ). The packed earth is the only thing holding this structure together at this point in time. Using a wrecking bar and a small sledge ( or even just a hammer ) – pry off the exposed concrete. It should easily break off with very little effort.



Step-3) Post Extraction.  With the concrete removed, the post is now much easier to extract as only the very bottom 12″ is applying pressure against all 4 sides.  If the post is not entirely rotten, the easiest method is to drill a 3/4″ hole through the post above ground level and shove a segment of 1/2″ black iron pipe.  For less than USD $40 total I purchased two matching 6 ton hydraulic bottle jacks which can then lift the iron pipe ( and 4×4 post ) slowly out of the ground.


Step-4) Is only necessary if Step-3 failed – the post is so rotten that it breaks into 2 pieces, a 6′ above ground section and a 2′ below ground section.  Using a small hand saw ( such as this great little folding jab saw ) – or an awesome mini “Sawzall” such as this 12V Bosch reciprocating saw cut the rotten section away and leave a nice level 4×4 surface of fairly decent wood. A friend of mine says this 12V Bosch is actually made by Playskool , but I don’t care – it gets into really tight places. Trick is to have lots of 12V Lithium Ion batteries ( I have 5 ).


Step-5) Attach the extractor. I built this extractor for about $40 using these 12″ lag bolts and some eye bolts from Home Depot and this 5,000 lb 36″ trailer safety chain. I have 30 posts total in my fence – so money well spent. Extracting the old 4×4 in tact means I can reuse 75% of the existing concrete base. This is about 150lbs of concrete I don’t need to buy, haul and mix and old concrete I don’t need to dig out of the ground and toss into a land fill.  Win-win.


Step-6) Screw the extractor into the remaining section of post using a ratchet and then lift it out using the bottle jacks.


Step-7) Insert the new post. I used Hem-Fir Severe Weather Standard Pressure Treated Lumber (Common: 4 x 4 x 8; Actual: 3.5625-in x 3.5625-in x 96-in) from Lowes for $10. The 4×4 post should go in easily assuming dry wood and should already be plumb ( but check with a level ). Pounding with a 4lb sledge from the top if necessary. I really like this 4lb sledge as it is small enough to wield on top of a 6-foot ladder like a normal hammer but still packs a punch. For the old/new hybrid base, surround the exposed 4×4 with some chunks of 4x4s or 2x4s as temporary spacers and then surround those with some cardboard. Fill in outside with packed dirt. Remove the wood blocks and pore the concrete between the post and the cardboard. I used a single 80lb bag of concrete for 2 posts. I think next time I will buy 50lb bags instead as the 80lb bag is just awkward to handle. While the concrete sets – remove old nails from the fence panels and then start rebuilding.  I rebuilt using these Deckmate star drive screws and my Bosch Impact Driver. Very little effort and time compared to hammering and will make the next tear down job much easier. Hopefully this post will last another 20 years.

12 hours of work start to finish and the Job is done!

I hope you found this short tutorial on a quick and easier method of fence post extraction and replacement helpful.

Quick and Easy Fence Post Replacement

The Future is Now!

IMG_1218 - Copy (2)

09.16.2015 – Black Mesa Labs was delivered a very unexpected large 2’x2′ (60×60 cm) package today. BML generally uses a U.S. quarter as a scale reference – but for this – a Pint glass is in order:


Examining the shipping label – Realized the new Lattice ICE-Ultra FPGAs had arrived 3 weeks early. This new 40nm FPGA from Lattice is a game changer for both BML and the Maker Movement.


Backstory – Back in May 2015, BML started experimenting with Lattice ICE40 family  as an alternative to large Xilinx TQFP devices for BML designs.  The ICE40LP384-SG32 appeared to be a game changer for BML as it was both low cost ( sub $2 ) and in a 2-layer PCB friendly package ( SG32 ). The big two FPGA vendors ( let’s call them Brand-X and Brand-A ) have gone entirely BGA for their FPGAs – which is completely useless for BML and the OSH-Park style 2-layer Maker Movement PCB designs and assembly. Lattice ( although offering mostly BGA ) has FPGAs in QFN packages ( aka MLFs, SGs ) which can be hand soldered. Sadly – the LP384 proved limited in capabilities – a simple Mesa-Bus bridge design that would easily fit in 200 Xilinx LCELLs completely filled the LP384 as 1/2 the LUTs were used as route-throughs ( consuming limited gates for simple routing ). The LP384 turned out to be about as useful as a large CoolRunner CPLD. But wait….

In June 2015 – Lattice announced that their newer ICE-Ultra ICE5LP4K ( 4,000 Logic Cells ) that was originally BGA only would soon be available in a SG48 package (QFN).  4,000 FPGA Logic Cells for $5 in a 7x7mm package that is 2-layer PCB friendly –  Sign me up!  Fast forward to July – the ICE5LP4K-SG48s were nowhere to be found in normal distribution.  BML contacted both Digikey and Lattice and learned the devices would need to be special ordered in quantity in uncut reels – with a minimum reel count of 50, and a minimum order of 10 reels. The ICE5LP4K FPGAs themselves are only $5, but 10x50x$5= $2,500 – not exactly within BML $100/month beer money budget.  Through persistence and careful negotiations, BML was able to secure a “Special Order” for a single reel of Qty-50 FPGAs – or $250 – manageable. Placed the order in July with an ETA of October 7, 2015 – but they arrived 3 weeks early – Christmas in September!

Inside the giant box was a little LP vinyl sized box and a whole lot of bubble wrap:


Inside the little box, the giant reel:


Unfurling the reel – the actual chips – this is all fifty chips:


Single chip- 4,000 Logic Cells in 7x7mm package for $5 – how cool is that?

IMG_1218 - Copy (2)

Backside you can see how it is 2-layer friendly unlike BGA devices:

IMG_1219 - Copy (2)

This FPGA is really a game changer as it is a true FPGA, much more than just a simple CPLD.  It contains 80 Kbits of SRAM, an on chip ~48MHz oscillator, 39 LVCMOS IOs and 3520 Logic Elements ( LUTS + FlipFlop ). A close Xilinx equivalent ( in a much larger 14x14mm TQFP  package ) would be a device like the Spartan3 XC3S200. This new Lattice device is 1/4 the size and 1/3 the price and 2-layer PCB compatible. 4K LEs aren’t enough for a custom CPU or DSP work – but ample logic for bus bridging, UART designs and complicated FSMs ( Finite State Machines ).  My general rule is 100 LEs a designer can easily consume in a short day of RTL design, 1,000 LEs in a week, 10,000 LEs in a month. 4K LEs is a perfect canvas size for BML designs.

Next up is assembly. BML has 3 PCBs that were waiting for these devices to arrive, Mesa-Video, Mesa-Logic and Mesa-GPIO:


Initial use for this chip is the Mesa-Bus bridge function – a daisy-chained serial bus that self enumerates based on location in a serial chain and converts clear text ASCII UART serial into either SPI or I2C. Purpose of Mesa-Bus is to provide USB like expansion to simple microcontrollers like Arduinos using only 2 pins ( TXD and RXD UART Serial ). Stay Tuned – the family of Mesa-Modules are about to come alive!

The Future is Now!

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

“BML Inverted Solder Ball Reflow” process

01_16_2016 Update:


BML has reflowed 1/2 a dozen of the original QFN packages for the Lattice ICE5LP4K-SG48 FPGA using a hot plate. The same process has recently been modified for use with a LGA-28 packages as well ( shown above – which have no visible pads once placed on the board ). This enhanced process is more reliable and requires less manual soldering ( ideally none ) after reflow. The original method would sometimes result in a misaligned IC due to flux bubbling and lifting the light 7x7mm IC off the PCB prior to solder reflowing. This new process tacks the IC in place with solder – preventing the issues with flux bubbling and the IC moving.

Improved 2016 BML Inverted Solder Ball Reflow process for QFN and LGA devices:

  • Step-1 : Solder bump the PCB pads only for components to be reflowed.
  • Step-2 : Solder bump the QFN / LGA pads of the IC as well ( apply flux too ).
  • Step-3 : Align components under microscope and tack into place using flux paste.
  • Step-4 : Using soldering iron, heat the corner PCB pads going to IC.
  • Step-5 : Solder the ground lug from behind ( if device has one ).
  • Step-6 : Reflow PCB for 4 1/2 minutes on a hot plate ( Aroma ) .
  • Step-7 : Visually inspect and hand touchup pads using soldering iron.

07_24_201532-VFQFN Exposed Pad


Black Mesa Labs recently developed a unique and new solder reflow process for soldering 0.5mm pitched QFN packages. The process is called “BML Inverted Solder Ball Reflow”.  Rather than apply paste or individually solder bumping the QFN package ( time consuming and expensive ),  the PCB is instead solder bumped ( quick and essentially free ) using a regular soldering iron and standard rosin core solder. Once the PCB is bumped, the QFN is simply reflowed to the PCB using a hotplate. Proper QFN component alignment prior to reflow is crucial and is made possible using flux paste.

The Black Mesa Lab Inverted Solder Ball Reflow Process:

  •   Step-1 : Solder Bump the PCB pads only for components to be reflowed.
  •   Step-2 :  Align components for reflow and tack into place using flux paste.
  •   Step-3 : Reflow PCB for 5 minutes on a hot plate.
  •   Step-4 : Visual inspection and hand touchup QFN pads using soldering iron.
  •   Step-5 : Hand solder remaining components.

How I got on this path is the need to reflow QFN ( leadless ) packages. Xilinx – my goto FPGA provider has gone completely BGA with all their new devices after Spartan6 (45nm) generation.  BGA devices are great unless you are designing 2-layer and 4-layer PCBs and wanting to reflow at home. Basically, I needed a new FPGA vendor that is more aligned with the Maker Movement – small, inexpensive and easy to assemble FPGAs for 2-layer PCBs. Atmel is an awesome company ( they still sell AVR / Arduino CPUs in DIP packages ! ) profiting immensely from Maker community ( all the Arduinos out there ) – but sadly have no FPGA technology.  I discovered Lattice has a 40nm FPGA family called ICE40 that are small inexpensive FPGAs in QFN32 5x5mm and QFN48 7x7mm packages ( majority are still in BGAs of course ). For $2 – $5 I can buy 400 to 5,000 Logic Cell FPGAs that can be soldered to 2-layer PCBs . Compare this to Xilinx Spartan6 XC6SLX9-TQFP144 at 20x20mm at $15 and you can understand my reasoning to chose Lattice over Xilinx for my Maker designs going forward. The picture below shows my new Lattice design ( all components on top side of PCB, FPGA in center ) versus my last Spartan6 Xilinx design ( top side is nothing but FPGA, bottom side has all the other components ).

Lattice Nano-FPGA versus Xilinx Nano6-FPGA Board:


Back of the larger Nano6 ( with more IO brought out ). Shows all the components on the back.


QFNs vs QFPs :


Regarding QFNs ( leadless ) – they are fantastic small and inexpensive packages with great thermal characteristics and compatible with 2-layer PCBs, but difficult to hand solder compared to QFPs ( leaded ) as there are no leads.  They really want to be reflowed in an oven with paste much like a BGA. I almost purchased a toaster oven for BML but Nathan Seidle at wrote this great tutorial on using an electric skillet for reflowing surface mount PCBs instead of an oven.  I have decided to try this path for my own prototyping for a number of reasons. One limitation of the skillet method is only populating one side of PCB with components.  If you have seen my previous designs, you know I like to get 2 square inches of components on a 1 square inch PCB – so this is a definite drawback for me.  On the flip-side ( or NOT as it turns out ) I am wanting to start some designs I could potentially have manufactured and sold through Sparkfun – so going single sided for component placement makes sense. Here is a picture of a single sided Sparkfun PCB getting reflowed:


My new PCB designs – “Mesa Zero” and “EVEy Video” are actually my 3rd assembly using the skillet/hot plate method.  The 1st 2 attempts were small QFN32 Lattice ICE40 FPGA boards. 1st attempt was using actual solder paste.  The paste was very messy to apply and post reflow left microscopic solder balls on the PCB solder mask I needed to carefully inspect and cleanup. The biggest downside of solder paste however is the shelf life of only a couple of weeks ( it dries up ). 2nd attempt was using my new Inverted Solder Ball method, but trying to reflow everything with no hand soldering. The small 0603 components tended to bounce around as the flux paste turned to liquid and started bubbling. Both attempts ~worked~, but required a lot of cleanup and hand soldering cleanup post reflow.

One tricky thing about QFNs ( also known as MLFs ) is the substrate ground slug in the center. For many devices – it is the only ground connection and must be soldered – so I place a 0.125″ hole underneath the slug. Unfortunately, this means no routing underneath the package.  For my Xilinx TQFP designs, I always have top-side 1.2V and 3.3V power “planes” underneath the package ( virtual 4-layer ). For QFNs, this isn’t possible as top-side is a ground slug ( and ground is on the bottom side ).

The most difficult thing about QFNs are the leads – they don’t exist – so you can’t see them from above. To check alignment, I need to angle the PCB from all 4 sides.  My 1st attempts I used Elmer’s Glue to hold the package in place while I checked alignment under a microscope.  This actually worked really well, but then I discovered flux paste, solder flux, but in a paste.  A single product replaced liquid flux and the glue. Now I use the flux paste to hold the QFNs in place while I angle the PCB to check aligment. The paste flux melts prior to the solder and becomes a necessary wetting agent ( surfactant ) to improve the soldering process to the pads. Amazing stuff that works great!


Here is my new procedure in detail, it involves 5 steps but achieves very good results:

Step-1 ) Decide which components I need to reflow on the hot-plate and using a regular soldering iron, solder and liquid flux to tin the pads for those components. This is my “Bumping” process.

OSH-Park Rendering:


PCB as delivered from OSH-Park:


Solder placed on QFN and QFPs pads:


These pictures are the 2 PCBs before and after I solder the pads. The “Mesa Zero” board is a 32bit ARM Cortex M0+  Arduino Zero clone.  The SAMD21 CPU is only $6 and is equivalent in horse power to a Intel 386 CPU from the 1990s containing 256KBytes of flash and 32K Bytes of SRAM in a 7x7mm TQFP48 package.  I designed the board thinking it had a ground slug, but the device does not – so I did not solder underneath that package. The micro-USB connector has caused me grief soldering by hand in the past as the solder tends to flow inside the connector and obstructs cables from plugging in.

OSH-Park Rendering:


PCB as delivered from OSH-Park:
IMG_0066Solder placed on QFN and QFPs pads:


The “EVEy Video” board is designed around EVE embedded video with a FTDI FT813 800×600 SVGA GPU in a QFN56 package and a TFP410 in a TQFP64 package for reflow and also a small 5x3mm oscillator. This step-1 of soldering the PCB pads with regular solder is equivalent in function to applying solder paste in a normal production assembly.

Step-2 ) After solder is applied to pads I place the components on the PCB and use this Rosin Paste Flux to keep them from sliding around.  The QFPs aren’t that big of a problem as from a vertical viewpoint, I can tell if the 0.5mm pitch leads are aligned.  The QFNs however require me to turn the PCB at 45 degrees for all 4 sides to see if the leads are aligned and is tricky under a 10x microscope. This flux paste keeps the components from sliding around. One caveat is that the paste quickly turns to liquid above about +85F, so the PCB and room must be below that melting point. This picture shows the paste in four corners of each device ready for reflow:


Step-3 ) Time for reflow.  For less than $20 I bought this awesome Aroma Hot Plate from Amazon



The solder flux seeps through all the vias and makes a sticky mess of things, so I use a sheet of aluminum foil between my PCBs and the hot plate. My 1st attempt I used the “High” setting and I swear the FR4 almost caught on fire ( certainly discolored the OSH-Park Purple to Brownish ). This go around I used “Medium” and it reflowed from “Off” to “Medium” in about 5 minutes. I actually use the hotplate as my permanent “work area” base for microscope work now. Unfortunately, it takes a good 30 minutes to cool down completely.

Step-4 ) Inspection and touchup:

The TQFP had a few leads needing touchup when I inspected with my dental pick.


The QFN stayed completely aligned thankfully.  I believe that QFNs reflow much like BGAs and tend to “self align” once the solder has turned molten.


Here is a link to a great video of a BGA package reflowing on top of solder paste slightly out of alignment and snapping perfectly into place. The entire package floats on these molten spheres of solder and aligns automatically.  I believe I am achieving the same results with my QFNs.

Oscillator did well under reflow and stayed aligned.


I had to remove a bunch of flux ( using a wooden toothpick ) to fully inspect all of the pads on the QFN.  The QFN I could see some “non-silver” on the sides so I went ahead and soldered by hand all the leads just to be certain. The real leads are underneath and can not be visually inspected, but seeing solder on the sides is assurance there is some connection. Once the package is aligned, hand soldering the side “walls” is easy, it is just a matter of rolling a giant solder ball down each side. Step-4 is about soldering all the leads by hand. Step-4 is only possible if Step-3 succeeds in holding the components in place perfectly aligned – which it did. Note that I use really large 0.25 x 1.75mm pads for the QFN when 0.25×0.50mm would normally work.  This makes for easier cleanup as it provides a large surface area for the excess solder to adhere to. Step-4 cleanup is as easy as dumping flux to an area and running my soldering iron tip across it. The solder magically seeks out and adheres to all non solder masked surfaces. No solder wick required. Flux is great stuff. Here is a Before and After of Step-4 on the QFN:

Before Cleanup Pass:


After Cleanup Pass:


After Step-4, nothing but silver.  Step-4 is all about hand soldering and inspection of the difficult components. It is imperative to ensure all the difficult components are properly soldered prior to installing the other components as access to the QFNs and QFPs with an iron becomes much more difficult when all the bypass caps, etc are in place. Previously I would use a lot of solder wick for cleanup, now I tend to just use liquid flux as the excess solder will scramble and adhere to the soldering iron tip so long as the tip is clean. This method requires more cleanup ( alcohol and Q-tips – but they are cheap at 1,000 for $10 ).

Step-5, the final step is soldering all of the small components, 0603 and SOT-23, SOIC8 devices and large connectors by hand. Once they are on and I do a final visual component inspection and alcohol scrub and then solder the large through hole connectors. Presenting the final assembly!



Spent some time writing FPGA firmware and trying to bringup EVEyVideo. No valid video out yet. Able to toggle the FT813’s GPIO PowerDown output pin, so basic SPI communication is working. Video timing is complicated and this chip has a million registers and proper sequences to follow, so need to persist at it.


EVEyVideo is Alive!

This morning I succeeded in getting a valid HDMI video signal at 800×600 @ 30 MHz dot clock out of EVEyVideo design. The “@ A B C” are the 1st things I got the GPU to display ( graphics come next ). To save engineering time, rather than try and bring up the FT813 GPU from the SPI Master interface on an Arduino ( and suffer through multiple compile and firmware loading ), I instead created a Nano3 ( Spartan3 XC3S200A ) FPGA design that provides 16 GPIO pins on the Nano Bus header.  This FPGA design can be re-used for anything as all 16 pins are configurable for Input,Output, Drive-1-Only or Drive-0-Only. Having a software bit-bang interface at 1st means I can script everything and iterate rapidly. Here is my 1st image:IMG_1129

Note: About the Nano Bus.  The “Nano Bus” isn’t actually a bus, but an electrical interconnect standard I established at BML for all of my FPGA and peripheral designs.  If you are familiar with PMOD, it is similar, but I think better of course. “Nano Bus” provides 2 GND pins, 5V Unregulated Raw Power ( current limited at 3A by pin ) and 3V regulated ( limited current by masters LDO ). The connectors are color coded Yellow=5V, Red=3V and Green = GND. I can quickly spot 2 PCBs with the Yellow and Green identifiers and know that I can plug them in without blowing anything up. The remaining pins, typically 4,8 or 16 in a dual row configuration are digital IO pins at 3V.  I have splitters that convert a x16 master to two x8s, or a x8 and two x4s, etc.  Also have “Gender Benders” so that I can plug 2 Masters together ( an FPGA and an Arduino for example ). It is a cost effective and versatile interface as I can build a FPGA with a x16 ( 2×10 0.100″ ) Nano Bus Header and plug a small x4 SPI peripheral board into it that is only 1/2″ wide. OSH-Park charges by the square inch, so I can build Nano Bus SPI chip peripherals boards for only $2-$3  that have a 2×4 0.100″ connector ( 2 GNDs, 5V,3V and 4 signals ).

Back to EVEyVideo bringup, so with the Nano3 FPGA as SPI Master to the FT813 in place, I then wrote a Python script for bitbanging the SPI Bits over a standard FTDI USB serial cable. Every SPI clock cycle takes two FTDI serial port writes at 921,600 baud which is REALLY slow of course ( takes about 1 minute for FT813 bringup ). Using this flow means I avoided compiling Arduino C code and flashing firmware. Scripting languages like Python, Perl and Powershell are a tremendous time saver for initial hardware bringup. C is king for final performance but awful for iterating and trying things.

That ends this blog, the EVEyVideo board is fully assembled and electrically all tested out. I will start a new blog in the future specific to EVEyVideo programming and where I plan to take this OSH project. My end goal is to provide a low cost and easy to use video interface for Arduino developers.

“BML Inverted Solder Ball Reflow” process

Arduino ProMini for Nano Bus


Assembled my 1st Arduino Pro Mini clone for my Nano Bus. It is an Atmel ATMEGA328 AVR 8bit CPU with Arduino Bootloader, a 8 MHz XO, 3.3V LDO, Red LED, 1×6 FTDI Connector and a 2×6 Nano Bus connector on a 0.6″ x 0.8″ 2-layer PCB. Functionally equivalent to the SparkFun   Arduino Pro Mini  – in my opinion the best $10 you can spend for a micro controller. My spin is that it is much smaller and plugs directly into my Nano Xilinx FPGA boards. The Nano bus has both SPI and I2C pins of AVR for interfacing with my FPGA designs. I used my Linux workstation and the Atmel AVRISP mkII ISP programmer to load the Arduino Bootloader. Now that the Arduino bootloader is in flash I can use the Windows Arduino app to load sketches via a standard FTDI cable. Works great. My total cost is about $8 per assembly – no great savings over Sparkfun – but in a form factor I prefer.

Arduino ProMini for Nano Bus



03_24_2015 : Out for Fab

Just fabbed out my most ambitious OSH-Park 2-layer PCB yet.  It is called “VideoDuino” and is an Arduino Pro Mini compatible CPU board ( ATMEGA328 ) that has HDMI graphics via my Spartan6 ( Nano6 ) FPGA design combined with a TI LVCMOS to HDMI converter. Also has the new Analog Devices AD5592R that contains 8 12bit ADCs, DACs and GPIO in 8 configurable IO pins over a simple SPI interface. Board measures 2.6″ x 1.6″ – large for one of my designs, $21 for Qty-3. Board is powered from a standard micro-USB connector. Dual FTDI 1×6 headers for configuring CPU and FPGA from a PC’s USB port. As far as I can tell, there are no Arduino platforms with graphics – so this is somewhat unique.

04_08_2015 : Almost fully assembled!


04_11_2015 :  Powered up!



Assembly is 90% Complete.  Still need to solder on the Analog Devices AD5592R and all the headers.  Did a power current test 1st and verified minimum 5V USB current ( about 30mA ) and then used my Digilent HS2 JTAG programmer and Xilinx impact software to download the top.bit bootloader into the FPGA.  Once the bootloader was in, I used BD_SHELL.EXE to load the bootloader permanently into PROM Slot-0 and then my HDMI test design into PROM Slot-1. Power cycled and got my color test bars 1st try! FPGA and HDMI converter chip are at about 70mA on 5V supply. Next I need to download the Arduino bootloader using the AVRISP mkII and verify the CPU is working.

Stage-1 of this project was PCB design.  Stage-2 was assembly and power on test.  Now I will move on to Stage-3 which is FPGA firmware design and Arduino software design.

04_12_2015 : Arduino CPU is Alive!


Used my AVRISP mkII USB to ISP ( SPI ) dongle from Atmel to program the Arduino bootloader from Arduino app on my Linux workstation into the AVR ATMEGA328 micro controller – magically turning it into a full fledged Arduino.  The firmware upload flow for this board is to use proprietary cables ( HS2 JTAG For Xilinx, AVRISP mkII for AVR ) only once on the board after assembly. After both bootloaders are installed, I use a generic FTDI cable to update firmware.  The bright red LED is actually flashing at 1Hz using my bringup sketch. My board is fully software compatible with the awesome Sparkfun Arduino Pro Mini. A tremendous bargain for $10.

Next goal for the project is to design a simple SPI bus bridge from the CPU to my FPGA. My goal is to be able to rapidly prototype software in Python on my Linux workstation that talks directly to the FPGA via FTDI. When I have working Python – I can then port it to C and have it run on Arduino standalone.

04_27_2015 : VGA 80×32 or 40×16 Text is working


One of the main practical features of this project is to provide text output for microcontrollers over just a couple of wires. Actual graphics might be slow to transfer- but text should be quick – especially when I provide hardware line scrolling. Today I got my VGA text going.  I found a free to use VGA equivalent font ( 8×16 ) called Unicode VGA font – Thank you Dmitry Bolkhovityanov! All I needed to do was to write a quick python script to parse out the 1st 128 ASCII characters and build a 2Kx8 Verilog inferrable ROM from it. The ROM size 2Kx8 is 128 ASCII characters by 16 vertical lines by 8 data bits for the 8 horizontal pixels per character which is a single Xilinx Block RAM.  A 4Kx8 RAM then provides a text buffer for 128×32 characters ( displayed as 80×32 on the 768×512 HDMI display ). Only hickup was Spartan6 has some issues with ROMs and my 1st attempt was always reading out nothing but zeros. For some reason switching to inferrable VHDL ROM instead of Verilog fixed the problem – strange Xilinx issue.   Basic circuit works great.  Now I need to decide if I should provide scrolling display feature ( “Trace” ) in hardware or write it in software.  I think I need to create a generic hardware block for zeroing out line bursts of either text of graphics to speed things up.

I am toying with the idea of providing hardware sprites so that this could be used for simple 8bit gaming.  In a 4Kx9 RAM ( 2 BRAMs ) I could provide 16 different sprites of 16x16x9 ( 3bit RGB ).  Games would be limited to dynamic sprites overlayed on top of static ( slowly drawn ) background. If I go this route – I probably would need to provide sound as well….

05.09.2015   So I designed this new bus protocol I call “BML Packet Bus” for transferring bits, bytes and dwords over multiple interfaces ( UART, SPI, I2C, Bit-Bang ) with the bus master being a uP ( ala Arduino ) or even another FPGA.  It is an enhancement over my existing “Pixel Bus” and it is very flexible in terms of payload optimization and ideal for video transfer ( burst increments can be specified for bursting in any direction ). Like all great ideas – I designed it in my backyard hammock on an engineering notepad. I even got so far as typing it all up in Verilog comments. Sadly – I then hit a roadblock realizing it isn’t something I can just write the Verilog in my head and debug in circuit.  I need a simulator. I use and love Modelsim at my day job, unfortunately they have no “Home License” for a few $100 like Eagle does for layout.  They have a “Student Edition” – but I haven’t set foot in a classroom since I was a Science Docent for my kids in the 2000’s. So – looking for a good simulator for home. Have used Icarus Verilog + GTKwave in the past – but would like something better. Any suggestions ?