Pages: [1] 2 3 ... 6   Go Down
Author Topic: Comments on Arduino 1.5 Specifications  (Read 15738 times)
0 Members and 1 Guest are viewing this topic.
France
Offline Offline
God Member
*****
Karma: 11
Posts: 637
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Arduino has released two entries of its wiki about the specifications for 1.5:


I like the new structure described in 3rd party Hardware specification. It is cleaner and more open to 3rd party. I've already implemented it in my embedXcode project.

Now, IMHO, I'm not a big fan of the new library specification, as the files of a single library are going to be split among different folders.

See the example provided for Servo:

  • Servo.h goes under Servo/src/
  • but Servo.cpp is under Servo/arch/avr/.

This means parsing the directories in search for all the files and thus makes the makefiles more complex.

What do you think?

As Arduino is taking the lead over Wiring, I guess all the Processing-based Wiring-derived Arduino-like IDEs have little choice but to comply with the new standard.

I hope Arduino is considering taking a more advanced editor with now standard features as code completion, syntax helper, and a much needed debugger.
Logged


Belgium
Offline Offline
Edison Member
*
Karma: 68
Posts: 1893
Arduino rocks; but with my plugin it can fly rocking the world ;-)
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Now, IMHO, I'm not a big fan of the new library specification, as the files of a single library are going to be split among different folders.

See the example provided for Servo:

  • Servo.h goes under Servo/src/
  • but Servo.cpp is under Servo/arch/avr/.

This means parsing the directories in search for all the files and thus makes the makefiles more complex.

What do you think?
I'm happy you bring this up  smiley-twist

As provider of the Arduino eclipse plug-in I fully agree. Most of the 1.5.X changes are great improvements but I see this library change as over-engineering because of the focus on multiplatform. Many libraries are not multiplatform. I think there are enough c++ ways to solve the multiplatform problems for the libraries that need it; without dependencies on the IDE/make.
Note that I do like the dependency tree smiley-grin

Best regards
Jantje
Logged

Do not PM me a question unless you are prepared to pay for consultancy.
Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

0
Offline Offline
God Member
*****
Karma: 25
Posts: 602
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Duplicate code for each platform will very likely lead to libraries that poorly support the less-used platforms.
Logged

France
Offline Offline
God Member
*****
Karma: 11
Posts: 637
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@Jantje

I'm glad you share my humble opinion.

@Paul

I don't see clearly the link between the availability of a library for a given platform and the new structure for the libraries on the Arduino 1.5 specifications.

Some boards —as Teensy and Digispark— add plug-ins to the main Arduino IDE. How to proceed with the installation of the libraries included on a plug-in? What will happen when a plug-in provides a header specific to its platform when the header is already on the top folder —like the Servo example with servo.h?

Dealing with conditional pre-processing statement to deal with the different platforms / architectures is a nightmare I've been dealing with when I've developed the embedXcode template for Xcode. The template currently supports Arduino, chipKIT MPIDE, Digispark, LaunchPad Energia, Maple, Teensy and Wiring.

I rather prefer today's de facto approach with one folder per platform / architecture, with everything related to it: cores, variants, firmwares, libraries, system, bootloader.

See below the examples of
• Arduino 1.5.3 with avr and sam
Energia 0101E009 with msp430 and lm4f, a fork of Arduino for Texas Instruments' LaunchPads

I'd appreciate some feedback from the Arduino team.


* Arduino153.png (32.9 KB, 236x382 - viewed 71 times.)

* Energia009.png (23.04 KB, 203x231 - viewed 426 times.)
« Last Edit: May 12, 2013, 11:04:52 am by avenue33 » Logged


France
Offline Offline
God Member
*****
Karma: 11
Posts: 637
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I'd appreciate some feedback from the Arduino team.

Arduino team, are you there?
Logged


North Queensland, Australia
Offline Offline
Edison Member
*
Karma: 64
Posts: 2100
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Duplicate code for each platform will very likely lead to libraries that poorly support the less-used platforms.

I like the idea that the 1.5.1 had ( not used later ) where it has a global 'libraries' folder, and then an architecture specific 'libraries' folder. This approach is far more standard, as you could simply define a bunch of macros specifying the Due's existence, allowing me to simply use a ifndef to exclude/include specifics.

Or I could place my entire library in an AVR specifics folder if it was not Due compatible.

Arduino needs to move closer to C++, rather than try and hide it behind the scenes. All it does for newbies is add to the confusion as they do not realise they are using C++, and parts of the standard are not applicable because of Arduino's hidden background changes and inconsistent use of file structures.
Logged


