Add support for M575

[rafaljot]

Add support for M575

Parameters:

P<Serial no 0 or 1>
B<baud rate>

example:

M575 P0 B250000 ; change baud rate for serial 0

M575 B250000 ; change baud rate for all serials

Description

https://reprap.org/wiki/G-code#M575:_Set_serial_comms_parameters

Benefits

It allows to change baud rate without recompiling.

[thinkyhead]

@MarlinFirmware/host-software-team — A quick question for you…. How do hosts respond to a change in the serial baud rate with M575? Can they automatically reconnect at the new baud rate?

[thinkyhead]

RepRap wiki page updated, and Marlin page added at http://marlinfw.org/docs/gcode/M575.html

[rafaljot]

You need to restart the host connection.
It was useful for me to test upload configuration
#12249

[thinkyhead]

This will be slightly delayed while we contemplate whether to increase the size of all Marlin builds or make this an optional feature.

[rafaljot]

optionality is always right/easy decision
"think about it tomorrow" ;)

[thinkyhead]

Some of the serial classes used by Marlin have no end method. This includes the CDCSerial class in the LPC1768 core.

[AnHardt]

For USB-serials baudrate is meaningless anyway.

[repetier]

@MarlinFirmware/host-software-team — A quick question for you…. How do hosts respond to a change in the serial baud rate with M575? Can they automatically reconnect at the new baud rate?

Currently they do not respond at all and you would need to change baud rate in configuration and reconnect

One other problem is if board has more then one serial connection. Hosts do not know on which serial port they are connected. If it is omitted so host can assume all ports are omitted he can parse the command send and change baud rate. I think with Px it should not do that as it means 50/50 chance to handle it wrong. I think best solution would be change it in config and reconnect because control flow gets disturbed. Also host might do this with delay to give firmware time to do so which is kinda problem as it is parsed before sending and other commands may also in the pipe. So adjusting too early makes firmware never receive it. Simple solution would be to just update config and leave restart to user. Firmware restart will most likely not be seen as wrong baud rate prevents data to be recogniced.

[foosel]

How do hosts respond to a change in the serial baud rate with M575? Can they automatically reconnect at the new baud rate?

Will need a manual reconnect with the new baudrate.

And also agree with @repetier

[InsanityAutomation]

In theory yet another action command could be added to suggest a live baud change to the host, but it may disconnect and reconnect anyway causing a reboot on many platforms. This should have a flag to store immediately to eeprom prior to actually changing and signalling the host that its changing so that should a reboot occur the change is retained. Maybe follow the -U option from PID tuning?

Edit : Dont forget Raise3D and others use odd baud rates like 230400 so either we need to ensure all used rates are enabled (which means some research), or allow a way to override the sanity checking. Should host communication be lost, an LCD menu option will be needed to reset to common values as well.

[thinkyhead]

Dont forget Raise3D and others use odd baud rates like 230400

We start with this, and later we patch up as requested.

[thisiskeithb]

Looks like there's still issues with this PR: #14780

[InsanityAutomation]

FYI, ive started working on what this needs to actually be functional

https://github.com/InsanityAutomation/Marlin/tree/Finish-M575

As it stands most hosts would trigger the change, reconnect, then most platforms reboot on the reconnect going right back to what it was. Ive got the current baud rate stored and a check if it matches before resetting the connection. Ive got eeprom storage added. Data type changed to be consistent.

Still needs :
LCD Menus
EEPROM moved as early as possible in setup
Template modified for other HAL's (not many provide this overload class...)
A ton of testing
Some feedback to hosts to try and alert them to the change if they think they could handle the reconnect gracefully?

I can open the PR if anyone else wants to pick at it. Otherwise ill get back at it sometime tomorrow probably.

[rafaljot]

@InsanityAutomation
Could you add : case 2000000: case 4000000:

[InsanityAutomation]

@rafaljot done, as well as lcd menus and finishing making it compile for AVR. Added sanity checks for other platforms for now. Ill open the PR so I can tag the maintainers of some of the other HAL's and see if they can poke at what those platforms will need.

Still more to go but at least this should be closer to usable in most situations.