PIC32MX120f064h pin not included in XC32 compiler

[BurnedResistor]

Hey all,

Today I was continuing with my project using the PIC32MX120F064H. I want to use pin 35 (RF6) as an output, however the header files for this pic device that come with the xc32 compiler seem to not include this pin. Here is the structure from the pic32mx120f064h.h file:

Code: [Select]


typedef union {
  struct {
    unsigned TRISF0:1;
    unsigned TRISF1:1;
    unsigned TRISF2:1;
    unsigned TRISF3:1;
    unsigned TRISF4:1;
    unsigned TRISF5:1;
    unsigned :2;
    unsigned TRISF8:1;
    unsigned :3;
    unsigned TRISF12:1;
    unsigned TRISF13:1;
  };
  struct {
    unsigned w:32;
  };
} __TRISFbits_t;


The datasheet notes that this specific pin is not available on devices with USB capabilities, but the specific device I am using does not have a usb peripheral.

Any ideas/workarounds?
Would simply adding it to the structure work?

(I know, I simply could change the pins I am using, but I have already sent the PCB to the fab because I really was not expecting a simple IO pin to cause problems....)

[BurnedResistor]

I also just checked the erata, nothing mentioned!

[Howardlong]

Either of these any good?

Code: [Select]

    TRISFCLR = 0x0040;     // TRISFbits.TRISF6=0;
//...or...
    TRISFCLR = 1 << 6 ;     // TRISFbits.TRISF6=0;


[BurnedResistor]

Either of these any good?

Code: [Select]

    TRISFCLR = 0x0040;     // TRISFbits.TRISF6=0;
//...or...
    TRISFCLR = 1 << 6 ;     // TRISFbits.TRISF6=0;


My issue right now is that I do not have my devboard with me, so it is somewhat difficult to test...

I was hoping somewhat would recognize the issue :/

Could you give me a quick overview of how to use the set, clear and invert registers? As far as I understand it, setting a bit in the set register sets the corresponding bit in the sfr, setting one in the clear register clears the corresponding bit, and setting the invert clears the corresponding bit. Is this correct? What are the advantages to using these registers?

[BurnedResistor]

Either of these any good?

Code: [Select]

    TRISFCLR = 0x0040;     // TRISFbits.TRISF6=0;
//...or...
    TRISFCLR = 1 << 6 ;     // TRISFbits.TRISF6=0;


Do you think this is just an issue with the XC32 header files or am I skipping over something in the datasheets?

[Howardlong]

Either of these any good?

Code: [Select]

    TRISFCLR = 0x0040;     // TRISFbits.TRISF6=0;
//...or...
    TRISFCLR = 1 << 6 ;     // TRISFbits.TRISF6=0;


Do you think this is just an issue with the XC32 header files or am I skipping over something in the datasheets?

The headers are wrong.

You can test it in the simulator --- as I did! I don't have your physical device I'm afraid, I have others in the same datasheet but they all have USB so no good for testing this.

[BurnedResistor]

Either of these any good?

Code: [Select]

    TRISFCLR = 0x0040;     // TRISFbits.TRISF6=0;
//...or...
    TRISFCLR = 1 << 6 ;     // TRISFbits.TRISF6=0;


Do you think this is just an issue with the XC32 header files or am I skipping over something in the datasheets?

The headers are wrong.

You can test it in the simulator --- as I did! I don't have your physical device I'm afraid, I have others in the same datasheet but they all have USB so no good for testing this.

Great, thank you very much!

Sent from my SM-N7500Q using Tapatalk

[Sal Ammoniac]

Just change the header file to this:

Code: [Select]

typedef union {
  struct {
    unsigned TRISF0:1;
    unsigned TRISF1:1;
    unsigned TRISF2:1;
    unsigned TRISF3:1;
    unsigned TRISF4:1;
    unsigned TRISF5:1;
    unsigned TRISF6:1;
    unsigned :1;
    unsigned TRISF8:1;
    unsigned :3;
    unsigned TRISF12:1;
    unsigned TRISF13:1;
  };

And report it to Microchip so they can fix it in a future release.

[BurnedResistor]

Just change the header file to this:

Code: [Select]

typedef union {
  struct {
    unsigned TRISF0:1;
    unsigned TRISF1:1;
    unsigned TRISF2:1;
    unsigned TRISF3:1;
    unsigned TRISF4:1;
    unsigned TRISF5:1;
    unsigned TRISF6:1;
    unsigned :1;
    unsigned TRISF8:1;
    unsigned :3;
    unsigned TRISF12:1;
    unsigned TRISF13:1;
  };

And report it to Microchip so they can fix it in a future release.

Do you know where to report this issue? I was not able to find anything....

[dannyf]

A few alternatives.

I prefer the mask approach to set, clear or flip the data register.

Many modern mcus like the pic also have set, clear and inverse registers. They are slight faster and don't suffer from rmw.

The bit field approach is my least favored as it is quite compiler dependent. In this case, you can change the header file or create your own bit field struct and typecast it onto the data register - you don't need to rely on the header file for the bit fields.

[BurnedResistor]

A few alternatives.

I prefer the mask approach to set, clear or flip the data register.

Many modern mcus like the pic also have set, clear and inverse registers. They are slight faster and don't suffer from rmw.

The bit field approach is my least favored as it is quite compiler dependent. In this case, you can change the header file or create your own bit field struct and typecast it onto the data register - you don't need to rely on the header file for the bit fields.

Thank you!

[Howardlong]

My personal preference is for bitfields because I find it far more readable and maintainable, but that's just my opinion. I'm not convinced bitfields aren't portable, and realistically if you're looking to change compilers bitfields are probably the least of your worries.

The worst option is to assign a complete register with a single hex literal. Sure it's portable, but not so much fun to read and debug.

Just my opinion of course.

[dannyf]

The bitfield approach I mentioned earlier can be implemented, for example, like this:

Code: [Select]


//32-bit field definition
typedef struct {
unsigned char B0:1;
unsigned char B1:1;
...
unsigned char B31:1;
} B32_TypeDef;

#define LATBbits ((volatile B32_TypeDef *) &LATB)
#define LATBINVbits ((volatile B32_TypeDef *) &LATBINV)

//code example - flip port.6
LATBbits->B6 ^= 1; //flip port.6
LATBINVbits->B6 = 1; //flip port.6

You can make it fancier by implementing also unions of bytes, or words, etc.

Beware that 1) it is compiler dependent; and 2) it is endian-dependent. So be careful porting it.