On Wed, 2015-04-22 at 08:16 -0400, Nathan House wrote: > Well, the structs are unioned together, so the different member names > access the same locations in memory, That is correct > so they are duplicate definitions > (unless I'm misunderstanding something).. Not really "duplicate definitions" in the pedantic sense since they have different names, but they are simply different ways of saying the same thing. As I said earlier, I suspect it has to do with maintaining some degree of compatibility with other compilers. When you posted the original question I happened to be working with an assembler program which at first glance appeared quite normal, but on closer examination there were all sorts of syntactic differences. Most could probably have been dealt with through macros, but there is no reason for Microchip to provide those since MPASM has been pretty consistent for decades. C compilers not so much. If you look deeper you will see further defines that are duplicates. For e= xample you will probably see something like #define _LATB5 LATBbits.LATB5 In this case, it is simply a shortcut. There is nothing wrong with having = multiple names for the same thing. Multiple things with the same name, wel= l, that IS a problem. --McD >=20 > I'm a college student, take it easy on me ;-) >=20 > Check out my small hobby electronics business! > www.foxytronics.com >=20 > On Mon, Apr 20, 2015 at 4:39 PM, Jesse Lackey > wrote: >=20 > > ...additionally all these include files are clearly generated by scripts > > based on some core info about each chip, so it costs almost nothing to > > do all this. So for each chip microchip has (practically) ever made, > > pull info about it from some database, apply scripts that have been > > written over the years for the various compilers, output include files. > > There is little need to be concise, better to be compatible with the > > long past... > > > > J > > > > > > John J. McDonough wrote: > > > I assume this is an 8 bit part, I haven't seen quite so much redundancy > > > on the 16/32 bit parts. > > > > > > My guess is that it has to do with compatibility with other compilers. > > > Microchip has had relationships with a number of compiler vendors over > > > the years, tho they now seem to have settled on an 8 bit standard. The > > > 16/32 bit compilers have always been gcc, so you don't see all that > > > history. > > > > > > Sometimes compiler and assembler developers have a "better idea" and > > > feel like they can somehow improve things by, for example, > > > calling .TRISA7 .RA7 instead. Since Microchip supported a number of > > > these compilers over the years, I suspect they feel obligated to make an > > > attempt at retaining some degree of source compatibility. > > > > > > Just my guess > > > > > > --McD > > > > > > On Mon, 2015-04-20 at 13:59 -0400, Nathan House wrote: > > >> Hi, > > >> > > >> The main.pre file in my MPLAB X project seems to show the definitions > > for > > >> the configuration registers. One example is this: > > >> > > >> typedef union { > > >> struct { > > >> unsigned TRISA0 :1; > > >> unsigned TRISA1 :1; > > >> unsigned TRISA2 :1; > > >> unsigned TRISA3 :1; > > >> unsigned TRISA4 :1; > > >> unsigned TRISA5 :1; > > >> unsigned TRISA6 :1; > > >> unsigned TRISA7 :1; > > >> }; > > >> struct { > > >> unsigned RA0 :1; > > >> unsigned RA1 :1; > > >> unsigned RA2 :1; > > >> unsigned RA3 :1; > > >> unsigned RA4 :1; > > >> unsigned RA5 :1; > > >> unsigned RA6 :1; > > >> unsigned RA7 :1; > > >> }; > > >> } TRISAbits_t; > > >> extern volatile TRISAbits_t TRISAbits @ 0xF92; > > >> > > >> What is the point of making the same bits accessible through more than > > one > > >> name? > > >> > > >> I.e. the following lines of code are identical, correct? > > >> > > >> TRISAbits.RA0 =3D 1; > > >> TRISAbits.TRISA0 =3D 1; > > >> > > >> The LATAbits definition is even more convoluted: > > >> > > >> typedef union { > > >> struct { > > >> unsigned LATA0 :1; > > >> unsigned LATA1 :1; > > >> unsigned LATA2 :1; > > >> unsigned LATA3 :1; > > >> unsigned LATA4 :1; > > >> unsigned LATA5 :1; > > >> unsigned LATA6 :1; > > >> unsigned LATA7 :1; > > >> }; > > >> struct { > > >> unsigned LA0 :1; > > >> }; > > >> struct { > > >> unsigned :1; > > >> unsigned LA1 :1; > > >> }; > > >> struct { > > >> unsigned :2; > > >> unsigned LA2 :1; > > >> }; > > >> struct { > > >> unsigned :3; > > >> unsigned LA3 :1; > > >> }; > > >> struct { > > >> unsigned :4; > > >> unsigned LA4 :1; > > >> }; > > >> struct { > > >> unsigned :5; > > >> unsigned LA5 :1; > > >> }; > > >> struct { > > >> unsigned :6; > > >> unsigned LA6 :1; > > >> }; > > >> struct { > > >> unsigned :7; > > >> unsigned LA7 :1; > > >> }; > > >> } LATAbits_t; > > >> extern volatile LATAbits_t LATAbits @ 0xF89; > > >> > > >> I don't know why they union'd a separate struct for each of the bits > > >> instead of putting them all in one struct like with TRISAbits, but the > > same > > >> question applies to this as well. > > >> > > >> What's the point of all that redundancy? > > >> > > >> Thanks, > > >> > > >> Nate > > >> > > >> ----- > > >> > > >> I'm a college student, take it easy on me ;-) > > >> > > >> Check out my small hobby electronics business! > > >> www.foxytronics.com > > > > > > > > -- > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > > View/change your membership options at > > http://mailman.mit.edu/mailman/listinfo/piclist > > --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .