Tag Archives: #liveupdates

APP NOTE: Give your voltage regulator the margin it deserves

via Dangerous Prototypes

Texas instruments has an app note and video explaining how to make a programmable output power supply using a typical LDO voltage regulator and a DAC. This is the technique we used for the Bus Pirate Ultra power supply to get 0.8 to 5volts output, and it works a treat!

Consider the currents going in and out of the VFB node shown in Figure 3, which is connected to the ADJ pin of the LDO. Almost no current flows in or out the device through the ADJ pin (on the order of 0.01µA). As I previously mentioned, the output voltage of the LDO is always produced such that the voltage at the ADJ pin – and therefore the VFB node – is equal to the LDO’s internal reference voltage. Thus, the current through R2 is constant. It follows that any sourcing or sinking of current by the DAC through R3 is reflected as a proportional voltage increase or decrease at VOUT to compensate for the changing current that must flow through R1.

Bus Pirate Ultra display board v1d

via Dangerous Prototypes

Sorry for the poor image export. What have they done to Eagle?

The LCD carrier board for Bus Pirate prototype “Ultra” v1d went out today. This update matches the form factor of Ultra v1d (in progress) and has several minor changes:

  • 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: pipelined and non-pipelined commands

via Dangerous Prototypes

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)
  • Bus reads
  • Bus writes
  • Pin read/write/direction

These commands can be pipelined, but are currently handled in registers:

  • PWM
  • Frequency measurement

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)
  • Reset
  • 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: first test of Ultra v1b with SPI EEPROM

via Dangerous Prototypes

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: Ultra v1c board update

via Dangerous Prototypes

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

Boards and schematics are in our git repo, and you can follow the latest developments in the forum.

BUS PIRATE: 2bit anti aliased font for small color LCDs

via Dangerous Prototypes

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.

1bit font generator by maxpromer

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.