A few weeks I gave my usual presentation at Maker Faire San Mateo about the work we’re doing on the Arduino open source project and in which directions we’re hoping to take the platform. One of the key messages was that we want to make it as easy as possible for the community to run their code on as many platforms as possible with the least amount of changes.
Project Chainsaw; In recent years Arduino has been ported to a ton of different architectures and this has generated a lot of misalignment between each version, with different implementations of code that is essentially cross platform and there is no reason to re implement it multiple times.
A few months ago I realised I couldn’t re-use an example because the IPAddress class was older than in the SAMD core and I decided we had to do something.
Project “Chainsaw” is about separating the cross platform Arduino API code from the platform specific code creating a sort of “Hardware Abstraction Layer” which should make it much easier to port and maintain Arduino. We have an experimental repository we will open up in the next few weeks so that anybody can contribute and potentially adopt it for their port. This will mean that any bugfix in the common code will benefit all ports of Arduino and we can better pool resources between efforts and avoid duplications.
ArduinoAPI: When we launched Arduino we provided libraries for basic peripherals like SPI, I2C because the processors we used back then were quite simple and the projects people built were not that sophisticated yet. If somebody needed extra functionality they normally coded them in C or even Assembly. Right now, after the adoption of X86 or ARM processors we have more features available and each Arduino port is implementing them in a slightly different way. I think it’s important we have high level “abstract” API for thing like Bluetooth Low Energy , Low Power, Date/Time, IMU, HTTPClient, Timers, Crypto. I’ll publish the full list in a separate message to the developer list and release a set of repositories where we can comment on the API and hopefully converge.
Arduino Pre-Processor: In the last few years we’ve tried to “carve out” as much “business logic” as possible from the IDE to place it in external (open source) tools that are installed as binary command line processes. One of the major changes we introduced is the arduino-builder . This tool takes your code and turn it into full blown C++ automating a numer of steps that people have to do by hand in other IDEs, things like: discover the dependencies for all the libraries you include, generate prototypes for the functions you create, pass the files to the compiler, get a binary file, upload it and a lot more. Arduino-builder takes care of all of this. Unfortunately the pre-processing part had some weaknesses that made it unreliable in some edge cases. Thanks to an impressive effort of our Cristian Maglie, he managed to re-write the preprocessor using CLANG from LLVM. This means that parsing the code is more robust and the quality of the resulting code is better. Bonus feature is that we can use this new parser to ask to the compiler directly what functions can be used in a specific point in the code allowing us to add autocomplete to the IDE. Again look at the developer mailing list in the next few weeks when we’ll release this new experimental code. We need as many people as possible to test it before we can include it in the IDE. We’ll release this tomorrow!!!
Arduino Library format: With the introduction of Arduino 1.6.x we improved the layout of the Arduino libraries to support multiple architectures, metadata and more. One of the areas that needs improvement is documentation. At the moment documentation for libraries is kept separate from the source code itself. We will update the specifications to the Arduino library format to include a folder for documentation that can be written either in markdown or asciidoc. This will allow us to keep the documentation in sync with the code and make sure they don’t go out of sync.
Finally there are two longer term project we definitely need to get done before the end of the year:
Scheduler: A task scheduler to achieve some level multitasking on Arduino. There is a lot of code out there but , unfortunately, it’s all quite hard to understand unless you’re an expert. Let’s see if we can build something that can be used by most of the Arduino users.
Debugging: We did quite a bit of work on the backend with the help of Matthijs Kooijman and we were waiting for a sponsorship to complete the UI part. Unfortunately the sponsorship didn’t materialise so we’ll schedule this as soon as we have funds or a developer who wants to do it!
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
Scheduler: A task scheduler to achieve some level multitasking on Arduino. There is a lot of code out there but , unfortunately, it’s all quite hard to understand unless you’re an expert. Let’s see if we can build something that can be used by most of the Arduino users.
Clause 2: FreeRTOS may not be used for any competitive or comparative purpose, including the publication of any form of run time or compile time metric, without the express permission of Real Time Engineers Ltd. (this is the norm within the industry and is intended to ensure information accuracy).
For me, that is not an acceptable restriction, I would even say it makes it non-Open Source according to GPL principles.
https://www.gnu.org/philosophy/free-sw.en.html
"The freedom to run the program as you wish, for any purpose (freedom 0)."
--
--
> email to developers+unsubscribe@arduino.cc.
>
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
> email to developers+unsubscribe@arduino.cc.
>
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
Only the key concepts are left, a "Task", a "Semaphore" and a "Mutex". How the implementation is done behind the scenes is then a different question. Just because RTOS xyz is popular or well known does not mean it's appropriate for the task at hand.
An alternative approach, designed for school kids, is used by micro:bit. It is 'fibers' (see https://lancaster-university.github.io/microbit-docs/concepts/#concurrency and http://www.forward.com.au/pfod/microbit/gettingStarted.html)
Locks
and semaphores (and interrupts) are a trap for young (and
old) players. micro:bit avoids them by using message
passing and non-preemptive scheduling instead. Much easier
and more robust for programmers.
A
non-preemptive scheduler is closer to what the current
design of an arduino sketch is. Just one thing happens at a
time.
Lancaster University's C++ support implements a lightweight thread model called fibers. The multi-tasking is co-operative. That means while one part of your program is running other parts are not. Programs that do more than one thing at a time are called concurrent programs. The micro:bit C++ runtime provides two ways you can achieve concurrency in your programs:
The
multi-tasking scheduler is a type of non-preemptive scheduler.
This means that the runtime will never take control away from
your program - it will wait for it to make a call to a runtime
function that is blocking. (All the functions that are blocking
are listed as such in their documentation.) This means you do NOT need semaphores to guard lock test
and set. If you need to guard a method
from being run by more then one fiber you can just use a
simple bool value, say for example bool status, and test it on entry and
return if some other fiber has set it. See below for how to
queue access to a resource. ....
Hi Thomas,
> My USB/MSC requirement is such a good case
micro:bit handles USB and IMU OK. I believe it does it with
interrupts and posts messages. For a example see my
implementation of a serial connection to micro:bit BLE in the
library
http://www.forward.com.au/pfod/pfodParserLibraries/pfodParserMicroBit.zip
and for a complete example see the project
http://www.forward.com.au/pfod/microbit/androidControl.html
Matthew,
thanx about the pointer to the fibers. I need to recheck those links you included.
Interrupts and bad effects. For the STM32L4 I ended up using the PendSV logic a lot (ARM Cortex). Essentially there is a callback queue (or event queue if you want), where the real ISR puts a callback plus some arguments. That conceptually is really a 2nd execution priority over the normal "loop()". The callbacks are really one-shot tasks, which is often what the name "fiber" is used for. Overall it turned out that users having access directly to ISRs is not a good idea, as most of them will screw up a carefull layer out priority scheme, but putting in a "delay(1000)" in the highest priority ISR ..
In general I'd argue that you need pre-emptive multitasking. My USB/MSC requirement is such a good case. The USB ISR drives the USB/MSC logic, which then forwards the the SCSI handling to such a PendSV handler. But the reading/writing to the medium should be left to a task, as it might block, and may have to deal with concurrent access to a SPI (this is where mutexes come in handy). Granted, this is a system layer requirement, and may or may not be relevant to a real user scenario in terms of API.
A good example for wanting a preemptive scheduler is when you do things like reading/processing IMU data. In that case you want your main task interrupted and the higher priority processing being done.
- Thomas
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
Il giorno 08 giu 2017, alle ore 00:33, Thomas Roell <grumpyo...@gmail.com> ha scritto:RTOS
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
Carmine Spizuoco
Skype: Carmine.Spizuoco
Cell: 0034 640 20 43 52
Actually
Multithreading Non-preemptive Event Driven System based on message passing.
seems better to me.
You really want your longer running threads to block so that other threads get a chance to run. For example delay() puts the current thread to sleep to be woken up later and lets other threads run.
Automatic low power sleep mode.
An interesting aside. If all threads are sleeping/blocked, then you can put the processor into low power mode automatically. This removes the need for special processor specific sleep calls from the user code. The microprocessor specifics are hidden from the user in the scheduler code.
I believe micro:bit does this. It draws <2mA while running and connected via BLE and actively sending and receiving msgs.
Non-preemptive threads, on a single processor, removes the need for the user to use volatile (assuming they are not writing interrupt routines)
But we should consider how we will use this concept in multi-core
processors. Ideally the threads should run on any available core
and the threading/scheduling library should look after
volatile/synchronize as necessary. The ESP32 already has 2
processors and in the near future Arduino boards will have more.
Any design should take that into account.
matthew
C.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
For Serial I was thinking of having 2 pre-allocated buffers which are never freed. At the end of the message processing the call to "free" just marks the buffer a empty
so receive a char, put in buffer 1 post msg with buffer 1.
Switch to buffer 2 to hold subsequent received chars while waiting for buffer 1 to be processed and 'freed' i.e. marked as empty
When buffer 1 is 'freed' then post msg with buffer 2 and switch
to filling buffer 1 etc
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
> To be honest, this is pretty much the exact request that I see on the Arduino Forums - “I want to take this sketch that does X, and this other sketch that does Y (unrelated to X), and run them at the same time.”
Quite a bit I don't follow the forum, bit normally people who make this statement what the two code speak each other, like showing the data of the sensor on a web page of using it controlling something.
And this is exactly where all the issue with synchronization come into play, issue that is not seems in the small independent program run on your PC; the PC is a complex beast with hw and sw specialized for multitasking, simulating even basic stuff on a MCU is way different and with different design challenge.
The fact that is *possible* does not make it a good idea; after all you can boot Ubuntu from an atmega.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
"too hard" is relative.
Let's argue for a moment what a library needs minimally: