The GrayCode is an alternate bitwise representation system for numbers.
Normal Binary:
0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000 <- 4 bits change at the same time when moving from 7 to 8
9 1001
Gray Codes:
0 0000
1 0001
2 0011
3 0010
4 0110
5 0111
6 0101
7 0100
8 1100 <- only one bit changes when moving from 7 to 8
9 1101
Gray codes are designed so that no more than one bit changes for each increment or decrement of a number.
This is useful in certain engineering, measurement, and hardware contexts.
It is useful in measurement because even if the head is diagonal you are only off by one number.
It is useful in hardware because if you try to read the number in normal binary while the bits are flipping, you might get a number that is wildly different, while the grey coded number will only be one off.
- It is useful in hardware because if you try to read the number in normal binary while the bits are flipping, you might get a number that is wildly different, while the grey coded number will only be one off.
- ["Only one off, when the bits are flipping?" I don't think so.
- 0100 - > 0000 only one bit flipped, but the number is off by 7 and what about 1000 -> 0000?
- And what ever "diagonal head" means, I strongly doubt GrayCode is of any use. Unless there are processors that are much better at one bit operations than one word operations, which -- according to my knowledge -- doesn't exist in processor world.]
- The "bits are flipping" remark isn't referring to changing an arbitrary bit. It's referring to the transitional states when the counter is being incremented. For gray code, that's always one line either going from low voltage to high voltage, or vice versa. With normal binary, there are multiple lines changing, and these lines are likely to change at different times. This means that if you look at the output of a gray code counter from the moment you stroke it, it will always be either the previous number or the current number, and once it's changed to the current number it will stay there. For a binary counter, you will likely see intermediate values. E.g. Going from 7 to 8 might look like going from 7 to 5 to 13 to 12 to 8 in normal binary.
- It was poorly stated, but the bit about the "diagonal head" is presumably referring to a positional encoding head. Reading a binary code where multiple bits flip at once, a head with even a slight misalignment will see some flip before others, with wildly incorrect intermediate values (for 0000 to 1111, you'd see intermediate steps of 0001, 0011, and 0111, indicating very different positions). With a gray code where only one bit changes with each step, as long as the head isn't so badly misaligned that it's picking up bits of three different codes, the worst that will happen is the transition happens a bit sooner or later. (It's actually worse than this, the sensors within a real world encoder aren't going to be perfectly aligned with each other and have identical responses.)
- So the key aspect is that the bits are transferred over different pins of some device instead of being stored in one indivisible place. Furthermore due to some technical issues the reading device cannot ensure that all bits belong to the same value. Alright, in these circumstances I admit the GrayCode helps to reduce the deviation from the correct value down to 1 step.
- In hardware, there is no one indivisible place to store multiple bits.
- Of course there is: any register or even normal storage. Reading 32 bits on a 32 bit CPU you know it is ONE value. So GrayCode is meaningless in such a situation.
- A 32 bit register isn't indivisible. It can be divided into 32 1 bit registers. Whether or not GrayCode is meaningless there would depend on what you were using it for. If that register is being used as a counter, and you need to make asynchronous reads of its value, GrayCode would be extremely useful. It would eliminate the possibility of reading in a transient value.
- Registers are indivisible per definition. Same goes for load and store commands. If a value changes from 0111 to 1000, there is no possibility to read some transient value like 0110 or 0100 or 0000, even if the intern circuitry may change it this way. And even if any processor manufacturer is crazy enough to provide mechanisms for splitting registers into single bits, there is no reason for programmers to use these mechanisms other than to use GrayCode.
- If you really think that multiple-bit registers are indivisible per definition, you need to review that definition. In reality, multiple-bit registers are made up of single-bit ones. More importantly, multiple-bit registers have to use multiple lines to output their value. It's when more than one of these output lines change that you get transients, and GrayCode eliminates those transients in certain situations. It's not crazy for manufacturers to split registers into single bits, since nobody has come up with a way to do otherwise. Sure, there are other ways to eliminate transients, but GrayCode is as simple to implement as normal binary, and doesn't require any additional hardware to remove the transients. That gives it a rather significant advantage over the other ways.
- A register is absolutely not an indivisible unit, it is a human abstraction for a grouping of one-bit storage elements. Each is a simple electronic latch which holds one of two stable states independently with the others, each has its own settling time and propagation delays to other circuitry. Synchronous circuitry from the same clock domain can reliably avoid transient states, but asynchronous circuitry or circuitry from other clock domains can not, and in complex high-speed circuitry propagation delays can effectively put the attached circuitry in another clock domain. All this makes gray codes extremely useful, particularly in things like FIFOs that are designed specifically to get information across clock domains but also in other forms of high speed circuitry where they allow simpler and faster designs to be used.
- However, it helps only for a slow changing values and if the reading device is fast enough not to miss more than one cycle. If the measured value changes by more than 1 step, the deviation may be bigger as well. And if the reading device misses two cycles, the value is way off.
- That's an entirely different issue from the one gray codes solve (though gray codes do help indirectly, since they avoid feeding transient invalid values into logic). And no, the value isn't "way off", it's always no more than one off from the correct current value...you've just missed some intermediate codes.
WikiStub
Gray Code