Finally got back on this....connecting the encoder took longer than anticipated, and I didn't get the led confirmation on the dev board that I was expecting so wired up the other encoder as well which gave exactly the same results, so I figured it's some internal wizardry inside the encoder that does that.
With the basic 8bit encoder that I practiced on it caused the leds on the dev boards to light as you rotated the spindle, obviously the patterns looked haphazard due to the binary input, but they were all bright and clearly going full on & full off. However with the 10bit encoders there are large blank areas of rotation where none of the leds are illuminated (roughly 30 degrees or so) them a bright full on/off area (60ish degrees), and also a dim on/off area (60ish degrees). this repeats twice though a full revolution, which I thought was odd, hence I wired the other one as well, but its the same.
I do understand the concept, and I did say I'd created an excel spreadsheet in my earlier post just to confirm my grasp...I did a degree in electronics some time ago, and remember gates etc, but knowing they exist is one thing, getting them to work is another. So I spent the day going over it all.
There's no way to do them all at once, because what do do depends upon the state of the previous bit.
hence I was asking about looping it through, but I was sure there'd be a simpler way, as you went on to prove.
So I'm here at the moment using the link that ric previously posted.....although now I'll be back at converting the binary to hex again...
And here as mention above isn't working.....I get the first bit of text with the program info and the text that reads "Binary Output:" but when I turn the spindle nothing...
- Code: Select all
volatile uint8_t G_PortB;
volatile uint8_t G_PortC_0;
volatile uint8_t G_PortC_1;
volatile uint16_t GrayInput;
unsigned short temp;
unsigned short num;
unsigned short Result;
unsigned short grayToBinary(unsigned short num)
{
unsigned short temp = num ^ (num>>8); //short =16bits
temp ^= (temp>>8);
temp ^= (temp>>4);
temp ^= (temp>>2);
temp ^= (temp>>1);
return temp;
}
void main(void)
{
// Initialize the device
SYSTEM_Initialize();
PIN_MANAGER_Initialize();
INTERRUPT_Initialize();
EUSART1_Initialize();
INTERRUPT_GlobalInterruptEnable();
INTERRUPT_PeripheralInterruptEnable();
void EUSART1_Initialize(void);
{
printf("\rEasyPIC V7-8MHz Date 03/08/2019\r\n");
printf("USART Communications 8-bit Rx & Tx\r\n\n");
printf("10bit Encoder to port B(0:7) & PortC(0:1)\r\n\n");
printf("DIPS set to pull down. \r\n\n");
}
while (1)
{
G_PortC_0 = IO_RC0_PORT; //Pin RC0 Single bit Binary Input
G_PortC_1 = IO_RC1_PORT; //Pin RC1 Single bit Binary Input
G_PortB = PORTB; //Pin RB0-7 8 bit Binary Input
GrayInput = (G_PortC_0<<2 | G_PortC_1<<1 | PORTB); //shift G_PortC to become bit9 of GrayInput, shift G_PortC to become bit8 of GrayInput add all of PortB
Result =grayToBinary(GrayInput);
printf("Binary Output: \r",Result);
}
/**
End of File
*/
}
...and this is the terminal output
EasyPIC V7-8MHz Date 03/08/2019
USART Communications 8-bit Rx & Tx
10bit Encoder to port B(0:7) & PortC(0:1)
DIPS set to pull down.
Binary Output:
I'm very confused about the right shifting of the bits...
- Code: Select all
unsigned short temp = num ^ (num>>8)
(stop me if I'm wrong) is num xored with the previous value of num, but how is num (16bit) shifted 8 positions, and why?
would you be kind enough to explain what's going at this point?
Is it something to do with the way the variable is populated, i.e. LSB first...
Regards
Les
History teaches us that history doesn't teach us.