This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

toggling port pins through an element in a structure

Here is what I am trying to do:

sbit PORT_1_0 = P1^0;

void main ()
{ PORT_1_0 = 1; while(1) { PORT_1_0 =~ PORT_1_0; }
}

Now this is as simple as it gets.
The question is, is it possible to do the same thing using an element of a struct?

Something like:

struct abc
{ unsigned char bit : 1;
};

struct bit bit_array[24];

bit_array[0].bit = P1^0; //Assign the port pin to be toggled

//and then the toggling here.

Basically, how to assign a port pin to the bit in a struct? I am doing this because based on the address of a frame, I need to decide which pin is to be set.
I hope you get the question.

Parents
  • The processor instruction set have special bit instructions. These instructions are very small and efficient. But the instructions encodes the address of the bit inside the instruction - this makes the processor instruction "hard-coded" for operating on specific bits.

    Because of this, you can't change the address of the bit variable. Being able to have a bit that can change location would require the processor to support indexed bit operations, i.e. one instruction that takes the address of the bit from a processor register instead of having the address encoded in the actual instruction.

    Because of this, the compiler-specific construct with bit variables can't be freely mixed with standard C variable constructions. An array of bit variables would require that you can access it using an index. And the 8051 instruction set is unable to get a bit instruction to care about any index - you only have a small number of bit-addressable bytes within the internal RAM and a small number of bit-addressable bytes within the memory-mapped registers of the processor. And the source code or the build processes needs to assign the address of these bits.

    Note that C have a construction with bit fields (basically integers that are 1, 2, 3, ... bits large and stored within a "normal" integer container - i.e. an 8-bit byte can have room for 8 1-bit integers, or 4 2-bit integers or 1 3-bit, 1 2-bit and 3 1-bit (1*3+1*2+3*1 = 8) bit-field integers. But the C construct with bit fields is there to allow many small integers to be packed within a single larger integer to squeeze the most out of a very limited amount of RAM. And the bit fields supported by the C language can't make use of the special bit data type that C51 and some other 8051-specific compilers have added to the language - the bit fields are in the background implemented by bit-and and bit-or.

    Anyway - since C have bit-operating instructions for "and", "or" and "not", you can always toggle individual bits of any variable that is stored in RAM. Just that testing, setting, clearing or inverting a bit using standard C will not be as fast and small as the special case when you can create the 8051-specific 1-bit variables. The "C" way means "read a byte, set a bit, save a byte" while the Keil bit extension means "set a bit" with zero need to bother about the other 7 bits. The advantage was so huge that 8051 tool vendors just could not sneak in this extension to the C language even if they can't make bit variables fully mixable in structures or arrays or accessed through pointers.

Reply
  • The processor instruction set have special bit instructions. These instructions are very small and efficient. But the instructions encodes the address of the bit inside the instruction - this makes the processor instruction "hard-coded" for operating on specific bits.

    Because of this, you can't change the address of the bit variable. Being able to have a bit that can change location would require the processor to support indexed bit operations, i.e. one instruction that takes the address of the bit from a processor register instead of having the address encoded in the actual instruction.

    Because of this, the compiler-specific construct with bit variables can't be freely mixed with standard C variable constructions. An array of bit variables would require that you can access it using an index. And the 8051 instruction set is unable to get a bit instruction to care about any index - you only have a small number of bit-addressable bytes within the internal RAM and a small number of bit-addressable bytes within the memory-mapped registers of the processor. And the source code or the build processes needs to assign the address of these bits.

    Note that C have a construction with bit fields (basically integers that are 1, 2, 3, ... bits large and stored within a "normal" integer container - i.e. an 8-bit byte can have room for 8 1-bit integers, or 4 2-bit integers or 1 3-bit, 1 2-bit and 3 1-bit (1*3+1*2+3*1 = 8) bit-field integers. But the C construct with bit fields is there to allow many small integers to be packed within a single larger integer to squeeze the most out of a very limited amount of RAM. And the bit fields supported by the C language can't make use of the special bit data type that C51 and some other 8051-specific compilers have added to the language - the bit fields are in the background implemented by bit-and and bit-or.

    Anyway - since C have bit-operating instructions for "and", "or" and "not", you can always toggle individual bits of any variable that is stored in RAM. Just that testing, setting, clearing or inverting a bit using standard C will not be as fast and small as the special case when you can create the 8051-specific 1-bit variables. The "C" way means "read a byte, set a bit, save a byte" while the Keil bit extension means "set a bit" with zero need to bother about the other 7 bits. The advantage was so huge that 8051 tool vendors just could not sneak in this extension to the C language even if they can't make bit variables fully mixable in structures or arrays or accessed through pointers.

Children