France
Offline Offline
God Member
*****
Karma: 11
Posts: 637
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Arduino needs to move closer to C++, rather than try and hide it behind the scenes. All it does for newbies is add to the confusion as they do not realise they are using C++, and parts of the standard are not applicable because of Arduino's hidden background changes and inconsistent use of file structures.

I fully agree with Arduino needing to go closer to C++. That's the very paradigm behind embedXcode, the template I've developed for Xcode: plain C++ code and makefiles.
Logged


France
Offline Offline
God Member
*****
Karma: 11
Posts: 637
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Bump!
Logged


France
Offline Offline
God Member
*****
Karma: 11
Posts: 637
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Arduino team, are you listening?
Logged


Offline Offline
Sr. Member
****
Karma: 4
Posts: 327
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

very unlikely
  its August, Italy is closed,

Logged

France
Offline Offline
God Member
*****
Karma: 11
Posts: 637
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Since May?
Logged


Forum Administrator
Milano, Italy
Offline Offline
Sr. Member
*****
Karma: 23
Posts: 292
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi,

If you want to go with the classic C++ way (a big chain of #ifdefs), you're allowed to do so just ignore the arch/ folder.
This is not explicitly stated in the documentation, maybe its worth adding it, I don't know.

When I first implemented the new library format I've checked its functionality with two example of the Servo library:

1) the first example uses the classic chain of ifdefs:
https://github.com/cmaglie/LibTest/tree/master/libraries/Servo

2) the second uses the arch/* folders way:
https://github.com/cmaglie/LibTest/tree/master/libraries/Servo2

Both can be used, I could say that its a matter of taste, personally my favorite is the method 2).

Also note the with the library.properties you can filter the library from being displayed/compiled on architectures that are not supported by the library itself.

Logged

C.

France
Offline Offline
God Member
*****
Karma: 11
Posts: 637
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Thank you for the explanations.

My only concerns is the header is on one folder while the code is on another.

Not easy to deal with using plain makefile!

Another problem is, the shared header is compulsory for any new architectures.

  • What happens if a new architecture requires a modification of the header?
  • Who is going to maintain this repository?

My fear is, this structure looks like pretty much a walled garden...

Please note there's a third option: as for Energia, the libraries folder is under the main architecture folder.

So there's a hardware/lm4f/libraries/servo folder and a hardware/msp430/libraries/servo folder.

Logged


Forum Administrator
Milano, Italy
Offline Offline
Sr. Member
*****
Karma: 23
Posts: 292
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@avenue33

My only concerns is the header is on one folder while the code is on another.

Not easy to deal with using plain makefile!

why not?

if a new architecture needs a different header, this means that the header itself is architecture dependent and should be placed in one arch/xxx folder or, alternatively, the architecture-dependent piece of code needs to be placed around #ifdefs.

C
Logged

C.

Belgium
Offline Offline
Edison Member
*
Karma: 68
Posts: 1893
Arduino rocks; but with my plugin it can fly rocking the world ;-)
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@avenue33

My only concerns is the header is on one folder while the code is on another.

Not easy to deal with using plain makefile!

why not?

I have the same problem with the eclipse plugin that is also based on (automatically generated) makefiles.
Basically the code included in the project is "the root folder and all subfolders"
Having method 1 as you describe makes I have 1 folder for each library.
For method 2 I have to do something smart because I do not need all subfolders.
In your servo example for method 1 I only need the folder
./libraries/Servo/src ( Great I don't even need to exclude examples)
To be added to the include and source path.
In method 2 I need to include
./libraries/Servo2/src
To the include path (and probably also to the source path)
and
./libraries/arch/${arch}
to the include and source path.
I think this has following disadvantages:
1) It is more work for the tool (while C/C++ has already fixed this)
2) It breaks upwards compatibility for tools.
3) It is not obvious from the code what is going on.
4) There is no easy way to notice a hardware is not supported.

I was wondering: have you considered a c/cpp file like this?
Code:
#ifdef ARDUINO_ARCH_AVR
#include ../arch/avr/Servo.cpp
#elif ARDUINO_ARCH_SAM
#include ../arch/avr/Servo.cpp
#else
#error The hardware is not supported
#endif

Best regards
Jantje
Logged

Do not PM me a question unless you are prepared to pay for consultancy.
Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

Pages: [1] 2 3 ... 6   Go Up
Jump to: