7

Just as a complement to Paul's answer, I wrote a short program to show how to drive the 7-segment 4-digit display of his figure: This is actually a common cathode display, so the program assumes that, as well as the particular wiring of the figure. The interesting part is the refresh_display() function, which should be called periodically. The algorithm is ...


5

I'll try and take you through the complete basics of LED's etc. As 4-digit 7-segment displays are a combination of multiple "LED techniques". Wiring LED's LED's, or Light Emitting Diodes, are one of the fun things of Arduino. Essentially, they're easy to use, power them up and they'll light up. They can be annoying, because they have some kind of ...


5

The first thing to understand is how to connect the 7 segment display to your Arduino. The common anode pin connects directly to 5VDC. Each "segment" connects to the Arduino through a current limiting resistor (1k ohm is a good value to start with). To turn a segment on, you supply a ground to it (through the resistor of course). Change: digitalWrite(pin, ...


5

This display seems to have 32 addressable LEDs controlled by only 7 pins. Judging from this fact, and from the provided pinout table, it looks like a Charlieplexed matrix. A typical way to drive this kind of matrix is by looping over the cathodes. You pull one cathode pin LOW, and then pull HIGH all the anodes of the LEDs you want to shine which are ...


5

It looks like you have the center segment and the top left vertical segment reversed. For the image you show, if you switched the on/off states of those 2 segments, you'd see 1230. I don't know if the problem is in your code or in your wiring. The simplest fix would be to swap the pins for those 2 segments.


4

I tested your first code line and it outputs a right aligned 136 without colon at my display. (Said I have only a colon at the middle and no decimal points) The 5 at the fist digit (and also the A at your third code line) must have been set somewhere beforehand. The function does not change the unused digit, so it will stay whatever you set it to beforehand ...


3

You may want to use a boost converter which is a device that can step up voltage. You can get them from eBay for around $US 2. As Chris Stratton pointed out in a comment, the boost converter may run your batteries down quite quickly. Let's say you need 200 mA for your Uno, sensor and LEDs. At 5V power that is 1W of power (0.200 * 5). However to get 1W ...


3

In your loop() function, the statement buttonPressed == false; doesn't do anything; it is simply an expression that evaluates to 0 or false (because buttonPressed is equal to true). Your while() loop will never end which is why you can't stop the counter by pressing the button again. You probably meant buttonPressed = false;, which is an assignment ...


3

bitRead(x, y) takes a value x, and looks at bit number y. So, if: y is the number 2; x is 53 (binary number 0 0 1 1 0 1 0 1) ^ it looks at bit #2. Bits are counted from the right starting at 0 - I have indicated the bit in question above. So, bitRead(53, 2) would return 1, since bit #2 in 53 is a 1. In the above ...


3

Finally able to fix it with the help of @PeterPaulKiefer, I was able to find the problem. The problem is in the code itself (schematic is alright. No changes there) and this is the updated code. #include <SevSegShift.h> #define SHIFT_PIN_SHCP 6 #define SHIFT_PIN_STCP 5 #define SHIFT_PIN_DS 4 SevSegShift sevseg(SHIFT_PIN_DS, SHIFT_PIN_SHCP, ...


3

This one tm1637 sounds good. I was thinking to use it next time. Edit 1: Lately posted image suggests that it is without a separate display controller chip, then this library should work. Edit 2: This library specific to the SH5461AS display: Library Include these three libraries: #include "Segment.h" #include "Digit.h" #include "...


2

This is the code that fixed the issue: #include <SevSeg.h> SevSeg sevseg; void setup() { byte numDigits = 4; byte digitPins[] = {5, 4, 3, 2}; byte segmentPins[] = {13, 12, 11, 10, 9, 8, 7, 6}; sevseg.begin(COMMON_CATHODE, numDigits, digitPins, segmentPins); sevseg.setBrightness(50); sevseg.setNumber(0000, -1); } ...


2

You seem to be trying to do this from scratch. I haven't analysed the code, but you would be better off using one of the established libraries. The code is unclear - I am not sure what much of it is trying to do (a few comments would help). There are obvious errors - in particular the incorrect use of sizeof() which is a common error. I use the following ...


2

The code instantiates two instances of the SevSeg class. This may or may not work. Really depends on if the class uses any resources are not meant to be shared between multiple instances of that class. For instance, it is unlikely that one hardware timer can be used for more than one purpose at a time. But the code continues on to use the same (anode) ...


2

Any way to get rid of leading zeros? Sure but two conditions have to be true: 1) you have the font information for "blank"; you need to un-comment it in your code for that. 2) you need to get rid of leading zeros, after having calculated the display buffer. displayBuffer[0]=(displayBuffer[0]==0)?FONT_BUFFER:displayBuffer[0]; //eliminate leading zero ...


