so... why do it this way?
CannibalRobotics
Posts: 535
So I was poking around looking at different ways to handle I2c communication in SPIN and PASM and I ran accross this in Kwabena W. Agyeman's EEPROM driver. It works but under the repeat it's only changing port direction for each bit.
Its clever in that it is essentially functioning as an open-collector port. Neat-O! But Why?
Obviously there is a little speed improvement?
But any electronic advantage? Ports are still theoretically limited to 3.3 +-0.3v, 40mA (even though many have successfully violated that limit). Is it purely to accomidate the pull-ups speced for the SDA and SCL lines?
Hummm.
PRI transmitPacket(value) ' 4 Stack Longs
value := ((!value) >< 8)
repeat 8
dira[dataPin] := value
dira[clockPin] := false
dira[clockPin] := true
value >>= 1
dira[dataPin] := false
dira[clockPin] := false
result := not(ina[dataPin])
dira[clockPin] := true
dira[dataPin] := true
Its clever in that it is essentially functioning as an open-collector port. Neat-O! But Why?
Obviously there is a little speed improvement?
But any electronic advantage? Ports are still theoretically limited to 3.3 +-0.3v, 40mA (even though many have successfully violated that limit). Is it purely to accomidate the pull-ups speced for the SDA and SCL lines?
Hummm.
PRI transmitPacket(value) ' 4 Stack Longs
value := ((!value) >< 8)
repeat 8
dira[dataPin] := value
dira[clockPin] := false
dira[clockPin] := true
value >>= 1
dira[dataPin] := false
dira[clockPin] := false
result := not(ina[dataPin])
dira[clockPin] := true
dira[dataPin] := true
Comments
-Phil
I think that's a good idea because if something unexpected happens and some chip on the I2C bus tries to talk on the SDA line while the Prop is putting 3.3 VDC on it, it'll burn up...
Thanks-