Proposal: modification of the set command

[dihm]

Something that I don't super love about the current set command is that the firmware has to do some level of processing the float inputs to convert them to the required hex fractional integers for programming. This often leads to strange edge cases where what comes out is slightly different than what you programmed due to rounding errors and the like. In many cases, that is fine, but often these small differences can matter, and now the only way to truly know what is being programmed is to send the command, then query what was actually stored in memory. It is a bit tedious. This get exacerbated by the delta word for ramps, which is required as a fractional int (ie native), but the user can only choose the ideal value by first converting their floats to the native ints of the DDS then performing logic.

I think it would be good to have two modes for the set command (or perhaps a parallel command with alternative syntax) that allows for specifying things in one of two ways:

• Standard mode: Basically maintain the current set command, but remove the delta argument and have the firmware perform the logic to choose the best value internally. This type of command is useful for quick and dirty work when you want to command outputs simply, but don't want to bother with the little internal details and can live with the arbitrary round-off choices.
• Pass-through mode: In this mode, the user is expected to program all settings as their DDS native hex integers. This requires the user to understand the underlying logic of the DDS generation, but it also allows the user full, explicit control of what the output is going to be, as the firmware does no processing of the inputs. This mode would require the ramp delta word to be provided by the user.

[dihm]

seti of #50 addresses the second half of this. I still think modifying the set command to auto-calculate sweep rates is a good improvement, but we should save that for another PR than #50, which is touching many things already.

Going to create a separate issue for tracking modified set behavior so that this can be considered closed by #50.