What I was trying to solicit is to see is if everybody else is seeing the flawsin the current .properties specification with respect to trying to specify 3rd party coresor architectures within those 3rd party cores.
I didn't follow that.You can do pretty much anything to the compiler, linker, and download commands given theflexibility offered by the platform and board files. I had to completely change things for chipKIT but the flexibility wasthere for me to change all the commands around when chipKIT boards were selected withouthaving to change anything in the Arduino JAVA IDE code.
The user doesn't have to know any of this as long the system allows a libraryto specify which environments it works in.
In the bigger picture, 3rd party Core, Library, and tool writers are not normal users.They are the ones that create the s/w to make it easy for the normal users.
What I'm trying to bring up is that from a purely functional point of view(ignore how ugly or painful it might be to actually implement), the current.properties spec does provide enough information to specify whichcores and sub architectures within a core are supported by the library when3rd party cores are involved or when a library is specific to a particular chip.And without those types of capabilities,it is impossible to provide a nice clean & simple user experience.
Paul,What is your understanding of the "architectures=" field?
What I mean is that if platform.txt statescompiler.c.cmd=avr-gccand you selected a UNO and the boards.txt file containsuno.compiler.c.cmd=sam-gccthe plugin will use sam-gcc while I expect the Arduino IDE to use avr-gccI guess I don't have that expectation and don't see an issue here.The point of having the user pick a board is to potentially do things that are board (chip) specific,to allow a means to potentially do something differently for a given board (chip).If there are different chips supported within the same chip architecture,you must be able to potentially override any default settings in the architecture (platform.txt) file.While the above is a very contorted example, the values of the fields in the board file for a particular board have to be able to override the field values in the platform file.In my view, what you have described is the way it should and needs to work.For example, maybe I want to specify a shell wrapper to set up my toolsfor source level debugging. So maybe I set up a board type that uses a shellwrapper script that sets up link maps, DDD, AVaRICE, and my AVR dragon as part of the build and/or upload process. I might have to override the platform.txt values to get it to call my wrappers instead of the calling the tools directly.(I've done this, and did this to get chipKIT up and working on IDE 1.5.1)QuoteThe user doesn't have to know any of this as long the system allows a libraryto specify which environments it works in.It is visible in 1.5.2 when you select a boardI think perhaps you have misunderstood me.When there is a mechanism in place that allows a library to specify which boards (chips)it works on, the user only has to know what board he has. How it works underthe covers is no concern to him.QuoteIn the bigger picture, 3rd party Core, Library, and tool writers are not normal users.They are the ones that create the s/w to make it easy for the normal users.I fully agree on this but there is to much focus on Architecture while this could solve many other problems as well.For instance this http://forum.arduino.cc//index.php?topic=143940.msg1081073#msg1081073There is a library for avr for tone and you have a new implementation which is better but takes more space and is still in beta.Some people will want the old one. other will want the new one. Why not have both and let the user select the most appropriate for him/her?In this particular case the folder name can not be the architecture as the architecture is the same for the 2.so you will have tone/arch/stable and tone/arch/betathe folder /arch/stable contains a property file stating the architectures it runs on and so does arch/beta.So it can be that /arch/stable supports avr, sam, all and chipKIT but arch/beta only avr.I think the specific library (NewTone) is a poor example, as it used a different name and different APIthat the library it is trying to replace and as such does not conflict with the IDE supplied tone library.I'll assume you mean that you want to have a new/optional/experimental library that uses the same name and APIas some other library.That said, I'm not understanding if you are wanting the ability to select which library to useat the sketch level (sketch A used old and sketch B uses new) or whether you simplywant the ability to let the user configure/install a library than can override an existing libraryfor a given vendor core & architecture.I brought up a similar scenario in my very first post of this thread.It was scenario #2 of this response:http://forum.arduino.cc//index.php?topic=165827.msg1437604#msg1437604Given that the user libraries already override the IDE supplied libraries, the ability to support this capability should be possible if proper dependencies exist in the .properties files.i.e. Already today, if you install a library in your user sketchbook/libraries area it will overridea library provided by the IDE when the names are the same.So if a future build mechanism/system maintains this capability as well as properly picking the appropriatelibrary to support the chip on the selected board, by looking at the various propertiesin the library hierarchy, then it all will "just work".The key is to properly define the .properties file and how the library hierarchy works.The hierarchy mechanism should use a directory structure that doesn't require 3rd partiesto have to merge their separate properties information.QuoteWhat I'm trying to bring up is that from a purely functional point of view(ignore how ugly or painful it might be to actually implement), the current.properties spec does provide enough information to specify whichcores and sub architectures within a core are supported by the library when3rd party cores are involved or when a library is specific to a particular chip.And without those types of capabilities,it is impossible to provide a nice clean & simple user experience.Technically yes but it misses on process and ownership.For example if I created a new tone library I want to add a folder under libraries/tone/arch/ and it should work.I don't want to be dependent on someone else to change the existing properties file (for instance because this library supports sam implementation which is not yet available). And when the folder is removed the sam implementation is removed as well.In other words: As a provider of the library I want to be able to specify some fields in properties. The best way to do so is add a properties file which overrules (or adds to) the properties in the parent.I don't want to be dependent on a tool (which I would need to implement in eclipse) that updates the properties file based on user import and export activity.Best regardsJantje
hardware/maniacbug/avr/platform.txthardware/maniacbug/avr/boards.txthardware/maniacbug/avr/cores/arduino/[source code for "arduino" core of maniacbug]
hardware/maniacbug/avr/cores/arduino/[source code for "arduino" core of maniacbug]
hardware/arduino/avr/cores/arduino/[source code for "arduino" core of ARDUINO]
All 22 libraries that ship in Arduino 1.5.4's libraries folder have "core-dependencies=arduino (>=1.5.0)". What is my Teensyduino installer supposed to do with the core-dependencies field? If "arduino (>=1.5.0)" means it will only work with a core named "arduino", do I need to rename my core from "teensy" to "arduino"? Or do I modify the library.properties files to add the name of my core to the properties files?
hardware/pjrc/kinetis/platform.txthardware/pjrc/kinetis/boards.txthardware/pjrc/kinetis/cores/arduino/....hardware/pjrc/kinetis/variants/.....hardware/pjrc/avr/....same stuff here...
Likewise, how am I supposed to install Teensy 3.0's non-avr architecture EEPROM library? Suppose I name Teensy 3.0's architecture "kinetis". It seems logical that I would add a "kinetis" directory inside libraries/EEPROM/arch and copy my architecture EEPROM.cpp there? But what do I do about EEPROM.h? It's currently in libraries/EEPROM/src, shared by all architectures. My EEPROM library customizes that header, adding a constructor which I use to initialize the hardware (unlike AVR, the eeprom hardware needs to be initialized). It looks like I'll need to overwrite the platform neutral header with my customized version. Then, of course there's the library.properties file in EEPROM, which currently says the EEPROM library is only compatible with AVR architecture. Will I need to modify EEPROM's library.properties, for both architectures and core-dependencies?
SoftwareSerial is another library I've ported to Teensy 3.0. Fortunately, SoftwareSerial seems to have a header in libraries/SoftwareSerial/src that includes the architecture specific header, but it looks like I might need to patch library.properties, since both architectures and core-dependencies say it's incompatible with my hardware (even if I copy the code into a new directory to make it compatible).
Another complexity with SoftwareSerial is I'll want to patch the examples, which mention the supported pin numbers only for Arduino boards. I'll want to add similar comments for my 3rd boards. How am I supposed to do that?
I recall earlier you mentioned the intended path is to contact the library maintainer and get them to update their library.properties file and add the code. Is that really what you intend for the 22 libraries that ship with Arduino? Generally Arduino has maintained a policy of facilitating 3rd party hardware, but not shipping any code or file that directly support any non-Arduino boards. Arduino's lengthy release cycle could also be, well, frustrating if you're the path to get 3rd party support into those library.properties files.
I did notice 1.5.4 has two old style copies of the Wire library, in hardware/arduino/avr/libraries/Wire and hardware/arduino/sam/libraries/Wire. Maybe this the path? If I have a library like EEPROM ported to another architecture, but it's already present with library.properties incompatible with my hardware, can I put a pre-1.5 format library in my platform/arch/libraries directory? Will it override the same-named copy in the main libraries directory? I was under the impression those directories were the pre-1.5.3 way which was intended to be replaced by library.properties. Is that right? If those are the official way for 3rd party boards to be compatible with the 22 "standard" libraries that ship with Arduino, it really ough to at least be mentioned in the library spec.
The current IDE should work, more or less, like this:Let's call ARCH the architecture of currently selected board, and VENDOR its vendor name.1) The IDE discards all 1.5 libraries that haven't ARCH in the platform= property.2) From the remaining libraries it choose the first matching library by searching these folders, in order: a) SKETCHBOOK/libraries b) ARDUINOPATH/hardware/VENDOR/ARCH/libraries c) ARUDINOPATH/librariesSo putting a library inside ARDUINOPATH/hardware/VENDOR/ARCH/libraries works. Again, here there is another compromise to deal with: we can reorder the path priority for example b) c) a), but this won't let the user the possibility to override vendor-provided libraries.
core-dependecies - the core on which this library works on (multiple cores can be specified)
Guys,everyone of you made great points here.I would ask you to continue the discussion on the developers mailing list, that is where these discussions should take place.Please give a concise and clear recap of your concerns, and I'm sure that we can come up to a great library specification.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16