I have been using -mmcu=msp430x2618 if I understand correctly this will not be supported in the future and I will have to use -mmcu=msp430f2618 which does not work with the version that I have. what I would like to be able to do is to write code and makefiles that will work for all compilers provided the chip is supported. for example to support both the TI headers and the legacy headers all one must do is only use the standard TI defines because these are part of the legacy headers. Jesse
On Thu, Dec 23, 2010 at 5:47 AM, Peter Bigot <p...@peoplepowerco.com> wrote: > That is certainly a good goal and I'd like it to be reachable, but whether > it can be done depends on how many assumptions you want to make, which > devices you're targeting, and how you've been invoking the compiler. > > You might think of there being four existing versions of MSP430 support for > gcc: mspgcc (3.2.3-based), mspgcc with MSP430X enhancements (3.2.3-based), > and mspgcc4 (4.x-based) with either legacy and TI header files. Each > supports a slightly different subset of the product line, and there are > small changes to the supported arguments (and much larger changes in the > headers if you go to the TI-based stuff.) None of them correctly recognizes > all the variation points in the current MSP430 product line, though what's > there works for most chips that were introduced more than two or three years > ago. > > uniarch should bring this back to one compiler that supports all 270+ chips > with a preference to conforming to the vendor-defined APIs. I certainly > want to limit the pain that will inevitably result, but can't promise to > succeed completely. > > What was the "old way" that no longer worked for you with mspgcc4, and how > did you make it work (if you have)? > > Peter > > On Wed, Dec 22, 2010 at 6:23 PM, Jesse Frey <jmf...@alaska.edu> wrote: >> >> Is it possible to use the same command line to compile code with the >> current mspgcc and the future mspgcc. I just tried to make my >> makefiles compatible with the new way things are and found that it >> would not compile? it wold be nice if the same code and commandline >> would work for both versions. >> Jesse >> >> On Tue, Dec 21, 2010 at 2:25 PM, Peter Bigot <p...@peoplepowerco.com> >> wrote: >> > Traditionally, mspgcc has accepted genericized MCU part numbers, with an >> > "x" >> > substituted for the section of the part that denotes the chip memory >> > type. >> > E.g. -mmcu=msp430x1611 for the MSP430F1611. See the breakdown of how >> > MSP430 >> > part numbers are >> > >> > constructed.<http://mspgcc4.git.sourceforge.net/git/gitweb.cgi?p=mspgcc4/msp430-libc;a=blob;f=pn-decode.txt;h=bee4afbd76934f88371971f8d89c55081fea0f9f;hb=ti> >> > >> > Of the 270 distinct MSP430 MCUs in the latest list provided to me, 98 >> > cannot >> > be genericized in this way because the genericization is ambiguous. For >> > example, the MSP430F2131 and MSP430G2131 differ in RAM and ROM size and >> > offsets. The MSP430F423 has hardware multiply support, while the >> > MSP430FE423 and MSP430F423A do not. The MSP430F1111 has information >> > sections, while the MSP430C1111 does not. >> > >> > TI provides 61 legacy header files which can be shared for multiple >> > chips. >> > For example, the msp430x16x.h would work for MSP430F1610 MSP430F1611 >> > MSP430F1612 MSP430F167 MSP430F168 and MSP430F169--however, those chips >> > still >> > have different address maps, so a generic msp430x16x fails to provide >> > enough >> > information to allow an application to be linked. >> > >> > Attempting to detect when it is safe to recognize a generic name, and >> > what >> > prototypical MCU to map it to, is the road to insanity. TI advises that >> > new >> > projects should not use the legacy headers. >> > >> > Here's the point: The uniarch updates to mspgcc will no longer support >> > genericized mcu names. >> > >> > Under the current plan, you will have your choice: >> > >> > - Specify a recognized part, e.g. -mmcu=msp430f1611 >> > - Specify one of two special-case generic parts, -mmcu=msp430generic >> > or >> > -mmcu=msp430xgeneric, and only build relocatable object files (not >> > applications) >> > - Skip the -mmcu option, get whatever happens by default, and don't >> > attempt to reference device registers or constants >> > >> > Whatever you put as the -mmcu parameter to gcc will automatically be >> > defined >> > as a preprocessor macro, after conversion to upper case and >> > encapsulation in >> > double-underscores: e.g., using -mmcu=msp430f1611 will cause >> > __MSP430F1611__ >> > to be defined and available for conditional processing. >> > >> > Consequently, certain defines like __MSP430_1611__ which are really >> > alternative spellings of the genericized name will no longer be >> > automatically provided by the compiler. You can, of course, add them >> > yourself. >> > >> > Sorry, this is going to break some code. It'll probably be possible to >> > work >> > around this with a legacy.h header that does some magic, but I won't get >> > to >> > that in the initial releases, and will prioritize it below things like >> > integrating 20-bit pointer support and improving other optimizations >> > unless >> > I hear a lot of really really loud objections. >> > >> > Peter >> > >> > >> > ------------------------------------------------------------------------------ >> > Forrester recently released a report on the Return on Investment (ROI) >> > of >> > Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even >> > within 7 months. Over 3 million businesses have gone Google with Google >> > Apps: >> > an online email calendar, and document program that's accessible from >> > your >> > browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew >> > _______________________________________________ >> > Mspgcc-users mailing list >> > Mspgcc-users@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> > >> > > > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
