per-board generic option in config file boards.txt for disabling control of dtr+rts ...

[d-a-v]

...from IDE, allowing board specific use of these lines for example for reset or programming mode. Currently used by esp8266/Arduino.

credits go to esp8266/Arduino#22 and esp8266/Arduino@0dabb25 from where this patch originates.

[ozayturay]

This patch is really needed for some boards, especially ESP8266.

[NicoHood]

Is this somehow related?
#3386

[d-a-v]

It seems that #3386 relies on the general preference file. This leaves the configuration of the ports to the user.
On the other hand, this #4102 pull-request configures dtr+rts in a per-board basis in the board configuration file (generally not supposed to be read/modified by the user).
Thus the user needs not know what is happening, it will just work if the correct board / model is selected.

[igrr]

Would be really useful for the esp8266 core.

[tablatronix]

👍

[probonopd]

👍

[MrMartin92]

👍

[bjpirt]

It would be great if this could make its way in to the core as it's really useful for the increasingly popular ESP8266 platform. Is there any reason why it isn't being merged in? It's backwards compatible and just adds an extra config option for boards.txt which makes it more flexible

[lmihalkovic]

IMHO this is a narrow path to go down... instead of hardcoding overrides one at a time, there should a convention that boards can override ANY pre-existing property by following a naming pattern. E.g. Anything like

override.xxxx.yyyy.zzzz=abc

could be applied blindly in the config to replace xxx.yyyy.zzzz=abc. The point is that it is voluntary (presence of a prefix does not happen by accident) and generic (core ide does not need to be modified anytime a board needs something). The presence of a known prefix offers the additional benefit of being able to show something in the ide (i am working on some ide support for config settings in my fork and the core ide might want to do the same)

[d-a-v]

Do these settings (serial.disable.RTS, serial.disableDTR) exist elsewhere in the IDE configuration so they could be overridden with such a facility you describe ?

[lmihalkovic]

Sorry for my lack of clarity, the override part is related to the couple of lines in the patch that make direct reference to the values comming from bord pref. What i was offering for consideration is that the usage of these values should be done without direct reference to where they come from, but instead after a general merge overrides step.
The heuristic would be

values = PrefDta.values()
values.merge(board.getValues("override")  // THIS IS WHERE override.xxxxxx get read and plastered-on
values.merge("override", board.getPrefs()) // is probably a better alternative

// and then where needed
Bool whatEver=VALUES.getBoolean("serial.disableDTS")  // no longer a direct ref to PrefData

This ensures that THE prefdata does not get contaminated by the boards, and give a chance to all boards to modify anything they want. VALUES get recomputed on each board switching in the ide.

An alternate design (making things transparent to existing code that directly references PrefData - probably what I will do) is to modify PrefData such that it contains 2 stores (basically local and parent, where parent can be another instance, allowing the scheme to be made cleanly tiered). I did exactly that already for the themes to support DARK with minimum extra work.

[bjpirt]

@lmihalkovic The method you propose sounds nice and flexible and would let extension authors customise things without breaking things for the users.

Can anyone on the Arduino team weigh in with their thoughts on this issue - it would be great to get some kind of solution for the ever-growing number of ESP8266/Arduino users out there!

[lmihalkovic]

I will be using something along those lines to replace the internals of PreferencesData/PreferencesMap. The idea is to be able to maintain a n-level (likely: defaults/board/variant with the ability to insert new ones) hierarchy without having to spread that knowledge around.

[matthijskooijman]

I have been pondering a similar scheme as proposed by @lmihalkovic a while ago - the current preferences, board properties and platform properties handling is a bit of a mess which would do well to be cleaned up. I created #4431 for this, so we can keep this issue about specifally adding support for DTR/RTS.

[PetrH]

It's any progress here? I can see that ESP Core implemented this option to board.txt. But still without support from side of IDE is quite useless...

[tablatronix]

I was just about to ask the same.

[ozayturay]

Still open so i guess no. :(

[ghost]

Any progress on this at all, where's it stuck at?

[uSlammer]

Great patch! Really needed.

[cmaglie]

Thanks!