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 https://github.com/arduino/arduino-ide/issues/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 arduino/Arduino#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: https://github.com/arduino/Arduino/issues/5308#issuecomment-255789934

[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.

[JamesNewton]

@mikaelpatel That would generally work for me, but it wouldn't help out the newbies who copy an INO from some website and paste it in. I would suggest that comments in the main INO file are a perfectly acceptable solution which /also/ helps out the newbies by setting the board and other options correctly for the program.

@NicoHood I have no idea how I am failing to communicate with you. This has NOTHING to do with the preprocessor. There is NOT a working solution. I am absolutely, 100%, totally, and in NO way suggesting any changes to the preprocessor. This is about USER INTERFACE in the IDE. Please try to grasp that. User interface... not compiler or preprocessor or anything that happens after the INO is opened or pasted in. Even if the user is presented with an error message on compile, based on F_CPU, that still doesn't tell them how to set the board, port, frequency, etc... under the Tools menu. An individual author might write an error message that explains this, but...

that STILL doesn't help me when I have 15 different projects over 4 different boards which are connected to the machine and I'm switching back and forth between them. I want something that automatically sets the board and other settings when I open that INO.

As to your own opinions about how the INO file is bad... please post a separate issue and discuss your ideas there.

[mikaelpatel]

@JamesNewton What I am trying to address is not so much the format/syntax or what file to store the settings in as when and who will interpret them. There are a lot of open questions which I think has added to the confusion. 1) Is the setting changed by the menues? 2) Should it be allowed to be changed in the comment section in the sketch (user edit of text)? 3) If so should the IDE menues be changed accordling? 4) If it is the wrong syntax? 5) If the board is not installed 6) If the board is not corrected/port available. I think you get the picture.

[JamesNewton]

@mikaelpatel thank you for bothering to try to understand! It is very appreciated.

1. "Is the setting changed by the menues?" I'm not sure I understand the question, but I /think/ you are asking if making a new selection in the menues would change the comments in the code? That is not necessary, and I'm not sure it's a good idea. Maybe there could be a menu item which copies the comment block to clipboard? But that is later. For now, you type the comment manually. You only do that once, so it's not a problem.
2. "Should it be allowed to be changed in the comment section in the sketch (user edit of text)?" Again, not sure I understand... of course the sketch can be changed by the user... and the comment section is part of the sketch... I'm confused as to why you ask this... I must not understand the question.
3. "If so should the IDE menues be changed accordling?" I think you are asking if any editing of the comments should instantly be reflected by a change to the menus? No... that would be very nasty, I think... The menues only change when you first open the file, or perhaps when you make the first paste of code after starting a new project. And actually, the menues don't automatically change, instead a dialog opens and says "Should I make these changes based on the comments in the sketch?" with a list of the changes as parsed from those comments. Then the user selects "Yes" or "Cancel". I described this in the very first post: "Which should result in a dialog that offers to set those settings. You can always cancel it... "
4. "If it is the wrong syntax?" it is ignored.
5. "If the board is not installed" As I said in the initial post: " If the board isn't available, the IDE can direct you to the board library manager." Or just ignore that comment. I like the idea of it saying "This sketch is for an ESP8266, but that board is not available" but to start with, just ignore it.
6. "If the board is not corrected/port available" Same as 5. Minimum is to just ignore it. Or display an error. Or help the user select the correct one. If the board is available, but the port is wrong, the dialog that comes up will show what is going to be done if the user clicks "Ok". So they can also see what will NOT be done.

Thank you for these constructive questions which help to develop the idea and how best it could be implemented!

[mikaelpatel]

@JamesNewton My comments and questions have to do with consistency between the IDE settings and sketch (file/comments). This is a potential "can of worms". The easier solution to achieve the requirement/goal would be to allow a settings/property file together with the sketch. The IDE would read that on opening the sketch and on change the settings would be saved.

In anycase I think it is good to start by trying to isolate the new functionality (requirements) before attempting to give a solution. Often people get tied up with a specific solution instead of determining added value by the new functionality.

[oldmanegan]

Why not have it be a User_Ino_Setup.h file that can be the store for board specific info, and other implementation specifics the programmer may wish to enter, which is under a tab for the main .ino file? The .ino file could then be portable between platforms (various MCUs). The header file could allow for #ifdef type decision making at compilation so that it too could be set for various platforms, just comment out the unwanted ones... ? Very similar to what users encounter with several libraries that use the User_Data or User_Setup approach. The IDE would have to recognize the file, then seek out the specific board and relevant platform details upon compilation request, as a sort of Arduino-specific preprocessor function that runs a priori to any C/C++ functions.

By the way, as a secondary approach, if I had the time I could write some sort of script for a Mac to run to do something akin to this, by seeking out text in a file and then the script doing pseudo menu commands to select the desired options, but would be a kluge of sorts. If the Arduino IDE was AppleScript-able this would be a non-issue for us Mac guys. Probably something cross-platform is possible, too. But this is a workaround that should be secondary versus fixing the IDE. IMHO.

[JamesNewton]

@oldmanegan because for the 5,000th time, this is NOT a compiler or pre-processor issue, it's an IDE user interface issue. It happens NOT at compile time but when the INO file is opened or when the sketch is first pasted into a new project. Because that would diverge the Arduino compiler / pre-processor from other systems. Because that would then NOT store the settings in the main INO file, which is critical to help newbies. I am flabbergasted that people can't see this... Xo(

[JamesNewton]

Ok... I give up. I'm closing this because I don't have the emotional bandwidth to deal with the complete and total lack of understanding around the suggestion. If someone else feels there is a point to it, they can open their own feature request. I'm out.

[readysetawesome]

The world needs James's ideas badly. This is a problem. It has wasted many hours of my time when I switch computers and have the wrong CPU type selected - many hours of debugging broken comms because TTL timing is off due to clock speed.

[OpenGG]

Guys at thinx.cloud introduce some kind of yaml config, whose values fill into the arduino cli arguments. Hope it helps. https://github.com/suculent/arduino-docker-build