stty not called until baud rate is changed

[chrstphrchvz]

I mentioned encountering difficulty getting a device working under Linux in #5:

I haven't gotten the board working with HSW12 on Linux yet, but I don't think it's an issue with HSW12 specifically. It looks as if it's immediately echoing back any prompts from D-Bug12 and gets stuck in a "Bad Command" loop, but the same happens when using cat < /dev/ttyUSB0. minicom works, though.

I have since found that once I used minicom with the device, other programs such as HSW12 and cat worked as expected. This was due to the terminal line settings being updated by minicom and persisting in other programs, as stty -F /dev/ttyUSB0 will output many changes in the settings compared to the default Linux settings or stty -F /dev/ttyUSB0 sane (neither of which were usable due to echoing, hardware flow control, etc.).

The default settings for stty in hsw12_pod.pm indeed make the device usable, but at the moment stty is not called until the baud is manually configured (which I had not been doing). But if the device is already be sending data to the computer, then it immediately gets stuck in an echo loop, sometimes hanging HSW12, and not allow the baud to be changed (and stty to turn off echoing).

So should HSW12 either be executing stty when connecting to the port, or should it also be setting the baud (in turn executing stty)? If the stty command needs to include setting the baud, maybe either a default baud is specified (e.g. 9600), or the existing baud is read using stty -F $device speed before executing stty again.