DrivelLib assert()

assert is a macro, defined in assert.h. If the expression is false, it will print an error message on stderr and then call abort to end the program.

If the symbol NDEBUG is defined, the assert macro won't be compiled.

I don't know how it is implemented on an MSP which doesn't have stderr and where you cannot return to the OS through abort().

Really need help on this, what does assert do on MSP430?

Silver Diamond said:

what does assert do on MSP430?

It has nothing specifically to do with the MSP430.

As JMG said, assert() is a macro; so it does whatever the macro is defined to do - possibly nothing at all.

It is a standard programming technique:

http://www.cplusplus.com/reference/cassert/assert/

As JMG also said, a microcontroller (eg, MSP430) system often has no operating system - so no stderr and no abort(). So, again, you have to look at the macro definition to see what is defined in your particular case...

Andy Neil said:

As JMG also said, a microcontroller (eg, MSP430) system often has no operating system - so no stderr and no abort(). So, again, you have to look at the macro definition to see what is defined in your particular case...

Once approach is simply to make the processor "hang" in an infinite loop - you can then inspect the system using the debugger.

Or you might have a handler to record some status somewhere in memory; turn on some fault indicator or display; etc, etc,...

http://www.embedded.com/electronics-blogs/break-points/4416078/Asserting-Failure

http://www.embedded.com/electronics-blogs/other/4023329/Assert-Yourself

I do understand what assert is, but what is the purpose of it in the driverLib code?  Are there other functions in debug mode that can use the assert output?  Is there any document that can help me to understand how I can use it specifically in MSP430?

It would make more sense for the driverlib asserts to call a simple function which spun in a infinite loop where a break point could be set (as is done in TivaWare

The mechanism is already in place.  It's just a matter extracting the RTS lib, adding exit.c and placing the breakpoint or any other indicator of one's choosing.

/****************************************************************************/
/* ABORT - ABNORMAL PROGRAM TERMINATION.  CURRENTLY JUST HALTS EXECUTION.   */
/****************************************************************************/
void abort(void)
{
   /*-------------------------------------------------------------------*/
   /* SET C$$EXIT LABEL SO THE DEBUGGER KNOWS WHEN THE C++ PROGRAM HAS  */
   /* COMPLETED.  THIS CAN BE REMOVED IF THE DEBUGGER IS NOT USED.      */
   /*-------------------------------------------------------------------*/
   __asm("        .global C$$EXIT");
   __asm("C$$EXIT: nop");

   for (;;);   /* SPINS FOREVER */
}

Another option is redirecting to your own abort function

#ifdef MYABORT
     #define abort() modAbort()
#endif

void modAbort(void);

int main(void) {

// Magic stuff goes here

}

void modAbort(){

	for(;;){

// Magic stuff can go here also

  }
}

Michael S said:

The mechanism is already in place.  It's just a matter extracting the RTS lib, adding exit.c and placing the breakpoint or any other indicator of one's choosing.

However, i think the following from the RTS assert.h:

     #define assert(_expr)   _NAMESPACE_PREFIX _assert((_expr) != 0,      \
                    "Assertion failed, (" _STR(_expr) "), file " __FILE__ \
                    ", line " _STR(__LINE__) "\n")

And assert.c:

/****************************************************************************/
/* _ASSERT() - Implements the assert macro. Checks the argument. Aborts     */
/*             with a message if not true.                                  */
/****************************************************************************/
_CODE_ACCESS void _assert(int expr, const char *string)
{
    if (!expr) _abort_msg(string);
}

/****************************************************************************/
/* _ABORT_MSG() - Write out a string and never return.  Abort function for  */
/*                false assertions.                                         */
/****************************************************************************/
#pragma FUNC_EXT_CALLED(_abort_msg)
_CODE_ACCESS void _abort_msg(const char *string)
{
    fprintf(stderr,"%s",string);
    fflush(stderr); /* Always a good idea to flush */
    abort();
}

