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
