Does Arduino have a future?

fat16lib:
Arduino feels like a company that is living on its past success. I don't plan on buying a Tre, Zero, Intel Galileo, or any other new Arduino board I know about.

I feel the yun is really worth looking at. Though a yun mega or a yun teensy3.1 would have been a killer

Atmel's AVR chips are falling behind the ARM chips (Teensy, Maple, etc.). They need to start kicking up the clock speed and memory to stay competitive. That's my only concern.

With respect to the Raspberry Pi, Beaglebone, etc., those are not microcontrollers. There will always be tons of situations where just a simple microcontroller is warranted and AVR chips will always have their place there.

Chagrin:
There will always be tons of situations where just a simple microcontroller is warranted and AVR chips will always have their place there.

While I agree that micontrollers will have a place for quite some time, I'm not as
sure about the 8 bit AVRs. I find it increasing painful to deal with when there are other
chips out there that are the same price point like the pic32 that have oodles more
of everything on them, are 32 bit, MUCH faster and don't have the all the split memory
progmem issues.

I mean consider this, if you had your choice, and the cost was the same,
would you pick an 8 bit processor that runs at 16 Mhz with 32k flash, 2k ram, and a funky split
address space where C const data doesn't work
or would you pick a 32 bit processor that runs at 50 Mhz, with 128k of flash, 32k ram,
lots more i/o and peripherals including native USB AND C const data works.

The point is that other much better chips than the 8 bit AVRs are now already available
for the same cost - including in DIP packages,
so I believe that people will start to migrate away from the 8 bit AVRs and eventually leave them behind.

I would bet that if the Arduino were starting to day, it would use a PIC32MX250f128B
rather than the Atmega8.

--- bill

I needed more speed for my projects so I've been testing the DUE, Teensy3, and ChipKit UNO32. I agree that the added power over the original Arduino's is an advantage. The fact that they are Adruino "compatible," can use the large number of arduino libraries, and user experience base, gives them an advantage over "non-compatibles." For example, the much smaller user base for ChipKit has made it harder for me to use this board.

The Galileo will need to develop a user base pretty much from scratch. The TRE is somewhere in between. I'm waiting to see how Arduino compatible the TRE user interface is. I have not see a review of the BeagleBone part of the TRE board. If the BeagleBone is $79, how much more will the TRE be? It's like car companies, they make a cheap Volkswagon Beetle, (I'm old enough to know how cheap the first US volkswagon's were) then over time grow it into a Cadillac. More gadgets I don't need, and more complicated for us less experienced to learn and use. Where does that leave the hobbiest? The DUE, Teensy3, and ChipKits are today's Beetle - a bit faster, a bit more complicated, and a bit more expensive - but still affordable.

I think if it is to have a future then the infamous Uno 'avrdude: stk500_recv(): ' errors need to be addressed. How many new users encounter this issue and don't get a resolution I wonder? And that is probably the last time they spend money on this platform, maybe this hobby.

dannable:
I think if it is to have a future then the infamous Uno 'avrdude: stk500_recv(): ' errors need to be addressed.

I have never seen this problem myself with a genuine Arduino board & drivers. Some of the new platforms like the ST Nuclio present a flash drive to the connected PC and programming is as simple as dragging the compiled file into the drive.

While I agree that micontrollers will have a place for quite some time, I'm not as
sure about the 8 bit AVRs.

I started to use Arduino because I wanted an easy way to work with microcontrollers.

I started using Arduino in 2008 and wrote the Fat16 library for the 168 Arduino with 16 KB flash and 1 KB SRAM. It was just a toy to play with.

Now I want a microcontroller like Cortex M4 with more power than AVR but not an application processor designed for "hosting a rich OS platform" like the Cortex A series.

I have been developing a new FAT file system using STM32F4 processors. The difference in capability over AVR is overwhelming. I tried to love the Arduino Due when it came out but couldn't.

Here are two examples.

The ADC on AVR Arduinos run at a max of about 10 ksps with analogRead. You can increase the clock speed and get fair, not full 10-bit, accuracy at 40 ksps. Low end STM32F4 ADCs can do 2.4 msps, about 60 times faster than AVR with 12-bit accuracy and very flexible DMA. High end STM32F4 chips can run three ADCs interleaved for 7.2 msps.

I am developing a new file system for high end embedded processors. The STM32F4 has a good, not great, SDIO controller which can run the 4-bit bus at over 48 MHz. I have achieved sustained read speeds over 20 MB/sec. I have sustained write speeds of 12 MB/sec but this is a limited by the SD card I am using. I have ordered a new Samsung Pro card and hope to write at close to 20 MB/sec.

The AVR can never read or write faster than about 500 KB/sec that's about the best you can do with program I/O on the 8 MHz SPI bus. In addition SD cards don't present their fast commands on the SPI bus, only on the SDIO bus. This means you will have very long occasional write latencies with SD cards on the SPI bus.

The Arduino system software is not adequate for these new chips. You really need priority based pre-emptive scheduling to take full advantage of the features of these chips. Most chip manufactures are now providing a free RTOS solution. ST and Atmel provide FreeRTOS ports, Freescale has MQX, and there are other great systems like ChibiOS.

I really enjoy development with boards like the STM32F4 Nucleo boards. ChibiOS can do about 1.2 million context switches per second on the NUCLEO-F411RE. I am using a Olimex stm32-H407 and it can do a context switch in 400 ns. The 407 has 196 KB SRAM and 1 MB flash.

fat16lib:
This means you will have very long occasional write latencies with SD cards on the SPI bus.

I think I noticed this while working on a recent project and wondered why it happened.

fat16lib I must say that I have had a similar experience with the stm32f4 discovery board. Today I was messing around with some of my camera modules that I own and was amazed on the ease of use. All I had to do was setup the DCMI and DMA peripheral and then I can easily take pictures without cpu intervention. I also wrote a program that does real time sample synthesis that is impossible on the arduinos based on AVR mcus.

To discuss the future of Arduino there should be more transparency about project in development: TRE and Zero.

  • What problems remain?
  • Date of delivery
  • Selling price
  • Progress in library. Remaining bugs.

I have some other remarks :

In the future a FPGA might be build into a microcontroller, to have the best of both worlds.

One built a microcontroler inside an FPGA and not the contrary. It soon exist: Xilink and Altera propose this.

[Quote from: dannable on July 14, 2014, 08:47:36 am]
I think if it is to have a future then the infamous Uno 'avrdude: stk500_recv(): ' errors need to be addressed.

I have never seen this problem myself with a genuine Arduino board & drivers.

You perhaps, but I yes. I buy an genuine UNO R2 in an official reseller and it was buggy : Win 7 and Linux don't recognize it.
At the date of purchase the bug was solved since four months but bugged cards has been sold without correction.

I am convinced that there are three markets:

  • Simple applications where avr 8 bits is sufficient
  • Most powerful applications where ARM is necessary
  • This of some beginners who do not know how to use a microcontroller but absolutely want the most powerful and newest model.
    For this market you need one card but no more, it is useless.

The market targeted by the TRE is absolutely not this of beginners.
I find that in this headlong rush, Arduino abandons its core market to a semi-professional market.
In this semi-professional market it will face the MBED project (NXP, Freescale, ST, and so on.) .
For your information signe on MED , you will discover a true professional environment with a free personal git.
They come from the professional market and they can crush Arduino.
To survive Arduino must not leave the market for beginners and avr.

Three members of forum fit respectively Eclipse, Code Blocks and Xcode to arduino libraries .
Whoever adapted Xcode leaves Arduino to Energia, tired that arduino team does not answer his questions.
So Mac user who want use Xcode will switch to Energia.

Why there has no support from the team ?
The work was done, they had only to formalize and integrate the authors in the team.
May be they do not want anyone in the team to be able to control everything ?

I got two stm32f4, and compared to the arduino, they are very hard to use.

Once I got the thing to work, which took about a year [ I was distracted by other things ], I implemented a lot of the arduino functions on it so I could use the same stuff.

What do you compare :
avr 8bits with STM32 ARM 32 bits
or
DUE ARM 32 bits with STM32 ?

If is the first case I agree with you, but if is comparing carrots with patatoes.

I've just received a Tiva C-Series TM4C1294XL evaluation board from Texas Instruments.. $20 usd.. (I wish the evaluation board included the microSD interface for a few more dollars, but oh well...)
I will see if it is better suited for some of the more challenging personal projects I'm working on where I had originally intended to use DUE.

However, for some really simple projects with commercial application that I'm developing.. 8 bit Arduino UNO gave me the skills and confidence to move to Tiny84a for the release project. Even Tiny84a is more powerful than I need, but I'm sure I would not have stumbled upon this little guy, if it weren't for diving into Arduino and the DUE 18 months ago.

I've just received a Tiva C-Series TM4C1294XL evaluation board from Texas Instruments.

Looks like a nice board.

This is great, the major companies are all building boards that can compete with Adruino and are talking to users.

We are looking forward meeting Makers and showcasing the MCU LaunchPad development ecosystem at Maker Faire Bay Area in San Mateo, Calif.

These companies are also working with universities to provide better tools and products for labs.

It's intended for artists, designers, hobbyists and anyone interested in creating interactive objects or environments.

For this market, a product has to be "right-sized." The Duemilanove with m168 was about perfect for a lot of things; the m328 versions added additional memory space "for free", so that was OK too.

The next question is "what else will people pay for?" Arduino MEGA? Networking? Depressingly overpriced in the Arduino arena, IMO. But a lot of those "art" and "design" projects seem to have a weird budget model (compared to "hobbyist" or "commercial" anyway.)

After that, perhaps "how much can be improved at the same price points?" I haven't been inclined to do much with MEGA or Due, but I have some Teensy3 modules, ChipKits, and m1284 boards. They're swell, I think. Arduino Zero might have potential.

Things like the RPi, BeagleBone, ST, NXP, and TI ARM boards have always bothered me. As a hobbyist, they're OK. But my theoretical "goal" is small scale production of custom electronics (say, 100 to 1000 boards?) With a mega328-sized design, I can easily plunk down the "meat" of an arduino on my own board design, assemble them by hand, and be done. For the small pitch parts on the "more powerful" designs, I don't think that there is any way I can duplicate the cost of the sold boards with my own board, by the time I do the 4+ layer PCB and contract assembly. Maybe I shouldn't care, and using vendor-subsidized
modules with questionable product lifetimes and licensing issues is the way to go. :frowning:

I watched with some amusement and horror as linux system administration issues on RPi and BB replace the programming and electronics issues people have with Arduino/etc. :frowning:

I'd like to see an OS that is closer to Bare Metal for BB and RPi. Or an OS for Teensy/NXP/ST/TI that is better than the current bare metal, without sacrificing the "ease of use" of the Arduino libraries. But I don't think that either one exists yet. :frowning:

Small simple projects will continue to use the bare metal approach. An OS makes little sense for under 32 KB of program space. A simple development environment is adequate.

For larger DIY/hobby projects using 32-bit processors there are now many hardware options and the future will bring many more. It would be a shame to be limited to choices made by the Arduino company.

About 30 years ago big science faced a similar situation. From the late 1960s to mid 1980s DEC (Digital Equipment Corp) minicomputers dominates control and data acquisition in large science experiments. DEC supplied the software environment with systems like RSX/M, a real time system, and VMS for larger VAX machines.

Around 1985 single board computers based on the MC68000 and other microprocessors started to be used There was no standard OS for these boards.

Fortunately two of my friends, Jerry Fiddler, and David Wilner, had left the Lab in 1982 and founded Wind River Systems. Wind River developed VxWorks which is a flexible RTOS that can be targeted to a wide variety of processors. VxWorks became very popular in large physics experiments, space experiments like the NASA Clementine moon probe, and the Mars landers. This defacto standardization was really important for big science at that time.

UNIX on SUN and other work stations became the standard OS for operator consoles and other non-real time applications . Linux is now the best choice for boards like Rpi and BB that have Cortex Application processors.

The problem is that there are too many RTOS choices for micro-controllers like Cortex M and PIC32. Many companies are supporting FreeRTOS but it is not technically outstanding.

I like ChibiOS/RT but it only has great HAL support for STM32.

I think Arduino is like Digital Equipment Corp and will fade in the same way. There will are too many other outstanding hardware options and there will be even more in the future.

There is not an obvious software solution for DIY/hobby users. FreeRTOS supports a wide variety of hardware, just look at this list Microcontrollers and compiler tool chains supported by FreeRTOS. FreeRTOS is just not very exciting.

Too bad it is so easy to build a little RTOS kernel, this means there are many half baked RTOS systems instead of a project like UNIX and it's follow on, Linux.

westfw is right, the problem is the proper OS for DIY/hobby users.

Or an OS for Teensy/NXP/ST/TI that is better than the current bare metal, without sacrificing the "ease of use" of the Arduino libraries. But I don't think that either one exists yet.

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.

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.

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:

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.