Hi,
I have tried the usb->serial adapters I could find lying around the office.
Using the code you sent me, not the very latest from sources.
The FTDI chips we use in our products work fine
ep13.0 255 csp 0xff vid 0x10c4 did 0xea60 'Silicon Labs' 'CP2102
USB to UART Bridge Controlle
> Maybe it's as simple
> as having separate read and write QLocks.
For normal endpoints it is that simple. Control endpoints, however,
are bidirectional but effectively half-duplex, so reads and writes
still need to be locked against each other.
Today's version of /n/sources/contrib/miller/9/bcm
On Mon, Dec 12, 2016 at 9:39 PM, Richard Miller <9f...@hamnavoe.com> wrote:
> Oops, pressed the wrong button - that reply was intended for
> Steve Simon and not the whole of 9fans. Oh well, if anybody
> else wants to rummage through the usbdwc driver too, they
> are welcome.
>
Thanks, because I
Oops, pressed the wrong button - that reply was intended for
Steve Simon and not the whole of 9fans. Oh well, if anybody
else wants to rummage through the usbdwc driver too, they
are welcome.
> I cannot get the usb serial interfaces we use to work. I have never managed
> to get
> usb serial adapters to work with the raspberry pi, though never had problems
> on x86 boxen.
> ...
>
> Text into the pi works fine, but outgoing text seems stalled until text is
> received,
> I can type ahe
Hi,
I have upgraded my pi desktop to a 3 which is noticable faster.
I am using Richard's pi image which as usual works perfectly, but for one
wrinkle.
I cannot get the usb serial interfaces we use to work. I have never managed to
get
usb serial adapters to work with the raspberry pi, though nev
Hi,
Todays problem is getting a USB serial device to work with plan9 on a raspberry
PI.
I have several dongles which seem to reprisent two chipsets.
One is recognised by the USB driver and it starts usb/serial for me,
sadly It just seems to receive a single character constantly.
The other is n
> 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 cat
> 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 ration
On Sun, 23 Mar 2014 20:32:07 EDT erik quanstrom 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
> > 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
On Sun, 23 Mar 2014 17:53:22 EDT erik quanstrom 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 prog
> 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
On Sun, 23 Mar 2014 16:32:12 EDT erik quanstrom 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 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 an
On Sun Mar 23 15:56:52 EDT 2014, pau...@gmail.com wrote:
> On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola wrote:
>
> >
> > if(!setonce){
> > setonce = 1;
> > serialctl(p, "l8 i1"); /* default line parameters */
> > }
>
> And setonce needs to live in the interface, and it needs to
On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola 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.
> 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
>
> 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 i
On Sun Mar 23 14:35:52 EDT 2014, pau...@gmail.com wrote:
> On Sun, Mar 23, 2014 at 7:09 PM, erik quanstrom 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´
On Sun, Mar 23, 2014 at 7:09 PM, erik quanstrom 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
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){
> Erik has seen some of these problems, maybe he has fixed them?
he! usb serial is my nemisis. you're welcome to try the 9atom usb/serial.
it should have some corrected little bits so at least the endpoint debugging
stuff isn't truncated.
- erik
On Mon, Mar 17, 2014 at 3:35 PM, arisawa wrote:
> Thank you Gorka,
>
> I made a mistake.
> The usage of 9front is different from that of Bell-labs.
> It seems FT232R is OK, but PL2303HX has a problem.
>
> term% cat /lib/ndb/consoledb
> group=sys
Yes, I see. FTDI is better supported, because I ha
Thank you Gorka,
I made a mistake.
The usage of 9front is different from that of Bell-labs.
It seems FT232R is OK, but PL2303HX has a problem.
term% cat /lib/ndb/consoledb
group=sys
uid=glenda
uid=arisawa
console=usb3 dev=/dev/eiaU3 openondemand=1
gid=sys
console=usb4 dev=
Isn't it a variant of the version (almost) supported? There were sone issues at
fast speed, but I believe it is there in the distro.
G.
> On Mar 16, 2014, at 6:40 AM, arisawa wrote:
>
> Hello,
>
> Anyone has a driver for FT232R or PL2303HX?
> Or working on those drivers?
>
> Kenji Arisawa
>
Hello,
Anyone has a driver for FT232R or PL2303HX?
Or working on those drivers?
Kenji Arisawa
> I have one which I used to write the code and used as my sole console
> to the machine I was debugging for everyday like 3 months. Then I got
> a new one and I stopped using it. Some weeks ago Jeff complained
> about it and Richard and I concurrently found a bug in it. I tested
> it very light
> typing doesn't work at all.
>
> before i go charging off learning about the prolific serial,
> has anyone gone a round or two with this type of hardware?
> any clues on what i should be looking for?
I have one which I used to write the code and used as my sole console to the
machine I was deb
; usb/probe
ep12.0 255 csp 0xff vid 0x067b did 0x2303 '' '' ohci
i've got a new arm box, and i'm having some trouble with the
serial. occasionally i can connect to the box, but generally
i can't connect, and when i do connect the connection gets
easily wedged. i just killed off all the usb/s
> With the Ein fix, it works again with the
> Trendnet TU-S9
Thanks, I've sent it as a patch.
With the Ein fix, it works again with the
Trendnet TU-S9 which reports:
vid 0x067b
did 0x2303
which is prolific.
G.
Yes, I am looking into it and just saw this.
G.
On Feb 14, 2013, at 8:24 PM, Richard Miller <9f...@hamnavoe.com> wrote:
> I said:
>
>>> The current Plan 9 usb architecture perpetuates the confusion by
>>> referring to them both with one name epN.1, but you still have to open
>>> them both indepe
I said:
>> The current Plan 9 usb architecture perpetuates the confusion by
>> referring to them both with one name epN.1, but you still have to open
>> them both independently.
Erik replied:
> in that case, shouldn't these three blocks be reverted?
Erik is right, I was talking through my hat.
from the dump:
Jan 25 15:54:19 CST 2013 serial 213453 [jmk]
Jan 25 15:54:19 CST 2013 /n/sourcesdump/2013/0214/plan9/386/bin/usb/serial
213453 [jmk]
Dec 10 21:27:37 CST 2012 /n/sourcesdump/2013/0125/plan9/386/bin/usb/serial
211141 [sys]
…
the Dec 10 version works with Prolific USB-to-Serial devi
On Thu Feb 14 05:24:27 EST 2013, 9f...@hamnavoe.com wrote:
> > this is a WORKAROUND. a proper fix would be something
> > like allowing ORDWR in usbopen if that is indeed the problem.
>
> No, endpoints are unidirectional by design; in the usb spec there are
> no read/write endpoints. The confusin
> this is a WORKAROUND. a proper fix would be something
> like allowing ORDWR in usbopen if that is indeed the problem.
No, endpoints are unidirectional by design; in the usb spec there are
no read/write endpoints. The confusing thing in the spec is that two
different endpoints can have the same
lyons# 6.out
ehci 0xfe00dfa23000: port 1 didn't reset within 500 ms; sts 0x1101
usb/hub... usb/serial... epout 1 epin 1
serial: open i/o ep data: '/dev/usb/ep4.1/data' permission denied
6.out: serial: serial: no endpoints found for ifc 0
139: 6.out: bootes: fault addr=0xfffe kpc=0x223be7
6.
On Mon Feb 4 10:54:40 EST 2013, lu...@proxima.alt.za wrote:
> > On Mon Feb 4 10:29:57 EST 2013, lu...@proxima.alt.za wrote:
> >> Does this look familiar to anyone?
> >>
> >>
> >>term% usb/serial
> >>usb/serial: startdevs: opening #0 /dev/usb/ep5.0
> >>serial: open i/o ep data: '/dev
> On Mon Feb 4 10:29:57 EST 2013, lu...@proxima.alt.za wrote:
>> Does this look familiar to anyone?
>>
>>
>> term% usb/serial
>> usb/serial: startdevs: opening #0 /dev/usb/ep5.0
>> serial: open i/o ep data: '/dev/usb/ep5.3/data' permission denied
>> usb/serial: devmain: seria
On Mon Feb 4 10:29:57 EST 2013, lu...@proxima.alt.za wrote:
> Does this look familiar to anyone?
>
>
> term% usb/serial
> usb/serial: startdevs: opening #0 /dev/usb/ep5.0
> serial: open i/o ep data: '/dev/usb/ep5.3/data' permission denied
> usb/serial: devmain: serial: no
Does this look familiar to anyone?
term% usb/serial
usb/serial: startdevs: opening #0 /dev/usb/ep5.0
serial: open i/o ep data: '/dev/usb/ep5.3/data' permission denied
usb/serial: devmain: serial: no endpoints found for ifc 0
serial 11096: suicide: sys: trap
42 matches
Mail list logo
