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....
