Including wrong header files

I can't help you with the CCS specific portion (sounds like a project option issue), but wanted to comment that you should be using #include <msp430.h> instead. This header picks up the correct device specific header for you automatically, and allows greater portability of code between family members.

Brian Boorman said:

I guess CCS is a "broken" tool

Not that negative about CCS, TI guys did a lot of good work!

It would change automatically if he did it on the right way, but as you can read above he just changes the header files name. If he select the proper device the symbol will change to. That I’m not mending this is, I want to put his nose directly on the (big) meaning of the predefined symbols in the hope he learned something.

Brian Boorman said:

using #include <msp430.h> instead

This has pros and cons.

It removes the context information for the following code. If the code is pasted without the project settings then, nobody knows anymore for which MSP the code was written. This is the source of many "I'm using this demo code but keep getting compiler errors" posts in this forum.

Also, the automatism of picking the right header file, besides picking a header file the code wasn't written for, has another problem: the linker file is also specific for the target MSP, and the IDE cannot simply replace it on a target change, in case it had been tailored for the project.

The whole mechanism lacks some consistency checking, like a linker error "the linker script doesn't match the selected target". But it has to be incomplete still, as the linker doesn't know which headers the compiler used. This is getting worse if you use libraries.

It's a result of the IDE being just a supervisor of independent commandline tools.

Jens-Michael Gross said:

This is the source of many "I'm using this demo code but keep getting compiler errors" posts in this forum.

#include <msp430.h> is not the source of the compiler errors! The source is mindless mixing parts of code ho’s written for device X with code for device Y and not having the knowledge realizing they are different. They should more reading data sheets instead posting. All TI example source files each, are good documented and describes for which device the code is written.

Jens-Michael Gross said:

the automatism of picking the right header file

As I already wrote here it’s not a magic automatism. msp430.h contains just a list of all possible header files; based on the predefined symbol it points to the right header file, on this way all source files have only one and the same header file name and the correct device name is centralized defined at only one place in your project build configuration.

Jens-Michael Gross said:

the linker file is also specific for the target MSP, and the IDE cannot simply replace it on a target change

Using this centralized way you can have multiple linker command files for multiple devices, all well pointed and selected by the Build configuration.

Jens-Michael Gross said:

This is getting worse if you use libraries

Opposite! Library files created on this same way are flexible in device using, one library file can contain code for multiple dives, the final project settings where the library is included defines which code is used.

Only for people not using structuralized projects should point to the specific device header file and copies all the project files multiple times for each different device and need to keep all source files synchronized when changes are made.

Leo, I see your point. And in an ideal world, I would agree.

However, in real world, source code is posted and used by those who do not know the inner mechanics of the IDE.

And seeing code in which nothing refers to the actual target is code that leads inexperienced people into trouble without them knowing why.

Using a direct include of the proper header file at least give a hint for which MSP the code was written. If someone uses this code unchanged and compiles it for a different target, it won't work. And when he then changes the header and gets compiler errors, he could figure out on his own what happens: that this code is not intended to work for his target.

If there is an 'auto selection', you will use code that is posted as working, hasn't been touched by you, and fails with compiler errors. And you have no clue why this happens.

As I already wrote here it’s not a magic automatism.

One could make this method bullet-proof by triggering compiler warnings when the code uses symbols that aren't supported by the currently selected device, but this would be a huge task.

something like this:

#ifdef HAS_USCIA1

sfrb(UCA1TXBUF, 0xXXXX)

#else

#define UCA1TXBUF USCIA1_NOT_AVAILABLE_ON_TARGET_MSP

#endif

This would give an 'unknown symbol USCIA1_NOT_AVAILABLE_ON_TARGET_MSP' compiler error.

Library files created on this same way are flexible in device using

And even if you get a source code collection, chances are that the creator didn't include any mechanics to prevent use in a project for a not supported target.

And even if, this mechanism may fail, since you don't know in which IDE the code will be used - as those predefined symbols are toolchain-specific, and even using these symbols for a fault-proof mechanism will break compilation on a different toolchain, while without this mechanism, it would compile and work fine.

As I said, it is not a perfect world.