On Mon, Dec 11, 2017 at 10:05 AM, Rob Landley <[email protected]> wrote: > 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.)
thanks to -g, stty's a bit easier than that. i relied on that a bit while testing. > 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 -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
