From: Maymi, F. M. E. <Fer...@us...> - 2005-02-07 19:58:48
Attachments:
ROK footprint.pdf
|
I've been able to use all ports except /dev/ttyS2 (STUART). A word of caution (if you haven't figured this out already... It took me a while): ttyS0 and ttyS3 have RS232 signaling levels at the round connectors while ttyS1 and ttyS2 come out as TTL signals.=20 I connected directly to pins K4 (transmit) and M3 (receive) on the bluetooth pad of a non-bluetooth Gumstix in order to use ttyS1. (See attached pin schematic for the Bluetooth module.) I haven't been able to use ttyS2 at all (and would love to), so I would appreciate any clues you may be able to drop my way! Fernando -----Original Message----- From: gum...@li... [mailto:gum...@li...] On Behalf Of tigeba Sent: Monday, February 07, 2005 2:27 PM To: gum...@li... Subject: [Gumstix-users] Using all available serial ports Hello all. I am working on a project where I would optimally like to use all of the serial ports available. My desired setup would be something like: /dev/ttyS0 GPS / Emergency console? /dev/ttyS1 TNC /dev/ttyS2 Microcontroller /dev/ttyS3 Microcontroller In my case this means no bluetooth, and redirecting the console output away from the serial ports. This also presents a bit of a challenge during development as if something goes wrong, there is basically no way to fix anything (assume no USB). I understand that the bluetooth module is wired directly to ttyS2(?), but I am assuming if it is not initialized, it would be ok to hang some additional wires off this port. Perhaps one of you has devised a clever way to suspend console output temporarily, and resume if problems arise? Perhaps if uboot was always accessible via console, but it would switch off when the kernel started, unless a param was passed..... I have attached my nano makefile as a sacrifice to the gods of the mailing list. It does not perform any sort of dependency checking, so you will need to run 'make ncurses' first. I'm not a big vi fan, so it was the first thing I installed on my gumstix :) Craig, please feel free to add it to the distro if you feel it is helpful. Thanks! |
From: Philip T. <ph...@te...> - 2005-02-08 02:17:30
|
On Mon, 2005-02-07 at 14:58 -0500, Maymi, F. MAJ EECS wrote: SNIP > I haven't been able to use ttyS2 at all (and would love to), so I would > appreciate any clues you may be able to drop my way! > Hi Fernando, I'd be very interested in this too! The pins wouldn't have to be configured for the UART function would they? They might be configured as standard GPIO by default. Craig, would this be the case? > Fernando > HTH, Phil |
From: Craig H. <cr...@hu...> - 2005-02-08 02:29:15
|
On Feb 7, 2005, at 6:17 PM, Philip Trickett wrote: > On Mon, 2005-02-07 at 14:58 -0500, Maymi, F. MAJ EECS wrote: > SNIP >> I haven't been able to use ttyS2 at all (and would love to), so I >> would >> appreciate any clues you may be able to drop my way! >> > Hi Fernando, > > I'd be very interested in this too! > > The pins wouldn't have to be configured for the UART function would > they? They might be configured as standard GPIO by default. > > Craig, would this be the case? # cat /proc/gpio/GPIO4[67] 46 GPIO in set 47 GPIO in set if you modprobe proc_gpio then # echo AF2 in > /proc/gpio/GPIO46 # echo AF1 out > /proc/gpio/GPIO47 that should configure it right. By the way, looks like proc/gpio is case sensitive -- somebody should smack whoever wrote it that way. C |
From: Philip T. <ph...@te...> - 2005-02-09 15:45:40
|
On Mon, 2005-02-07 at 18:29 -0800, Craig Hughes wrote: > On Feb 7, 2005, at 6:17 PM, Philip Trickett wrote: > Snip > > Craig, would this be the case? > > # cat /proc/gpio/GPIO4[67] > 46 GPIO in set > 47 GPIO in set > > if you modprobe proc_gpio then > > # echo AF2 in > /proc/gpio/GPIO46 > # echo AF1 out > /proc/gpio/GPIO47 > > that should configure it right. By the way, looks like proc/gpio is > case sensitive -- somebody should smack whoever wrote it that way. > > C > OK, tried this, and as of yet I see nothing on the Waysmall board solder pads (using pins 5 and 7 on the 20 pads, with 16 as GND). Has this port been tested as part of the Gumstix operation? Cheers, Phil |
From: Craig H. <cr...@hu...> - 2005-02-09 18:16:55
|
On Feb 9, 2005, at 7:45 AM, Philip Trickett wrote: > On Mon, 2005-02-07 at 18:29 -0800, Craig Hughes wrote: >> On Feb 7, 2005, at 6:17 PM, Philip Trickett wrote: >> > Snip >>> Craig, would this be the case? >> >> # cat /proc/gpio/GPIO4[67] >> 46 GPIO in set >> 47 GPIO in set >> >> if you modprobe proc_gpio then >> >> # echo AF2 in > /proc/gpio/GPIO46 >> # echo AF1 out > /proc/gpio/GPIO47 >> >> that should configure it right. By the way, looks like proc/gpio is >> case sensitive -- somebody should smack whoever wrote it that way. >> >> C >> > > OK, tried this, and as of yet I see nothing on the Waysmall board > solder > pads (using pins 5 and 7 on the 20 pads, with 16 as GND). > > Has this port been tested as part of the Gumstix operation? Hmm -- Gordon says no. But the pins are a straight line out from the PXA pins... I'll read the PXA docs and see if there's something special about the STUART. C |
From: Craig H. <cr...@hu...> - 2005-02-11 21:22:59
|
On Feb 9, 2005, at 10:16 AM, Craig Hughes wrote: >> OK, tried this, and as of yet I see nothing on the Waysmall board >> solder >> pads (using pins 5 and 7 on the 20 pads, with 16 as GND). >> >> Has this port been tested as part of the Gumstix operation? > > Hmm -- Gordon says no. But the pins are a straight line out from the > PXA pins... I'll read the PXA docs and see if there's something > special about the STUART. Ok, we just tested this, cutting the HWUART lines on a waysmall board and plugging the STUART lines into the level shifter. The following steps needed to be taken to get it working: 1. Set GPIOs up correctly -- needed to program them through /proc/gpio before, but now I've altered u-boot with r374 to set the GPIOs up correctly at boot. 2. Need to stty -F /dev/ttyS2 -ixon speed 115200 The second piece tells the kernel to ignore flow control, since the STUART doesn't do flow control, and won't transmit unless flow control is turned off on the port. The speed will obviously depend on what you're connecting to it. C |
From: Lawrence H. <lharris@HariTech.com> - 2005-02-12 00:38:49
|
Craig Hughes wrote: > On Feb 9, 2005, at 10:16 AM, Craig Hughes wrote: > >>> OK, tried this, and as of yet I see nothing on the Waysmall board >>> solder >>> pads (using pins 5 and 7 on the 20 pads, with 16 as GND). >>> >>> Has this port been tested as part of the Gumstix operation? >> >> >> Hmm -- Gordon says no. But the pins are a straight line out from the >> PXA pins... I'll read the PXA docs and see if there's something >> special about the STUART. > > > Ok, we just tested this, cutting the HWUART lines on a waysmall board > and plugging the STUART lines into the level shifter. The following > steps needed to be taken to get it working: > > 1. Set GPIOs up correctly -- needed to program them through /proc/gpio > before, but now I've altered u-boot with r374 to set the GPIOs up > correctly at boot. > 2. Need to stty -F /dev/ttyS2 -ixon speed 115200 > > The second piece tells the kernel to ignore flow control, since the > STUART doesn't do flow control, and won't transmit unless flow control > is turned off on the port. The speed will obviously depend on what > you're connecting to it. > > C > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users Is it not true that you would use: stty -F /dev/ttyS2 clocal speed 115200 to disable hardware flow control? -ixon manages software flow control which should be a upper level driver issue and not directly affected by the port hardware. clocal should allow for 2 wire serial port operation and then if the device handles software flow control you can use the ixon and -ixon parameter to turn that on and off. Lawrence Harris |
From: Craig H. <cr...@gu...> - 2005-02-12 01:12:54
|
On Feb 11, 2005, at 4:38 PM, Lawrence Harris wrote: > Is it not true that you would use: > > stty -F /dev/ttyS2 clocal speed 115200 > > to disable hardware flow control? -ixon manages software flow control > which should be a upper level driver issue and not directly affected > by the port hardware. > > clocal should allow for 2 wire serial port operation and then if the > device handles software flow control you can use the ixon and -ixon > parameter to turn that on and off. Yeah, clocal would be better. I was having trouble though with ixon, and -ixon fixed it for me so things would work. C |
From: Philip T. <ph...@te...> - 2005-02-13 11:50:06
|
On Fri, 2005-02-11 at 13:22 -0800, Craig Hughes wrote: Snip > Ok, we just tested this, cutting the HWUART lines on a waysmall board > and plugging the STUART lines into the level shifter. The following > steps needed to be taken to get it working: > > 1. Set GPIOs up correctly -- needed to program them through /proc/gpio > before, but now I've altered u-boot with r374 to set the GPIOs up > correctly at boot. > 2. Need to stty -F /dev/ttyS2 -ixon speed 115200 > > The second piece tells the kernel to ignore flow control, since the > STUART doesn't do flow control, and won't transmit unless flow control > is turned off on the port. The speed will obviously depend on what > you're connecting to it. > > C > Thanks Craig, Will report back on this when I have a chance to connect up again. Phil |
From: Philip T. <ph...@te...> - 2005-02-17 15:36:34
|
On Sun, 2005-02-13 at 11:50 +0000, Philip Trickett wrote: > Thanks Craig, > > Will report back on this when I have a chance to connect up again. > > Phil Thanks Craig, This works. Phil |