gumstix

Hi Sean,

> Problem is, PWR from the Gumstix UARTs is V_BATT, which is the
> regulated power.  This is a lot of drain on the RoboStix's power
> regulator, and for us, the camera plus the Gumstix, five infrared
> sensors, an LCD, and two bump-switches is just too much on the
> regulator.  Instead we're powering the CMUCam2 by hooking its power
> supply to V_MOTOR and GND on one of the RoboStix's servo ports, which
> provides unregulated power from our battery pack I believe.  I think
> that's fine as the CMUCam2 has a more than adequate power regulator
> onboard.  Then we just hook up the respective TX and RX lines on the
> TTL and leave the PWR and GND lines unconnected.  Seems to be working
> reasonably but I've not tested that much.

Yes - V_MOTOR would be unregulated power.

> At this stage my understanding is that the CMUCam2 might be receiving
> juice from two possible sources: the PWR line of the TTL UART, and
> the RX line ("0-bit" is 5V send from the Gumstix's TX to the
> CMUCam2's RX).  Power from the PWR line is fine -- it bypasses the
> switch though.  But power to the RX line isn't good if not
> accompanied by the PWR line.

If you put a pull-down resistor (say 10-50K) between Gnd and the STUART RxD=
.
Configure GPIO 46 as input, and GPIO 47 as output set to zero.

When you detect a logic high on GPIO 46, then the CMUCam has been
powered on, and you can configure 46 as AF2, and 47 as AF1 to get the
STUART functionality back.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

On Mar 1, 2006, at 11:05 PM, Sean Luke wrote:

> At present we're running at 115200 (set the camera to that too) and  
> with echo turned off.  To this end  modified /etc/init.d/S98ttyS2   
> (ours is S98) to say
> 	stty -F /dev/ttyS2 -echo -ixon speed 115200
>
> I've been doing light testing by doing something like
> 	cat /dev/ttyS2 > /dev/ttyS0&
> 	echo "CMUCam2CommandHere" | tr '\012' '\015' > /dev/ttyS2
> 	echo "AnotherCommand" | tr '\012' '\015' > /dev/ttyS2
> 	echo "And so on" | tr '\012' '\015' > /dev/ttyS2

For a better way of light-weight testing, I'd suggest building socat  
with termios support and using that to hold the connection to ttyS2  
open.  It seems that when a process which has a tty open exits and  
closes the tty, all unsent characters in the UART buffer are dropped,  
not sent.  Using socat, you can hold the tty open (and set speed, etc  
using the termios options) and do bi-directional I/O easily.  In the  
above situation, probably the cat process reading from ttyS2 is  
holding the UART open and so the contents are getting dropped.

C