Arduino Due + Eclipse + C++ = Arduino++

[Andrea Palazzi]

Hi,

I've started the development of a full c++ standalone library derived from the Arduino library.

MOTIVATION:
The Arduino IDE is great for a beginner, but it hides too many things when someone wants to dive more into the bare metal programming.
Also, I like C++, but the Arduino environment is more resembling of a mixed C/C++, and I think that the Due and probably also the Zero have more than enough horsepower  to run full C++ applications; eve though the actual Arduino library is already written in C++, there are still many things that can be done only through C-ish calls - digital and analog IO, delay(), ...

THE PROJECT:
The project aims at obtaining 1) a fully c++ library, derived from the official library, to program Arduino boards, and 2) a comforatble Eclipse setup where one can develop Arduino applications.

STATUS:
The project is made of two pieces: the library itself and a template code that will hopefully become an Eclipse project template.
I can build a subset of the core library, enough to make a "blink" test case - but without delay(), that I plan to replace ayway.
The code uses standard start files and libraries (that is, the flag --nostdlibs is NOT enabled).

TARGETS:
- write a fully C++ library: keep at a minimum the C-ish functions
- easily customization of main(), setup() and loop(): in the actual form they push towards the use of global variables, which is IMHO not a good programming behaviour
- rewrite the code so that it's more adherent to a recognized coding standard: MISRA-C++ would be optimal, but since it's not of public domain I'll stick to JSF coding standard: http://www.stroustrup.com/JSF-AV-rules.pdf
- if possible, reorganize the directory structure to keep at a minimum code dispersion, but still keepeing separate the different libraries (Arduino/ASF/CMSIS)

WISHLIST:
- upgrade to the latest version of ASF and CMSIS
- port it to different MCUs/boards

I plan to create a public repository on github with my code soon: let me know your comments, if you're interested, suggestions etc.

Thanks
Andrea Palazzi

[Matthew Ford]

According to Linus Torvalds (developer of Linux) “C++ is a horrible language” not suitable for low-level system programming. He recommends using C instead.  http://article.gmane.org/gmane.comp.version-control.git/57918

IMHO toggling output pins on a micro-processor qualifies as low-level system programming.
matthew

--
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.

[Matthijs Kooijman]

Hey Andrea,

> I've started the development of a full c++ standalone library derived from
> the Arduino library.

Are you talking about implementing libstdc++ / STL / etc. here? Or implementing an
API similar to Arduino's API (to toggle pin, control timers, etc.) in
C++? If the latter, you should have a look at Cosa [1], which is a
Arduino IDE-compatible core which, I believe, has a more C++-style API
and might be what you're looking for?

[1]: https://github.com/mikaelpatel/Cosa

Gr.

Matthijs

[bob cousins]

I don't want to get into a C vs C++ debate, I think that C++ has obvious merits but still tends to be heavy on memory footprint unless one is careful. High-level abstraction is great, but for low-level bit twiddling it can be a serious overhead.

So some sort of blend of C and C++ would be ideal for small and real-time applications, I'm not sure exactly what the perfect blend would look like. Arduino is already quite a good compromise I think.

Mbed and Chibios are interesting platforms which are more C++ friendly, and are multiplatform. I found them both a bit heavy for small projects, and a lot of effort to port to new platforms. So a light-weight C++ with a portable HAL would be of great interest. Being able to build in Eclipse is a must have feature for me.

I have worked on various 3D printer firmwares, and one thing they really lack is portability. I started writing my own rudimentary C based HAL, with a simple cooperative tasking and some Unix like IO, but now I feel I would like to start again with a C++ orientation. The Arduino API is great at what it does, but has some features I am not so keen on, otherwise it would be a good base to build on.

I will beinterested to see what you come up with :)

[bob cousins]

On Wednesday, August 6, 2014 8:17:06 AM UTC+1, Matthijs Kooijman wrote:

 If the latter, you should have a look at Cosa [1], which is a
Arduino IDE-compatible core which, I believe, has a more C++-style API
and might be what you're looking for?

[1]: https://github.com/mikaelpatel/Cosa

Cosa looks nice, but is targetted only for AVR processors. A multi-platform version would be great, not sure how easy that would be.

[Lars Poetter]

The discussion of good for beginners vs good for experts has been
decided upon. Arduino is for beginners, if experts can use it good, but
no features for expert that could confuse the beginners. So as your
clearly aim for the more experienced users the Arduino API can only be a
starting point but you will probably divert from it very fast.

> MOTIVATION:
> The Arduino IDE is great for a beginner, but it hides too many things
> when someone wants to dive more into the bare metal programming.

Here I have a problem understanding what you really want. Why do you
want to do "bare metal programming" ? For performance? To not be
portable? to torture yourself?

> Also, I like C++, but the Arduino environment is more resembling of a
> mixed C/C++, and I think that the Due and probably also the Zero have
> more than enough horsepower to run full C++ applications; eve though
> the actual Arduino library is already written in C++, there are still
> many things that can be done only through C-ish calls - digital and
> analog IO, delay(), ...

As you aim for the Due and refer to the "more than enough horsepower" I
assume that you don't want to do "bare metal programming" for
performance reasons. Especially as you seem to want to do the bare metal
programming in C++ with the standard Lib available.

In my confusion I now only see two options:

Either you are a desktop programmer that loves C++ (and hates C) that
used Arduino to get into embedded programming. You know have your first
experiences and think that with the Due you could introduce the much
more comfortable programming environment you are used from doing desktop
application to the Arduino world.

Or you love the Object Oriented programming and have seen how much
easier it makes programming. You have experienced that an OO environment
makes you much more productive and is much more flexible than anything
else. You dream of Objects for each Hardware component (Timer, Uart,
SPI, ADC,..) that you will then use in your OO Application in the
Arduino. You hope that this could give you portability, with
Applications that can be compiled for different Arduinos and just work
because the Hardware objects will just be compiled for the different
hardware with the same API.

Whichever it is you will soon run into the Problem that embedded is all
about performance and bare metal programming to get the best
performance. With "just" a new library that is nice and cleaner and C++
only and with standard Libs this will not work. There simply is no way
to do bare metal programming for performance in your environment. So
with just the Lib I see as your users those Desktop programmers that
don't want to do bare metal programming and don't want to learn about
embedded, those developers that just want a nice C++ only environment.
They are probably OK to get the performance of an Arduino UNO out of an
Arduino Due with your lib.

You should think twice if it is worth the effort to create this C++ only
environment for this user group.

On the other side. If you really want to dig into bare metal programming
and like to play with assembler then use the library just as API. Roll
your own compiler and do aggressive optimizing by breaking some of the
guaranties C gives and let C++ programmers create Firmware that gets the
same performance out of the Arduino that the C programmers get. With
only providing to compile the firmware as one module a lot more
optimizations could be done. With the additional knowledge that there is
no Operating System, that there is no other applications even more
automatic optimizations could be done. Then this would be an interesting
project. It might be that the result is that it can not be done, and it
is probably more work then you intend but it would be new and
interesting and not just another API for Arduino,..

[Matthew Ford]

>>So some sort of blend of C and C++ would be ideal for small and real-time applications, I'm not sure exactly what the perfect blend would look like. >>Arduino is already quite a good compromise I think.

I agree with this entirely. 

Arduino has a good blend on C and C++, being very light on the C++ side.
Classes to control variable name space and simple inheritance to abstract common functionality  are very useful.
I don't believe much else is needed so you could say Arduino is hardly using C++, which is as it should be for low-level programming.

matthew

--

[Rob]

Andrea ,

I invite you to checkout Motate, which is still in active development:

https://github.com/synthetos/motate/

The documentation is still thin, but you can get a sense of it front he Pin documentation:

https://github.com/synthetos/Motate/wiki/Motate%3A%3APin

Most of the code compiles to nothing but register manipulation, is heavily optimized for both speed and code space, it’s highly portable, and has a complete Makefile-based build system that could easily be placed into most IDEs.

-Rob

[Andrea Palazzi]

Hi,

I'm talking about an API as close as possible as the Arduino API.

I've looked at the Cosa; it's an interesting project, there are a few
critical points:
- it's a completely new API, while I'd like to keep the "new" API as
similar as possible to the actual (and well known)
- it support only AVR, while I'm focusing more on ARM. With AVR in fact
C might be a better choice than C++
- it relies on the Arduino IDE, while I'm aiming to make Eclipse the
preferred IDE

Anyway, I could take some pieces and use them in my project - hoping
that there's not an avalanche effect.

Bye
Andrea

[Andrea Palazzi]

Hi,

Il 06/08/2014 20:55, bob cousins ha scritto:
> So a light-weight C++ with a portable HAL would be of great interest.
> Being able to build in Eclipse is a must have feature for me.

That's exactly the aim of the project, you nailed it more clearly than me :)

Bye
Andrea

[Mikael Patel]

Hi Andrea (and developers).

I would like to comment on the conclusions about Cosa being the
principle researcher, architect and designer behind Cosa.

