Re: uchcom(4) did not work

2014-05-14 Thread Creamy
> > > > /* > > > > * XXX: it is difficult to handle the line control > > > > appropriately: > > > > -* - CS8, !CSTOPB and any parity mode seems ok, but > > > > -* - the chip doesn't have the function to calculate parity > > > > -* in !CS8 mode. > >

Re: uchcom(4) did not work

2014-05-14 Thread Mark Kettenis
> Date: Wed, 14 May 2014 11:04:56 +0200 > From: Martin Pieuchot > > On 13/05/14(Tue) 21:24, Mike Larkin wrote: > > On Wed, May 14, 2014 at 11:02:49AM +0900, SASANO Takayoshi wrote: > > > Hi, > > > > > > Simply magic values are rewrited with #define. > > > If these values need to be disassembled,

Re: uchcom(4) did not work

2014-05-14 Thread Martin Pieuchot
On 13/05/14(Tue) 21:24, Mike Larkin wrote: > On Wed, May 14, 2014 at 11:02:49AM +0900, SASANO Takayoshi wrote: > > Hi, > > > > Simply magic values are rewrited with #define. > > If these values need to be disassembled, please take a while... > > > > I think we need to understand what those value

Re: uchcom(4) did not work

2014-05-13 Thread Mike Larkin
On Wed, May 14, 2014 at 11:02:49AM +0900, SASANO Takayoshi wrote: > Hi, > > Simply magic values are rewrited with #define. > If these values need to be disassembled, please take a while... > I think we need to understand what those values mean. When I mentioned #defines, I meant something like:

Re: uchcom(4) did not work

2014-05-13 Thread SASANO Takayoshi
Hi, Simply magic values are rewrited with #define. If these values need to be disassembled, please take a while... SASANO Takayoshi Index: uchcom.c === RCS file: /cvs/src/sys/dev/usb/uchcom.c,v retrieving revision 1.19 diff -u

Re: uchcom(4) did not work

2014-05-13 Thread Kenneth Westerback
On 13 May 2014 21:09, Mike Larkin wrote: > On Wed, May 14, 2014 at 10:01:28AM +0900, SASANO Takayoshi wrote: >> Hi, Mike. >> >> >> + val = 0x501f; >> >> + idx = 0xd90a; >> > >> > What are these magic numbers? >> >> These numbers come from Linux driver (ch341.c). I don't know what they mean. >> M

Re: uchcom(4) did not work

2014-05-13 Thread Mike Larkin
On Wed, May 14, 2014 at 10:01:28AM +0900, SASANO Takayoshi wrote: > Hi, Mike. > > >> + val = 0x501f; > >> + idx = 0xd90a; > > > > What are these magic numbers? > > These numbers come from Linux driver (ch341.c). I don't know what they mean. > Maybe these numbers represent default character len

Re: uchcom(4) did not work

2014-05-13 Thread SASANO Takayoshi
Hi, Mike. >> +val = 0x501f; >> +idx = 0xd90a; > > What are these magic numbers? These numbers come from Linux driver (ch341.c). I don't know what they mean. Maybe these numbers represent default character length and baudrate divisor. http://lxr.cpsc.ucalgary.ca/lxr/#linux+v2.6.31/driver

Re: uchcom(4) did not work

2014-05-13 Thread Mike Larkin
On Wed, May 14, 2014 at 05:39:38AM +0900, SASANO Takayoshi wrote: > Hello, > > Recently I bought Arduino board which uses Nanjing QinHeng (WinChipHead) > CH340T USB-UART bridge via eBay, and I found uchcom(4) did not work. > At misc@, other user reported similar problem. [1] &g

Re: uchcom(4) did not work

2014-05-13 Thread Bryan Steele
On Wed, May 14, 2014 at 05:39:38AM +0900, SASANO Takayoshi wrote: > Hello, > > Recently I bought Arduino board which uses Nanjing QinHeng (WinChipHead) > CH340T USB-UART bridge via eBay, and I found uchcom(4) did not work. > At misc@, other user reported similar problem. [1] &g

uchcom(4) did not work

2014-05-13 Thread SASANO Takayoshi
Hello, Recently I bought Arduino board which uses Nanjing QinHeng (WinChipHead) CH340T USB-UART bridge via eBay, and I found uchcom(4) did not work. At misc@, other user reported similar problem. [1] The uchcom(4) comes from NetBSD and it seems to be worked at that time. I found that