• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 22 subscribers
  • Views 1265 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

Struct for registers

Jose Paulo Remor

Hello,

i'm using keil 3.05 evaluation, its my first experience with this tool.
Normally i found in other tools a struct inside the .h of the uproc. In this case i found just a define.

#define PCON (*((volatile unsigned char *) 0xE01FC0C0))

trying to create a structure, i dont know how to set the struct mem position. I've tried this code bellow without sucess.

/* Cria os bits da estrutura */
struct { unsigned int PLLE : 1; unsigned int PLLC : 1; unsigned int NotUsed : 6;
} PCONbits __at 0xE01FC0C0;

i'll have this libs with the full version of keil tools?

thanks!
Jose

  • 0

    Bit fields can be quite nice sometimes, but you do not want to use them when accessing real hardware, or when generating output files that must be read by different programs.

    Do not rely on the location of the individual bit fields in the struct! Different compilers may perform the bit allocation differently. Use the pointer and or/and bits instead.

  • 0 in reply to ImPer Westermark

    I think that output files does not have any influence using bit struct. I'm wrong?

    About the bit allocation, this is not a problem. If i change the compiler, i just chance the .h file either. And finally, can you show a example using pointer?

    thanks again

  • 0 in reply to Jose Paulo Remor

    I agree with Per regarding the avoidance of using bitfields. That said, you can do it quite similarly to the char PCON macro version.

    #define PCON_BITS (*(volatile struct PCONbits*)0xE01FC0C0)

struct PCONbits {unsigned PLLE:1, PLLC:1, NotUsed:6;};

PCON_BITS.PLLE = 0;

  • 0 in reply to Dan Henry

    If you write a PC program that generates an output file, then it is important that the output file has a file format that you may always be able to read again.

    If the file is binary, and you make use of bit fields, then a compiler change may make the recompiled code unable to read back the data.

    Hence my note about output files. But the problem is similar for embedded systems if you store configuration in EEPROM or FLASH memory and support firmware updates.

    If you change (or upgrade) the compiler and then rebuild the application, then you can not be sure that the recompiled application will read back the same bit-field contents from EEPROM or FLASH.

  • 0 in reply to ImPer Westermark

    This solution with macros can help me,

    thanks!