4 digit 7 segment notworking correctly (Menu with SevSeg Library)

I`m trying to code a small display menu, which displays the “mode titles”. I guess if you look at the code you will get my point.

By using the UP/ DOWN buttons a variable is changed from 1- 5, thus changing the “title”.

To drive the four digit, seven segment common cathode display I am using the SevSeg.h library from a fellow named DeanIsMe.

The problem I have right now is, that my display ist just showing random characters on random digits (only one at a time), not the text that I have witten in sevseg.setChars("…");.

If I would only type the sevseg.setChars("…") in my loop, then everythign works fine and the right text gets displayed properly.

Any Ideas what I am doing wrong?

Earlier I tried to display random messages that change with time, like this:

void loop
{
sevseg.setChars(“HELO”);
sevseg.refreshDisplay();
delay(500);

sevseg. setChars(“UHUH”);

}

and thad also did not work. It seems to me, that this library has problems as soon as time plays a role.

I would be very thankful if someone could give me some tips.

(See code in next post because it says its over 9000 characters :o)

I`m sorry its only black, it would be too big for the formatted version…

#include <SevSeg.h>
SevSeg sevseg;

const int menuButton = A0;
const int upButton = A1;
const int downButton = A2;
const int enterButton = A3;

int menu;
int submenu;

void setup()
{
byte numDigits = 4;
byte digitPins = {7, 8, 12, 13};
byte segmentPins = {0, 1, 2, 3, 4, 5, 6};
bool resistorsOnSegments = true;
byte hardwareConfig = COMMON_CATHODE;
bool updateWithDelays = false;
bool leadingZeros = false;
bool disableDecPoint = true;
sevseg.begin(hardwareConfig, numDigits, digitPins, segmentPins, resistorsOnSegments,
updateWithDelays, leadingZeros, disableDecPoint);
sevseg.setBrightness(20);

pinMode(A0, INPUT_PULLUP);
pinMode(A1, INPUT_PULLUP);
pinMode(A2, INPUT_PULLUP);
pinMode(A3, INPUT_PULLUP);

updateMenu();
}

void loop()
{
if (!digitalRead(downButton))
{
menu++;
updateMenu();
delay(100);
while (!digitalRead(downButton));
}

if (!digitalRead(upButton))
{
menu–;
updateMenu();
delay(100);
while (!digitalRead(upButton));
}
}

void updateMenu()
{
switch (menu)
{
case 0:
menu = 5;
break;

case 1:
sevseg.blank();
sevseg.setChars(“Addr”);
sevseg.refreshDisplay();
break;

case 2:
sevseg.blank();
sevseg.setChars(“SLNd”);
sevseg.refreshDisplay();
break;

case 3:
sevseg.blank();
sevseg.setChars(“Soun”);
sevseg.refreshDisplay();
break;

case 4:
sevseg.blank();
sevseg.setChars(“SenS”);
sevseg.refreshDisplay();
break;

case 5:
sevseg.blank();
sevseg.setChars(“Auto”);
sevseg.refreshDisplay();
break;

case 6:
menu = 1;
break;
}
}

Well, you have a few problems.

One is trying to connect a seven segment display directly to an Arduino. This is a very crude approach which will give poor results with varying brightness as the display changes. perhaps that is no concern.

Now the “sevseg” library requires you to “drive” it to perform the multiplexing of the digits. Frankly I do not know exactly how you are expected to drive it as I consider it of no practical use, but I presume it has something to do with calling sevseg.refreshDisplay(); on a frequent and regular basis such as every 10 milliseconds. This means that you cannot use any “delay()” value longer than 10.

And finally, the matter of posting code.


You need to go and read the forum instructions so that you can go back and modify your original posts (not re-post them) - using the “More → Modify” option below the right hand corner of your post - to mark up your code as such using the “</>” icon in the posting window. Just highlight each section of code (or output if you later need to post that) from the IDE and click the icon.

In fact, the IDE itself has a “copy for forum” link to put these markings on a highlighted block for you so you then just paste it here in a posting window. But even before doing that, don’t forget to use the “Auto-Format” (Ctrl-T) option first to make it easy to read. While you were lucky so far, If you do not post it as “code” it can easily be quite garbled and is generally more difficult to read due to the font.

It is inappropriate to attach it as a “.ino” file unless it is clearly too long to include in the post proper. People can usually see the mistakes directly and do not want to have to actually load it in their own IDE. And even that would also assume they are using a PC and have the IDE running on that PC.

Also tidy up your blank space. Do use blank lines, but only single blanks between complete functional blocks.


Your alternate plan of using the TM1637 display is much more practical. While there are some limitations of these modules, they do work nicely and once you write the data to them, the TM1637 looks after all the multiplexing for you - it just displays.all by itself. :sunglasses:

I think I will just wait for my TM1637 Modules to cume, maybe I will even buy myself one TM1638.

What I noticed is that the delay(200); in my loop code makes the multiplexing mad.

Lesson learned: Absolutely no delays in regard with multiplexing in loops...

One other plus of the TM1637 setup is that I don`t have to do the button debouncing in software.

thed9950:
I think I will just wait for my TM1637 Modules to come, maybe I will even buy myself one TM1638.

Indeed, why not! :grinning:

thed9950:
What I noticed is that the delay(200); in my loop code makes the multiplexing mad.

Care to explain just what you mean?

thed9950:
Lesson learned: Absolutely no delays in regard with multiplexing in loops...

No, not "no" delays, but the multiplexing call must be relatively frequent, just every few milliseconds, an must be the same delay (using a "millis()" check) each time so the digits get equal time an thus equal brightness. This becomes more difficult when your code is doing many other tasks simultaneously.

thed9950:
One other plus of the TM1637 setup is that I don`t have to do the button debouncing in software.

It does apparently implement a crude sort of de-bounce as it only polls the keys every few milliseconds.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.