Jump to content


Photo
- - - - -

Hex Display Project


  • Please log in to reply
3 replies to this topic

#1 systems_glitch

systems_glitch

    Dangerous free thinker

  • Moderating Team
  • 1,669 posts
  • Gender:Male

Posted 28 August 2013 - 01:45 PM

Nearly three years ago, I purchased a bunch of bubble magnified 7-segment displays, probably intended for calculators (rememeber LED display calculators?). I purchased the lot for a reasonable price, thinking I was receiving 20 displays. Turns out I was getting 20 bags of 10, plus 30-some loose displays! I decided to build a 3-byte (6 hex char) parallel hex display using a PIC microcontroller to handle the multiplexing. I had some PIC16F88 devices on hand, and lashed this together on a breadboard:

 

 

After that, I purchased some PICs with more I/O, some prototyping breakout boards (64 pin TQFP is hard to prototype otherwise), and basically forgot about the project. Last weekend, I had reason to revive it for another project, and have so far implemented most of what I wanted to accomplish:

 

1spSaRR.jpgS587Ssr.jpgUb8ln7P.jpg

 

The displays are a mix of 8- and 9-digit devices. I built the prototype with a 9-digit device, but I'm only driving 8 digits at the moment. I was able to reuse some of the multiplexing code from my last go at this project, and continued the same basic approach with this implementation. The current (work in progress) source is available on GitHub at https://www.github.c...ajs/hex_display

 

It's implemented as a bitmapped display, with the LSB corresponding to segment A and the MSB corresponding to the decimal point. Bit patterns are held in an 8-byte display buffer. An interrupt-driven multiplexing routine pulls characters out of the display buffer and pushes them out to the display, calling a subroutine to turn on the appropriate character. Since the subroutine is interrupt-driven from one of the PIC's timers, the PIC is free to do other tasks in the time in between.

 

While the display is primarily intended to be a debugging tool, displaying binary data as hex, I designed it in such a way that none of the "interesting" device pins are tied up by the display itself. It's possible to modify the firmware to take input from I2C, SPI, RS-232, the parallel slave port, or any of the ADCs on the PIC.



#2 systems_glitch

systems_glitch

    Dangerous free thinker

  • Moderating Team
  • 1,669 posts
  • Gender:Male

Posted 01 May 2014 - 01:21 PM

I've finally started turning this into a proper PC board. Here's a 1:1 image of what it should look like:

 

WY9QGOh.png

 

By far the most complicated board routing I've done, largely due to the (self-imposed) size constraints. Should be back from http://www.oshpark.com in two weeks!



#3 systems_glitch

systems_glitch

    Dangerous free thinker

  • Moderating Team
  • 1,669 posts
  • Gender:Male

Posted 14 May 2014 - 01:19 PM

Boards came back from OSH Park yesterday, so I assembled one over lunch break:

 

RHYYzJc.jpg

 

Hooray! It works the first time through! I spent 1.5 hours debugging a "problem" in my board layout, only to discover that the display module I'd grabbed had an internal short between segments A and B. Looks like I'll be making a test jig before soldering to any future displays.

 

The 64-pin TQFP PIC was easier to solder on the OSH Park boards than on the "Digole" breakout boards I'd used for the prototype. I tacked down two pins for alignment, coated with flux, and drag soldered the rest. Excess solder was removed with solder wick. The ULN2803 Darlington array and the discrete resistors and capacitors were all hand-soldered. The board layout leaves enough room that 0603 devices are no problem. I soldered down a socket for the display since it's a prototype.

 

So far I've updated the firmware for the rev 0 board's pin designations (some pins were rearranged to make the board simpler), added a pinouts file for the board, and tested display buffer loading/display multiplexing with demo firmware that just populates the display buffer with "deadbeef". I've also added more descriptive comments to the source code and cleaned it up a bit.

 

The rev 0 board still needs the 24-bit input layout tested. I'm probably going to adjust the board a little to make JP1 to JP2 pin spacing compatible with 0.1" perfboard, so the display board can be used as a module in other projects.



#4 dinscurge

dinscurge

    "I Hack, therefore, I am"

  • Members
  • 937 posts
  • Country:
  • Gender:Male
  • Location:the bunker

Posted 16 May 2014 - 12:44 AM

looks good as always






BinRev is hosted by the great people at Lunarpages!