The former (cast to void* at point-of-use) is probably better.  Otherwise
the compiler might optimize away operations through iep0_buf because it
doesn't know the USB peripheral also accesses that memory.  (This presumes
it won't optimize away the memset for the same reason, which would be
inconvenient.)

Peter

On Sat, Feb 16, 2013 at 6:51 AM, Mathias K. <kes...@freenet.de> wrote:

> Same assembly but 2 warnings:
>
> main.c:11:1: warning: passing argument 1 of 'memset' discards 'volatile'
> qualifier from pointer
> target type [enabled by default]
> In file included from main.c:3:0:
> /usr/lib/gcc/msp430/4.7.0/../../../../msp430/include/string.h:65:15: note:
> expected 'void *' but
> argument is of type 'volatile unsigned char *'
>
> So the cast to void* would remove the warnings:
>
> memset((void*)&USBIEP0BUF, 0, EP0_MAX_PACKET_SIZE);
>
> or with the correct define
>
> #define iep0_buf ((uint8_t*)&USBIEP0BUF)
>
>
> Regards,
>
> Mathias
>
>
> On 16.02.2013 13:39, Peter Bigot wrote:
> > Or just:
> >
> >   memset(&USBIEP0BUF, 0, EP0_MAX_PACKET_SIZE);
> >
> > since the buffer is declared in the header (though as a byte, not an
> array).  The name with the
> > underscore suffix is technically internal to the mspgcc implementation;
> the syntax above should work
> > with any MSP430 compiler that uses the TI headers (which is all the ones
> I know of: mspgcc, CCS, and
> > IAR).
> >
> > Peter
> >
> > On Sat, Feb 16, 2013 at 4:26 AM, Mathias K. <kes...@freenet.de <mailto:
> kes...@freenet.de>> wrote:
> >
> >     Hello,
> >
> >     the RAM starts at 2400 and your variable is placed before this
> address. You can simple use a pointer
> >     or define to access this buffer. Anyway the Pointer for the EP0
> buffer is defined in the msp430
> >     header files.
> >
> >     #include <msp430.h>
> >     #include <stdint.h>
> >     #include <string.h>
> >
> >     #define EP0_MAX_PACKET_SIZE 0x08
> >
> >     #define iep0_buf (((uint8_t*)(int)USBIEP0BUF_))
> >
> >     int main()
> >     {
> >      memset(iep0_buf, 0, EP0_MAX_PACKET_SIZE);
> >      return 0;
> >     }
> >
> >     Assembly looks like this:
> >
> >         4404:       3d 42           mov     #8,     r13     ;r2 As==11
> >         4406:       0e 43           clr     r14
> >         4408:       3f 40 78 23     mov     #9080,  r15     ;#0x2378
> >         440c:       b0 12 12 44     call    #0x4412
> >
> >
> >     Regards,
> >
> >     Mathias
> >
> >
> >     On 16.02.2013 09:34, Ionut Nicu wrote:
> >     > Hi,
> >     >
> >     > I have a USB driver for the msp430 5xx series which allocates the
> USB
> >     > buffers at the proper addresses in the USB RAM using asm("0xaddr")
> >     > statements.
> >     >
> >     > With the 20120911 compiler, when using "-fdata-sections" the code
> no
> >     > longer compiles. For example, with the following code:
> >     >
> >     > #include <msp430.h>
> >     > #include <stdint.h>
> >     > #include <string.h>
> >     >
> >     > #define EP0_MAX_PACKET_SIZE 0x08
> >     >
> >     > static uint8_t iep0_buf[EP0_MAX_PACKET_SIZE] asm("0x2378");
> >     >
> >     > int main()
> >     > {
> >     >         memset(&iep0_buf[0], 0, sizeof(iep0_buf));
> >     >         return 0;
> >     > }
> >     >
> >     >
> >     > ionut@heimdall:~$ msp430-gcc -mmcu=msp430f5528 -fdata-sections -c
> main.c
> >     > -o main.o
> >     > /tmp/ccaEQtpB.s: Assembler messages:
> >     > /tmp/ccaEQtpB.s:8: Error: Missing symbol name in directive
> >     > /tmp/ccaEQtpB.s:8: Error: junk at end of line, first unrecognized
> >     > character is `x'
> >     > /tmp/ccaEQtpB.s:9: Error: expected comma after name `' in .size
> >     > directive
> >     > /tmp/ccaEQtpB.s:10: Error: junk at end of line, first unrecognized
> >     > character is `0'
> >     >
> >     >
> >     > If I remove the "-fdata-sections" option, the code compiles just
> fine.
> >     >
> >     > In my project, since it's being used for multiple devices, there
> are a
> >     > lot of things (code and data) that need to be stripped if they're
> not
> >     > used. That's why I need to use "-fdata-sections -ffunction-sections
> >     > -Wl,--gc-sections" to eliminate data and code that isn't used.
> >     >
> >     > Trying the same code with the x86 gcc shows the same problem, so I
> guess
> >     > this is not mspgcc specific, but rather something that changed in
> newer
> >     > versions of gcc.
> >     >
> >     > Does anyone have a suggestion on how to solve this? I thought about
> >     > declaring sections for each variable in a custom linker file and
> then
> >     > using __attribute__((section(".section_name"))) when declaring the
> >     > variables, but I think it's an ugly solution.
> >     >
> >     > Thanks,
> >     > Ionut.
> >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     > The Go Parallel Website, sponsored by Intel - in partnership with
> Geeknet,
> >     > is your hub for all things parallel software development, from
> weekly thought
> >     > leadership blogs to news, videos, case studies, tutorials, tech
> docs,
> >     > whitepapers, evaluation guides, and opinion stories. Check out the
> most
> >     > recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> >     > _______________________________________________
> >     > Mspgcc-users mailing list
> >     > Mspgcc-users@lists.sourceforge.net <mailto:
> Mspgcc-users@lists.sourceforge.net>
> >     > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >     >
> >
> >
> >
> ------------------------------------------------------------------------------
> >     The Go Parallel Website, sponsored by Intel - in partnership with
> Geeknet,
> >     is your hub for all things parallel software development, from
> weekly thought
> >     leadership blogs to news, videos, case studies, tutorials, tech docs,
> >     whitepapers, evaluation guides, and opinion stories. Check out the
> most
> >     recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> >     _______________________________________________
> >     Mspgcc-users mailing list
> >     Mspgcc-users@lists.sourceforge.net <mailto:
> Mspgcc-users@lists.sourceforge.net>
> >     https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >
> >
>
>
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to