What does abort() do?

I don't get it, please help me out with this.

What does actually abort() do in Arduino? I don't find any related documentation.

If I upload this code into Arduino:

void setup() {
  Serial.begin(19200);
  Serial.println("Start");
}
void loop() {
  Serial.println("Start Loop");
  abort();
}>

I only get two dashes on the serial monitor, no "Start Loop" and even no "Start". It looks like not even setup() is running. Well, actually that's impossible, since something is "moving" on the serial line after all.

What am I missing?

robitabu:
What does actually abort() do in Arduino?

It clearly has undesirable side-effects. Why would you want to use it?

I only get two dashes on the serial monitor, no "Start Loop" and even no "Start". It looks like not even setup() is running. Well, actually that's impossible, since something is "moving" on the serial line after all.

setup() is running, and buffering serial data. Then, loop() starts and buffers some more. Before anything can get shifted out, you call abort(), which does what it's name suggests. It stops the program that is running, including interrupts (which are how the serial data gets shifted out).

So, the question is why are you calling abort()?

There is more documentation about the libs taht can be used @ nongnu.org

abort() is described (short) here - avr-libc: <stdlib.h>: General utilities

Btw, I was going to use abort() as a measure for halting the software in case totally unacceptable data were used as input.
I understand that's somehow drastic as an error handling method. I wonder how/if/when abort() maybe used such as that.

I'm not going to write some crazy complex error handling routine for this particular purpose anyway, enough being to simply stop everything.

while ( true );

I understand you care for others ... that's nice :slight_smile:

I see now!!! I've found it in stdlib.h :slight_smile:
Thank you anyway, I appreciate that. It's nice to know there's people like you out there :slight_smile:

PaulS:
setup() is running, and buffering serial data. Then, loop() starts and buffers some more. Before anything can get shifted out, you call abort(), which does what it's name suggests. It stops the program that is running, including interrupts (which are how the serial data gets shifted out).

That was quite precise and complete. Respect!

I'm not going to write some crazy complex error handling routine for this particular purpose anyway, enough being to simply stop everything.

In CATIA, we have, occasionally, dialog boxes that pop up that say "Click OK to terminate", like someone would really want to.

The cause is almost always a result of failing to handle an exception. That sounds like what you are planning to implement.

I would strongly encourage you not to do that. Restarting the Arduino because of a type, or noise on the serial line, or some other strange input arriving is not a best practice. It's far better to simply ignore out-of-range data.

PaulS:

I'm not going to write some crazy complex error handling routine for this particular purpose anyway, enough being to simply stop everything.

In CATIA, we have, occasionally, dialog boxes that pop up that say "Click OK to terminate", like someone would really want to.

The cause is almost always a result of failing to handle an exception. That sounds like what you are planning to implement.

I would strongly encourage you not to do that. Restarting the Arduino because of a type, or noise on the serial line, or some other strange input arriving is not a best practice. It's far better to simply ignore out-of-range data.

I completely agree with you, andI usually tend to spend quite some time on error handling. Especially because I'm not a professional programmer, so I'm going to use the code for myself, not for customers :wink:

In this case I'm going to use abort() in a preliminary stage of the coding. I'm not going to bother much about providing valid alternative default values in case the input is going to be unacceptable. It's ok to me if it runs an infinite loop. It doesn't break anything at the moment. But it's good to know what it does precisely :slight_smile:

In which case, this may be helpful...
http://www.nongnu.org/avr-libc/user-manual/group__avr__assert.html

It could ... but I don't have the slightest idea of how to direct stderr to the serial ... so why bother adding this layer of complexity?
No, seriously, how may I define __ASSERT_USE_STDERR ? Do I get to redirect it to the serial channel? How?

Anyway, I find usefull that I can disable the assert() when I'm finished debugging, by simply defining NDEBUG once and for all.
That's cool to know :slight_smile:

robitabu:
In this case I'm going to use abort() in a preliminary stage of the coding.

It's already been explained to you that calling abort() under any circumstances in an Arduino sketch is a bad idea. If you want the sketch to chop itself off at the ankles, you could use the while(1); that Coding Badly showed you. Personally I think doing that just because of duff input is probably a cop-out, but if you can't be bothered to do anything more user-friendly then it's a legitimate way to halt your sketch. Calling abort() is not.

...but I don't have the slightest idea of how to direct stderr to the serial...

If you do nothing special...

#include <assert.h>

void setup( void )
{
  assert( false );
}

void loop( void )
{
}

abort is called if the assertion fails. stderr does not come into the picture.

[quote author=Coding Badly link=topic=144756.msg1087551#msg1087551 date=1359071251]If you do nothing special...

#include <assert.h>

void setup( void )
{
  assert( false );
}

void loop( void )
{
}

abort is called if the assertion fails. stderr does not come into the picture.[/quote]

That's all clear to me. That's how I already used it after you suggested it to me.
But ... that way, it does no more than calling abort(), right? Why should I even bother with calling assert() then? What's the point if it does'nt add anything new to the picture?

You can disable it with the #define. Just a few posts up you said that was a good thing. 8^)

But now that it has been brought up, is there any way to redirect stderr to Serial, and then enable with #define __ASSERT_USE_STDERR , like int std c++ you could do

std::cerr.rdbuf(myOStream.rdbuf());

?

johncc:
But now that it has been brought up, is there any way to redirect stderr to Serial,

Yes, there is. You can associate stdin, stdout and stderr with the hardware Serial if you want (or any other device) by writing put and get functions for the device and then associating these functions with each stream by calls to fdevopen().

That's the most interesting piece of information I have seen all week.