Specify target board / settings in .ino code / comments.

[JamesNewton]

As the IDE is used for more and more boards / devices, it becomes increasingly confusing for new users to select the correct device in the Tools / Boards menu... and increasingly annoying for me to have to reset it all the time as I bounce from one project to another. Personally, this is really bad when working on ESP-8266 projects as there are soooo many settings under tools.

It would be really nice to have some way to include that information IN the source code... in the main .ino file. Just open the .ino, and the IDE automatically selects the correct device, port, programmer, CPU speed, etc...

One way of doing it would be with simple comments in a specific format at the start of the file which would trigger an "offer" from the ide to copy those settings. This would allow the settings to double as documentation, and preserve the standard C/C++ functionality. e.g. it wouldn't make the file unique to this IDE.

for example:

// Tools / Board: Generic ESP8266 Module
// Tools / CPU Frequency: 160 MHz
// Tools / Port: COM32

etc...

Which should result in a dialog that offers to set those settings. You can always cancel it... If you approve, it should set the board FIRST, then set the next line, then the next, and so on. If the board isn't available, the IDE can direct you to the board library manager.

[per1234]

Duplicate of arduino/arduino-ide#2438

[tochinet]

This is definitely a much needed feature. Before, it was relatively simple to select a board. And as long as you just play with a few LEDs, it made sense to be able to port a sketch from Uno to Nano to Pro mini etc.

But today this kind of portability is long gone. You just can't run the same sketch on Mega than Nano, or Wemos or panstamp NRG or ESP8266-01. Especially when the libraries are not interchangeables (ESP8266HttpClient instead of HttpClient and different functions). And worse, you now need to choose not only a board but also the Serial and CPU speed, voltage, ROM size, etc.

I'm not very confident that a simple C++ // syntax is the most appropriate for such feature. Isn't this closer to a pre compiler directive, something like #board ESP8266 etc ?

[PaulStoffregen]

Especially when the libraries are not interchangeables (ESP8266HttpClient instead of HttpClient and different functions).

Such incompatible libraries are the part which really must improve.

[tochinet]

Hi Paul. I won't start the list of part that must improve either ;-) But I recently found there was even some official ArduinoHttpClient libraries now. That will probably make it worse for an order of magnitude of more people...

To come back om my comment on the C++ // syntax, I found some #pragma comment(board, "Arduino Nano") syntax that I find much more elegant. Not sure if it's the appropriate kind though.

[PaulStoffregen]

Maybe I'm misunderstanding, but it sounds like you're proposing further fragmentation in the Arduino world in response to existing fragmentation?

[oldmanegan]

I find the problem of not fixing the board and processor information to an .ino file an irritation as I swap between boards and MCUs during a multi-system development effort.
Many have suggested making the added text part of the start of an ino file. I see it differently. The information should be placed at the end of the ino file, so it does not interfere with Doxygen or preprocessing, or be a separate small text file associated with an ino file and stored to the same directory as the ino file, thus making the ino file easily "portable" between boards and MCUs. This board prefs file could have its own tab when present for an ino file, making for easy adjustments in the future as changes come about to the Arduino environment and capabilities. May I suggest it be a ".inp" file standing for "ino preferences?"

[JamesNewton]

PaulStoffregen,

NO. I am specifically not suggesting further fragmentation. Which is why I suggested the information be placed in a COMMENT. Frankly, ignoring that seems like it would have to be willful. A carefully structured comment as a HINT to the IDE does no damage to portability and solves many problems. A special file placed in the folder would also NOT cause fragmentation, but would also not preserve the hint with the source INO.

