[9fans] usb/serial control open
it seems odd to me that opening the ctl file would
reset some serial parameters. wouldn't it be better
to leave them alone?
static int
dopen(Usbfs *fs, Fid *fid, int)
{
ulong path;
Serialport *p;
path = fid-qid.path ~fs-qid;
p = fs-aux;
switch(path){ /* BUG: unneeded? */
case Qdata:
dsprint(2, serial, opened data\n);
break;
case Qctl:
dsprint(2, serial, opened ctl\n);
if(p-isjtag)
return 0;
serialctl(p, l8 i1); /* default line parameters */
break;
}
return 0;
}
- erik
Re: [9fans] usb/serial control open
On Sun, Mar 23, 2014 at 7:09 PM, erik quanstrom quans...@quanstro.net wrote: it seems odd to me that opening the ctl file would reset some serial parameters. wouldn't it be better to leave them alone? What do you return on read if you don´t know the state? For some devices if you don´t set the state, you have no idea. You can do it in read, but it seemed more intuitive in open at the time, (and you don´t set the state on every read). G.
Re: [9fans] usb/serial control open
On Sun Mar 23 14:35:52 EDT 2014, pau...@gmail.com wrote: On Sun, Mar 23, 2014 at 7:09 PM, erik quanstrom quans...@quanstro.net wrote: it seems odd to me that opening the ctl file would reset some serial parameters. wouldn't it be better to leave them alone? What do you return on read if you don´t know the state? For some devices if you don´t set the state, you have no idea. You can do it in read, but it seemed more intuitive in open at the time, (and you don´t set the state on every read). so if i do this echo l7/dev/eiaU6/eiaUctl cat /dev/eiaU6/eiaUctl that's two opens, isn't it? then isn't l reset to 8 by the second open? - erik
Re: [9fans] usb/serial control open
so if i do this
echo l7/dev/eiaU6/eiaUctl
cat /dev/eiaU6/eiaUctl
that's two opens, isn't it? then isn't l reset to 8 by the second
open?
It has been a while and I don´t have the code at hand now, but once
it is at a known state, it shouldn´t set it again, that is probably a bug.
It should be something like:
if(!setonce){
setonce = 1;
serialctl(p, l8 i1); /* default line parameters */
}
G.
Re: [9fans] usb/serial control open
What do you return on read if you don´t know the state? For some devices if you don´t set the state, you have no idea. You can do it in read, but it seemed more intuitive in open at the time, (and you don´t set the state on every read). What I meant, is if you write then read, the read does not set the state. if you read then write, it does. It is cleaner to set it on open. The rule is simple, the first open sets the state. As I said, the first part is missing :-). G.
Re: [9fans] usb/serial control open
On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola pau...@gmail.com wrote:
if(!setonce){
setonce = 1;
serialctl(p, l8 i1); /* default line parameters */
}
And setonce needs to live in the interface, and it needs to be locked, etc.
G.
Re: [9fans] usb/serial control open
On Sun Mar 23 15:56:52 EDT 2014, pau...@gmail.com wrote:
On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola pau...@gmail.com wrote:
if(!setonce){
setonce = 1;
serialctl(p, l8 i1); /* default line parameters */
}
And setonce needs to live in the interface, and it needs to be locked, etc.
another idea: since this is only needed by some hardware. and then only in
init.
why not make it the responsibility of such hardware to do this in the init
fn. then the problem can be addressed without any special cases like
!setonce.
what do you think?
- erik
Re: [9fans] usb/serial control open
And setonce needs to live in the interface, and it needs to be locked, etc. another idea: since this is only needed by some hardware. and then only in init. why not make it the responsibility of such hardware to do this in the init fn. then the problem can be addressed without any special cases like !setonce. what do you think? Init is probably the right place to do that, except I wouldn't configure interfaces I am not going to use, because, some times, they are connected to funky things (like jtag, for example). I used open to do it on-demand. I don't know if it was the right decision, but that was the rationale behind it. If you think there is a better way, proceed :-). G.
Re: [9fans] usb/serial control open
On Sun, 23 Mar 2014 16:32:12 EDT erik quanstrom quans...@quanstro.net wrote:
On Sun Mar 23 15:56:52 EDT 2014, pau...@gmail.com wrote:
On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola pau...@gmail.com wrote:
if(!setonce){
setonce = 1;
serialctl(p, l8 i1); /* default line parameters */
}
And setonce needs to live in the interface, and it needs to be locked, etc.
another idea: since this is only needed by some hardware. and then only in i
nit.
why not make it the responsibility of such hardware to do this in the init
fn. then the problem can be addressed without any special cases like
!setonce.
On FreeBSD:
The sio driver also supports an initial-state and a lock-state control
device for each of the callin and the callout data devices. The
termios settings of a data device are copied from those of the corre-
sponding initial-state device on first opens and are not inherited from
previous opens. Use stty(1) in the normal way on the initial-state
devices to program initial termios states suitable for your setup.
A similar idea here would be to have a default command to
for default settings. When a device is opened, it is
initialized with these settings. The reason I like this is
because then I don't need to teach every serial IO program
what setting to use (often the other end is a dumb device
requiring its own fixed and peculiar settings).
Re: [9fans] usb/serial control open
A similar idea here would be to have a default command to for default settings. When a device is opened, it is initialized with these settings. The reason I like this is because then I don't need to teach every serial IO program what setting to use (often the other end is a dumb device requiring its own fixed and peculiar settings). i think it is even easier to set the state up properly with cpurc or consolefs' configuration file, and have the various programs not even care that they're talking to a serial port. rdb, for example, was one program that got this wrong. it was setting the baud, which backfired in some cases. not doing anything is a better solution. you can always echo bxyz/dev/eiaXXctl, assuming it really is a serial line. :-) - erik
Re: [9fans] usb/serial control open
On Sun, 23 Mar 2014 17:53:22 EDT erik quanstrom quans...@quanstro.net wrote: A similar idea here would be to have a default command to for default settings. When a device is opened, it is initialized with these settings. The reason I like this is because then I don't need to teach every serial IO program what setting to use (often the other end is a dumb device requiring its own fixed and peculiar settings). i think it is even easier to set the state up properly with cpurc or consolefs' configuration file, and have the various programs not even care that they're talking to a serial port. Not my experience. Occasionally programs do have to care about some serial port parameters and if such a program crashes you have a partially working interface. Think CTS/RTS state etc.
Re: [9fans] usb/serial control open
i think it is even easier to set the state up properly with cpurc or consolefs' configuration file, and have the various programs not even care that they're talking to a serial port. Not my experience. Occasionally programs do have to care about some serial port parameters and if such a program crashes you have a partially working interface. Think CTS/RTS state etc. doesn't sound like the common case. in any event, seems like a program fiddling with CTS/RTS should do the whole setup, especially if it plans on crashing. :-) - erik
Re: [9fans] usb/serial control open
On Sun, 23 Mar 2014 20:32:07 EDT erik quanstrom quans...@quanstro.net wrote: i think it is even easier to set the state up properly with cpurc or consolefs' configuration file, and have the various programs not even care that they're talking to a serial port. Not my experience. Occasionally programs do have to care about some serial port parameters and if such a program crashes you have a partially working interface. Think CTS/RTS state etc. doesn't sound like the common case. in any event, seems like a program fiddling with CTS/RTS should do the whole setup, especially if it plans on crashing. :-) The issue is program A can leave things in non-working order and program B running after A has to deal with this. This is no different from bringing up a system in a known good state.
Re: [9fans] usb/serial control open
Init is probably the right place to do that, except I wouldn't configure interfaces I am not going to use, because, some times, they are connected to funky things (like jtag, for example). I used open to do it on-demand. I don't know if it was the right decision, but that was the rationale behind it. If you think there is a better way, proceed :-). can you explain a little more about why delaying configuration helps, and how you are using it, esp with jtag. for instance, is the usb cable always connected, even when not in use? i'm trying to understand here. - erik
Re: [9fans] usb/serial control open
The issue is program A can leave things in non-working order and program B running after A has to deal with this. This is no different from bringing up a system in a known good state. I think I'd rather be able to have a preceding program be able to set up the interface and leave it than cater for possible failures and needing all serial handling programs, irrespective of their application, needing to go through the set up motions. I'm with Erik on this one. ++L
