Boards Directory

[sgk]

Load the board definitions from text files inside "board" directory
in addition to the "boards.txt" file.

This makes users to install a new board definition for third party
Arduino derivatives by just dropping a file.

[damellis]

You can already add a board by simply adding a text file, you just need to put it in its own folder and call the file "boards.txt". Adding another, redundant, option seems confusing and unnecessary to me. Also, I think it's good to discourage people from adding new boards inside the Arduino application itself, because then they need to be copied when you update to a new version of the software.

[sgk]

You can already add a board by simply adding a text file, you just need to put it in its own folder and call the file "boards.txt".

Do you mean adding a new platform? It is right that we can add a new platform by adding a new folder with "boards.txt", "platform.txt", "cores" and other files and folders. However, it is a little bit too hard to maintain the whole target platform folder contents when we want to just add one single board definition.

We still need to edit the "boards.txt" file to add a board definition for third party Arduino derivative.

Also, I think it's good to discourage people from adding new boards inside the Arduino application itself, because then they need to be copied when you update to a new version of the software.

No. I mean "users" are administrators like teachers, hackers and third party vendors of Arduino derivatives, who wants to prepare their own IDE before distributing. It is true that such people are able to edit the "boards.txt" file with no hassle. However, it is important to keep original files untouched even for such people. This is why I propose this feature.

It should be better for you to learn from the Linux and Unix history, which added directories like "/etc/cron.d" even when there already was another way to maintain the settings.

But, this should depend on if you, Arduino team, are willing to support third party vendors or not. If you don't want to support third party vendors, this pull request is just rubbish.

[damellis]

The boards.txt file in one package can refer to the cores in another
package, and should be able to do the same for the platform.txt file (issue
#1157). So you shouldn't have to maintain any other files just to provide a
boards.txt file.

And for users who are customizing the distribution, why is important for
them not to edit the original boards.txt? I think it's fine and probably
useful -- for example, for a teacher who wanted to remove all the boards
that weren't going to be used in their class.

On Sun, Feb 3, 2013 at 9:13 PM, Shigeru KANEMOTO
notifications@github.comwrote:

You can already add a board by simply adding a text file, you just need to
put it in its own folder and call the file "boards.txt".

Do you mean adding a new platform? It is right that we can add a new
platform by adding a new folder with "boards.txt", "platform.txt", "cores"
and other files and folders. However, it is a little bit too hard to
maintain the whole target platform folder contents when we want to just add
one single board definition.

We still need to edit the "boards.txt" file to add a board definition for
third party Arduino derivative.

Also, I think it's good to discourage people from adding new boards inside
the Arduino application itself, because then they need to be copied when
you update to a new version of the software.

No. I mean "users" are administrators like teachers, hackers and third
party vendors of Arduino derivatives, who wants to prepare their own IDE
before distributing. It is true that such people are able to edit the
"boards.txt" file with no hassle. However, it is important to keep
original files untouched even for such people. This is why I propose
this feature.

It should be better for you to learn from the Linux and Unix history,
which added directories like "/etc/cron.d" even when there already was
another way to maintain the settings.

But, this should depend on if you, Arduino team, are willing to support
third party vendors or not. If you don't want to support third party
vendors, this pull request is just rubbish.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1263#issuecomment-13060092.

[lestofante]

original file should remain untouched, because any modify into boards.txt
can lead to break official board support.
This is not user-friendly as there is a first time for everybody, and break
all IDE trying to add a new board can be frustrating, also in case of an
update of the IDE they will not need to keep a backup of their boards.txt

In the other hand REMOVING official board from ide as you say has it's
meaning.

Then we can work out a solution like the libraries one: you can provide an
URL to the ide where he can download an XML with links and name to all
supported board file. Also the IDE will be shipped with an offline version
of the XML+board file. The user will then select/unselect the target board
he need and the ide will automagically download board's file and
install/remove/update it.
That way offline user will be able to use all official board, and it will
be easy to provide a 3rd part board file.
Maybe official board will be shipped as installed as default, so a teacher
can remove unwanted board without needing to modify the boards.txt any
update

Also this can be used to download the compiler; the lightweight
installation will come without avrdude, compiler or board's/xml file. Then
based on user selection the right dependencies will be dowloaded... so this
issue will be a sub-issue of #1227

2013/2/4 David A. Mellis notifications@github.com

The boards.txt file in one package can refer to the cores in another
package, and should be able to do the same for the platform.txt file
(issue
#1157). So you shouldn't have to maintain any other files just to provide
a
boards.txt file.

And for users who are customizing the distribution, why is important for
them not to edit the original boards.txt? I think it's fine and probably
useful -- for example, for a teacher who wanted to remove all the boards
that weren't going to be used in their class.

On Sun, Feb 3, 2013 at 9:13 PM, Shigeru KANEMOTO
notifications@github.comwrote:

You can already add a board by simply adding a text file, you just need
to
put it in its own folder and call the file "boards.txt".

Do you mean adding a new platform? It is right that we can add a new
platform by adding a new folder with "boards.txt", "platform.txt",
"cores"
and other files and folders. However, it is a little bit too hard to
maintain the whole target platform folder contents when we want to just
add
one single board definition.

We still need to edit the "boards.txt" file to add a board definition
for
third party Arduino derivative.

Also, I think it's good to discourage people from adding new boards
inside
the Arduino application itself, because then they need to be copied when
you update to a new version of the software.

No. I mean "users" are administrators like teachers, hackers and third
party vendors of Arduino derivatives, who wants to prepare their own IDE
before distributing. It is true that such people are able to edit the
"boards.txt" file with no hassle. However, it is important to keep
original files untouched even for such people. This is why I propose
this feature.

It should be better for you to learn from the Linux and Unix history,
which added directories like "/etc/cron.d" even when there already was
another way to maintain the settings.

But, this should depend on if you, Arduino team, are willing to support
third party vendors or not. If you don't want to support third party
vendors, this pull request is just rubbish.

—
Reply to this email directly or view it on GitHub<
https://github.com/arduino/Arduino/pull/1263#issuecomment-13060092>.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1263#issuecomment-13076915.

[sgk]

The boards.txt file in one package can refer to the cores in another
package, and should be able to do the same for the platform.txt file (issue
#1157). So you shouldn't have to maintain any other files just to provide a
boards.txt file.

Nice idea, but it is not straight forward. It's a kind of hack because the folders should represent "target" architectures, not "vendors" nor "boards". Do you want to see a folder name like "teensy" where there are "avr" and "sam"?

And for users who are customizing the distribution, why is important for
them not to edit the original boards.txt?

Did you learn from the Linux and Unix history?

The original "boards.txt" file is the heart of Arduino, and the IDE will not work correctly with official boards if the file is broken.

I think it's fine and probably
useful -- for example, for a teacher who wanted to remove all the boards
that weren't going to be used in their class.

From this point of view, the current "boards.txt" file should also be separated into small files in the "boards" folder so that each file contains only one board definition.

If you are still not willing to have "another, redundant, option" as in your first comment, I would propose to remove the support for "boards.txt" file.

[damellis]

The new, third-party hardware folder has two levels: package/platform. For example, "arduino/avr" or "teensy/arm". The idea is that the top-level folder represents the person or organization providing the folder; I imagine there will be lots of these. The second level folder (e.g. "avr" or "sam") represents the microcontroller architecture; there will probably be fewer of these. So for example, you might have "sanguino/avr/boards.txt". Or "bob/avr/boards.txt" or "jill/avr/boards.txt" or whatever. That doesn't seem too complicated to me, although I realize its an extra level of organization vs. 1.0.x.

Splitting up the current boards.txt files into multiple files (one per board) would be a big change. It might have been a better option if we were starting over, but it's not clear to me that any advantages it might have are worth the annoyance of switching formats.

[sgk]

The new, third-party hardware folder has two levels: package/platform. For example, "arduino/avr" or "teensy/arm". The idea is that the top-level folder represents the person or organization providing the folder; I imagine there will be lots of these.

I see. I understand what you are saying. Teensy was not good example for this matter. When adding Teensy, it seems to be best to create a new brand directory like "teensy" under "hardware" to represent Teensy. This is because Teensy has different bootloader and runtime than Arduino.

Forget Teensy and pickup Arduino compatible boards like Boarduino. When adding such board, it is not good idea to have completely independent directory under "hardware", which has "platform.txt", "cores" and "platfrom.txt" in addition to the "boards.txt". It is too complicated to me.

And, if you succeed to prepare the directory with some files and sub-directories, there is another problem. The added board will occupy 1 extra entry on the "Board" menu in addition to the board names. The extra entry is grayed out platform name like "Arduino AVR Boards" or "Arduino ARM (32-bits) Boards".

"boards" directory feature is very simple.

Splitting up the current boards.txt files into multiple files (one per board) would be a big change. It might have been a better option if we were starting over, but it's not clear to me that any advantages it might have are worth the annoyance of switching formats.

No. It is not a big change. It does not change the format. It is not required to split to multiple files. The use of "boards" directory is optional. Both the current "boards.txt" file and the new "boards/*" files will be read. You do not have to alter the current "boards.txt" file.

"boards" directory feature is to give an easy way to add board definitions with less change to the source code and the file format.

If you still don't want to have the "duplicate" way to define boards, you should be better to remove the current "boards.txt" feature and just move "boards.txt" inside "boards" directory.

[sgk]

Any ideas? > @ffissore @cmaglie

[cmaglie]

sgk,

I don't want to decide right now to accept or discard your patch, I need to work out some details inside the IDE to figure out if it is worth or not. I want to ask you to be a little patient.

Don't look at the actual 1.5 behaviour, we are working toward an implementation that doesn't require a platform.txt file to add a new board. When its ready you should be able to add a new board by "only" putting a file in hardware/sgk/avr/boards.txt.

And, if you succeed to prepare the directory with some files and sub-directories, there is another problem. The added board will occupy 1 extra entry on the "Board" menu in addition to the board names. The extra entry is grayed out platform name like "Arduino AVR Boards" or "Arduino ARM (32-bits) Boards".

Probably this could be avoided if we make possible, from the boards.txt file, to point to another platform.

C

[PaulStoffregen]

Hi Christian,

As the creator of Teensy, I'm watching and waiting for 1.5.x to settle before I support it. The exact details of boards.txt, platforms.txt and other things really do not matter much. My installer already needs to add many patches to the IDE for Teensy's special features which are very different from any official Arduino board.

What matter most to me, as a 3rd party board provider, is a relatively stable platform. The last thing I want to do is a lot of work to support 1.5.1, and then have to redo it all over again for 1.5.2 or future versions that make substantial changes. I know some ongoing change is inevitable, but my wish is for as much platform stability as is reasonably possible.

But if I could make one small request..... please consider bringing keywords.txt into this package/platform/board/variant system. As a 3rd party board with additional keywords, overwriting the global keywords.txt file is not a good solution.

[barbudor]

Hi

To second Paul's email, I beleive the keyword.txt file should belong to the
"library" it matches. Whether this is an additional library or a "core"
library.

Cheers

Jean-Michel (~barbudor)

[sgk]

Thank you Christian,

I don't want to decide right now to accept or discard your patch

I understand. I don't have any objection to your plan. I don't want to insist on my pull request if you are trying to find the best solution for the platform package directory format. As you pointed out, it seems that the current directory format is not perfect. I would like to help if you want.

Please remember to try this pull request or an equivalent implementation even when you rearranged the directory format. I believe the "boards" directory should be useful even when we can add a package directory with only "boards.txt" file.

Thanks you.