There was some discussion about whether to include msp430/common.h; the pros are that the documentation says it should be included and people seem to expect it; the cons are that it defines certain things that aren't necessarily common, like the address of the watchdog timer (fixed) and the LPM bits that arguably belong in some other module (maybe pmm.h; I'm not convinced). I think it's safe to add it.
For the 54xx chip, the correct includes are dmax.h (not dma.h) and gpio_5xxx.h (not gpio.h). Again history affects this; in both cases the architectural changes for MSP430XV2 were too great to risk breaking code that works just fine with the existing headers, so advanced chips need to include the correct version. The naming differences arise from different maintainers adding these features. See cc430_.h for what needs to be added for this family of chips. If you do both these mods, confirm that they work, and send me the patches, I'm willing to add them in the repository. I don't have a test environment for that chip, and am reluctant to make changes that haven't been verified by somebody. Peter On Mon, Mar 8, 2010 at 3:27 PM, Anthony Asterisk <[email protected] > wrote: > I noticed something in the msp430x54xx.h header file. It seems to be > missing msp430/common.h. Also missing are dma.h and gpio.h, but perhaps > those still need to be ported. > > Is it safe for me to add this locally until the header files are further > developed? > > > a* > > > Hi JMGross wrote: > > First, the 5418/19 is 100% hardware compatible to the 5437/38. The _only_ > difference is the Flash size (128 instead of 256kb). In the middle sits the > 5435/36 with 192kb. > > Everything else is 100% identical, same hardware modules, same package, > even the same silicon errata :) > > > > The only difference is the A series of these processors. The A types have > some smaller differences like a separate reference voltage module which > needs to be configured first before you can use the ADC12_A, or a > > _usable_ (fully CCCITT compatible, not bit-inverted) version of the CRC16 > module. And of course lower power consumption and increased maximum clock. > For a siginificantly higher price > > > > Th elimitation of the NON-X version of MSPGCC is that only the lower 64K > of the address range are usable. The compiler does not know of the extended > memory range commands and the existence of flash beyonf > > 64K. > > It is possible, however, to store data above 64K (the linker handles data > explicitely put into FARTEXT segment) and access it with a hand-written > assembly function. If you have large amounts of data but access it not > > too often, this might be a way to use the additional flash. Maybe even as > a flash disk drive :) > > Also, you might place hand-written assembly functions (naked, no preample > and such) in FARTEXT, calling them with your own calling macro (which uses > CALLA opcode rather than CALL). > > But every code the compiler generates needs to be in lowe 64K (and even > with the 430X instructions, at least ISRs still need to be in lower 64K as > the interrupt vectors are only 16 bit) > > > > > > For the 32bit multiplication, it is sufficient to put a corrected > function in your own project code. This will have preference over the ones > in gcclib. You can even exchange the 64bit (software) multiplication > function, so it > > uses the (way faster) 32 bit hardware multiplyer. But then there is no > way to disable usage of the hardware multiplyer for 64 bit multiplication > (in ISRs or globally), as the compiler always assumes it software. > > The inline code for 16x16 multiplication is generated correctly by the > compiler. > > > > I have written some more explicit multiplication inline functions where > the result is twice the size of the arguments and the MPY is used with > highest effectiveness. > > Often you multiply two 16 bit values and need a 32 bit result. Using the > standard functions (with the * operator) this is always done by promoting > the 16 bit values to 32 bit and then do a 32x32 multiplication, > > discarding the upper 32 bit of the result (if you don't cast the 16 to 32 > bit first, the multiplication is done 16x16 bit with 16 bit result and then > extended to 32 bit!). > > Same for 32x32 to 64 bit. But the MPY already gives a 32 bit result for a > 16x16 multiplication, so It is a LOT faster, but must be used with a > function call rather than just using the * operator. > > Also, 32x32 bit is done by the compiler through a function call, while > the 16x16=32 and 32x32=64 functions are inline and subject to optimisation. > Another speed advantage. > > > > Note that these are partly limitations introduced by the C language spec > itself (result of a single arithmetic operation is always the same size as > its larger parameter). > > > > JMGross > > > > P.s.: you've alread found the central place for current limitations and > workarounds. :) > > > > And, well, since I'm not a compiler programmer (I did write one once, but > this was a lifetime ago), but need the 54xx processor and a working > compiler, yes, there are some parallel efforts. > > I for myself extend the header files and look for workarounds myself > while porting my hardware support library from 1232/1611 to 54xx, while > using the old but mostly working MSPGCC. > > As a plain windows user (at work) and being paid for working on our > projects rather than on MSPGCC itself, there's no choice. > > Others are working on the 4.0 branch and on the 430X extensions or the > gcclib for these brances. Actually, the 4.0 is listed as a separate > sourceforge project. > > > > > > ----- Ursprüngliche Nachricht ----- > > Von: Anthony Asterisk > > An: [email protected] > > Gesendet am: 25 Feb 2010 21:21:43 > > Betreff: Re: [Mspgcc-users] support for msp430F5437 > > > > I only have limited time for experimentation and possibly i can live > > with the 40KB limitation. To clarify would this limitation be 40KB*4 > > banks so 160KB total or actually only 40KB? > > > > > > Does the 02/18/2010 mspgcc4 release have all the patches you mentioned? > > > > It seems like the patches are > > * 430x/430x2 language extensions for increase flash size > > * header file fixes > > * 32-bit multiplication function uses wrong address for hardware > > multiplier > > > > Any central place I can look to understand the current limitations and > > workarounds? > > Are there multiple parallel efforts happening or is this all under the > > mspgcc4 (?) cvs? > > > > > > Switching to 5418/5419 is not an option since I already have hardware in > > hand.... > > > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Mspgcc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >
