----- Ursprüngliche Nachricht ----- Von: Roman Lim Gesendet am: 02 Okt 2009 11:40:57
> i've been using mspgcc (MSP430X branch) for a X architecture >(msp430f2417) for about 5 month without noteworthy problems. my code >also uses the extended memory. From this point of view, there exists >support of X the architecture. Can't say anything about MSP430F54xx though.. Currently, I'm using the latest build (december 08) of the non-X-Version, as I don't have time or equipoment to make my own build from CVS. So I have to rely on the win32 distributions. The first few runs are promising. Of course neither compiler nor linker support the extended memory. if the programming tool supports the extended address range (the MSP toolchain does not, but it does not even recognize the 54xx processors at all), it should be possible to use it using separate segment definitions and adjusted linker data. At least placing of data arrays, together with assembly-written access functions for byte/word read, could be placed into the extended flash without need of any 430X support at all (the access functions can use direct word definitions of the required opcodes). My main concern was the interrupt handling, but this seems to work flawlessly. We don't need that much flash (yet), but we need the speed and the hardware of the 54xx processors. And currently chances are that everything works as expected. The only thing might be the use of the multiplication unit, as the 54xx do have a different one. So either I have to manually call my own (inline) function and disable the hardware multiplyer for the compiler completely, or i somehow have to replace it (if possible). It looks somewhat compatible on the 16bit site anyways, so perhaps a simple address change for the module location is sufficient. I haven't used any multiplication now, as yesterday was my first day with this processor. Dmitry Zuikov wrote: >> The main branch in general is also broken for 54XX: the wrong registers >> definitions in the headers (some guys here sent the patches, but they >> are not in CVS so far). Hardcoded and wrong MPY-s registers and I could >> not patch the libraries to produce correct code for multiplication. Indeed. With the old definitions from december 08, most of the modules have no macros defined at all. I wrote my own for the clock module, timers and the CRC and while my intended clock system startup code (which checks for quartz etc.) does not seem to work (I'll have to double-ckeck the register difinitions and the proper order of instructions), things look promising yet. See above for the MPY. Unfortunately, it is not easily possible to have more than one mspgcc installation in parallel. There are problems with the path settings and the include path for the DLLs and so on. I'm able to switch between installations but cannot use them parallel. >> Also, there is no point to blame the TI for poor support of open source >> community. There is no open source compiler with support of X and X2 >> architectures. Period. The opensource toolchain works perfectly for old >> plain MSP430 and that's all. >> [...] >> So the only serious issue with MSP430X and X2 for the moment is the >> compiler. The MSP toolchain already makes use of the TI libraries (even if there is no funclet support when not using the mspgcc lib). And with the TI libraries, it is no problem to access the USB FET as well as the LPT FET. I tried the libraries that come with CCE and IAR and at least with the IAR version of the libs I had some success accessing a 430F1611 device. It did not, for any case, identify the 5438. Neither with the LPT nor the USB programmer. The elprotronic software, however, uses the IAR libraries too and has no problem with the 5438 on both programmers. So for flashing alone, there is no need for better support by TI :) JMGross p.s.: the debugging part, as nice as it sometimes could be, is of no interest for me, since our projects have to deal with realtime events which are not under control of the debugger. So a debugger connection is useless for debugging. I'd need a (realtime) register, data- and addressbus logger and analyzer which could replay the code run later in slow motion :)
