Uses 10 pin 0.5mm flexible PCB connector, wired to the main board with a 1:N connection. This connector is much smaller and thinner than the 1.25mm connector on v1b, it reduces the space needed between the display board and the main board.
Flipped LCD orientation 180 degrees so font data can be written into bounding boxes in a more natural “left-to-right” orientation, eliminating the need to precalculate the text end point and write characters in reverse sequence
Nudged the display towards the IO header. We’ll experiment with some buttons in the remaining available space
Decoupling capacitors on LCD power pins
The 2 inch 240*320 IPS LCD display we’re been testing has a very pleasing pixel density, but we’re also itching to try the bigger 2.8 inch version. Next week we’ll send out a prototype carrier board for the bigger display, as well as some Bus Plug breakout boards.
Bus Pirate prototype Ultra v1b uses an FPGA to process commands sent through a FIFO buffer to a state machine. Pipelined commands can be loaded into the FIFO and executed by the state machine with per-clock repeatability. Non-pipelined commands halt the state machine while the MCU takes over to perform the command, the delay is unpredictable and depends on many factors such as USB operations the MCU may be servicing.
These commands are currently pipelined and handled in the FPGA by the state machine:
Delays (ms, us)
These commands can be pipelined, but are currently handled in registers:
These commands will be pipelined in v1c and later:
ADC reads (on any pin, Vout)
These commands could be pipelined with some hardware updates:
Pull-up resistors toggle
Power supply enable
Power supply margining (by adding an external DAC)
These commands cannot be pipelined because they happen outside the FPGA:
Mode change (reloads the FPGA)
Jump to bootloader
Self-test (involves tests on the MCU and FPGA)
There are also mode macros to consider, which probably need to be a combination of pipelined commands and non-pipelined commands. This week we’ll choose an external DAC and add it to the board.
Bus Pirate prototype “Ultra” v1b successfully wrote to and read back from a 25LC020A SPI EEPROM chip. The image shows the Bus Pirate reading 8 bytes of 0x02 from the EEPROM at address 0x00, and the bus activity can be verified on the logic analyzer graph. Still a long way to go, but it’s nice to have everything working.
Tomorrow we’ll finish the major SPI commands and general purpose mode features like analog measurement and manipulation of the auxiliary pins. As always, you can follow our latest progress in the forum.
Bus Pirate prototype “Ultra” version 1c is technically done, but we came up with some hot last minute additions this weekend. We’ll skip this board and send out the updated version 1d with the additional features at the end of the week.
Version 1c changes:
4 layer PCB
1MHz 12 bit SPI ADC connected directly to the FPGA
Vout/Vref is also measured through the analog multiplexer, which is changed to to the bigger 16bit version (74HCT4067). This will probably change to two 74HCT4051s instead because supplies of the 4067 are skimpy! We can have one “divide by two” 4051 for 5volt measurements on the IO pins, and one 3.3volt 4051 tied directly to the ADC for measuring lower voltage analog stuff
Beefier 3.3volt supply
The 1.2volt supply is now monitored by the MCU for self testing
0.5mm flex cable connector for the display board opens up a bit of board space
Additional ADC measurement point before the back-current shut down protection on the power supply. This gives us a way to include it in the self test and detect when it activates
Bus Pirate prototype “Ultra” v1b has an IPS LCD to show pinout labels, voltage levels, and other useful info. The background image was done in Photoshop and is stored in the 32Mbit flash chip on the board. Pin labels and voltage readings are drawn on top of the background image with a fixed-width font.
Most LCD fonts represent each pixel with a single bit (on or off). This is an efficient way to store a font, but the results look jagged and unprofessional. To get a better look, we anti aliased an open source font and then extracted two bits per pixel of color data. The results, shown above, use a four color lookup table to represent the background, text color, and two intermediate colors for anti aliased pixels.
Anti aliasing smooths the edges of each letter with a few pixels in intermediate colors. The bottom line of text is not processed at all, angular and circular edges look jagged and stepped. The top four lines of text use various styles of anti aliasing and the edges appear smoother on a small display.
Real-time anti aliasing on the MCU will take too many resources, so we made a pre-anti aliased font. Instead of storing each pixel as a single bit, we use 2bits of data per pixel and a four color lookup table to draw the characters. The resulting font takes twice as much space as a one bit font, but the extra bit (two extra colors) are used for those nice fuzzy edges.
The background image is designed for characters 14 pixels tall. It’s important to choose a fixed-width monospaced font so that each character has even spacing. We used DejaVu Mono, an open source fixed-width font that is used in Linux. At 14 pixels tall the characters are 10 pixels wide. Our characters will be 10×14 at 2 bits per pixel, that’s 35 bytes each.
In Photoshop we used View->New Guide Layout to create a 10×14 pixel grid, then added the typical range of ASCII characters. We skipped a box between each character so that any stray anti aliased pixels that fall outside the box don’t get included in a neighboring character. We tried several types of anti aliasing, and decided “Windows LCD” looks best on our small display.
At this point we have a grid of nicely anti aliased characters, but Photoshop is using dozens of different colored pixels to make those smooth edges. Before we process the character set we need to reduce that to something manageable. The simplest enhancement to a 1 bit font is to add an extra bit. 2 bits per pixel provides a four color pallet: text, background, and two shades of grey for the anti aliased pixels. We converted the characters to a four color pallet in Photoshop with Image->Mode->Indexed color, then assigned a four color custom pallet and saved the result as a 8bit color bitmap.
Bus Terminal has become a dumping ground for our utility scripts. A small addition loads the font image, crops each character, and outputs the font variables as HEX numbers. The font output goes into a font.h file to include in the Bus Pirate firmware.
lcd.c demonstrates how to use the 2 bit font. Our display uses 16 bits per pixel in 565RGB mode. font_lut16RGB contains our pallet of 4 16 bit color codes. We prefer to start with 24 bit color codes because they’re ubiquitous, so we enter our colors into font_lut24 and pre-calculate the 16 bit color values during initialization. Our color pallet includes the background image color, a white shade for the character, and two grey tones for the anti aliased pixels.
To write a character we loop through the 35 bytes of data, pulling out 2 bits at a time. Each two bit set is used to lookup a color code in the lookup table. The color code is sent to the display via SPI. A lot of data has to be moved to write a single character, 280 bytes each for this font.
This is an example of different anti aliasing methods (sharp/crisp/strong/smooth) using 2 bits/pixel. The line on the bottom has no anti aliasing. Without anti aliasing the bottom line is jagged and rough. The other lines add one bit (two indexed colors) for anti aliasing and look remarkably better, even without tweaking.
Taking it further
The 2 bit font looks much better than a 1 bit font. This same technique could be used to extract 3 or more bits of color data per pixel, but that eventually feels like reinventing the PNG.
This is very much a hack in progress. A few tweaks the pallet during conversion to indexed color that will probably make it look much nicer. Some of the characters in the set hang below the outline, so g, q and p are cut off. While Photoshop is good for extensive tweaking, it’s going to take a lot of effort to make font in different sizes.
It seems possible to render each character, anti alias it, and reduce it to indexed color using Qt libraries like QPaint and QPixelmap. The Photoshop side could be automated in Qt to export any system font in any size with minimal hassle.
The Bus Pirate prototype “Ultra” v1b has a 10 pin 1.25mm connector for a display daughterboard. We wanted a more dynamic way to keep track of the pinout and other handy information like pin states and voltage levels.
There are various reference stickers and labeled probe cables for the Bus Pirate v3 and v4, but a display frees us from strict pinout conventions and makes setup a lot easier for new hackers. More on the display below.
We wanted to use ePaper!
At first we really wanted to use ePaper. A static, easily readable display is reminiscent of the stickers it replaces, and makes reference to its primary purpose as a label. The slow update speeds also dampen expectations of flashy graphics and interaction.
The three color ePaper shown above was a top candidate, but it requires 180 seconds of rest between updates to stay in spec. Slow updates are acceptable, but we need to be able to change the display more frequently than once every three minutes.
While the two color version of this display doesn’t have this limitation, we ultimately decided that the Dots Per Inch is just too low to look really good. ePaper is also quite expensive compared to IPS LCDs with much higher pixel density.
Our attention turned to inexpensive LCDs. These are not the dodgy panels with limited color and ever-changing driver chips you may have used in the past. About $3 buys a 240×320 pixel 2 inch IPS (view from every angle) display supporting 250K colors, with a simple SPI interface and well known driver chip. We bought samples from two manufacturers, a QT020HLCG00 and a HT020SQV003NS.
With a bunch of colors and the ability to constantly update, we can show a lot of useful info. Each pin has a proper name corresponding to the active mode, along with input/output direction indication. Color caps on each pin match the probe cable wires, the terminal interface and the logic analyzer client.
Starting with v1b we can measure voltage on all 8 IO pins, so we’ll show that on the display. We’re particularly excited about this feature because we always end up jugging multimeter probes to verify levels during a rough hack. Now we can just look at the display!
Both LCDs are approximately the same dimensions, but the solderable flex connector is a slightly different length. The LCD daughterboard has extra long pads that fit both displays. The files for the display board are in the git repo.
The image on this LCD is just a static mock-up exported from Photoshop. Next we’ll need to create a font and write actual values to the display. This is will be tricky because LCD fonts typically look jagged and ugly, and we don’t really have enough power to do anti aliasing on the fly. Follow our latest progress in the forum.