2

There are several bugs that I spot right off the bat. First off, you should never need goto in C++. You should be able to use if, for, and while to completely eliminate those. goto makes code hard to follow and read, so it makes it nearly impossible for someone else to try to debug. Be nice to yourself and forget that goto ever existed. I would suggest ...


2

This should work (sort of). It will be flickery, but it should give you a starting place to work from. int A = 2; int B = 3; int C = 4; int D = 5; int E = 6; int f = 7; int G = 8; int P = 9; int D4 = 10; int D3 = 11; int D2 = 12; int D1 = 13; void setup() { // put your setup code here, to run once: pinMode(A, OUTPUT); pinMode(B, OUTPUT); pinMode(...


2

The importance of proper indentation is clear here... I thought you were missing a closing curly braces. When you type code, press regularly cmd/ctrl-T to ident your code -- it helps catching mistakes. You are indeed missing one, for is_astuon(). Moreover these lines are wrong too: **void** uz_vien(); delay(5); **void** is_vien(); digitalWrite (isej1, ...


2

The key point is that if you do that, you're doing it wrong. Typically a multi digit display is time multiplexed, such that you use a common set of segment lines to activate the pattern on each digit in turn, therefore at any one time only at most 7 (or 8 counting the decimal point) segments should actually be on. Then in terms of the common connection ...


2

In your code, you call: newPos = encoder.getPosition(); which grabs the absolute position of the encoder. When you rotate this one step, the value of newPos goes up (or down) by one. Then, you make pos = newPos + 4, which simply adds 4 to the value that is going up or down by one step at a time. newPos: 1 pos: 5 newPos: 2 pos: 6 newPos: 3 pos: 7 ...


2

Always start by reading the docs. The README of the TM1637 display library gives a short summary of the available functions, then states “Please refer to TM1637Display.h for more information.” It would thus seem the authoritative documentation is the header file itself, which is indeed rich ins structured comments. According to it, the signature of ...


2

Whit the displays which use shift register to light multiple seven segment digit blocks, the register lights up only one digit at a time. The illusion of multiple digits lit is created by fast switching the digits in round. Small delays in this cause the number to look dim, larger delays create flickering and long delays show only one digit lit. So a sketch ...


2

What caused the problem of the digit that driven by pin 12 is quite obvious to me. You use pin 11, 12, 13, 14 for driving the 7-segment digits. While SPI library by default uses pin 10, 11, 12, 13 as SS, MOSI, MISO and SCK, and set pin 12 (MISO) as INPUT which is in conflict with your pin 12 (as an OUTPUT) for driving the digit. Pin 13 is also used by the ...


2

I don't know. If I had to talk about it, I would say a LED segment display with a matrix layout with a complementary drive. If a pin is used as a cathode, a LOW signal must be applied. If it is used as an anode, a HIGH signal must be applied. You could define constants for each segments anode and cathode that define a pin number. e.g : #define CAT_1A = 2 ...


2

Found <TinyDHT.h> and all works ok, just what I wanted.


1

What you have is a Charlie-Plexed display like the one in the picture below. You need one more wire than this example because your display also includes the decimal point. If you go through the electrical paths where for each pair one line is driven high, the other is driven low and all other lines are set to input, only one LED at a time will be forward ...


1

With foregood you mean broken probably. I don't see any resistor in your circuit, probably the LEDs are broken. I'm afraid you have to use a new segment LED, and follow: Arduino Example Especially read this fragment: Current-limiting Resistors Don't forget that the display uses LEDs, so you should use current-limiting resistors in series with the ...


1

Missing pinmode(4,OUTPUT) in your setup routine. As a general comment, using variable names instead of 'magic numbers' makes your code easier to read - and thus usually easier to debug. for example: const int leftDisplay = 4; const int rightDisplay = 5; const int seg1 = 12; const int seg2 = 11; [...] You can also use HIGH and LOW instead of 1 and 0 for ...


1

Just to suggest an alternative, and more energy efficient, solution... There appear to be newer versions of the HC-SR04 on the market that support 3.3V, such as the HC-SR04 v2 - Low Cost Ultrasonic Sensor (3V to 5V Supply). So you could use an Arduino Pro Mini designed to run at 3V in conjunction with the 3.3 V HC-SR04, and run it straight off your ...


Only top voted, non community-wiki answers of a minimum length are eligible