Question

could someone please have a look at this code.

// bitfield definitions

typedef union {
struct {
    unsigned TRISA0                 :1;
    unsigned TRISA1                 :1;
    unsigned TRISA2                 :1;
    unsigned TRISA3                 :1;
    unsigned TRISA4                 :1;
    unsigned                        :1;
    unsigned TRISA6                 :1;
    unsigned TRISA7                 :1;
};
struct {
    unsigned RA0                    :1;
    unsigned RA1                    :1;
    unsigned RA2                    :1;
    unsigned RA3                    :1;
    unsigned RA4                    :1;
    unsigned                        :1;
    unsigned RA6                    :1;
    unsigned RA7                    :1;
};
} TRISAbits_t;
extern volatile TRISAbits_t TRISAbits @ 0xF92; 

this is from a Header file Of a PIC microcontroller.

what I already know,

1) the the size of the union is its largest element inside it. so we have 2 structs here with the same size, so the size of the union is going to be sizeof(unsigned)*8

2) the :1 after each variable gives bit level access

3) accessing TRISA0 or RA0 gives access to the same bit in memory, and so on for the rest.

Think my confusion arises from this part

extern volatile TRISAbits_t TRISAbits @ 0xF92; 

4)extern declares the TRISAbits of type TRISAbits_t but does not allocate memory for it.

5)Volatile means that the Memory for this can be changed by a different thread, without my code altering it.

6)when I am writing code I would Write TRISAbits.RA0 which would be the same as TRISAbits.TRISA0 .

7)what does the @ 0xF92 hex do? and are my answers correct?

thanks.

Edit. for anyone interested this is from the PIC18f1220 micro-controller header file

Était-ce utile?

La solution

That's quite a lot of questions all rolled into ... I don't know how many since a) your numbering is broken and b) not all numbered items in your question are, really, questions. :)

The size will be affected by the fact that all the struct members are bitfields. It's hard to be more specific than that, but code at this level (often tailored for a very spefific combination of compiler and hardware) generally is written with some very particular outcome in mind.

In this case, I would say that the size is probably 1, since there's 8 bits being mapped out.

The extern says "treat the memory at address 0xf92 as a value of this type". This is mapping out an absolute location, where the PIC has a hardware register. This syntax is not standard C, that's some compiler's extension. The portable way would have been to declare it like this:

// in some header
extern volatile TRISAbits_t * const TRISAbits;

// in some library or C file that you link into your app:

volatile TRISAbit_t * const TRISAbits = (volatile TRISAbits_t *) 0xf92;

This declares TRISAbits as being a pointer to the register, rather than a variable that really is at the register's address. The pointer style means accesses have to look like this:

TRISAbits->RA0 = 0;

It also uses more memory since the global pointer variable has to "live" somwhere, whereas the magical @-instance lives in the register space, not in memory.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top