Hi, > Also, the below proposed usage will make the pointer volatile (so the > compiler will NOT store it in a local register but constantly reload > it from RAM) and not the hardware register it points to. It might happen > that the value, once read, is calculated with again and again without > ever reloading it.
There is one thing I forgot inside my declaration it should be: volatile OutputEndDescriptorType *tOutputEndDescriptorBlock = (volatile OutputEndDescriptorType*) ... otherwise it would lead to an implicit cast from a pointer to volatile data to a pointer to plain data. But I think there is something wrong in your explanation. Because if i've understood your suggestion, my version should be something like that: OutputEndDescriptorType * volatile tOutputEndDescriptorBlock = (OutputEndDescriptorType * volatile) ... Therefore I have copied an explanation out of the C-Standard. If I'am wrong please correct me: EXAMPLE The following pair of declarations demonstrates the difference between a variable pointer to a constant value and a constant pointer to a variable value. const int *ptr_to_constant; int *const constant_ptr; The contents of any object pointed to by ptr_to_constant shall not be modified through that pointer, but ptr_to_constant itself may be changed to point to another object. Similarly, the contents of the int pointed to by constant_ptr may be modified, but constant_ptr itself shall always point to the same location. The behaviour is the same for any other qualifier (like volatile in our case). For further explanation take a look on page 115 to 117 at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1362.pdf Best regards, Gerald -----Ursprüngliche Nachricht----- Von: JMGross [mailto:[email protected]] Gesendet: Donnerstag, 3. Dezember 2009 18:34 An: MSPGCC mailing list, Betreff: Re: [Mspgcc-users] msp430x5529 support Hi! Why using a pointer? The normal defines in MSPGCC are evaluated to volatile unsigned char/int NAME asm(#ADDRESS); So in this case volatile OutputEndDescriptorType tOutputEndPointDescriptorBlock asm(#USBOEPCNF_1); should do the trick. Any member of the struct is then accessed by tOutputEndPointDescriptorBlock.xyz It not only saves two bytes of RAM for storing the pointer to the register, it will also generate slightly smaller code, depending on usage. Also, the below proposed usage will make the pointer volatile (so the compiler will NOT store it in a local register but constantly reload it from RAM) and not the hardware register it points to. It might happen that the value, once read, is calculated with again and again without ever reloading it. JMGross ----- Ursprüngliche Nachricht ----- Von: Gerald Lutter An: 'GCC for MSP430 - http://mspgcc.sf.net' Gesendet am: 03 Dez 2009 09:19:06 Betreff: Re: [Mspgcc-users] msp430x5529 support Hi Bernie, changing addresses inside the assembler section does not change the symbol for your C-Code. This is because the assembler Section of the header is only available if you use assembler. But I think you are using C-Code therefore your changes will have no effect. By the way, the assembler section of msp430x55x9_newversion.h is generated automatically during the build of the library out of msp430x55x9_template.header (this file does only exist before you build the msp430-libc after applying our patch). But now to your actual question: if tOutputEndPointDescriptorBlock is of type OutputEndDescriptorType then you have to define your tOutputEndPointDescriptorBlock as pointer: volatile OutputEndDescriptorType *tOutputEndDescriptorBlock = (volatile OutputEndDescriptorType *)&USBOEPCNF_1; you are now able to configure your component using this code tOutputEndDiscriptorBlock-><any field inside your struct> = <any value tOutputEndDiscriptorBlock->you need>; Best regards, ---------------------------------------------------------------------------- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