On 08/07/2014 09:44 AM, 'Andrea Palazzi' via Developers wrote:
> Hi,
>
> I'm talking about an API as close as possible as the Arduino API.
>
> I've looked at the Cosa; it's an interesting project, there are a few
> critical points:
> - it's a completely new API, while I'd like to keep the "new" API as
> similar as possible to the actual (and well known)

Cosa is designed to use C++ for higher performance and lower footprint
than C. For instance, basic Cosa Pin operations are X5-X10 faster than
Arduino. C++ allows more compiler optimizations to be exploited.
Conceptually it is easier for beginners to build larger systems with OOP
(Please see SmallTalk and Simula). OOP also offers an easier integration
methodology.

Adapting to the functional Arduino/Wiring API is more or less a one
liner (Please see the Pin benchmark).

> - it support only AVR, while I'm focusing more on ARM. With AVR in
> fact C might be a better choice than C++

Cosa is object-oriented with a focus on both application APIs and device
driver APIs. The so called upper and lower bound APIs. In Linux they are
application libraries, system calls, and device driver interfaces.

One of the major issues with Arduino/Wiring is that it is not clear how
to extend with new drivers. There is also a lack of common device driver
handling. This is one of the reasons why using different Arduino
libraries can be a challenge. The Cosa SPI driver support is a good
example of how this can be structures to allow multiple drivers on the
same bus.

Cosa is designed for multi-variant/multi-target. There is a very small
set of base classes that are hardware dependent. These are the Cosa HAL.
It is possible to port to ARM etc but the issue is much larger as with
the available resources would allow multi-tasking, etc.

Cosa is built for scaling from Tiny up to Mega (and other processors).
Cosa follows some of the structure of a RTOS. Building RTOS and tools
for base-station development on many core DSP systems is my day job :)
And with many I mean 32-128 DSPs per chip and at least four per board.

> - it relies on the Arduino IDE, while I'm aiming to make Eclipse the
> preferred IDE

Cosa can be used with any IDE. I use GNU Emacs together with the Cosa
command line build support system (built on Arduino-Makefiles and
miniterm.py). The alternative Arduino IDEs all support Cosa; embedXcode,
UECIDE, and Eclipse. Using Eclipse/CDT is a question of configuration
with the cosa build support and no big issue. Correctly configured both
embedXcode and Eclipse with use the Cosa documentation and give dynamic
help.

I have this configured of Eclipse on my machine but only use that for
demonstration as I am more productive with old-school tools -- GNU
Emacs/Make/Etags. Cosa has grown with approx. 500-1000 lines of code per
week over the latest year. It is difficult to achieve with all the
"distractions" in modern IDEs such as Eclipse. And they drain the
batteries on my laptop too fast :)

The Cosa command line build allows rapid rebuild of very large sketches
with many libraries. It is based on makefiles but wrapped in such a way
that users only need to give the board type as command parameter instead
of writing a makefile per board. For instance, the command "cosa nano
avanti" will build, upload and start the serial monitor (for Arduino Nano).

And yes, you can use Cosa through the Arduino IDE (1.0.X and 1.5.X) but
I would only recommend that for sketches smaller than a few hundred
lines of code.

Cheers! Mikael

[bob cousins]

I find Motate interesting for a couple of reasons, and I've seen it suggested before. It's designed for CNC firmware which is quite similar to 3D printer firmware.

But I look at https://github.com/synthetos/Motate/blob/master/MotateProject/motate/Atmel_sam3xa/SamPins.h, to guage how easy the codebase is to work with. There are macros to generate templates to generate objects. I am sure it compiles to efficient code, but it seems a lot of work compared to a few lines of C.

I am not a C++ expert, I admit that. I guess C++ people might look at that code and think "there's some awesome C++ coding!", but I am thinking "this is not the light-weight, easily portable HAL I am looking for". Decompiling object code back to assembler might lead to highly efficient code, but it seems like a really time-consuming way to write code.

Most of the time, maximally efficient setting of IO pins is not necessary, only in cases where you are bit-banging SPI or something (which arguably should be left to hardware anyway), and if you have a faster CPU like ARM it seems worth sacrificing a few cycles. By the time you have finished writing the code and debugged it, there will be a faster chip available which is also cheaper. So IMHO it would better to write as little hardware specific code as possible, with a view to porting to faster hardware, instead of hand-crafting code to a particular CPU.

My 2c.

[bob cousins]

Excellent! When will it be ready? :)

I've got dev boards ranging from Cortex-M0 up to Cortex A at 536Mhz, with chips from Atmel, Freescale, NXP and STM, so if you want a tester, let me know.