Certainly you'll need an updated header. It may also be necessary to update binutils and gcc; the 430x41x2 chips are not currently recognized as different from the 430x41x chips, and I haven't looked into the issue enough to estimate whether it's trivial or messy to fix this. You might be able to get away with just lying to the compiler, but that's not a good habit to get into.
(Unrelated comment: For the last six months or so, I've been updating binutils, mspgcc, and msp430-libc to support new chips. I'm happy to keep doing this, but is there anybody out there from the group that did all the original work to get msp430 supported in open software that wants to be involved? Please let me know.) The header isn't a big issue: TI has graciously provided me with draft mspgcc-compatible headers generated from their internal chip databases, with an implied promise to feed me new ones as they update their product line and fix header bugs. The only hold-up on making it official is their need to nail down the text of the BSD-style license they want applied to the files. This would allow mspgcc to use exactly the same names, preprocessor directives, etc as both Code Composer and IAR's compiler, and remove much of the burden on the msp430-libc maintainer(s) of trying to transcribe stuff from 40+ datasheets. Source-level portability between compilers: what a concept. The gotcha is that the header file organization is very different, since they generate complete headers for each chip rather than try to pick relevant pieces from a common functional module header as msp430-libc currently does. I've also dragged my feet on integrating this because I know it'll break older code: the headers won't have the lower-case __msp430_have_* symbols, and they definitely won't have any of the structure definitions to overlay UART registers and the like. What I plan to do is add a build-time option to msp430-libc to select either the legacy or TI-provided headers. My initial tests indicate this has promise. Sounds like you could be a candidate to help test this new configuration. If so, and especially if you're comfortable building binutils, gcc, and msp430-libc individually and manually as patches are applied, please add a tracker ticket on the mspgcc4 project to add this support, including information on any time constraints you're working under (msp430 toolchain support isn't officially among my primary tasks). If anybody else has an interest in testing TI-provided headers with MSP430 software and gcc, please let me know. (BTW: The draft TI headers I have include USB support on the 55xx.) Peter 2010/7/2 Asser Lähdemäki <likapyykkiavuodest...@hotmail.com> > > Hello everyone, > > I'm involved in a project in which I intend to use msp430F4152. However, it > seems that mspgcc currently does not support the msp430F41x2 devices though > it supports msp430F4xx devices.. I was thinking that msp430F415 and > msp430F4152 are not too much different( I need 2 USCIs, that's why > msp430F415 won't do), I could probably write the header file even myself. > > But what about debugging, would it work? And is there something else to it > except the header file? > > PS. Will there be support for the 55xx series with USB peripheral module in > future? > > _________________________________________________________________ > Uudessa IE8 selaimessa on uudet pikatoiminnot. > > http://www.microsoft.com/finland/windows/products/winfamily/ie/beta/default.mspx > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > >
