With the upcoming much more powerful Arduino boards (ARM and friends) we will be able to tackle more complex problems and all the great Arduino libraries plus a RTOS might be helpful. Also if we would have multithreading in mind from the beginning the libraries could be designed accordingly from the beginning and there would be no need to add somehow multithreading support to them as an afterthought like it is right now.
Is there going to be any Arduino officially supported multithreading solution?
Robert, very good point. This is what arduino lacks. Most probably because even today the mainstream here is the 328p. I do not understand why such chips like 1284p are still not taken into serious consideration. 16kB of ram is big enough for any rtos or a simple os. p.
real multithreading is impossible in the normal Arduinos.
Why do you say that? (it could be true, depending on your definition of "real multithreading", but...)
this recently showed up on the Developers mailing list:
The ThreadKit library [Google Code Archive - Long-term storage for Google Code Project Hosting.] provides
simple, low-overhead, non-stack-based, cooperative multithreading on
Arduino and similar microcontroller systems. I have released a
preliminary version of ThreadKit for the Arduino IDE under the MIT
License. To demonstrate the library on the Arduino platform, the
project includes a two-voice music-playing program called Muser.
I have an Arduino UNO and DruinOS, which is derived from FreeRTOS, running happily on it.
FreeRTOS is a real RTOS and supports 8 bit microcontrollers like 8051, AVR, PIC18. I just ported it to a 18lf45k22 just because people were telling me that this is not possible
It certainly adds a few percent of overhead for those little machines, but I'm more after the concept of programming in threads compared to the superloop, as it is typical for the Arduino.
Projects are usually growing and having an RTOS just helps to break things into tasks and to add new tasks without seriously affecting the timing.
Hey I'm a geek and use a RTOS even on small microcontrollers
... but as bigger microcontrollers are getting cheaper and cheaper it's certainly a topic we should look into a bit to be ready to roll on future Arduino boards ...
I don't know threadkit, but judging from what I can see from the sources it's very limited because it is a cooperative scheduler and not a preemptive one and lacks interprocess communication primitives like e.g. semaphores, mutexes and queues.
limited because it is a cooperative scheduler and not a preemptive one
You can do a LOT of multitasking without preemption. cisco and procket operating systems were both cooperative... Sometimes preemption causes as many problems as it "solves."
BTW, the biggest issue with rtos-es is the availability of drivers for ie. i2c, spi, uart, etc. Pushing few buttons and blinking few leds works nice, however when the drivers are needed the fun with rtoses stops..p.
You wrote: "the biggest issue with rtos-es is the availability of drivers for ie. i2c, spi, uart, etc".
Talking about Arduino. It's biggest strength is exactly what you see as the biggest issue with RTOS-es.
Hence my idea to combine both.
Wouldn't it be great to have a RTOS with an Arduino API or Arduino with a RTOS?
If this is something more people are interested in I believe it's doable and in order to minimize most of the troubles you have with drivers and RTOS-es it would be good to put hooks into the Arduino libraries from now on and not as an afterthought.
What I mean is, that we could create libraries where the shared resources are protected by macros, which expand to nothing when you don't use any RTOS and which expand to something when a RTOS is used. Also we could actually get a performance gain under certain circumstances by using a RTOS because there will be no need for polling and the CPU could be given to other tasks.
Anyhow these are just preliminary thoughts and we'll need more discussions and a careful design.
I am sure that RTOS-es will be used on ARM Arduinos. It would be nice if some thought was given to the core software so it would work well with the old style Arduino setup(), loop() or with an optional RTOS.
Leaflabs includes FreeRTOS as a library for their STM32 Arduino-like board.
Leaflabs has done a great job with their libmaple for the STM32 ARM processors.
pito:
BTW, the biggest issue with rtos-es is the availability of drivers for ie. i2c, spi, uart, etc. Pushing few buttons and blinking few leds works nice, however when the drivers are needed the fun with rtoses stops..p.
I'm not sure why you say that -- the ATmega chips are very capable of doing all those things. The bigger issue is that the open source / GPL libraries tend to be lower quality and/or functionality that commercial products. For hobbyists who want to use an RTOS, they'll have to write their own or get the quality of the libraries up to true production quality.
The other big problem is that the ATmega chips are Harvard architecture processors (separate instruction and data spaces) and have very limited data segment sizes. Even that can be resolved using some of the SRAM chips with an SPI interface -- adding massive amounts of SRAM to an Arduino is just a matter of allocating some digital pins and using those parts.
Arduino is open source so why not use other open source software with Arduino. There are several open source RTOS-es that work fine. FreeRTOS is used in lots of hobby projects and runs on avr.
Adding SPI SRAM is not very effective. avr SPI is very slow programed I/O. You can do a lot with the ATmega 1284, 16 KB SRAM.
ARM Arduino boards will be a better solution for larger apps.
I've been using and producing open source software for the better part of 25 years -- there's nothing wrong with using it, or producing it, but many open source projects suffer from abandonment or incomplete functionality even if they are being maintained. The most recent example of that is when I went looking for a Modbus sketch and wound up writing my own because the one that's most commonly referenced here and in other Arduino fora is both incomplete and very broken. Great for hobbyists, lousy for production-quality work.
The best advantage to using SPI SRAM isn't that it's fast (it can be), it's that it's huge. With a very small number of I/O pins you can get access to an almost unlimited amount of SRAM, 32KB at a pop. All the ATmega chips have all the pins needed to give you all the SRAM you can eat.
Guess you were talking storage. I can get about 830 KB/sec to external SRAM or 1200 ns/byte. Internal SRAM has a 62.5 ns cycle time. The limit for Arduino is mostly due to the max SPI rate of 8 MHz which is 1000 KB/sec.
For huge I like Dataflash. A 8-pin SOIC with SPI interface can store up to 16 megbits of data and costs under $2.50 from DigiKey.
I started developing/using open source software over 40 years ago so understand its nature.
When I needed reliable I went with systems like VxWorks from Wind River Systems, a company founded by two of my friends.
Arduino is open source. Look at the Arduino core and notice that it could never pass certification for use in a critical embedded system. So why worry so much about the stuff you use with it? You don't use Arduino hardware/software for serious critical applications.
What company do you buy your production-quality Arduino software from?
@Robert: Hmm, frankly, I would say you cannot use the existing libraries (ie i2c, spi, uart, etc.) for an rtos easily - you need to rewrite those as you need none blocking ones, you need to control a concurrent access to them from several tasks/threads, etc. This is the issue - my understanding is all drivers need to be redone..
So, again - I am writing here about "rtos-capable drivers and libraries"..p.
I wrote my first programs in the mid-70's, and started getting paid to do it in the late 70's. I think we've both been at this software thing a really long time.
If 830 KB/sec isn't fast enough, you really need a faster processor anyway -- memory shuffling is one thing, processing the memory you shuffle takes a bit more work. Even if there was no overhead in doing the memory transfer, you'd get something like 40 clocks per byte read and written at 16MHz. FWIW, the first processor I worked on executed about 90,000 instructions per second.
I'm still in early production for a Modbus-enabled product that will initially be based on an Arduino and a signal conditioning board I'll have laid out in the next week or so. If the product makes me money, I'll spend more money to make it better. As for the code, have keyboard, will travel -- I have over 30 years of kernel experience. I trust my code, and the best thing about my code -- I don't have to pay someone else royalties to ship it.
830kB/sec r/w is great for most applications arduino hobbists run! I wish I get a compiler which can compile into an external ram and to run code out of it!! AFAIK the IAR compiler can compile code to external ram of atmegax. @jfhaugh: when talking 70's - have a look at "retrobsd.org" - 2.11bsd runs on pic32mx (chipkit MAX32 board supported as well), it uses an sdcard for root partition and swap. We can write ~300-600kB/sec and read ~1-1.5MB/sec to the sdcard (it depends on sdcard used). I guess it outperforms most PDP-11 versions from 70's. We are looking for contributors as well. ]
P.
You can use existing libraries and device code with a RTOS. You just need to use the proper task structure with queues, semaphores, and mutexes to get sharing to work.
Currently I am playing with FreeRTOS and ChibiOS/RT. I like ChibiOS/RT for ARM but FreeRTOS is a better choice for avr Arduino.
Using a preemptive kernel takes knowledge/skill for proper use so it's not for beginners.
fat16lib,
I would be happy to see an example of using default arduino libs with an rtos, indeed .
I've ran chibios on my stm32vl discovery modules (the demo, I overclocked them, both 48MHz stable, one module 56MHz stable). So not bad for $10 gadget 8).
P.
I would say you cannot use the existing libraries (ie i2c, spi, uart, etc.) for an rtos easily - you need to rewrite those as you need none blocking ones, you need to control a concurrent access to them from several tasks/threads, etc. This is the issue - my understanding is all drivers need to be redone
The real question at this point is whether the APIs that have been defined by Arduino are reasonable if you suddenly put an operating system (let's skip the "RT" part for now; IMO, RT is overrated and ... really hard) underneath.
Mind you, it's not at all easy to do microcontroller-like things on top of an operating system. bit-banging I2C out a couple of general purpose IO pins becomes a choice of whether you want to move excessively slowly (by blocking) or have the functions take longer than you'd like. Ditto software-serial and SPI, though at a byte level; some things can be moved to interrupts, but the SPI hardware present on an AVR is still byte-at-a-time. Doing really well under an OS means you need DMA or highly buffered and intelligent controllers for each perpheral, and the AVRs don't have them. (some of the 32bit CPUs might.)
But pretty soon you end up with WINCE, .NET, or Android, where IO pins are no longer directly accessible, flexibility is lacking, latency sucks, and you need an (old-style) arduino-class board (with no OS) to play with real hardware. Fine if you want a micro web server that copies stuff from SD card to TCP, but lousy at driving that big LED matrix thing or doing retro electronic gaming...
You could do a "proof of concept" on an old linux PC. digitalWrite() out the parallel port, etc...
.