Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » MSPGCC
  • » [Mspgcc-users] Notice of elimination of genericized mcu names in uniarch [RSS Feed]

#1 Dec. 21, 2010 23:28:02

Peter B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] Notice of elimination of genericized mcu names in uniarch


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
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mspgcc-users

Offline

#2 Dec. 22, 2010 01:03:52

Chris L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] Notice of elimination of genericized mcu names in uniarch


Am 22.12.2010 00:25, schrieb Peter Bigot:
> -mmcu=msp430xgeneric, and only build relocatable object files (not
> applications)

hardware multiplier support will be switched with different command line
options?

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

this sounds like a simple header file that maps (#defines) the
MSP430X1121 to MSP430F1121 etc would suffice to get backwards compatibility.

this would of course only make sense when this backwards compatibility
would be automatically handled by io.h. if the users sources need to be
touched to insert an other include, it's also easy to change the -mmcu
option in the makefile. however it would be nice to have a solution that
is compatible among several compiler versions.

maybe you do not have to do this all by yourself and someone else can
provide such helper files.

chris


Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mspgcc-users

Offline

  • Root
  • » MSPGCC
  • » [Mspgcc-users] Notice of elimination of genericized mcu names in uniarch [RSS Feed]

Board footer

Moderator control

Enjoy the 16th of August
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support