According to Wikipedia a “Lingua Franca” is a language systematically used to make communication possible between people who do not share a native language or dialect.
In the last 12 years Arduino has grown to be the “lingua franca” of microcontrollers, a set of API implemented on a large number of different architectures making it very easy for people of every skill level to learn to write embedded code and to port code from one processor to another.
Yesterday 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.
I’ve selected some of the projects I’ve presented yesterday that can help us get there:
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.
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!
I jokingly described my talk yesterday as the “most boring talk I ever gave” but I’m happy to go back talking about what we can do to make our platform better and be able to tackle bigger challenges. Join the dev mailing list, check out github and help us out!