is not optimal for a MSP430 device. The reason is that the string argument to the abort function and the fprintf code to output the string in _abort_msg could cause problems with lack of space on a MSP430 device. With the default RTS the output from fprintf (stderr) won't be visible unless the device is running in the debugger to capture the output, and so would the RTS assert.h be better to define the assert macro as a call to abort if the assertion fails?

You then just have to set a breakpoint on the abort function.

[to be honest, I haven't tried enabling asserts with driverlib to see how much the memory usage increases...]

Chester Gillon said:

is not optimal for a MSP430 device. The reason is that the string argument to the abort function and the fprintf code to output the string in _abort_msg could cause problems with lack of space on a MSP430 device.

Well.. you can think of many possible problems. So what? It does not automagically mean that "industry standard" assert implementation shall be crippled because of that. You have opportunity to redefine assert macro and rewrite _assert() function to suit your needs/hardware. I'ts literally few lines of code to change. What's the problem?

Ilmars said:

Well.. you can think of many possible problems. So what? It does not automagically mean that "industry standard" assert implementation shall be crippled because of that.

Jens-Michael Gross said:

on MSP, there is no OS. So 'industry standard' functionality makes no sense.

It does not make sense to break C programming language either. Let me remind you that (existence of) OS does not define assert() macro.

http://en.wikipedia.org/wiki/Assert.h

So obviously it is wise to not frustrate programmers with "better for MSP having no OS" implementation but just to stick with one everybody are familiar with (industry standard). After all I said already - you can "optimize" it by changing few lines of code. What's the fuzz about such a little thing?

Ilmars said:

It does not make sense to break C programming language either. Let me remind you that (existence of) OS does not define assert() macro.

It's a convenience define and there might be many ways to do any useful job with it.

My own implementation enters a loop where a row of LEDs is flashing n times, then making a pause, then flashing again, endlessly. The assert macro contains a number (the number of flashes between two pauses) in addition to the error text. So you can see what's wrong even if there is no console attached to the RS485 connector.
Buuuuh! Not industry standard! I was breaking the C language (now it is only an 'L'?). But wait: it does the job where the 'standard' didn't. So what's better? Die with the 'standard'? Or live with a functioning solution?

Jens-Michael Gross said:

So its implementation cannot break the language.

But i't s implementation "other way" like LED blinking will frustrate unaware users of "optimized" assert() for sure. So better offer widely known approach knowing it's not the best. Well, I agree that manufacturer of compiler (not library) can offer alternative assert's which can be switched using debug level defines.

One of them: do not concatenate everything in one string but pass expression_str, filename and line_no as separate parameters:

void _assert(int expr, const char *filename, int lineno) {

  debug_printf("Assertion failed: %s [%s:%d]", expr, filename, lineno);

}

I recall modifying assert on x86 CPU's by simply putting software debug interrupt (int 3) in place of _assert() function call. This would be other of alternative ways besides LED blinking.

Why don't you better advice how to do software debug interrupts on msp430 and it's compilers instead of playing word-picking game? ;)

Ilmars said:

But i't s implementation "other way" like LED blinking will frustrate unaware users of "optimized" assert() for sure.

Ilmars said:

So better offer widely known approach knowing it's not the best.

Someone who uses assert should know what it does. And ensure that it does something useful. Else he should not use it. Well, that's true for almost everything.
(one exception are women: often, nobody knows what they are doing, and even if one knows, it doesn't seem to be something useful. Still no reason to leave them aside)

Jens-Michael Gross said:

one exception are women: often, nobody knows what they are doing, and even if one knows

What about software debug interrupts?

Ilmars said:

one exception are women: often, nobody knows what they are doing, and even if one knows

What about software debug interrupts?[/quote]I have no clue how to debug a woman's firmware. But I'm sure it would be a job for many lifetimes.
And the only software interrupt I ever experienced with them, was, well, this doesn't belong where minors could read it.