On 12/10/2017 08:30 PM, James McMechan wrote: > Yes, history still has a lot of sharp teeth waiting to bite. > Alas, it is not just old buildings, people are still producing stuff > with oddball settings. > e.g. my controller software is hardcoded to 7-o-1.5 make the > replacement work like the old stuff did. > then a few years later, make the new controller software work with the old > gear. > So both ends have been replaced, only the format between them has not changed > :(
You've "grandma's axe"ed a protocol. *shrug* Ok, still need the serial port setting stuff. The problem is I have no idea how to _test_ it. (All the serial hardware I have at this point is USB, and QEMU's serial emulation copies characters into and out of the I/O registers in all the drivers I've looked at. Last time I looked at serial data in an oscilloscope was 2012, I just don't have the hardware at the moment...) I suppose I can use strace and check that the right stuff is going into the syscalls, but that's a manual check not an automated regression test. (I'm not creating regression tests with strace just now, thanks.) In general the problem I have poking at stty right now is I dunno how to regression test my changes... > And it seems no one wants to replace both ends at the same time, even > if they did > it would likely be only one of the 17 pieces of gear that would be > replaced with the controller, > and I usually it would break something... > > There were even some good reasons for some of it, a open wire would > produce a stream > with bad checksums for odd parity. > >> Um, shouldn't stty operate on _stdout_ instead of stdin when modifying? >> Hmmm... no, I guess not, the other one isn't doing so and "cooked/raw" >> are stdin questions anyway. So yes, open stdin for _writing_. Which >> presumably means the shell that launched us has to have opened stdin for >> writing if it's a tty? I should write that down somewhere... > > I don't think it ever has, there was likely a reason 30 years ago, > that I have forgotten. All the implementations I'e seen did open(); dup(); dup(); but I didn't know they were _required_ to. :) Let's see... http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html doesn't seem to mention that, how about http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05 > At program start-up, three streams are predefined and need not be > opened explicitly: standard input (for reading conventional input), > standard output (for writing conventional output), and standard error > (for writing diagnostic output). When opened, the standard error > stream is not fully buffered; the standard input and standard output > streams are fully buffered if and only if the stream can be determined > not to refer to an interactive device. Nope, that's not it... >> that have some meaning? (The serial ports I've dealt with recently were >> all USB so it was a packet protocol, and then the j-core uartlite device >> is simple hardware running at a fixed speed, so I'm trying to think when >> the last time is I set a serial port speed. Probably the cortex-m board, >> but the kernel set the speed of that for me. Makes it kind of hard to >> TEST any changes I make here, doesn't it?) > > I too have been working with the USB serial ports, mostly it is nice. > The custom of having the reference voltage on board next to the TX/RX > does make life much easier, just pulling the jumper on the USB board > and hooking it up to the reference makes it simpler. > > Except of course when the manufacture puts something like a 5V supply > next to a 3.3V serial port, I unfortunately have some of these. > > The other problem of the hardware comes up in something old fashioned > like 9600-8-n-1 if you are lucky, means that until you are fully booted > you get to watch the screen slowly scroll. The Numato Mimas v2 (most powerful $50 FPGA board I've seen) has USB serial port hardware set to a fixed rate by the firmware, meaning when you boot j-core linux on the thing you have to set it to 9600. There's a firmware you can flash into it that sets it to 115200, but it's a separate firmware (not the spi flash the FPGA loads from) and the only tool they give you to update it is a windows binary. Sigh. Anyway, what I can test once by hand and what I can figure out how to do automated regression tests for are two different things. I really prefer toybox not require special hardware setups to test stuff, but qemu doesn't emulate at this level. Its serial port abstraction is a byte transport to and from a host filehandle. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
