1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Devel:Uniarch

From mspgcc

Revision as of 22:40, 22 March 2011 by Pabigot (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Unifying MSP430 MCU Architectures

The MSP430 product line contains hundreds of microcontrollers with a wide variety of features and characteristics that affect both the code they can run and the layout of that code in memory. Historically the MSP430 toolchain support in binutils, gcc, and gdb has hard-coded these characteristics in the source code. In the earlier days of MSP430 new chips were introduced rarely enough that this was not a significant maintenance burden; currently new chips are introduced every couple months, resulting in significant overhead to update each package and keep them in sync.

Details

The Uniarch initiative replaces the hard-coded MCU names with more primitive options:

  • cpu indicates the MCU's central processor architecture and is one of:
    • 430 the original 16-bit architecture
    • 430x the CPUX architecture which adds new instructions and support for 20-bit addresses
    • 430xv2 an improved CPUX implementation which has no new features but changes the instruction timing
  • mpy indicates the MCU's hardware multiplier support and is one of:
    • none indicating that no hardware multiplier is available
    • 16 indicating that a basic 16-bit hardware multiplier is available
    • 16se indicating that a 16-bit hardware multiplier with automatic sign extension is available
    • 32 indicating that a 32-bit hardware multiplier is available
    • 32dw indicating that a 32-bit hardware multiplier with delayed write support is available
  • ivcnt indicates the number of interrupt vectors supported and is one of 16, 32, or 64

The GNU Compiler Collection specs feature is used to take mcu options provided by the developer on the gcc command line and translate them to the appropriate combination of cpu, mpy, and ivcnt for the identified microcontroller. It provides the necessary flags to the compiler, assembler, and linker.

Because, the mcu option is translated only by the gcc driver, direct invocations of the assembler or linker no longer recognize it, and the base options of cpu, mpy, and ivcnt must be provided to ensure correct behavior.

msp430mcu

To make it easier to support new chips, all chip-specific information will be collected into a new package, msp430mcu, which will provide the following components:

  • MCU-specific headers, provided by Texas Instruments, that identify the available peripherals and constants relevant to a specific MCU
  • A generic msp430.h header which includes the MCU-specific header based on a standard preprocessor symbol derived from the compiler mcu option.
  • Linker scripts defining the appropriate offsets and sizes of ROM, RAM, interrupt vector, information memory, and other memory regions

Changes in Distribution

For a couple years, stalled development in the mspgcc project led to a forked port of MSP430 support to the 4.x version of GCC, and was distributed under the mspgcc4 project. The mspgcc4 project was funded and driven by the needs of the Wirelessly Accessible Sensor Populations project.

The mspgcc4 distribution includes a buildgcc.pl script which automatically downloads the upstream distributions, applies the MSP430 patches, and builds a complete system. While this is convenient for individual users, it significantly increases the workload for maintainers of the mspgcc infrastructure. With the termination of the WASP project and return of MSP430 toolchain development to the mspgcc project, specialized build scripts are no longer provided. Instead, complete patches relative to upstream distributions will be packaged together. The expectation is that downstream packagers will convert those patches into pre-built binaries (e.g. RPM or DEB format) appropriate to a specific distribution.

User Visible Changes

binutils

  • The -mmcu option is present for legacy reasons but has no effect on msp430-as or other tools. Use the -mcpu and -mmpy options.
  • Base binutils does not include the memory maps and peripheral address maps that are required to link applications into non-relocatable executables. You need the msp430mcu package for that.

gcc

  • The __MSPGCC__ preprocessor symbol is defined to a monotonically increasing integer reflecting a release. Use definition of this as an indication that you're using the uniarch variant of mspgcc, if you need to support old and new compilers in the same source.
  • The -mmcu option is recognized, but is translated into appropriate -mmcu, -mmpy, and -mivcnt options as described above in the Details section.
  • All startup code formerly in msp430-libc is now integrated into gcc. The multilibs are configured to support all cpu and mpy combinations.
  • All peripheral references including to MPY and the watchdog timer are left as symbolic until the final link phase.
  • Built-ins are provided for all operations that were formerly done using asm statements in msp430-libc headers.

msp430-libc

  • MCU-specific headers are now in the separate msp430mcu package. Include <msp430.h> if you don't choose to include the exact header required by your chip. <io.h> is deprecated.
  • There is no need to include <signal.h> unless you really want to confuse people by hiding how things are done.
Personal tools