NO. The issue is NOT resolved even with perfect libraries for every target. Again, I made no mention of library issues in my original description so why assume this is dependant on that? Others have mentioned that it would work around that ongoing problem. We need this feature specifically because the Arduino IDE supports so many targets correctly. E.g. you can compile the same code for an UNO, NANO, Trinket, ESP (in some cases) and given a fairly simple requirement have it work just perfectly. But when a project needs to be on a NANO for example, for hardware or space or other reasons, the author of the source code should have some way of indicating that (which they do, in a comment) and the IDE should be smart enough to take that hint and automatically select that target (which it's not).

More than that, there are often multiple settings for one target. E.g. is this code designed to run on an ESP with the clock at 80 or 120 MHz? Or on a Trinket at 8 or 16 MHz? Manually making those changes every time you open an INO is a pain.

Computers exist to help us. Processing the comments when an INO is first opened, looking for a specific set of comments, using that to suggest a target setup, then allowing the user to confirm or discard that suggestion is worth doing.

[bengtmartensson]

when a project needs to be on a NANO for example, for hardware or space or other reasons, the author of the source code should have some way of indicating that

#ifndef ARDUINO_AVR_NANO
#error This file is for Nano only
#endif

[tochinet]

@PaulStoffregen I think I have to reply since indeed I don't (think I) propose more fragmentation (I only deplore there is so much). I simply realised that not only there was (one or more) esp8266HttpClient library around, but also both HttpClient and ArduinoHttpClient for apparently the same board (family). Since I own no WizNet board I didn't investigate differences, and maybe I missed something, but that's confusing anyway. What James and I (and issue arduino/arduino-ide#2438) want is that when you open a sketch in the IDE, the board selection is adapted automatically. Today, if I work with a UNO and a MEGA talking together, the board will always be the last one I used, and I have to go back selecting it again each time. It's even worse if you use esp8266 or pro minis, because then you potentially have to select board, speed, memory and serial port again and again and again. Using some comment rule to inform the compiler which board to use is a nice feature that would let us all win time and avoid mistakes.

I also want to use the opportunity to thank you specifically because while the Teensy family has fabulous capabilities on its own, you took the effort at several occasions to provide the results of your efforts back to the community at large, instead of keeping that for your own boards. Kudos.

@bengtmartensson I think what you show there simply works to some extent : it may be tricky to identify the board, but #ifdef __AVR_ATmega328__ identifies the chip you're using.

My previous comment with #pragma was more towards the OP, because I feel a simple //board, Arduino UNO comment is not supposed to do anything in any situation.

[JamesNewton]

My previous comment with #pragma was more towards the OP, because I feel a simple //board, Arduino UNO comment is not supposed to do anything in any situation.

If we were talking about a compiler, I would agree. We aren't. We are talking about an IDE, and there is NO rule that says an IDE can't read the code, make suggestions, and interact with the user to implement those suggestions. That is, in fact, pretty much the definition of an IDE.

The Arduino IDE already does this for syntax highlighting.

Many IDE's have autocompletion. The suggestion has been made to add this to Arduino IDE #849

Code analysis tools exist which look through the code for common errors and make suggestions for improvements. e.g. Lint.

JavaDoc reads source code, including specially formatted comments, to build code documentation:
http://www.oracle.com/technetwork/articles/java/index-137868.html

All of these are examples of the IDE reading the code, and helping the user.

[NicoHood]

Use what @bengtmartensson said and you are all fine. No stupid arduino preprocessor stuff that does not work in the end. Specifying a comport is useless and the MHz is also a one time setting which is not even available for most boards. You still have F_CPU though. And the rest can all be defined in boards.txt and you can do quite a lot with this and normal c.

[JamesNewton]

@NicoHood , that in no way addresses the issue. Not even a little bit. And I am NOT suggesting pre-processor stuff, stupid or otherwise. Again... NO change to the compiler. It's a change to the IDE. Stunning that people can't get that. Please actually read what I posted just above your post:
#5308 (comment)

[mikaelpatel]

@JamesNewton would it be sufficient to save an IDE settings file in the sketch directory. It would for instance be read by the IDE when opening the sketch.

[NicoHood]

@JamesNewton you are not changing any compiler. That is normal c preprocessor stuff, as the whole world codes their programs. You do not need to reinvent something new when there is already a perfect working solution. Also adding something else that you suggested will just blow up even more bugs in the arduino-preprocessor. If you ask me arduino should get rid of the .ino stuff and just stick to plain c++ as .ino files just mess up complicated stuff as template etc. And so will any other non default board selection do. You cannot get any more precise than a definition check of the board or F_CPU.