PIC32MX120f064h pin not included in XC32 compiler - Page 1
Forum section: electronics / general

author: BurnedResistor
author_rank: Regular Contributor
timestamp: February 04, 2016, 06:12:35 pm
content: 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: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....)

author: BurnedResistor
author_rank: Regular Contributor
timestamp: February 04, 2016, 06:23:55 pm
content: I also just checked the erata, nothing mentioned!

author: Howardlong
author_rank: Super Contributor
timestamp: February 04, 2016, 07:08:01 pm
content: Either of these any good?Code:TRISFCLR = 0x0040; // TRISFbits.TRISF6=0;//...or...TRISFCLR = 1 << 6 ; // TRISFbits.TRISF6=0;

author: BurnedResistor
author_rank: Regular Contributor
timestamp: February 04, 2016, 08:22:42 pm
content: Quote from: Howardlong on February 04, 2016, 07:08:01 pmMy 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?

author: BurnedResistor
author_rank: Regular Contributor
timestamp: February 04, 2016, 08:48:00 pm
content: Quote from: Howardlong on February 04, 2016, 07:08:01 pmDo you think this is just an issue with the XC32 header files or am I skipping over something in the datasheets?

author: Howardlong
author_rank: Super Contributor
timestamp: February 04, 2016, 09:24:30 pm
content: Quote from: BurnedResistor on February 04, 2016, 08:48:00 pmThe 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.

author: BurnedResistor
author_rank: Regular Contributor
timestamp: February 04, 2016, 09:25:27 pm
content: Quote from: Howardlong on February 04, 2016, 09:24:30 pmGreat, thank you very much!Sent from my SM-N7500Q using Tapatalk

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: February 04, 2016, 09:44:42 pm
content: Just change the header file to this:Code: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.

author: BurnedResistor
author_rank: Regular Contributor
timestamp: February 04, 2016, 10:15:12 pm
content: Quote from: Sal Ammoniac on February 04, 2016, 09:44:42 pmDo you know where to report this issue? I was not able to find anything....

author: dannyf
author_rank: Super Contributor
timestamp: February 04, 2016, 11:02:21 pm
content: 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.

author: BurnedResistor
author_rank: Regular Contributor
timestamp: February 05, 2016, 08:14:33 pm
content: Quote from: dannyf on February 04, 2016, 11:02:21 pmThank you!

author: Howardlong
author_rank: Super Contributor
timestamp: February 05, 2016, 08:46:43 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 06, 2016, 12:35:32 pm
content: The bitfield approach I mentioned earlier can be implemented, for example, like this:Code://32-bit field definitiontypedef 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.6LATBbits->B6 ^= 1;//flip port.6LATBINVbits->B6 = 1;//flip port.6You 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.