From: Darren G. <ts...@ya...> - 2005-01-31 01:56:00
|
Would it be fantastically tricky to get gumstix to do non-standard baud rates on a uart? I'm thinking of MIDI (31250). |
From: Craig H. <cr...@hu...> - 2005-01-31 02:58:24
|
=46rom the PXA Processor Developer's guide: 10.4.2.3 Divisor Latch Registers (DLL and DLH) Each UART contains a=20 programmable baud rate generator that can take the 14.7456 MHz fixed =20 input clock and divide it by 1 to (216=961). For the FFUART and the=20 STUART, the divisor is from 4 to (216=961). The baud rate generator=20 output frequency is 16 times the baud rate. Two 8-bit latch registers,=20= shown in Table 10-5 and Table 10-6, store the divisor in a 16-bit=20 binary format. Load these divisor latches during initialization to=20 ensure that the baud rate generator operates properly. If each Divisor=20= Latch is loaded with a 0, the 16X clock stops. The Divisor Latches are=20= accessed with a word write. The baud rate of the data shifted in to or=20= out of a UART is given by the formula: [picture of formula] For=20 example: if the divisor is 24, the baud rate is 38400 bps. The=20 divisor=92s reset value is 0x0002. For the FFUART and the STUART, the=20 divisor must be set to at least 0x0004 before the UART unit is=20 enabled. The formula in question is baudrate =3D 14.7456MHz/(16xdivisor), ie divisor =3D (14.7456*10^6)/(16*baudrate) (14.7456*10^6)/(16*31250) =3D 29.49 So you'd have to choose 29 or 30 14.7456M/16*29 =3D 31779 14.7456M/16*30 =3D 30720 setserial should work I think for either of those values. C On Jan 30, 2005, at 5:55 PM, Darren Gibbs wrote: > Would it be fantastically tricky to get gumstix to do non-standard=20 > baud rates on a uart? I'm thinking of MIDI (31250). > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive = Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Darren G. <ts...@ya...> - 2005-02-01 02:58:35
|
Thanks for this info! Thinking this would be a slam dunk I tried typing "setserial=20 /dev/ttyS0", oops no setserial in gumstix distribution. I read up on=20 setserial and downloaded the source for setserial 2.17. When I run it=20= on the gumstix, I get semi-reasonable looking output: # ./setserial /dev/ttyS1 -a /dev/ttyS1, Line 1, UART: undefined, Port: 0x0000, IRQ: 14 Baud_base: 921600, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal But when I try to change anything, I get "invalid argument" from=20 ioctl(fd, TIOCSSERIAL, &new_serinfo) in the set_serial() function: # ./setserial /dev/ttyS1 low_latency Cannot set serial info: Invalid argument # ./setserial /dev/ttyS1 divisor 10 Cannot set serial info: Invalid argument But different from "missing argument": # ./setserial /dev/ttyS1 divisor Missing argument for divisor I added some printfs to dump the new_serinfo struct, thinking I might=20 be able to see what the ioctl is complaining about, but no luck. I can=20= see that the command line is being parsed properly: # ./setserial /dev/ttyS1 divisor 5 /dev/ttyS1, Line 1, UART: undefined, Port: 0x0000, IRQ: 14 Baud_base: 921600, close_delay: 50, divisor: 5 closing_wait: 3000 This same source seems to work fine on my SUSE box. Any ideas about what might be going wrong? thanks, darren On Jan 30, 2005, at 6:58 PM, Craig Hughes wrote: > =46rom the PXA Processor Developer's guide: > > 10.4.2.3 Divisor Latch Registers (DLL and DLH) Each UART contains a=20 > programmable baud rate generator that can take the 14.7456 MHz fixed =20= > input clock and divide it by 1 to (216=961). For the FFUART and the=20 > STUART, the divisor is from 4 to (216=961). The baud rate generator=20= > output frequency is 16 times the baud rate. Two 8-bit latch =20 > registers, shown in Table 10-5 and Table 10-6, store the divisor in a=20= > 16-bit binary format. Load these divisor latches during=20 > initialization to ensure that the baud rate generator operates=20 > properly. If each Divisor Latch is loaded with a 0, the 16X clock=20 > stops. The Divisor Latches are accessed with a word write. The baud=20= > rate of the data shifted in to or out of a UART is given by the=20 > formula: [picture of formula] For example: if the divisor is 24, the=20= > baud rate is 38400 bps. The divisor=92s reset value is 0x0002. For the=20= > FFUART and the STUART, the divisor must be set to at least 0x0004=20 > before the UART unit is enabled. > > > The formula in question is baudrate =3D 14.7456MHz/(16xdivisor), ie > > divisor =3D (14.7456*10^6)/(16*baudrate) > > (14.7456*10^6)/(16*31250) =3D 29.49 > > So you'd have to choose 29 or 30 > > 14.7456M/16*29 =3D 31779 > 14.7456M/16*30 =3D 30720 > > setserial should work I think for either of those values. > > C > > > On Jan 30, 2005, at 5:55 PM, Darren Gibbs wrote: > >> Would it be fantastically tricky to get gumstix to do non-standard=20 >> baud rates on a uart? I'm thinking of MIDI (31250). >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive=20 >> Reporting >> Tool for open source databases. Create drag-&-drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, = etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive = Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-02-01 05:21:34
|
On Jan 31, 2005, at 6:58 PM, Darren Gibbs wrote: > Thanks for this info! > > Thinking this would be a slam dunk I tried typing "setserial > /dev/ttyS0", oops no setserial in gumstix distribution. I read up on > setserial and downloaded the source for setserial 2.17. When I run it > on the gumstix, I get semi-reasonable looking output: Yeah, so I just noticed setserial's not there :) stty is though, and it too has trouble changing some parameters -- probably some limitation of the pxa serial port ioctl implementation. In particular, it seem to allow me to set certain "standard" serial port baud rates, but not funky ones like 30720 or 31779. I'll look at the kernel code in the morning to try and figure out why. C |
From: Darren G. <ts...@ya...> - 2005-03-06 03:28:07
|
On Jan 31, 2005, at 9:21 PM, Craig Hughes wrote: > :) stty is though, and it too has trouble changing some parameters -- > probably some limitation of the pxa serial port ioctl implementation. > In particular, it seem to allow me to set certain "standard" serial > port baud rates, but not funky ones like 30720 or 31779. I'll look at > the kernel code in the morning to try and figure out why. I've been trying today to figure this out, and I think I'm on the right track. There doesn't seem to be a way to ask for funky baud rates directly. You'd have to change 4-5 different files to add the new baud rates to the list. However it would seem that I can set the port to 38400, set the UPF_SPD_CUST flag, and the driver will jam a custom divisor into the port's Divisor Latch Registers for me. in drivers/serial/pxa.c the funtion serial_pxa_set_termios(): /* * Ask the core to calculate the divisor for us. */ baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk/16); quot = uart_get_divisor(port, baud); uart_get_divisor() is in serial_core.c if (baud == 38400 && (port->flags & UPF_SPD_MASK) == UPF_SPD_CUST) quot = port->custom_divisor; else quot = (port->uartclk + (8 * baud)) / (16 * baud); return quot; There are examples of how to do it with setserial, but they fail: # ./setserial -a /dev/ttyS3 divisor 29 spd_cust set_serial():TIOCSSERIAL:Cannot set serial info: Invalid argument /dev/ttyS3, Line 3, UART: undefined, Port: 0x0000, IRQ: 0 Baud_base: 921600, close_delay: 50, divisor: 29 closing_wait: 3000 Flags: spd_cust setserial's ioctl appears to call into uart_ioctl(), and then uart_set_info() in serial_core.c. I'm guessing that this: /* * Ask the low level driver to verify the settings. */ if (port->ops->verify_port) retval = port->ops->verify_port(port, &new_serial); might be where it's failing... static int serial_pxa_verify_port(struct uart_port *port, struct serial_struct *ser) { /* we don't want the core code to modify any port params */ return -EINVAL; } Does anyone know their way around this code enough to guess where to look more closely? |
From: Darren G. <ts...@ya...> - 2005-03-07 03:11:27
|
Changing this function in pxa.c to return 0 lets setserial set the divisor properly. I verified that it's working using pxaregs to dump the HWUART's LCR. On Mar 5, 2005, at 7:28 PM, Darren Gibbs wrote: > serial_pxa_verify_port(struct uart_port *port, struct serial_struct > *ser) > { > /* we don't want the core code to modify any port params */ > //return -EINVAL; > return 0; > } |
From: Craig H. <cr...@gu...> - 2005-10-20 21:04:09
|
On Mar 6, 2005, at 7:11 PM, Darren Gibbs wrote: > Changing this function in pxa.c to return 0 lets setserial set the > divisor properly. I verified that it's working using pxaregs to > dump the HWUART's LCR. > > On Mar 5, 2005, at 7:28 PM, Darren Gibbs wrote: > >> serial_pxa_verify_port(struct uart_port *port, struct >> serial_struct *ser) >> { >> /* we don't want the core code to modify any port params */ >> //return -EINVAL; >> return 0; >> } Darren, just going through cleaning out all the really old mail in my inbox that I hadn't yet dealt with -- I had this in there, but don't have the context for it -- what exactly is the purpose of this proposed patch? thanks C |
From: Darren G. <ts...@ya...> - 2005-10-22 02:18:14
|
Hi Craig, It's been awhile since I looked at this and I should have taken better notes! The gist of it is that I was trying to get the gumstix serial port to do MIDI (31250 or as close as possible). After asking some folks on this list and reading about stty and setserial it seemed like I should be able to do this: setserial /dev/ttyS3 divisor 29 spd_cust stty -F /dev/ttyS3 speed 38400 stty -F /dev/ttyS3 speed 38400 to specify a custom divisor and use stty's "custom mode" to have the serial code setup the port properly. It kept not working for no apparent reason. I used pxaregs to check out the low-level settings and found that the divisor I specified kept not getting set. I spent a bunch of time stepping through the serial code and found that setting the new divisor wasn't working because serial_pxa_verify_port () was returning an error unconditionally. The comment in that function didn't really explain why the error was being returned. When I changed the code to return zero, the custom divisor code starting working fine. I don't know if there are side effects to "fixing" it this way (I didn't see any when stepping), but there may be. The hack has been working great since I figured all of this out last March... we've been shipping product and MIDI send/receive has been reliable. If there's a better way to do this I'd be happy to know so I don't have to reapply hacks to the buildroot when I update... (the main reason I haven't updated my buildroot since March -- under the "if it ain't broke don't fix it" principle). A related hack I applied was to comment out the AFE for HWUART in serial_pxa_set_mctrl() so I could use the HWUART as a second port for MIDI. // if (port->line == 3) // HWUART // { // mcr |= UART_MCR_AFE; // } I wasn't confident enough in my understanding of the serial code to fix this properly and make it software configurable. Has someone wiser that I fixed it in the meantime? thanks, darren On Oct 20, 2005, at 2:03 PM, Craig Hughes wrote: > On Mar 6, 2005, at 7:11 PM, Darren Gibbs wrote: > > >> Changing this function in pxa.c to return 0 lets setserial set the >> divisor properly. I verified that it's working using pxaregs to >> dump the HWUART's LCR. >> >> On Mar 5, 2005, at 7:28 PM, Darren Gibbs wrote: >> >> >>> serial_pxa_verify_port(struct uart_port *port, struct >>> serial_struct *ser) >>> { >>> /* we don't want the core code to modify any port params */ >>> //return -EINVAL; >>> return 0; >>> } >>> > > Darren, > > just going through cleaning out all the really old mail in my inbox > that I hadn't yet dealt with -- I had this in there, but don't have > the context for it -- what exactly is the purpose of this proposed > patch? > > thanks > > C > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@gu...> - 2005-10-22 17:07:33
|
Ok, that's more or less what I figured as I wrestled with insomnia by coding and reading docs two nights ago. I implemented a slightly different version which instead of just returning 0 will check some stuff to make sure things are at least a little sane before returning the 0 (eg makes sure baud rate isn't higher than allowed, etc). I also checked in a fix to the HWUART AFE thing which sets AFE in a better place and with a better condition check, and an attempt at getting RTS/CTS working for the non-HWUART ports too, which works by only writing one byte at a time, waiting till it's been sent, then only sending the next byte is CTS is high. That patch was suggested by someone on the list. C On Oct 21, 2005, at 7:18 PM, Darren Gibbs wrote: > Hi Craig, > > It's been awhile since I looked at this and I should have taken > better notes! The gist of it is that I was trying to get the > gumstix serial port to do MIDI (31250 or as close as possible). > After asking some folks on this list and reading about stty and > setserial it seemed like I should be able to do this: > > setserial /dev/ttyS3 divisor 29 spd_cust > stty -F /dev/ttyS3 speed 38400 > stty -F /dev/ttyS3 speed 38400 > > to specify a custom divisor and use stty's "custom mode" to have > the serial code setup the port properly. It kept not working for > no apparent reason. I used pxaregs to check out the low-level > settings and found that the divisor I specified kept not getting > set. I spent a bunch of time stepping through the serial code and > found that setting the new divisor wasn't working because > serial_pxa_verify_port() was returning an error unconditionally. > The comment in that function didn't really explain why the error > was being returned. When I changed the code to return zero, the > custom divisor code starting working fine. I don't know if there > are side effects to "fixing" it this way (I didn't see any when > stepping), but there may be. The hack has been working great since > I figured all of this out last March... we've been shipping product > and MIDI send/receive has been reliable. > > If there's a better way to do this I'd be happy to know so I don't > have to reapply hacks to the buildroot when I update... (the main > reason I haven't updated my buildroot since March -- under the "if > it ain't broke don't fix it" principle). > > A related hack I applied was to comment out the AFE for HWUART in > serial_pxa_set_mctrl() so I could use the HWUART as a second port > for MIDI. > > // if (port->line == 3) // HWUART > // { > // mcr |= UART_MCR_AFE; > // } > > I wasn't confident enough in my understanding of the serial code to > fix this properly and make it software configurable. Has someone > wiser that I fixed it in the meantime? > > thanks, > > darren > > > On Oct 20, 2005, at 2:03 PM, Craig Hughes wrote: > > >> On Mar 6, 2005, at 7:11 PM, Darren Gibbs wrote: >> >> >> >>> Changing this function in pxa.c to return 0 lets setserial set >>> the divisor properly. I verified that it's working using pxaregs >>> to dump the HWUART's LCR. >>> >>> On Mar 5, 2005, at 7:28 PM, Darren Gibbs wrote: >>> >>> >>> >>>> serial_pxa_verify_port(struct uart_port *port, struct >>>> serial_struct *ser) >>>> { >>>> /* we don't want the core code to modify any port params */ >>>> //return -EINVAL; >>>> return 0; >>>> } >>>> >>>> >> >> Darren, >> >> just going through cleaning out all the really old mail in my >> inbox that I hadn't yet dealt with -- I had this in there, but >> don't have the context for it -- what exactly is the purpose of >> this proposed patch? >> >> thanks >> >> C >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Power Architecture Resource Center: Free content, downloads, >> discussions, >> and more. http://solutions.newsforge.com/ibmarch.tmpl >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Darren G. <ts...@ya...> - 2005-02-01 18:45:37
|
Hmmm... Seems like I might have bigger problems. The MIDI spec says the=20= data rate is 31.25 Kbaud (+/- 1%). On Jan 30, 2005, at 6:58 PM, Craig Hughes wrote: > So you'd have to choose 29 or 30 > > 14.7456M/16*29 =3D 31779 > 14.7456M/16*30 =3D 30720 The formula for error I found in a PIC data sheet: Error =3D (Calculated Baud Rate =96 Desired Baud Rate) / Desired Baud = Rate error =3D (31779 - 31250) / 31250 error =3D 1.7% I figure this problem can't be new, but I'm finding very little info=20 about it. Some sites hint that an error of up to 3% is OK with certain=20= MIDI devices. Since I'm transmitting to a PIC, I could use its auto=20 baud rate detection feature to sync to whatever the gumstix is using...=20= but I want the gumstix to be able to receive commands from standard=20 MIDI controllers. I guess I should just try it and see... if it=20 doesn't work, maybe I could do a bitbang/GPIO approach to serial i/o=20 for MIDI? Has anyone tried it? Since we have ghosts on the team, could we have a seance and ask them=20 to update the Audiostix to a Musicstix which adds the MIDI physical=20 layer, baud rate translation from 31250 to a standard rate, and a=20 breakout cable for MIDI in/out/thru? And while they're at it, USB host=20= capability and drivers so you can connect any USB MIDI interface. ;-) darren= |
From: Darren G. <ts...@ya...> - 2005-02-03 04:02:49
|
RE: allowable error... In case this might interest someone searching=20 future mailing list archives, I learned: if it's an asynchronous serial protocol then the MAXIMUM allowable=20 error is close enough to 50/(start bits + data bits [+ stop bits]) % (Stop bits may not be necessary depending on system design) ie the error required to get half a bit error so that sampling wanders=20= off the proper bit onto the adjacent one. eg the standard 1+ 8 + 1 serial data protocol gives 50/(1+8) =3D~ 5.6% With stop bit that's 50/(1+8+1) =3D 5% That's the error at BOTH ends. If the error is in the same direction at both ends you can tolerate=20 higher error rates. If it goes opposite ways then the above applies. Murphy says it goes=20 the same way during design and opposite ways in real world must-work=20 situations. On Feb 1, 2005, at 10:45 AM, Darren Gibbs wrote: > Hmmm... Seems like I might have bigger problems. The MIDI spec says=20 > the data rate is 31.25 Kbaud (+/- 1%). > > On Jan 30, 2005, at 6:58 PM, Craig Hughes wrote: >> So you'd have to choose 29 or 30 >> >> 14.7456M/16*29 =3D 31779 >> 14.7456M/16*30 =3D 30720 > > The formula for error I found in a PIC data sheet: > > Error =3D (Calculated Baud Rate =96 Desired Baud Rate) / Desired Baud = Rate > > error =3D (31779 - 31250) / 31250 > > error =3D 1.7% > > I figure this problem can't be new, but I'm finding very little info=20= > about it. Some sites hint that an error of up to 3% is OK with certain=20= > MIDI devices. Since I'm transmitting to a PIC, I could use its auto=20= > baud rate detection feature to sync to whatever the gumstix is=20 > using... but I want the gumstix to be able to receive commands from=20 > standard MIDI controllers. I guess I should just try it and see... if=20= > it doesn't work, maybe I could do a bitbang/GPIO approach to serial=20 > i/o for MIDI? Has anyone tried it? > > Since we have ghosts on the team, could we have a seance and ask them=20= > to update the Audiostix to a Musicstix which adds the MIDI physical=20 > layer, baud rate translation from 31250 to a standard rate, and a=20 > breakout cable for MIDI in/out/thru? And while they're at it, USB=20 > host capability and drivers so you can connect any USB MIDI interface.=20= > ;-) > > darren > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive = Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |