Does Arduino have a future?

Community Suggestions for the Arduino Project
21

Kowalski's work with Cosa is a really interesting development for a C++ OO Framework. It's a bare metal approach that will give us some task scheduling that might allow us to do some things that we expect an RTOS to accomplish. He's not included any of the ARM core MCUs. If he expanded it to Cortex-M3.. for DUE.. .Then we'd want him to expand it to Cortex-M0 for ZERO.... then there would be others of us who'd like to see it expanded to Cortex-M4 for TI Tiva C series.

Then there's the IDE. Not very powerful... but hides allot of the ugliness. The Wiring based IDE forked and used by Arduino (for Arduino AVR and Cortex M0 and M3) and Texas Instruments (Energia for TI Tiva C Series) . So although there is fun stuff happening with Visual Studio and Xcode Addins, the Arduino team hiding all of the ugliness with the tool chains and so forth makes a compelling case for just putting up with the weak IDE. It's still very easy to use.

There's the hardware itself. I wish that they could have made use of the native Ethernet and SDIO/MMC capabilities of the ATSAM3X8E and installed a physical RJ45 and microSD slot on the DUE. Instead, DUE ended up being a faster MEGA with lots of library issues to work out. They will give us all of that with the TRE, but all appearances are at increased complexity and costs. Perhaps the Arduino ZERO should have come first.... Maybe we will get a Quattro based on the Cortex-M4 and give us the missing pieces from DUE and Tiva C Series (looking at you SDIO interface... really wanted that included in the TI Launchpad!).

I like the idea of having built in microSD support, Ethernet and getting eeprom back.... but I don't want to have to school myself on Linux to get it.

Whether or not Arduino survives.. I'm not sure... none of us are privy to their financial performance. But they certainly have benefited the Maker crowd and Academia by getting the cost of basic prototyping platforms down to levels we can all afford to use! I think they've gotten the attention of bigger folks (Texas Instruments). Increased competition drives innovation and costs.

Maybe the Italians have a little work to convince us that ZERO, UNO, DUE and TRE are a real complimentary family of products.... instead of radical departures at each turn. We've got CortexM3 with DUE.... then TRE is announced and grabs TI's Sitari (aka BeagelBone) architecture and drags along AVR with it... then we move on to ZERO and we are back in the Atmel fold with the CortexM0.... I've given Arduino lots of cash by purchasing official boards/shields and I've supported 3rd party development through clones/shields/others. But ultimately, for me, it's about a working, well supported product. We know UNO and MEGA are great.... everything else they are developing/doing feels like such a departure that we don't hesitate to look at other architectures, other vendors products. As a user community, we have no idea where Arduino is going....

But maybe that's not that important. Perhaps the Arduino folks aren't either? Looks like TI and Atmel are the big suppliers for Academia and the Maker set now (is it my imagination that PIC is losing out to these guys?). TI even promotes the BeagleBone boards on it's site and makes no bone (pun intended) about the Tiva C series taking advantage of the Arduino and Wiring Frameworks, despite both of them being competitors to their own development boards. Maybe we will see a convergence of technologies, architectures and methodologies... Consider we've got AVR (Atmel 168, 328) Cortex-M3 (Atmel AM3X), Cortex-M0 (Atmel SAMD21), Cortex-M4 (Ti TM4C), Cortex A8 (Ti Sitari) architectures all running on a form of the Wiring Framework with forks of the same IDE developed in Processing. Maybe Arduino IDE 2.0 will really extend the reach? The only questions might be do you want a board that uses Shields, Capes or BoosterPacks? Our skills may just easily transfer across platforms/vendors/products.

Wow, this got long fast.

22

This feels like a search for the Holly Grail.

He's not included any of the ARM core MCUs. If he expanded it to Cortex-M3.. for DUE.. .Then we'd want him to expand it to Cortex-M0 for ZERO.... then there would be others of us who'd like to see it expanded to Cortex-M4 for TI Tiva C series.

I am mainly interested in Cortex-M processors. There is no hope that one person or even a few people can provide an open source firmware library for these devices.

Here is a project with the goal for providing such a library http://libopencm3.org/wiki/Main_Page

The libopencm3 project (previously known as libopenstm32) aims to create a free/libre/open-source (LGPL v3, or later) firmware library for various ARM Cortex-M0(+)/M3/M4 microcontrollers, including ST STM32, Ti Tiva and Stellaris, NXP LPC 11xx, 13xx, 15xx, 17xx parts, Atmel SAM3, Energy Micro EFM32 and others.

They barely have software to configure the pins on devices. There is no support for SDIO on any device http://libopencm3.org/wiki/Status.

Kowalski's work with Cosa is a really interesting development for a C++ OO Framework. It's a bare metal approach that will give us some task scheduling that might allow us to do some things that we expect an RTOS to accomplish.

Embedded systems are about time and Costa almost ignores problems of concurrency. The importance of preemptive systems has been understood for over 40 years.

Liu, C. L.; Layland, J. (1973), "Scheduling algorithms for multiprogramming in a hard real-time environment", Journal of the ACM 20 (1): 46–61,

Here is a summary of this important theoretical result Rate-monotonic scheduling - Wikipedia.

There are lots of resources for Cortex M List of ARM Cortex-M development tools - Wikipedia so I can't complain too much.

23

Ive been thinking about this for a bit, and I've had a couple of thoughts:

  1. The original arduino was aimed at incorporating ELECTRONICS in art/design/hobby projects. Because for a couple of decades now, the response to most "I want my thing to do something electronic" desires has been (and should be) "you should throw in a microcontroller to do that." Except that using microcontrollers was difficult and relatively expensive (not counting Basic Stamps, I guess.)

The Arduino abstractions, philosophies, and libraries are more-or-less aimed at that "hardware replacement" function. IMO, they did a pretty good job at defining these. For that application.

  1. That particular "bare-metal" treatment of a microcontroller/board is NOT particularly compatible with layering "on top of" an operating system. Or processors that are much faster than the AVR, for that matter. (Even a 16MHz AVR can push the ability of normal "wire" in a max-rate pin-toggle loop. Fortunately, the form factor used encourages short wires!) (as an example, look at the problems that happened when HardwareSerial transmit became interrupt-based...)

  2. We need a sort of "backward" OS, where the high-level functions (like SD-card file access) are handled in the background, while the user's code runs at approximately bare-metal levels of priority/non-interference/etc.

  3. That's not the way most modern OSes work. Certainly not Linux, which is clearly the natural choice for most of the "big" cpu configurations.

  4. The "target market" isn't really big enough to support development of a custom operating system :frowning:

24

The architecture of AVR or cortex CPUs is essentially the same as those of 50 years ago, and in that time people have been wrestling with the problem of bare-metal vs OS.

Unfortunately, there is no way to create OS-like functionality without incurring some overhead. The more independence of processing that you want, the more overhead you need. This is an inevitable feature of several processes sharing a single CPU core, memory and peripherals.

Fortunately, the hardware guys keep making faster chips, so we get round the problem that way. The alternative is to have independent cores, e.g. like the Parallax Propeller. But I am pretty sure there is no software trick to get the best of both worlds.

There is a niche at the bottom end for bare metal systems, and I think the basic Arduino will continue to provide an entry level type system for that. It's also clear there is demand for systems with rich environments like Raspberry Pi. The price/performance of those will continue to improve, and the price get closer to that of Arduino, if not already there.

What will probably not change is the middle ground, between bare metal and feature rich OS like Linux. For example, I would like to add TCP/IP, web server, USB host with support for wi-fi dongle to my bare metal project. That's a big chunk of code. There is no obvious off the shelf solution, or "go to" RTOS which supports all that out of the box.

The problem is that there are thousands of RTOS to choose from, but drivers and middleware for them is lacking. I think this is one area where diversity doesn't help, and a single standard would allow people to develop drivers and middleware instead of re-inventing the RTOS.

Perhaps the Japanese had the right idea with ITRON, but a government funded standard seems like anathema to the western way of doings. ITRON is claimed to be the most widely used OS (units shipped), but few people have heard of it.

Ironically, an old version of Unix might be a good real time OS, at least for 32 bit devices. It has a simple clean architecture and is well known.

The gap between 16MHz 8 bit AVR, and a 500MHz 32 bit ARM with 4MB RAM (roughly where Linux becomes runnable) is too big to be bridged with a single RTOS. It should be possible to scale from say 50MHz ARM with 32KB upwards on a single RTOS, but chips with a few kB of RAM will be too resource constrained to run anything more than a very basic RTOS if at all.

So I think Arduino will continue as a cheap and simple way to interface to electronics, systems like Beaglebone will reach the price point of Arduino, and the problem of the middle ground between bare metal and Linux will continue.

Perhaps the answer is dual function boards like Arduino Tre and UDOO, with a fast interface between the low and high level CPUs.

25

an old version of Unix might be a good real time OS, at least for 32 bit devices.

One of the chipKit (PIC32 Arduino-like board) has had 2.9bsd ported to it. Old time operating systems do not tend to handle "small ram, large flash" configurations very well.

The "big OS-running cpu" and "little bare-metal IO cpu" (ala Yun or those NXP M0/M4 chips) has potential, given suitable communications protocol(s).

A lot of intermediate-sized OS development gets distracted by "real time", which complicates everything and may not be necessary (arguably, Arduino is already NOT "real-time.")

26

Unfortunately, there is no way to create OS-like functionality without incurring some overhead.

Modern embedded OSes are often more efficient than ad hoc solutions. The algorithms in these systems have been under development for over 40 years. It's like the difference between a bubble sort and quick sort.

A lot of intermediate-sized OS development gets distracted by "real time", which complicates everything and may not be necessary (arguably, Arduino is already NOT "real-time.")

Real-time and RTOS are unfortunate terms for an OS designed for embedded systems. It's not about fast, it's about appropriate features.

Here are some quotes from "Introduction to Embedded Systems" by Lee & Seshia. Download link http://leeseshia.org/download.html

The computers in embedded systems often do not interact directly with humans in the same way that desktop or handheld computers do. As a consequence, the collection of services that they need from an operating system (OS) may be very different. The dominant general-purpose OSs for desktops today, Microsoft Windows, Mac OS X, and Linux, provide services that may or may not be required in an embedded processor.

An OS for embedded systems should have a few additional featues.

These OSs share many features with general-purpose OSs, but typically have specialized the kernel to become a real-time operating system (RTOS). An RTOS provides bounded latency on interrupt servicing as well as a scheduler for processes that takes into account real-time constraints.

A microkernel and modularity is desirable.

The core of any operating system is the kernel, which controls the order in which processes are executed, how memory is used, and how information is communicated to peripheral devices and networks (via device drivers). A microkernel is very small operating system that provides only these services (or even a subset of these services).

I also believe features to support the "Internet of Things" are also important. The OS should make it easy to inter-operate with phones and other modern smart devices.

The problem is that there are thousands of RTOS to choose from, but drivers and middleware for them is lacking. I think this is one area where diversity doesn't help, and a single standard would allow people to develop drivers and middleware instead of re-inventing the RTOS.

I have evaluated RTOSes for many years. If you screen the long list of OSes with a few key requirements such as HAL support or driver support for your chip and a modular micokernel, the list will soon be reduced to a manageable size.

The major chip companies all support an RTOS with FreeRTOS being most popular.

RTOSes are now used in the majority of 32-bit embedded systems. Billions of copies of OSes like VxWorks and FreeRTOS are now in every day products.

27

I'm curious to see ultimately what direction Arduino is going product wise. They didn't take the DUE far enough, not utilizing the native connectivity of the Cortex-M3 (sic.. Ethernet), the SD interface and others. But I guess they'd rather sell shields.

Do they feel users require a full applications processor (Sitari A8) with a proper OS (Linux) ala the TRE to enable the internet of things?

Or rather are they planning something (QUATTRO, QUA, AWD, 4WD or 4TO) with a just powerful enough microcontroller (Cortex-M4 or newly announced Cortex-M7) with a decent RTOS option to enable the same IoT?

Anyone heard any good rumors?

28

If you want a better Arduino, design one. You don't have to sit back and wait and then
grumble that its not what you would have done!

If you come up with a good design, evangelize it, kickstarter it, talk to Arduino, see
if its got wings... After that you've earnt the right to grumble methinks.

Rather than fret about such issues, remember the strengths of open sourced designs
that allow anyone to build on the work of others.

[ slight rant over ]

It struck me this thread was too negative and "us and them".

29

Mark,

Honestly.. to design a 'better' Arduino is way beyond my capabilities. Lightyears. (To use an Arduino? Now I've done that plenty and had some fun.) The Arduino team is far brighter than I. I found some design decisions for a few recent products to be puzzling, but I don't think I was overtly critical.

However, I would reward the Arduino team with my hard earned dollars through purchase of a 'better' Arduino if they designed one. In fact, I've rewarded no less than 3 different manufactures of DUE alternatives who built a better mouse trap. Good stuff.

Thank you for your rant. Perhaps, now that you've expressed your righteous indignation of all of us ingrates, the entire Arduino team can comfortably rest on it's laurels. I'm hoping they don't. I'm looking forward to more excellent products from them... Is it wrong to hope for them to go the extra mile on the next big release?

Peter

30

The problem is ... in general we don't need a "better arduino." The 16MHz AVR is "just right" for a lot of the things that Arduino should be doing, while maintaining a pleasing simplicity. If you want to spend two or three times as much to build a much more capable system (like an Intel Galileo, for instance), you're suddenly in a space that is more complicated, with a lot more potential solutions.

31

I think that the success of Arduino up to now is mainly due to the "easy of use" of its IDE and the libraries available.

If the future of Arduino is to release new products , like the DUE, with scarce libraries available despite the long period of time since DUE release, then I fear that the future will not be quite successful.

Fist complete the DUE work, demonstrate that Arduino can deliver complete HW+SW and then go with THREE for minorities.

jma

32

With DUE, Arduino went the cortex-m3 route; with TRE, they are going the cortex-a8 route; with Galileo, they will go x86 route. Lots of Cores/ISAs to keep straight; whereas UNO and it's derivates stayed the AVR course.

But I like to watch what 3rd part folks are doing. Take Atlas-Scientific for example. They build embedded circuitry for interfacing sensors to microcontrollers. Years ago you could find sample code for mbed and arduino uno and mega.

Fast forward and look at some recent developments: Now we have ARM kind of sorting opening up mbed and announcing development of mbed os v3.0. We have Arduino playing with Cortex-M* ARM architectures. Guess what Atlas-Scientific's response to all of this development has been? You guessed it. Look on their website. No more mbed code samples. Their Arduino code samples are still just for UNO and Mega with no DUE (Cortex-M3) examples. It's still 8bit AVR from this supplier. In fact, they've recently modified and relaunched many of their products (under the EZO name) to include I2C functionality. And guess what? You got it, their code samples are still just Arduino Uno and Mega. They'll leave it up to you to make it work with the other stuff.

UNO/AVR is stable and well understood. That may be what folks are going to continue to use. That's key: solid hardware/software support (ie. libraries, working features and documentation).

These Atlas-Scientific guys have a production facility in Flushing NY (not a cheap location). They sell allot of product. And they are saying to everyone who buys their product, "Hey, here's how you can get this to work easily with Arduino UNO. Here's some good C code that works with that tried and true architecture". That's a real testimony to what Arduino has accomplished with the UNO and it's AVR family.

33

Arduino will always have a market in the low end of speed requirements for uno and such like I am about to start a new project using an arduino as a high end laser controller because its all I need, I could use Ti boards or what ever but at this stage it will be a wast to use them as the arduino has enough grunt to do the job for know

34

Very bleak after this latest improved web site which keeps telling me I have unread personal messages belonging to someone else. I did not read them, deleted them and it is still telling me I have them, but there are none in the box.
Since they only care if I post unformatted code snippet nobody will read this anyway.
So why bother speculating on future. It is the present Arduino inc. should be concerned.

35

The AVR based Arduinos will still be around for quite some time. While the ARM based ones provide more processing power, those more powerful chips are also more power hungry, making it much harder to impossible to use them for anything intended to run for longer time powered by batteries.
And the lower voltage levels make them more susceptible to any kind of burnout and much less flexible in terms of power sources as the quite robust AVR based boards.

Yes, the IDE could use a bit of a 'face-lift', there are a lot of little features that people seemed to have implemented themself which the Arduino folks don't think is worth to pick up and integrate in the mainstream release.
Kind of curious as to what the ways are supposed to be to program the Tre or even more so, the Zero, with its integrated debugger chip. I seriously hope they do not expect people to use Atmel Studio, with the behemoth of Visual Studio core underneath and the loss of cross-platform use of the current Arduino IDE...

Ralf

36

"Yes, the IDE could use a bit of a 'face-lift', there are a lot of little features that people seemed to have implemented themself which the Arduino folks don't think is worth to pick up and integrate in the mainstream release."

As long as same outfit who done the web site does the job, their future AKA having a job ( to fix things) is safe.
Not sure about the "product".
So far my new Due is working as expected, but the compiler could use some help to speed things up.

37

Vaclav:
So far my new Due is working as expected, but the compiler could use some help to speed things up.

Again, Vaclav, you're complaining in the wrong place.

38

I have 4 Arduino boards, Uno, Leonardo, Mega2560 and Due. I bought them when I was thinking about go back to microcontroller tinkering. However the community quickly bored me out as the project seems half dead, libraries I want to use seems unmaintained, and when a problem arose it is up to myself. I am a student of CS major so I am far from helpless when those issues came to me but after I lose some hair figuring that problem out I still got no support.

The boards themselves are really nice - I have even designed an RFID authenticator that would enter your password for you if you can identify yourself using RFID based on Arduino Leonardo. I think the problem here is the software is lagging behind.

Just a wild suggestion, is it possible to redesign the entire software stack, using newer versions of base libraries and reinvent the entire user-friendly interface stack?

39

Well, they DID redesign a bunch of the libraries to work on top of stream. (or below? Inherit from? idk...)
That was a pretty significant and useful change.

reinvent the entire user-friendly interface stack?

What did you have in mind? The way things look to me, the Arduino stacks are equal or better (but more limited) than vendor-provided libraries like CMSIS, ST Peripheral Library, TI Tivaware, and etc. (most of which seem to provide all of the bloated overhead of Arduino, without providing any simplification. Sigh.)

40

westfw:
Well, they DID redesign a bunch of the libraries to work on top of stream. (or below? Inherit from? idk...)
That was a pretty significant and useful change.
What did you have in mind? The way things look to me, the Arduino stacks are equal or better (but more limited) than vendor-provided libraries like CMSIS, ST Peripheral Library, TI Tivaware, and etc. (most of which seem to provide all of the bloated overhead of Arduino, without providing any simplification. Sigh.)

Here is what I have in mind:

Some things should be left behind.

This current IDE approach is helpful for beginners but is burdensome for anyone that went beyond that level, and the IDE itself is not really helpful enough. So this Processing-based IDE should be ditched and a new one should be created.

The existing libraries actually posed a learning curve for both newbies and experienced programmers as it deviate from the common programming environment so much, especially anything that derived from the Print class. My suggestion is POSIX-ify the library API.

Some things should be created. A new IDE should be created as the old one is no longer useable. I have checked that some LLVM fork have AVR support so a clang-backed IDE with way better language sensing can be built. Xcode is an example of an clang-backed IDE and Apple released all required features as part of libclang.

A new set of POSIX-styled C-based API should be created. This will allow existing programmers migrate from desktop environment with very few burdens, and allow newbies started from Arduino migrate to desktop more smoothly.

Also, libraries should be really libraries, i.e. in the form of an UNIX static library archive and linked using -l flag on GCC.