Go Down

Topic: Comments on Arduino 1.5 Specifications (Read 56519 times) previous topic - next topic

visualmicro

I think it would be a good idea to step back and look at the reasons why the newer structure is required.

Previously it was possible for various library authors to support some architectures but not all. This allowed users to include a library in projects that do not support the selected architecture. Very confusing.

The new structure allows the "Library Import" menu item(s) to accurately show the libraries that are valid for a project/architecture. This removes a whole bunch of support issues.

It might be that this point could have been achieved another way, such as a properties file and the old lib structure however the new structure works really well with many C++ intellisense systems. In fact in Visual Studio, as we  switch between Arduino architectures, we see "red squiggles" for "unsupported" #includes.  So this new system works very well indeed and is very clear for newer users.

By the sound of it even the older structure was a problem for some systems where by all library paths need to be combined into a "master list" of include paths. This is not how the Arduino compiler is normally designed to work, combining all lib paths regardless of the sketch #includes  leads to other issues unrelated to the new format.

Currently other support issues arise when a library that depends on another library is included by a user. The new properties system should allow us to ensure a more intelligent #include system either automatically including other libraries or by prompting the user to do so.

The new system has a lot of future flexibility (potential) such as supporting "auto download" of missing dependencies and better version control.

I am not suggesting the new system is perfect but the clarity it brings to the UI looks GREAT and the reduction in potential support problems is a big plus.
Arduino for Microsoft Visual Studio Pro and Atmel Studio 6.1 http://www.visualmicro.com
Arduino Debugger http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx

bperrybap

VisualMicro,
I fully understand the goal of a better library & build process.
The problem is that the goals you mention cannot be achieved with the current specification.
Yes it can work for simpler libraries, but not for more complex libraries or libraries
that have different maintainers for the different architectures.
Have a look at the specific examples I provided earlier.
Still not convinced, have a look at the current 1.5.4 examples.
Go down to the USB examples. They show up on an UNO and yet will create compile errors
because the UNO does not have support for USB and yet the users still sees the examples
that depend on USB support.

The .properties library specification does not have the needed capabilities
to tie libraries/examples/sketches to specific cores or more importantly specific chips within a core.
The current specification simply lumps together the capabilities of all the architectures
within a core. This is unrealistic given the vast differences between the chips that are
being supported within a core like the stock AVR "Arduino" core.

So while I admire and agree with the goals of the new .properties specification, it is a long way
from providing the desired/needed capabilities.

So far away, that I think it needs a complete reboot/restart.

As I said earlier, the current spec solves a few issues, but also creates new ones, and
leaves many current real-world 3rd party issues un-resolved.

My view is that if something like this is going to implemented and be embraced,
then it needs to take a bigger step in solving issues for everyone:
- Arduino Team developers
- users
- 3rd party library developers
- 3rd party tool developers

The problem I see with the current definition is that it was done in a vacuum without the input
of the 3rd party library and tool developers.
Because of this, we are already seeing a luke warm response towards it and even examples
where it doesn't work.
Come on Arduino Team, it is time for you guys to embrace being more open so you can actually
take advantage of the 3rd party community resources rather than having to battle them.

My view is that to come up with a system that solves many of these issues
will take the input of many people.
It can't be done by the Arduino team by itself  or just by the 3rd party developers as many of the issues
for each are not seen or experienced by the others.
I also believe that many things will have to be dealt with simultaneously.
In other words, to make something like this really work, it isn't possible to be just about a library spec or a directory
structure. It also requires re-examining the actual build process itself as many of these issues actually
stem from that.


--- bill

visualmicro

#47
Oct 22, 2013, 08:05 pm Last Edit: Oct 22, 2013, 10:19 pm by Visual Micro Reason: 1
Hi Bill,

Yes a fuller specification would be ideal and way to more easily tune the options for the hardware will remove tons of confusion.

With 1.0.x at end of life and with continued support for pre 1.5 libraries in 1.5, I hope we can just stick with it for a while and take time to discuss a better solution or extended solution.

I hope that final solution takes into account all of the points you make so eloquently and caters better for duplicate library source code names.

Tim

edited for clarity
Arduino for Microsoft Visual Studio Pro and Atmel Studio 6.1 http://www.visualmicro.com
Arduino Debugger http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx

avenue33

Bill

Thank you for summarising and pointing the real need for discussion.

Let's hope the Arduino team listens...

pjrc

Bill, while you're made some good points, you've also used some pretty strong language.

In particular, I would disagree with your opinion that this spec was "done in a vacuum without the input of the 3rd party library and tool developers".  Months ago, Cristian did post this spec to the developers mail list.  Input was requested.  How much useful input was actually given, and to what extent that input shaped the final spec is a good question, but it was far from "in a vacuum without the input".

I think your point about the technical limitations could be better made with less harsh rhetoric.

pjrc

Also, I just use the term "final spec", but honestly I have no idea if the spec really is finalized or open to changes?

bperrybap

Paul,
I concede that perhaps my comments were a bit harsh and bit ill informed.
But over the past few years even you have been quite frustrated with the Arduino teams lack of willingness to
work with and accept ideas (or even code) from outside of its inner circle.

My biggest concern is that this will end up creating a situation like what happened with
final release 1.0
What the team did then with respect to backward compatibility was simply inexcusable
as it wasn't necessary.
My concerns would be greatly relieved if some one from the Arduino would
commit to not repeating that mistake.

--- bill

avenue33

I launched this thread many, many months ago, back on: May 11, 2013, 11:53:48 am, as soon as I read the specifications. Jantje and Paul joined the conversation the very same day.

But we had to wait till... September until a member of the Arduino team answered. That is, 4 months later.

Maybe I'm wrong about this forum and maybe there's another secret one.

Now, I'm not convinced at all by the last minute solution approach. Just consider what happened in the U.S. with the government shut-down ;) till next January-February.

pjrc

Yes, I've had many extremely frustrating occasions try to contribute to Arduino.

Since then, the leadership has changed.  I'm not saying things are perfect now.  But I do consider the worse of those experience to be old and in the past, now that Cristian is the technical lead for Arduino.

Jantje

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 -

cmaglie

Bill!

First I want to reassure you that if you want to stick to the 1.0 lib format, you can safely do that, we are not going to remove old library support. We already discussed that (in a google issue maybe? I can't remember), so I don't know why you're so concerned about that yet.

You're right about the fact that the library properties doesn't manage specific chips inside an architecture, we deliberately made this decision, otherwise we would end up with a structure like arch/[architecture]/[cpu] (and probably jantje would kill me :)), for example arch/avr/atmega328: this lead to massive code duplication since code for atmega328 is very similar to code for many other atmegaxxx, sometimes only a single line of code or a register name is different, and that can be handled easily with #ifdefs.
The same is not true when you move your focus from CPU to ARCHITECTURES: different architectures like SAM and AVR have very low code matching, practically null, and you end up using #ifdefs to select the whole file: in this case is much more clear and handy to use different files at all.

May we could extend just the .properties file to say that a library runs only on a specific chip? so for example a library for a 32u4 would not be listed when the selected board doesn't have a 32u4? Maybe.
We could extend that also to the examples? Maybe.
I would like to see a proposal from you on how you will do that.
These are all things that can be added (also later) to extend the capabilities of the library specification. BTW, this is all parsing work that will go to the back of tools-maintainers too.

"dependency" and "dependency-core" are placeholders for the future library manager. The version specified in the dependency-core is the  version of the CORE (and not the IDE as you presumed, even if they are still coupled). You can find the core version inside the platform.txt file. As you can see those fields are just drafted and there is room for improvements here when the library manager will be put in place. I'll make an announcement on the developers list when we start to define it.
At the moment the IDE doesn't enforce dependency check on those fields. I'm happy to see how you would improve that, consider that they are mainly focused for machine-dependency check on the future library manager.

About compatibility of 1.5 library with IDE 1.0: its true, but again, how would you change the specification to allow that? See that there is very small room for improvements on the old lib-1.0 format.

C.

cmaglie


I launched this thread many, many months ago, back on: May 11, 2013, 11:53:48 am, as soon as I read the specifications. Jantje and Paul joined the conversation the very same day.

But we had to wait till... September until a member of the Arduino team answered. That is, 4 months later.


I'm sorry to have joined this conversation so late, unfortunately I didn't noticed it until September, otherwise I'll have answered it early.

BTW I've sent the library specifications on the developers list on Feb. Why don't you replied, or started this topic there?
If you really have at hearth this topic, why don't you even tried to discuss it on the developers list, or maybe send an email to me or someone else of the Arduino Team?

For the next time, I'll praise you, to discuss this kind of things on the developers list, to be sure that someone of the Arduino Team, but also the whole developer community, notice it, not only the Arduino Forum's attenders.

C.

visualmicro

@avenue33 Do you know about the developers site? This is useful for Ide and build process discussion.

https://groups.google.com/a/arduino.cc/forum/#!forum/developers
Arduino for Microsoft Visual Studio Pro and Atmel Studio 6.1 http://www.visualmicro.com
Arduino Debugger http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx

cmaglie


Also, I just use the term "final spec", but honestly I have no idea if the spec really is finalized or open to changes?


We are still in beta, so... theoretically everything can happen. I'm thinking to reopen the discussion on the developers list.


I'm not saying things are perfect now.  But I do consider the worse of those experience to be old and in the past, now that Cristian is the technical lead for Arduino.


Thanks Paul. This is really much appreciated.
C.

avenue33

Thanks for the link.

Actually, I didn't know there was a developer site for Arduino on Google, as the code is hosted at GitHub and the forum is here. Quite confusing!

I'm on Twitter, Facebook, LinkedIn, GitHub, ... but I closed all my Google-related accounts last year.

Now, I've opened a new Google account and joined the developer site, on time for next Arduino 2.x revision.

Nevertheless, it seems that other developers duly introduced to the developer site at Google weren't listened at.

Go Up