It also makes lots of assumptions about the speed that the port is set to by default, the state of (in particular) DTR and so on.
Connecting via usb would be standard and there would be no need for speed etc. But the arduino should also be programmed to receive it correctly.
That's not the point I'm making. My point is that on Windows I /think/ that a serial port starts off in a known state and is restored to that state by the OS, while in unix- at least Linux but I believe others as well- the speed and signal state are /not/ normally changed by the OS... that's where the setserial command comes into it, at least for some port types.
And the convention that the OS does not meddle with the speed ties in with the convention that the serial port is /not/ opened exclusively, which goes back to how a getty works: it monitors a serial line and expects some form of user identification, after which it fires up either the login program (to read and validate a password) or e.g. a handler for an incoming fax. But in either case it stays running in the background with a handle for the serial line, and does not expect anything to permanently mess that up by e.g. changing the speed.
So a standalone program cannot ever assume that the speed and modem control lines are in a sane state: if dictated by its function, it has to set them explicitly.
And that's also why SerOpen() in serial.pp doesn't attempt to get an exclusive lock on the port it's opening. However in retrospect I regret that choice, and would prefer to e.g. have an SerOpenLocked:Boolean=true global or possibly an extra parameter to SerOpen(). But I'm not going to try adding it because (a) I don't relish getting involved with Git and (b) I'm no longer in a position to test thoroughly on a relatively-recent Windows and on a BSD-style unix.
MarkMLl
Recent
