You cannot ignore time. If you ignore time wont you always receive 1010101010. Surely, receiving Manchester encoded data is exactly the same as RS232 (timing wise) except you get twice as many bits.
RS232 uses fixed timing, Manchester doesn't, it's the transitions that are the data, NOT the HIGH or LOW points. In fact you can recover the original 'clock rate' from the Manchester coding if you didn't know it.
Obviously timing can't be completely ignored, a transition shouldn't occur too early, or too late - but there's a LOT of variation possible.
The reason this is important is that neither IR or Wireless links provide the same data output as you supply to the transmitter - which makes RS232 type timing unreliable. As long as you're running at a fairly low speed, you can read RC5 by a crude timed sampling technique, but obviously if you drift outside the correct bit you will read completely the wrong data - and as RC5 uses many more bits than RS232, it's got more chance of doing so. Having played for years with IR and Wireless links, I still find it confusing that the pulse widths from the receiver vary in width depending on the number and sequence of high and low bits, and the received signal strength.
Notice how the SIRC's IR system uses very different pulse widths, it's for the same reason - so timing is VERY non-critical.
But I was reffering to a variable I have created in my program, not an I/O port of the PIC. Before posting I did check the header file to see how they accomplish the setting of the ports. I could see what they were doing but wasn't able to relate it to my application.
Another question, I assume that you can manipulate the variable "byte" in the same way as any other variable? I'm talking about performing shift instructions on it etc.
Another question, I assume that you can manipulate the variable "byte" in the same way as any other variable? I'm talking about performing shift instructions on it etc.
It looks standard to me, too. I have studied structures a little but I've not used them in embedded programs (infact this is my first microcontroller program written in C).
Sorry, shouldn't have said C18 specific. I was referring to the OP stating that his compiler uses Ra0=xx etc and that the original question is best answered by using |=. The use of union and structures is just complicating the issue.
Sorry, shouldn't have said C18 specific. I was referring to the OP stating that his compiler uses Ra0=xx etc and that the original question is best answered by using |=. The use of union and structures is just complicating the issue.
I would say no. The structs are a good thing because they allow the naming of bits and fields. But without the compiler provided header file it will not compile.
If you do not like the idea of the compiler vendor owning the header file you can write your own. It would not be any more work then defining a good set of masks for doing bitwise operations.
Yes. If you look at the disassembly listing, you'll see that it's translated into a simple BSF instruction, as Mike said. Hi-Tech PICC compiler always checks if the mask is actually a 1-bit operation.
If you like to use bit numbers, you could use a simple macro, that will be translated into 1-cycle instructions (i.e. BCF or BSF):
No, it's plain old C coding. I have nothing against any programming method as long as it is clear and it does what the programmer intended. Var|=1 is perfectly fine too. The union also makes it easier to test the state of a bit within a byte by using the IF statement:
Code:
if ( data.bit1 == 0 ) { x++; }
What is neat about unions is that it makes for easy translation of data types and the grouping of bits within a byte, word, dword, float, etc: