Could you summarize the state of arduino language and ecosystem?

I think arduino is great and I've used it in the past extremely successfully. I found the ecosystem of sketches and help to be fantastic. I've actually never programmed on the bare metal.

I noticed another poster complained about how long it takes to compile a new sketch (close to a minute). At the moment, is the Arduino ecosystem in a bit of a difficult period? I also notice that compared with how amazingly useful Arduinos are in such a dazzling array of applications, the number of posters and views on this particular form is quite small....

could someone summarize what is going on with Arduino? Is it still as useful and unified as it ever was?

Thank you!

On a technical level, stagnant. It only has a few more years to run before it's eclipsed by other platforms.

aarg:
On a technical level, stagnant. It only has a few more years to run before it's eclipsed by other platforms.

Thanks. But what other platforms? There isn't really much competition is there?

What would you like to see technically? I mean, all arduino is is like a special language, IDE, and bootloader, to make it easier to program in a higher-level language, right? (Not be as close to the metal). Do I have this right?

If so, what's the alternative - just the metal? Or are there other alternatives developing...

I'd like to bear in mind that this is an arduino forum though so maybe we can keep it just a bit positive :slight_smile:

Compiling is generally only slow when there is a PC issue. I compile a pretty big sketch, 22Kbyte (& growing, for a '1284P talking to a GPS/GSM module, temperature reading chips, shift registers, etc.), in just a few seconds.
The PC issue in the past has been traced Bluetooth stuff running on the PC. Try searching and turning stuff off.

What other user friendly IDE will replace the Arduino? It goes thru some development rough patches from time to time - between 1.0.6 and 1.6.5r2 were problematic, and then again those leading up to 1.6.9 had some issues. (-0023 was good for a while too, then 1.0 to 1.0.5 had issues.) Plenty of folks willing to come up with the add-ins needed to support chips that are not part of the official family of supported chips.

CrossRoads:
Compiling is generally only slow when there is a PC issue. I compile a pretty big sketch, 22Kbyte (& growing, for a '1284P talking to a GPS/GSM module, temperature reading chips, shift registers, etc.), in just a few seconds.
The PC issue in the past has been traced Bluetooth stuff running on the PC. Try searching and turning stuff off.

What other user friendly IDE will replace the Arduino? It goes thru some development rough patches from time to time - between 1.0.6 and 1.6.5r2 were problematic, and then again those leading up to 1.6.9 had some issues. (-0023 was good for a while too, then 1.0 to 1.0.5 had issues.) Plenty of folks willing to come up with the add-ins needed to support chips that are not part of the official family of supported chips.

Thank you, this is very useful information. Out of curiosity, since you've written so much, have you ever thought about learning embedded programming on the metal? Or is there no reason, and better to write arduino code?

If you don't mind my asking, is this like in a product you're selling or just a hobby? Thanks.

Arduino code is C++

Learning embedded programming? C++ gets compiled down & runs pretty fast for the 8-bit AVRs. I use direct port manipulation and direct register writing to speed things up when I need it really fast. For example, I sometimes output bursts of SPI data:

#include <SPI.h>

#define nop asm volatile ("nop")
byte array[] = {0,1,2,3,4,);

byte ssPin = 10;

void setup(){
  pinMode ssPin (OUTPUT);
  SPI.setClockDivider(SPI_CLOCK_DIV2 ); // 8 MHz rate
  SPI.begin();
}

void loop(){
PORTB = PORTB & 0b11111011; // low on D10
SPDR = array[0]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
SPDR = array[1]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
SPDR = array[2]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
SPDR = array[3]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
SPDR = array[4]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
PORTB = PORTB | 0b00000100; // high on D10
}

The above gets blasted out at almost 1 byte/uS (17 clocks per byte), the fastest you can send stuff out to shift registers.

My wife and I sell lots of cards and do custom designs & builds as well.
http://www.crossroadsfencing.com/BobuinoRev17/
Here's one of the processor-less cards we sell, a Mega ScrewShield, and one of the '1284P designs we sell, Bobuino2 with SD card, battery backed RTC, and some prototype area:

curious48:
I noticed another poster complained about how long it takes to compile a new sketch (close to a minute).

If it's taking a minute to compile, there is something wrong with your setup. I just tested compiling one of my larger programs (to program bootloaders). It uses most of the program memory:

Sketch uses 28,024 bytes (86%) of program storage space. Maximum is 32,256 bytes.

That took 3 seconds to compile. Short, test, sketches take somewhat less. The "blink" sketch, for example, takes one second. This was using Ubuntu 14.04. Now I'm not going to sledge other operating systems right now, but if it takes a minute to compile "blink" you need to look at what is going on.

The Arduino environment is fine.

I've actually never programmed on the bare metal.

You can do that if you want to. You can make a sketch like this:

int main ()
  {
  }

That compiles into:

Sketch uses 138 bytes (0%) of program storage space. Maximum is 32,256 bytes.

Most of that is unavoidable overhead (interrupt vector table).

Now add whatever-you-want as the "bare metal" code.

Out of curiosity, since you've written so much, have you ever thought about learning embedded programming on the metal?

I'm not sure what you mean by that. The Arduino libraries just simplify a lot of common tasks. You can get down to the "metal" as you call it by directly accessing the processor registers, for example to set up timers in ways that please you.

There's nothing really to "learn" - you just read the datasheet and make the processor do what you want it to.

It only has a few more years to run

Heh. People have been predicting the demise of both C and 8-bit microcontrollers for decades, now...

Boards like the Raspberry Pi have been around for a while now, and are clearly better for some applications, but have failed to completely replace Arduino so far...

westfw:
Heh. People have been predicting the demise of both C and 8-bit microcontrollers for decades, now...

Well, I wouldn't say such a silly thing. Although I do believe C will eventually die. Maybe not in my lifetime.

aarg:
On a technical level, stagnant. It only has a few more years to run before it's eclipsed by other platforms.

The trouble with that theory is, 8-bit controllers (like the 6502 used in the Apple II) were indeed eclipsed by more powerful ones around 40 years ago. So why are Atmel and Microchip selling billions of chips the last few years? Because "powerful" isn't necessarily better.

  • Powerful requires more power - not great for something running off solar power or a battery
  • Powerful generates more heat
  • Powerful needs more complex programming (eg. multi-threading)
  • Powerful has an underlying operating system, which adds a layer of complexity and which can fail
  • Powerful is so complex it can be subverted by viruses and trojans without your knowledge

And who needs power when many of the things small time users do don't even need the power of an Arduino.

It cannot be justified to use a RPi to do any of the projects I have done.

Weedpharma

I do believe C will eventually die. Maybe not in my lifetime.

ForTran and COBOL are still alive "and well."

Arduino ecosystem? Is that like Arduino climate change where meanies have taken over the forum?

Also with C you can program close to the metal but if you want to program down the metal then that is written in solder and components.

It's not really metal anyway.

The connections are.