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
