Differences between "msp430.h" and "io430.h"?

this is from msp430.h:

/********************************************************************

*

* Standard register and bit definitions for the Texas Instruments

* MSP430 microcontroller.

*

* This file supports assembler and C development for

* MSP430x471x6 devices.

*

* Texas Instruments, Version 1.0

*

* Rev. 1.0, First Release

*

*

********************************************************************/

and this is from io430.h:

/********************************************************************

 *

 * Standard register and bit definitions for the Texas Instruments

 * MSP430 microcontroller.

 *

 * This file supports assembler and C/EC++ development for

 * MSP430x47x6 devices.

 *

 * Copyright (C) 1996-2009 IAR Systems AB.

 *

 * $Revision: 1.4

 ********************************************************************/

io430.h header provides structural access to SFRs. For example, instead of masking I can directly set or reset ports with P5OUT_bit.P5OUT_0 = 1; Or I can use if(P5IN_bit.P5IN_0 == 1) ..

I found io430.h is more readable, but I also faced some problem at compile time such as it says P5OUT_0 is not a member of structure when I try to use it. (not exactly for this register but for some others that I don’t remember now). Then I switched back to msp430.h.

I wonder there is anyone who has used io430.h for a complete project?

Regards,

BP.

BP,

What you said is part of the reason that I prefer msp430.h over io430.h

Those "structural access" to individual bits looks "more readable", but sometimes generate very bad and inefficient object code. (The object code has to use mask -- that is, BIT, BIS or BIC instructions.) I choose to use something reliable and efficient over something that just looks "more readable". But as I said, this is only my personal preference. Both io430.h and mos430.h are there. What you prefer is the always better one for you.

--OCY

Well, the includes are hierarchical.

On the mspgcc compiler, you usually include io.h.
Depending on the processor you selected in the project settings/makefile, io.h will include the proper MSP430Fxxx.h

This allows writing of somewhat generic sourcecode (provided the hardware you address in it is the same) without the need of changing the include when the processor changes.

Of course you can also directly include the proper MSP430Fxxx.h file.

On IAR or CCS, maybe this global file is called msp430.h instead.

Are there separate IO430fxxx.h files? Or rather: are there both types of files installed with your compiler? It would surprise me. if you mix compilers and their include paths, you may end up with both and probably none of them will actually work as expected. :)

old_cow_yellow said:

Those "structural access" to individual bits looks "more readable", but sometimes generate very bad and inefficient object code. (The object code has to use mask -- that is, BIT, BIS or BIC instructions.)

Do you have some specific examples?  IMO, a compiler OUGHT to be able to generate identical code for either "REG |= BIT6;" or "REG.BIT6 = 1;"  I thought that MOST modern compilers had reached the point where there were very few "this obvious construct produces really inefficient code compared to this other syntax that does the same thing" (except perhaps for certain pathological architectures where a compiler writer has specifically optimized one syntax.)

io430.h seems to be IAR-only ?  I don't see it anywhere in my ccs4 install...

That would seem to be a reason to prefer msp430.h to me.  Portability between different compilers is important.

westfw said:

Portability between different compilers is important.

This is very difficult.
Every compiler for the MSP has some things which are not or not easily portable.
Teh __delay_cycles() or __even_in_range() intrinsics ar enot available on mspgcc, the mspgcc has the excellent inline assembly support as well as the support for long long (64 bit) integers, the handling of interrupt funcitons is different (#pragma preprocessor commands on the IAR, __attribute__ function attributes on the mspgcc) and, and, and...

 plain C file is eaily compiled on all of them, but as soon as things are added which are somewhat outside the scope of the C language (such as dealing with status register bits such as GIE, defining interrupt functions etc.), there is not much portability. Even worse, things like the #pragma for interrupt functions cannot be made portable by defining proper header files, as preprocessor directives cannot be defined inside portability macros. They have to be placed into the source code directly.
And intrinsics are often impossible to port.

Hi BP,

I am trying to work out a simple example from Davis' book MCU basics.

The program titled timrled1.c flashes the LEDs with a frequency of roughly 1 Hz by polling free-running.

I understand the program as it is, but whenever I am trying to run it in CCS v4, the error is shown that the io430.h header is not known. After reading this post, I understand CCS does not have that header. I was wondering how would one rework the following code to fit in to msp header. The msp header recognizes everything but the structural reference. I tried to use the masking, but I get errors.

#include <io430x11x1.h>        // Specific device

// Pins for LEDs
#define    LED1    BIT3
#define    LED2    BIT4

void main (void)
{
    WDTCTL = WDTPW|WDTHOLD;                // Stop watchdog timer
    P2OUT = ~LED1;                        // Preload LED1 on, LED2 off
    P2DIR = LED1|LED2;                    // Set pins for LED1,2 to output
    TACTL = MC_2|ID_3|TASSEL_2|TACLR;    // Set up and start Timer A
// Continuous up mode, divide clock by 8, clock from SMCLK, clear timer
    for (;;) {                            // Loop forever
        while (TACTL_bit.TAIFG == 0) {    // Wait for overflow
        }                                //   doing nothing
        TACTL_bit.TAIFG = 0;            // Clear overflow flag
        P2OUT ^= LED1|LED2;                // Toggle LEDs
    }                                    // Back around infinite loop
}

        while ( (TACTL & TAIFG) == 0) {    // Wait for overflow
        }                                //   doing nothing
        TACTL &= ~TAIFG;            // Clear overflow flag

Hi OCY,

Thanks for the reply. I am a newbie on the MCU world. It has been barely 3 weeks. Could you explain the code you wrote so that I can get a general sense?

So, you changed the first instance with a mask and the AND operation (this is the bit operator, right?). I think I get that. But can you elaborate on the 2nd modification? It seems like you are resetting the Interrupt Flag (but negating it--so it was high initially?). Timers are really confusing to me. Hence, if you can direct me to a source, which is readable for a newbie, that will be awesome!

Thanks again,

UE

Also, does any know whether one can "import" the io430.h into Code Composer studio or if there is an equivalency chart to convert some codes written for the IAR to the CCS? Moreover, where can one download header files and add them to the current project? I wanted to add the header file to my current project and get around the coding issues, but was afraid whether calling both msp430.h and io430.h will cause some conflict.

Thanks,

UE

All the following statements mean the same thing.

TACTL &= ~TAIFG;

TACTL =  TACTL & ~TAIFG;

TACTL =  TACTL & ~0x0001;

TACTL =  TACTL & 0xFFFE;

It clears BIT-0 (TAIFG) and leaves all other bits unchanged.

Thanks for the clarification. It makes more sense now. By "Leaving all other bits unchanged", you mean setting them as high, right? This is because, ~0x0001 would entail 0x1110--this will set the rest high, but clear the first bit.

Hello Upol,

I realized that msp430.h and io430.h did not like each other. Some definitions use the same name.

However as you have full source code you might transit io430.h code to CCS. In my mind it makes no sense as msp430.h contains all of io430.h (and has more features).

One thing you should not forget in CCS (different to IAR): you need to define MCU type by hand e.g. __MSP340F2274__, prefereable in the project build properties:

I'm transit from io430.h to msp430.h some years ago and didn't regret.

Regards

Guenther

Upol Ehs said:

.... By "Leaving all other bits unchanged", you mean setting them as high, right? ...

No. What I meant was:

(a) If any of those other bits was a "1" before that statement is executed, it will still be "1" after that statement is executed.

(b) If any of those other bits was a "0" before that statement is executed, it will still be "0" after that statement is executed.

This is the nature of the "&" operator. It is a "bit by bit AND operation"

Hi OCY,

Thanks for keeping up with my questions.

Oh I see. I guess I am a little confused now. I do not understand HEX pretty well so I will try a 8bit binary sequence.

BIT0= 0b00000001

~BIT0= 0b11111110

Does negating it flip all the other ones? OR did I understand it wrong? If my given scenario is the case, then how can negating the TAIF still leave the 0's as 0's and 1's as 1's?

Hello Guenther,

Thanks for stopping by. I am trying to stick to the msp430x11x1.h as much as I can, but sometimes I feel the io430.h has some user-friendly features like the individual bit accessibility w/o masking.

When you transitioned to msp430.h, how did you adjust to such changes. I am new to both C++ and CCS. Hence, it has been difficult for me to translate the syntax back and forth between the two programs.

Thanks

UE

Hello Guenther,

Thanks for stopping by. I am trying to stick to the msp430x11x1.h as much as I can, but sometimes I feel the io430.h has some user-friendly features like the individual bit accessibility w/o masking.

When you transitioned to msp430.h, how did you adjust to such changes. I am new to both C++ and CCS. Hence, it has been difficult for me to translate the syntax back and forth between the two programs.

Thanks

UE

Hi Upol,

Yes, I adjusted my code a little bit. Using the bit structure is nice on single bit operation but creates overhead if you like to set multiple bits. It is even dangerous as the setting is split in multiple code lines as an interrupt may happen in between.

Here some examples ( I hope I can do it as good as yellow cow ;-):

io430.h: TACTL_bit.TAIFG = 0;

msp430.h: TACTL &= ~TAIFG

Both lines clear TAIFG bit only.

If you need to do multiple bits then:

io430.h:

  P1DIR_bit.p4 = 1;

  P1DIR_bit.p5 = 1;

msp430.h

  P1DIR |= (BIT4 + BIT5);

If you look on the disassembled code then the difference is even more obvious.

An easy guide is:

Clear:

port &= ~(BITx + BITy + ...)

Set:

port |= (BITx + BITy + ...)

Toggle:

port ^= (BITx + BITy + ...)

Query:

if(port & BITx) ...

Regards

Guenther

Upol Ehs said:

io430.h has some user-friendly features like the individual bit accessibility w/o masking

Upol Ehs said:

BIT0= 0b00000001
~BIT0= 0b11111110
Does negating it flip all the other ones?

What you missed with the operation above was that there was an AND operation included.

And AND keeps all bits set which are set in both parameters, and clear all bits which are clear in at least one of the two parameters. So & is used to clear bits. The inversion (it is not a negation, a negation is !x, which refers to the whole byte/word value and is either 0 or != 0) is required, as you need the bits set in the second parameter which shall stay unchanged in the first, and need the bits clear in teh second parameter which shall be cleared in the first (where 'first' and 'second' are exchangeable).

That's the inversion of an OR operation ("|"), which sets (or keeps set) all bits which are set in one of the two and keeps clear which wasn't set in any of the two.

See the logic table (for one bit, as the binary operations are bit by bit):

X & 0 = 0 (AND operation)
X & 1 = X
X | 0 = X (OR operation)
X | 1 = 1
X ^ 0 = X
X ^ 1 = 1-X (eXclusive OR operation = inversion)
~x == x ^ 1

Hi Guenther,

Thanks a lot for the table. If you don't mind, I will copy and print out this format.

UE

Upol Ehs said:

If you don't mind, I will copy and print out this format.

Basically, it hasn't changed since the days of the very first TTL logic chips and can be found in any TTL book. However, it might prove difficult to find a TTL book today. :)

Hi Upol,
You're welcome to do so. As Jens-Michael already said, old TTL stuff but always useful.
Regards
Guenther

Good