Defining pins

It would be nice if there were acessor get/set macros or something like that for each of the I/O functions, though I suppose to do that right you'd end up with Verilog/VHDL/Arduino/Wiring instead of C.

You could just make some preprocessor macros as follows:

#define SetRA3 P1OUT &= ~Bit3

#define GetRA3 P1IN & Bit3 >> 3

#define SetPort1(bit) P1OUT &= 1<<bit

#define BIS_Port1(BitMask) P1OUT |= BitMask

#define BIC_Port1(BitMask) P1OUT ^= ~BitMask

it just depends on if you can read the output register so the read/modify/write type of logical OR/XOR/AND operations can work, and what level of efficiency you want from the code, and so on.

If preprocessor macros don't do enough for you, you can make some inline/intrinsic functions that should get rid of a lot of the function call/entry/exit overhead for trivial operations.

It is not impossible to use inline assembly in conjunction with preprocessor directives or inline functions to improve efficiency still further if needed.

If that's not clean enough for you, then the right choice is probably not C but some kind of HDL or OOP or CASE tool that lets you deal with ports / pins / peripherals in a more object oriented fashion while preserving semantics of things like read only / write only / read-write / constant / compile-time settings vs dynamic ones etc. etc.

Part of the problem with having an "easy way" to make things like one's own headers relating to a chip's peripherals / pins is the unfortunate fact that the data sheets and peripheral documents are made as PDF files and aren't actually derived from the actual hardware design specifications themselves, so you have no machine readable reference information on what the ports / pins / registers actually are and what they do other than what someone bothers to write up as a header file.   In a better world the "header files" would actually be derived directly from the chip design HDL files themselves so that software CASE / debugger tools can take advantage of all the naming and functional data directly.  As it is we'll just have to keep reinventing the wheel making header files and function calls / methods and so on manually based  on the chip documentation until they make a more integrated hardware / software / specification development / debug / test system for things like common microcontrollers.

Hi C. Hayes,

please note, the CCE v3.1 compiler defaults to --opt_level=2 if not specified.  You need to switch to --opt_level=3 to generate the efficient assembly (to reuslt i.e. in BIS.B/BIC.B assembly instruction). 

This can be adjusted by Project->Properties->C/C++ Build->Tool Settings->MSP430 Compiler v3.1->Optimizations.

Rgds
aBUGSworstnightmare

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hi try to check

#include "io430.h"  //or device specific

#include "intrinsics.h"

and also check this out attached file1423.Defining Individual Pins.doc

It is genreally defined using Bit Fileds using STructs and Unions and

At least in principle, TI could have written header file which collects macros for all the Application Notes. Call this slac_x.h and keep it updated whenever a new APN is published.

Users only need to do

#include slac_x.h

void main(void)

{

do_slac_123();  // or do_slac_789(); etc.

}