Undo and I met a long time ago and quickly made good friends!
Maybe 'cause I don't understand what you're saying. See @LarryD post #78 and my reply to his post #82. What do you think he was saying to do? He said try 13. I did. In my reply, I state what I observed in the simulator when I made his change, that's the best I can do because I'm not fluent enough to speculate what his proposed change will do. @odometer added additional digits, which upped the array number. So, I know where the 15 came from, and the 14. You need to go over the thread more carefully. I entered the change in the code and explained the result. Changing the original code to 13 deleted one of the numbers. Of course adding additional elements in the array changes the number. Did you go to the simulator link to see what was happening?
They are all physical LED segments aren't they? I don't know what you mean here. If I'm missing your point try another tact. I think I understand more than you think and less than others think. I did not write the code! I am beginning to play with the code.
Obviously I'm beyond that as I've got everything pinned correctly and have a working model in both Wokwi and my physical mockup.
I meant MUX not MOX. MUX is a device and MOX is a process. Shift register functions somewhat at least as a multiplexor or MUX. I don't know enough to be versed in how they are different, but they are similar concepts even if they handle data differently.
My Bad. Maybe I misunderstood this statement
I read it as you not knowing where E and F came from. I'll go away now
No, not at all. A multiplexer is like a switch, and a register is an entity that stores bits, sometimes with the ability to shift.
As for the seven segments thing, it is seven segments that are all like LEDs. They share one connection, here their cathodes. To supply voltage to an anode is to light up that segment .
Below I link a simulation of a display with no code, just slide switches to turn on and off the segments. I did not place any series current limiting resistors because the wokwi doesn't need I am lazy, do not omit them IRL!
Play with the switches until you see the digit 7, then look at them, you'll see some are up (turn on the segment) and some are down.
Write down those as 1s (up) and 0s (down) A..G and you will see the bits like you see them in your array of how to form digits, viz:
0b11100000, // = 7
up up up down down down down (omitting the DP segment, least significant bit).
0b010101 is how you write a binary number constant, so it only has 1s and 0s.
When in your sketch the shift register is loaded with that bit pattern and... you see a seven:
HTH
a7
I like that Wokwi project. Shows alot. Shows what you've been trying to tell me.
I've got some other stuff to tend to but I can't wait to write down the numbers because dang if I could figure out where they were coming from. I originally thought the numbers were hex convert binary, but after refreshing myself on bases determined they aren't.
So, your Wokwi came in just in time to humble me some more! I'll never get out of being a newbie!
Plus there are too many... 8 digits versus 4. What is the B and 0b if the b isn't binary?
The B or 0b is a prefix to let the computer know "This is supposed to be a binary number."
byte x = 10; // This sets x equal to ten
byte y = 0b10; // This sets y equal to two (0b means binary, and 10 is binary for two)
@odometer, just getting to this.
Correct me if I'm wrong, I have been updating Wokwi.
Q1. 0-15 should now be 0-17 with the addition of blank and decimal point.
Q2. What is the purpose of the blank?
Q3. How did you know what number to assign the decimal point. I didn't see the data sheet
giving it a particular position.
For your void loop statement:
Q6. // , <=15should be <=17?
Q7. for (byte digit = 0; digit <= 15; digit++) { 15 should be 17?
Q8. sevenSegWrite(17); should be 18? (18 is the newest digital point)
delay(1000);
Q9. sevenSegWrite(16); should be 17 (17 is the new blank)
Q10. The repeat of the same statement between blank and digital point is what causes it to
blink?
Q11. If I didn't want it to blink but just cycle with the rest, I wouldn't need this (correct my
terminology to describe this) subroutine? (Don't get me wrong I like what you've done)
Q12. How do these extra segments/LEDs function in conjunction (I'll regret writing this) with
there only being 8 parallel outputs on the shift register? ( I can see it filling twice for 0-15 (16
total or 2 runs through register, but by its behavior it just keeps feeding the
outputs until inputs from sketch are exhausted.)
Q13. Is letter designations newer for shift register terminology?The initial statement defines my
shift register but I want to define it like my Texas Instrument data sheet, which uses letters
designations for parallel outputs instead of numbers. This will also keep me from making
changes to my project book diagrams. For future maybe even use both nomenclatures
since other shift registers use different names for /OE etc.
Can I reply to my own? I was looking at micro fahred not nano fahred. I did see a board setup like mine utilizing the aluminum barrel type capacitors. I tried reading about the differences and luckily I have my rubber boots on and could dig myself back out.
Where does the 0x27 come in... looking through posts I found it and know of one other that I wanted to ask about...it's like 0x then a letter or something. Ring any bells?
Yes, the blank is in position 16, and the decimal point is in position 17.
I wanted to make the decimal point flash on and off. The blank was needed to make the decimal point turn off.
Process of elimination. We are working with 8-bit binary numbers. Seven of the eight bits are used to control the seven segments of the digit. So, what else would the eighth bit be for, if not the decimal point?
Not the way I have my animation. I count up from 0 to F, then have a 5-second pause with a blinking decimal point before restarting the count. I could, of course, have done the animation differently. You can experiment with the code to see what results from any changes you make to it.
Nope, the decimal point is in position 17. Remember, in an array with 18 elements, the first element is index 0, and the last is index 17.
Same off-by-one error as the previous question. 16 is correct.
Yes. I understand that repeating statements (as I have done here) might not be the cleanest, most "professional" looking way to achieve an effect, but here, it gets the job done.
If you just want the counter to, after F, immediately restart from 0, just delete the lines I used to make the blinking decimal point effect.
I'm not sure I understand your question. There are only eight outputs on the shift register. You are using all eight outputs. The display has seven segments plus one decimal point, which makes a total of eight LED elements to control. As I said, you have eight outputs, which is enough to control all of this. At any one time, there is only ever one digit on the display, so you only need eight outputs.
When each new digit appears, it erases the previous digit. The fact that there are sixteen different digits does not change that you only need eight outputs on your shift register, because you are only displaying one digit at a time, and for that, you only need eight outputs.
I have no idea which is newer terminology. I'm actually more of a software than a hardware person. Maybe someone else can help you with this.
1 Like
0x means "This is a hexadecimal number."
10 is ten
0x10 is sixteen
1F is an error (not a valid number)
0x1F is thirty-one
0xF0 is two hundred and forty
1 Like
Conversion table for you:
binary hex
0000 0
0001 1
0010 2
0011 3
0100 4
0101 5
0110 6
0111 7
1000 8
1001 9
1010 A (ten)
1011 B (eleven)
1100 C (twelve)
1101 D (thirteen)
1110 E (fourteen)
1111 F (fifteen)
Using this table, you can convert 0x27 into binary:
hex 2 becomes binary 0010
hex 7 becomes binary 0111
and then put it together to get 00100111
and so you see that 0x27 is just shorthand for 0b00100111.
It's really just a form of shorthand, so you don't have to type so many zeros and ones. But sometimes it is helpful to actually see the zeros and ones. For what we are doing here, I think that seeing the actual binary zeros and ones is helpful: you need to see which LED segments you are turning on, and which you are turning off. But, for work in which you might deal with hundreds of binary digits at a time (such as complicated graphics for a display), the advantages of having a shorthand would start to appear.
OK, I think that the problem is that you fundamentally misunderstand what a shift register is, and what it is supposed to do.
You are using an 8-bit shift register. Think of it as a sort of conveyor belt, and what gets carried on the belt is binary bits, ones and zeros. This belt can hold eight bits at one time, maximum. If you try to put any more bits on the belt, then the older bits will fall off the end of the belt in order to make room for the newer bits.
Each digit on the display is represented by a pattern of bits, indicating which LED segments on the display are to be turned on for that digit, and which are to be turned off. To display a digit, this pattern of bits gets pushed onto the shift register conveyor belt, and while it is on the belt, each of the eight outputs of the shift register will show you what one of those eight bits is. If the bit is a 1, then the output will be HIGH, and an LED segment will turn on. If the bit is a 0, then the output will be LOW, and an LED segment will turn off. Then for the next digit, a new pattern of bits gets pushed onto the belt, and so the shift register outputs change, and so the LED segments change to show you the new digit. And so forth.
3 Likes
Thanks @odometer 
for clearing this up. It’s finally coming together.
Kinda thought it was something like that.
Plus blank and point make 17 and 18
Blank and point are not real hex digits. I just put them in the array because I had to put them somewhere in the seven_seg_digits array in order to get them on the display, because of how the sevenSegWrite function (for displaying the digits) is written.
I'm so lost between the two threads.
You been explained how to express constants in several bases, 0x27 is a hexadecimal (base 16) number I just picked at random, and the corresponding segments are totally wrong, like backwards and not accounting for the decimal point segment, so sry about that.
It was someone's choice somewhere in your learning materials to have the bits in the byte go "ABCDEFG.", that I hope is obvsly how you must wire the Q output bits from the shift register.
You could reverse both, or even do something perverse and what I call "swimming upstream" and have the bits in the table go in order "ACGEB.FD" as long as the shift register wiring corresponded.
But it would be like using black wire for Vcc. There's a reason all the engineers in the audience say (or think) "cut the red wire".
a7