8-Digit, 7-Segment Display for Arduino

[Chris Savage]

So, with regards to checksums, I was thinking that, at work I often test the ROM chips in devices by simply loading up my device programmer and comparing the checksum to the one that is usually on the UV sticker on the IC. In the few cases there's no checksum printed, I often have the correct ROM image on the HD to compare against. Instead of booting an extra PC just to run the programmer to do this, I thought I would build a project; a checksum calculator, if you will, that would simply tell me the checksum to any (E)EPROM / NVRAM plugged into the ZIF socket.

You cannot view this attachment.

Initially, I figured I would use an LCD to display the menu / checksum. A coworker suggested I go retro and use an 8-digit, 7-segment display. I thought this was an awesome idea. So I ordered those displays from Amazon.

6 PCS 8-Digit, 7-Segment MAX7219 Digital Segment Module for $10!

Unfortunately, the example code / driver I found doesn't display hex values. 

[Chris Savage]

If you know of a driver for this display that supports HEX values, please reply. Thanks.

[granz]

If you know of a driver for this display that supports HEX values, please reply. Thanks.

I had never heard of this display, and initially thought that maybe your issue was from the device only displaying decimal digits. But, the datasheet (https://www.analog.com/media/en/technical-documentation/data-sheets/max7219-max7221.pdf - second bullet item in the Features list) shows that the LED segments can be individually addressed.

You may end up having to write your own driver (is the sample code so bad that you cannot start with that?) It appears that the thing presents itself as a serially loaded bank of eight registers, with each bit of each byte mapped to one segment of the corresponding digit. So, theoretically it seems that you just write a byte to the device, and see what appears. Write another byte, and (if I'm guessing right) the first character moves over one digit space, and the new one appears where the first one was.

[Chris Savage]

You may end up having to write your own driver (is the sample code so bad that you cannot start with that?) It appears that the thing presents itself as a serially loaded bank of eight registers, with each bit of each byte mapped to one segment of the corresponding digit.

I have used the MAX7219 in several projects, more notably the Digital Alarm Clocks, and the Binary / Digital Clock, so I am familiar with it. One of the things about the Arduino is that there are so many pre-built libraries. I find that to be both a blessing and a curse.

A blessing in the sense that you don't necessarily have to write your own driver for every piece of hardware. Someone has probably done that. The curse? Well, it took me 3 or 4 drivers to find a good one for the OLED displays I was using and about the same trying to find a good NeoPixel (WS2812) driver.

So, theoretically it seems that you just write a byte to the device, and see what appears. Write another byte, and (if I'm guessing right) the first character moves over one digit space, and the new one appears where the first one was.

Close! There are registers that are initialized on startup. One such register is called BCD decode. As the name implies, it decodes data for up to eight bytes into BCD. In the two projects above I am displaying the time, so that register is fully enabled for each digit.

For this application I'm going to have to manually decode, which means mapping out which segment applies to each byte and creating a table of values. This isn't an issue as I've done this for every 14-segement / 16-segment display I've ever used, and for large 7-segment displays, where the data is coming from a shift register through a ULN2803 driver. As a side-note, the MAX7219 is often used for dot-matrix displays, such as this HiLetgo MAX7219 Dot Matrix Module for Arduino. In this case both letters are numbers are pixel-mapped.

I was just seeing if anyone had a good HEX-capable driver before I did take some time to write my own.

[granz]

One of the things about the Arduino is that there are so many pre-built libraries. I find that to be both a blessing and a curse.

A blessing in the sense that you don't necessarily have to write your own driver for every piece of hardware. Someone has probably done that. The curse? Well, it took me 3 or 4 drivers to find a good one for the OLED displays I was using and about the same trying to find a good NeoPixel (WS2812) driver.

My biggest concern with the Arduino libraries is the way that they are documented (NOT!!!) Most of the "documentation" for Arduino libraries is "you just add it in, and use it." It is a reflection of modern "teaching" - just copy this, paste here, and now you're a programmer. I once mentioned my "Intro to Microcontrollers" book to a kid who was currently taking microcontrollers classes. When I mentioned that I have the student start with a single LED, then show how, and why, it lit with different commands, and then build from there, he said: "I wish that was how they teach us. All we get it copy this and paste that." When I was going through school, I learned the hows, and whys. When I taught logic gates, I showed the electron flow, and voltage generation within the resistors, diodes and transistors - my students knew (or at least those who passed ) what was going on in the gates.

An example of my troubles is my initial tries at using a 16x04 LCD. The library said to call the commands with parameters, but nothing about what the parameters were, or what they meant. (In my looking just now, it seems that this is fixed, at least in arduino.cc tutorial - https://docs.arduino.cc/learn/electronics/lcd-displays/) But it was very frustrating for me as a beginner. When I first started using libraries (in assembly,) they were thoroughly documented. You called the routine with these variables (registers or memory locations) containing these data, then it would return this data in these variables, and while it was doing its thing, it would specify the use (change/destroy) these registers/memory locations. The documentation would even mention what type of data (byte/string/single-precision/double-precision/float/etc.) was in each location.

None of the Arduino libraries are (were?) documented that well.  Getting into the Arduino was rough.

[Chris Savage]

None of the Arduino libraries are (were?) documented that well.  Getting into the Arduino was rough.

You're right. Even when downloading them from Github, I am hard-pressed to find the list of functions that you can call with any given library. Sometimes they have specific examples, but rarely anything that shows all of the calls.

It's funny, in the lowest level languages, like assembly, you learn what it is, what it does, what addressing modes it can be used in, what registers are affected, flags affected, etc. Seems the higher up we go, the less information we get. Good documentation is a lost art (not Art). 

[granz]

Good documentation is a lost art (not Art). 

LOL

Years ago, one of my biggest clients had to let me go. When he did, he said that the "how to" documentation that I had written was so good that he didn't need me any more. 

[Chris Savage]

Years ago, one of my biggest clients had to let me go. When he did, he said that the "how to" documentation that I had written was so good that he didn't need me any more. 

I can't handle the arrogant people that say, "Well written code is self-documenting." Tell that to someone who doesn't program or understand that particular language.

[granz]

I can't handle the arrogant people that say, "Well written code is self-documenting." Tell that to someone who doesn't program or understand that particular language.

Yeah, if you put in about 10-100 times the number of lines of code in comments. I've seen pretty thoroughly documented code (written some myself) but never something that really documents the full operation of the program.

On the other hand, good documentation should include the source code - like they did back in the "good ol days" in the '70s.

[Chris Savage]

Yeah, if you put in about 10-100 times the number of lines of code in comments. I've seen pretty thoroughly documented code (written some myself) but never something that really documents the full operation of the program.

So, just to be clear, I'm referring to people who don't think there should be comments in the individual lines of code. When I was writing code for Parallax, I was excessive with my comments and got many compliments for being so clear on what was happening. But I also remember people who disagreed and thought if the code was well written, it didn't need comments to explain things. That's the part that annoys me.

There are still a few parts of the decompiled Z80 code that I tilt my head at. I'm not sure what I was doing there. Not because I didn't comment it, but because I don't have the source anymore and had to reverse engineer it. LOL

This woman gets into the controversy...

[Chris Savage]

Okay, @granz, you win! LOL I decided to map the segments, and it's more straight forward than I thought.

You cannot view this attachment.

So, this is how the segments on a 7-segment display are arranged and labeled.


You cannot view this attachment.

So, I wrote the following code, turning BCD Decode OFF and then sending the values in binary so I could observe the correlation of bits to segments.


You cannot view this attachment.

The results were better than expected! As you can see, in the first value I set the LSB to 1, then in each digit rotated that value so that I could map all 8 segments. The LSB is the 'G' segment, while the MSB is the DP. I commented that into the code to make it easy to create characters.

Continued in the next reply...

[Chris Savage]

...continued from the previous reply.

You cannot view this attachment.

Armed with the knowledge from my bit / segment testing, I was able to reconstruct all the digits as binary patterns, and cycle between the 0-7 and 8-F using this code.


You cannot view this attachment.
You cannot view this attachment.

This is the result of this test code. So, as you can see, this display IS capable of displaying HEX and of activating the decimal points.

[granz]

So, just to be clear, I'm referring to people who don't think there should be comments in the individual lines of code. When I was writing code for Parallax, I was excessive with my comments and got many compliments for being so clear on what was happening. But I also remember people who disagreed and thought if the code was well written, it didn't need comments to explain things. That's the part that annoys me.

Bah, humbug - those people don't know what they do.

[granz]

This is the result of this test code. So, as you can see, this display IS capable of displaying HEX and of activating the decimal points.

Congratulations! It is sad that you needed to write the code yourself; those people selling these displays should have been able to document it decently, and include some sample code.

[Chris Savage]

Congratulations! It is sad that you needed to write the code yourself; those people selling these displays should have been able to document it decently, and include some sample code.

Perhaps, but you inspired me to just code for myself, like I should have done from the start. I still need to create a function that displays the correct values when the values are passed along. Currently it's hard coded in this display demo. So, thanks for pushing me in the right direction. I guess I have gotten complacent with all these libraries and examples being available.

I was thinking about making examples for this display on several platforms, eventually.