The "bare minimum" sketch isn't the bare minimum ...

Now I know this is going to cause a ruckus, but ...

On this page:

http://arduino.cc/en/Tutorial/BareMinimum

The "bare minimum" sketch is described thus:

void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly:

}

But actually, the bare minimum is:

int main ()
{
  init ();  // hardware initialization
  
  // put your code here
}

And you could argue, this is simpler. We have had posts from people that complain that "loop" doesn't loop (ie. you can't do a "continue" in it). Or that something they put in "loop" is done very often. Or they try to make multiple "loop" functions.

But don't you think that making the "minimal" sketch have two functions (setup and loop) is a bit more complex, rather than less complex, than saying "here is main, do all your stuff in it"?

And eventually you learn that what really happens is this:

int main(void)
{
    init();

    setup();
    
    for (;;)
        loop();
        
    return 0;
}

So why try to hide it? The "real" bare minimum isn't that hard to understand, and there isn't hidden stuff going on that you don't know about.

The bare minimum sketch contains setup() and loop() because that's what a sketch is - the bare minimum C program is what you are describing ;)

So why try to hide it? The "real" bare minimum isn't that hard to understand, and there isn't hidden stuff going on that you don't know about.

Most likely this comes because of the relationship with processing. And because it has been this way in the past, it won't be changed in the future.

Korman

complain that “loop” doesn’t loop (ie. you can’t do a “continue” in it)

With the knowledge you showed, you can explain to anyone that you can “return” anyplace to exit the loop and start over.
e.g:

void loop()
{
  ...
  if (Serial.available() < 10) return;  // OK there are better ways to handle this ;)
  ...
}

MarkT:
The bare minimum sketch contains setup() and loop() because that’s what a sketch is - the bare minimum C program is what you are describing :wink:

This sketch compiles without error under the Arduino IDE and runs perfectly:

int main () {
  init ();
 // your code here
  }

I’m not sure why you imply it isn’t a sketch.

Korman:
… it won’t be changed in the future.

I’m not suggesting that any part of the IDE be changed. I’m pointing out that the tutorial shows a larger minimal sketch than is really the minimal one, especially for people who come from a C background and wonder where “main” is.

The Arduino home pages says:

The microcontroller on the board is programmed using the Arduino programming language …

and the link to “Arduino programming language” reveals that:

The Arduino language is based on C/C++.

This is a strength, a very big strength, that the IDE basically supports C++. Why hide it? And for people who are doing computer courses and learning C/C++ and who are thinking of buying an Arduino, they might be put off by having to learn “the Arduino programming language”. It would be nice to make it clear that they will be learning perhaps the most widely-used industry-standard language used in the world today: C++.

So why try to hide it? The "real" bare minimum isn't that hard to understand, and there isn't hidden stuff going on that you don't know about.

It's 'hidden' because the C language (and C++) was designed assuming it would always be run under an operating system and main() was designed to return to the OS with either an error code or 0 if no error. As the avr chip is not running under a OS, there is no place to return to. It's more logical to have a loop() function that never returns.

So I don't think it's a case of hiding anything from the user but rather the unique situation that a microcontroller chip running a compiled C/C++ program has no higher order OS to run under nor return to.

Lefty

This sketch compiles without error under the Arduino IDE and runs perfectly:

int main () {
  init ();
 // your code here
}

This is probably a bug. Since it overrides the main() function and initialization of the arduino core, it does not qualify as a "sketch" and probably shouldn't compile. (ok, your example exactly duplicates main() from the arduino core, but the "specification" for an arduino sketch does not include the exact definition of main(), and so that might not continue to be true.)

Like retrolefty, I always figured that this placed a nice emphasis on one of the key differences between embedded programming and desktop/large system programming - a microcontroller has no concept of being "done" with an application. (although as Korman points out, this is equally likely to just be a holdover from Processing.)

westfw:

This sketch compiles without error under the Arduino IDE and runs perfectly: ...

This is probably a bug.

Well I had to smile. How many people post here "my sketch compiles and works perfectly" and you reply "probably a bug"?

westfw: ... a microcontroller has no concept of being "done" with an application.

You raise an interesting point. In my minimal sketch, what happens once main is done? Does it enter another dimension?

Well, a look at the disassembly reveals that after the low-level initialization calls main, it then jumps to _exit.

_exit does a CLI (disable maskable interrupts) and then goes into a tight loop.

By the way, this "more official" sketch compiles:

void setup () {}
void loop ()
 {
   exit (0);
 }

Where do you suppose execution goes to on the exit() call?

How many people post here "my sketch compiles and works perfectly" and you reply "probably a bug"?

Lot and lots of compiler writers, alas. OK, not "here." But you probably get my point. More realistically, if a Makefile unexpectedly loads library /lib/foo instead of /usr/lib/foo, I would consider that a bug in the makefile, even if trivial programs continue to work.

Where do you suppose execution goes to on the exit() call?

I wouldn't have any idea. exit() is not currently defined by the arduino environment.

Arduino, Wiring, and Processing all decided a long time ago that they wanted a "sketch" to look somewhat different from a standard C/C++/Ada program. You are free to disagree with that decision, and you can write your own code differently, but that doesn't mean the "official" examples should be re-written to match your opinions... (why stop where you did? A sketch shouldn't need to call init() if it doesn't use the features that init() initialized. And why have the isr vector table if you don't use interrupts? Surely the minimal sketch ought to have the smallest possible object code. Assembler would be good for that. Arduino should support .S files, and the minimal sketch example should be in assembler...)

westfw:

Where do you suppose execution goes to on the exit() call?

I wouldn't have any idea. exit() is not currently defined by the arduino environment.

Ah, but it compiles and works perfectly (on the Arduino). ;)

Thus, exit() is defined. And the disassembly shows it exits in the sense that it goes into a loop.

You are free to disagree with that decision, and you can write your own code differently, but that doesn't mean the "official" examples should be re-written to match your opinions...

I think I see your point (apart from the obvious one that my opinion is just one amongst many). The Arduino environment does a brilliant job of being an easy entry point for beginners, and the IDE hides a lot of detail that might be confusing. I was merely trying to suggest that, for beginners:

int main ()
{
// your code
}

was simpler in fact than:

void setup ()
{
// initial code
}
void loop ()
{
// repeated code
}

... but perhaps if the teaching point being made is that programs generally have a setup phase, and a looping phase, then I see why that is being done that way.

the teaching point

I didn't think to say that, but Arduino does try to generate a "teachable framework" that becomes understandable and logical to its users, though not necessarily the standard engineering/CS structure.

It's a good place to stop; I think we're agreeing about as much as we're likely to!