<

As part of the ongoing effort to improve Red Menace, I wanted to be able to directly read the Gyro, and use the IFI controller to process the gyro output.

So, cribbing from my old ultrasonic code, I hooked up a Basic Stamp Board of Education to one of the IFI outputs (white = signal, black = gnd, and red = +5V if you're feeding it into the IFI), and wrote some code to measure the length of the pulse and send it out over the program/debug port. Seems to work fine, but more testing is going to be needed. The following code is hopefully self-explanatory, enjoy!

' PROGRAM:    BS2SX PWM Read Test
' Written by: Robert J Woodhead
' Date:       20 SEP 02
'
' Define BS2-SX Project Files
'
' {$STAMP BS2SX}
'
' Reads an incoming PWM signal, converts it to fracBase
' coordinates, outputs it as a packet ($FF,value) over
' the program/debug port.
'
' fracBase is the internal coordinate system used by my
' other code.  Instead of using 0..255 as is normal
' with a lot of IFI code, I use 0..250 to avoid overflow
' problems.  This also avoids the deadly 255 value being
' sent to the victors.  You can change fracBase to 256 if
' you want, it's entirely up to you.  However, using a
' smaller range lets you use an out-of-range value (I use
' fracBase+1) as a signal that means "no valid data"
'
' Another nice effect is that since 0..250 has an odd
' number of steps, the central step (125) is the true
' center of the range.
fracBase	con	250		' fractional range base, same as driver code
fracHalf	con	125		' half of fracBase
fracBaseP1	con	fracBase+1	' utility constants
fracHalfP1	con	fracHalf+1
' From empirical testing, I've found out the minimum and
' maximum pulse length (probably need to test it again
' to make sure).  From these numbers, I can precompute
' some constants to make the math go faster
minPulse	con	1120				' minimum pulse width
maxPulse	con	2658				' maximum pulse width
maxPulseM1	con	maxPulse - 1		' useful to have -1 value
rngPulse	con	maxPulse - minPulse	' max pulse range
badPulse	con	500				' bad pulse threshold
' In order to do precise math, when scaling from the pulse
' range to the fracBase range, I use a trick.  In order to
' avoid integer truncation problems, I first multiply the
' 0..rngPulse pulse width by some number greater than
' (rngPulse / fracBase), then divide it out again later.
' This in effect lets me do division with a fractional
' component.  As long as this multiplier is such that
' rngPulse * multipler < 65536, we'll never get an overflow.
'
' Since rngPulse is about 1500, as long as this number is
' above 6, and below about 40, we will get the desired
' accuracy.  I picked 32 because it's a number with only one
' 1 bit, and thus multiplies faster.
mulPulse	con	32
divPulseM	con	mulPulse * rngPulse
divPulse	con	divPulseM / fracBase
' So, the pulse, scaled to 0..rngPulse-1, multipled by
' mulPulse and then divided by divPulse, gives us our
' final value.
pulse		var	word				' the actual pulse
result	var	byte				' massaged result
' Right now, for testing, I actually output human readable
' text to the debug port.  In the final working code, these
' will be removed.
debug 0	' clear the screen
' Main loop.  Read PWM, display results
main:
	' Read a pulse from input line 0, low->high start,
	' and store the length in pulse
	pulsin 0,1,pulse
	' If no pwm received, indicate error (fracBase+1)
	if pulse <= badPulse then p_bad:
	' Pin results to the known good range.  I max out
	' at maxPulse - 1 to avoid "going over the top"
	' problems when doing the scaling.
	pulse = (pulse max maxPulseM1) min minPulse
	' Scale the pulse to 0..fracBase.
	result = ((pulse - minPulse)* mulPulse) / divPulse
	goto send_packet:
p_bad:
	' Set to our arbitrary "bad pulse" value
	result = fracBaseP1
send_packet:
	' Human readable output (home, output original and scaled
	' result, erase to end of line
	debug 1,dec5 pulse," ",dec3 result,11
	' Code you'd use to send to the basic stamp inside the
	' IFI.  You just connect the program/debug port of the
	' IFI to the program/debug port of your sensor manager
	' stamp (running this code).
	'
	' Amusingly, serout 16,16224 is the same as debug, but
	' it looks cooler this way.
	
'	serout 16,16624,[ $FF,result ]			' send packet
	' How the comm link works:
	'
	' This code is going to send out, without handshaking,
	' byte pairs a couple of hundred times a second.
	'
	' On the receiving end, in the code running on the IFI,
	' you have the following statement:
	'
	' serin 16,16624,50,timeout,[ WAIT($FF),STR pwm\1 ]
	'
	' This waits until it sees a $FF byte, then reads 1
	' byte into byte variable pwm.  If it doesn't finish
	' within 50 msec (1/20 second), it jumps to label
	' timeout.
	'
	' That timeout is probably generous, you can probably
	' reduce it (haven't done testing yet).
	'
	' The cute thing is that because the packet starts with
	' $FF, and because the data byte can't be bigger than
	' 251 (and thus, never $FF), even if the serin starts
	' reading in the middle of the send of a packet, there's
	' no combination of data bytes [or start/stop bits] that
	' can generate a $FF byte.  So the serin will simply
	' keep waiting until it sees the next packet.  You can
	' create, send and add a checksum if you want.  If you
	' do more complex stuff (I did some code reading 8
	' ultrasonic rangefinders) you can send multibyte packets
	' as well.  It's a lot cleaner than trying to generate
	' a voltage for the IFI to convert back into a digital
	' value.
	'
	' Note also that you can do some preprocessing in this
	' basic stamp.  In my ultrasonic code, what got sent to
	' the IFI was not the raw readings, but a massaged and
	' filtered driving recommendation, in the form of two
	' virtual joystick values!
	goto main: