MSP430 C Coding Techniques Across Different Target Hardware

Michael Choi said:

1) The portability of C code across different hardware targets.

It's doable, but you shall write "hardware abstraction layer" (HAL) for board, CPU and it's peripherals so when using other CPU or board you leave "business logic" unchanged, but change just HAL code.

Dear Ilmars;

     Thank you for your reply. 

      My apologies for the delay in writing a response to you.  I waited 3 business days for a reply by a TI engineer.  Unfortunately, I have read no reply. 

     I appreciate your thoughts on how to approach the portability issue. 

     I have read TI "migration" literature, however, it did not meet my needs. 

     With regard to my other question concerning pushbutton IO and CC5 updating .   I have found that you can follow the "form" of code written for the  MSP430 line found in literature.  However, the MSP430G2553 development board has a particular configuration that renders the program that  I uploaded inadequate for a "real world" application.  

     To answer my question:  Does an analogous program exist? The answer is, yes.  However, the program is not as simple as one would expect.

      Did I find the CC5 IDE able to update my button presses without using interrupts?  The answer is either no, or, not reliably (Note:  my particular computer system may be inadequate to perform this operation, therefore, my computer system is the source of the inadequacy).

      There may exist a better way to code this particular type of program for instant updating (most likely, using interrupts).  A TI engineer with years of experience would be better able to answer this question.   I just opened up the kit less than 30 days ago and I am just learning how to use these processors.

      Again, Ilmars, I would like to thank you for your reply.

Michael Choi said:

However, the MSP430G2553 development board has a particular configuration that renders the program that  I uploaded inadequate for a "real world" application.

Well.. Software examples/snippets are rarely adequate for real world applications. Their purpose: to show some function of MCU most efficient way without any irrelevant to particular example, code. You shall create production-ready code yourself.

Michael Choi said:

I just opened up the kit less than 30 days ago and I am just learning how to use these processors.

And after just 30 days you are thinking about applications that are portable between various types of devices? Why?

You might not like my answers.

First of all, why do they make different hardware? I think the answer is, different hardware are designed to do different kinds of jobs. Do you want to write a software designed to do all the different kinds jobs? Or, is it designed simply to do a certain specific kind of job? If it is for the former, you are a brave man! If it is for the latter, do you want to run it on a hardware that is not designed to do that kind of job? Why?

In one extreme, you can limit the software to utilize only the common features of all the different hardware. That is to say, even though the hardware are different, the differences between them are not utilized in your software. Your example falls into this category. You need very little memory, you do no care about timing (as long as it is within human reaction time), and you only need two GPIO pins, one for input and one for output. These features are in all different MSP430 chips. You do not need to do anything to make your code portable,

In another extreme, you can go the extra mile to make all the different hardware to emulate a single common virtual hardware. And you write software for that verbal hardware. In this way, the hardware can be different, but you make them emulate the same virtual hardware so that for software, they are not different. I think what llmars suggested is similar to this extreme.

Of course, there are lots of room between the above two extremes.

Michael:

Here is a related post:

http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/353439.aspx

Dear Ilmars;

     Thank you again for your reply. 

     To answer your question:

And after just 30 days you are thinking about applications that are portable between various types of devices? Why?

     I bought the TI products to "sample" TI's product line.     I purchase products if I can believe I can "grow" with them.  I don't believe in "re-making" the wheel every time I purchase a new target.    Again, this was just a sample purchase to see if I want to "grow" with TI's offerings. 

     I am still deciding.   TI offers a lot of advantages.  There is a lot I like about TI.   

Michael Choi said:

I can "grow" with them.  I don't believe in "re-making" the wheel every time I purchase a new target.

Please define "new target" then.

Simple considerations: to run same code on different microcontrollers, they shall be the same, literally. If one msp430 have 10-bit ADC without DMA support and another have 12-bit ADC with DMA, then there's no way same code will be good for both. Such way I can continue virtually about every peripheral. Why simply don't put most advanced peripherals into every msp430? - Simple. They all will have lot of logic elements, bigger die, so they all will be expensive, bigger physically and consume more power.

So what you have here: different kind/series of msp430 having similar CPU core with different memory, peripheral and I/O options. Also common rules of using CPU and peripherals. Obviously - you can reuse lot of code, but not always. Especially if you want to "jump" between series like from msp430x2xx to msp430x5xx. That's why I mentioned HAL which is quite common approach of designing firmware which could need another hardware in the future.

Did you study brochure ?

Dear Old;

     Thank you for your reply. 

     When you wrote: 

" you only need two GPIO pins, one for input and one for output. These features are in all different MSP430 chips. You do not need to do anything to make your code portable "

     If this statement were true:

 "You do not need to do anything to make your code portable "

    Then the program I uploaded should have worked on my development board.   This did not turn out to be the case for a variety of reasons.  

     I realize that I may be taking your statements too literally (I probably am), my apologies.    You have to understand that books are sold that reference MSP430 programming, however, it would appear that their utility is limited.   The average individual, who is not employed by TI, is not aware of TI's entire MSP430 product line and is, therefore, under the impression that the MSP430 product line is somewhat similar when first introduced to TI's offering.   

     I am at the point of evaluating the similarities and this was the reason why I had created this post.   I just wanted a little insight on how to best approach this product line.

     To answer your second question, I am not a person who is going to any extremes.   I find emulation to be a nice feature but I spend as little time as possible in the "high level" programming world, if possible.   I just see if my program works and I see how easily I can "port" the program to another target.   I tend to see if what I want done actually "works" first.  I have read in some rare cases (these were not TI products) that an "emulation" had failed to deliver.   Seeing is believing.

Michael Choi said:

how easily I can "port" the program to another target.

There is single User's guide for all x5xx series microcontrollers, the same for other series. So in case of x5xx series you can change between 186 different chips (targets) without changing your source code much.

Dear Mr. Anderson;

     Thank you very much for pointing me to the links.  

     I appreciate your efforts very much.   A link is definitely worth a thousand words.  

     Thank you, again!!! 

Writing code that runs on multiple targets isn’t easy.
Due to the different hardware (after all, they are different targets), it is impossible to make all code portable. Unless you write code that doesn’t use any hardware at all.
On bigger systems, you have an OS with libraries that provide an API for specific operations, hiding the real hardware form the application.
The widest used one is the BIOS of a PC: it allows an OS to boot from HD or CD or USB and output text to screen without knowing what storage or display is there.
The biggest one is probably DirectX, as it provides graphics access and advanced 3D features without the application needing to know about the hardware.

On a micro, you don’t have all that.

So you can only try to make your code partly portable. A HAL is a good start. You need to write an instance of your HAL for each target from scratch. But all other code will only call the HAL functions and not care for the target it is running on.
However, you’ll quickly get into trouble if you need functionality that isn’t available on a target. Then the HAL needs to simulate it in software or whatever. Even though the application could do the job in a different (maybe less efficient) way without needing the feature at all.
In general, a HAL isn’t very efficient. Setting a port pin can be done using a HAL function, which takes a hundred CPU cycles to execute, or with a direct instruction that takes only a few cycles.

 Personally, I use a mixed approach. E.g. RS232.C and RS485.C both use UART.C to provide functions like putch/getch. They are used on multiple targets with the same code. UART.C contains code that is conditionally compiled where necessary, to match the 1X family USART, the 5x family USCI or the UART of the ATMega, depending on project settings.

This is pretty much a HAL approach. However, the mid-level code uses these functions as well as (again conditionally compiled) different algorithms or such, depending on the available features of the targets (e.g. the ATMega has 32k ram and can do things differently than the MSP430F1232)

It usually makes no sense porting high-level functions (the application itself), but maybe parts of it (like an RS485 communication protocol driver) can be used on both, and if written in a portable way, chances of a bug are reduced when adding a new device to a network (provided that the low-level functions are working).

This mixture has proven to be quite efficient as well as fast to implement, as it doesn’t require the effort of a 100% hardware abstraction while making porting much easier than having to do a rewrite from scratch.

Jens-Michael Gross said:

In general, a HAL isn’t very efficient. Setting a port pin can be done using a HAL function, which takes a hundred CPU cycles to execute, or with a direct instruction that takes only a few cycles.

Completely agree that mixed HAL approach is the way to go. If you see that existing HAL (library) for some reason does not fit code footprint or performance requirements, you just performance- or code_size- optimize your HAL by selectively rewriting parts of it. After all HAL is not necessarily precompiled library, critical parts of it can be macro definitions which results in efficient code w/o function call overhead.

Look at source code of many small-footprint RTOS, how they are solving problem we are talking about. Salvo for instance.