Shop OBEX P1 Docs P2 Docs Learn Events
Spin conversion to C - confused by a Spin statement — Parallax Forums

Spin conversion to C - confused by a Spin statement

tj4sheetj4shee Posts: 25
edited 2015-01-13 08:08 in Propeller 1
Hoping someone can clear this confusion up for me.... I am not familiar enough with Spin....

I am trying to understand i2c in simpleIDE.... and the ONLY i2c program I have been able to get running was a Spin example I found for a PCF8574...

anyways... here is the Spin line I am trying to understand...

outa[SDA] := (data <-= 1) & 1

The way I interpreted this is .... data is bit-rotated left by 1, then ANDed with 1.....

but this doesn't make sense.... why rotate ??? if you are going to AND by 1, it wouldn't matter what was in the most significant bit... it would always end up as a 1 in the lowest significant bit....

and...... why do this at all... because the only real options to assign to out[SDA] would be a 1 or a 0.... isn't the result above always > 0 ?

The only thing I could think off is that a timing issue is being created in a complex way ?

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2015-01-13 06:42
    tj4shee wrote: »
    but this doesn't make sense.... why rotate ??? if you are going to AND by 1, it wouldn't matter what was in the most significant bit... it would always end up as a 1 in the lowest significant bit....
    You're not confusing this with OR?

    Anyway, outa[SDA] := (data <-= 1) would be sufficient here (left side is only one bit -> implied AND).
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-01-13 06:58
    "(data <-= 1) & 1" will rotate data left by 1 and produce the value of the original sign bit as either 0 or 1. It is the same as 
    data <-= 1
outa[SDA] := data & 1
    or 
    data := data <- 1
outa[SDA] := data & 1
    If this is part of a loop that is sending out a byte value then data must have been pre-shifted left by 24 prior to entering the loop.

    EDIT: kuroneko is correct that "outa[SDA] :=" will only use the LSB of the right side, so the "& 1" is not necessary.
  • tj4sheetj4shee Posts: 25
    edited 2015-01-13 08:02
    Both... Thanks.... Dave, Yes... you are correct re: the <<24... here is the entire proc I am trying to understand and replicate....

    PRI Write(data) : ackbit '(SCL, data) : ackbit | SDA
    '' Write i2c data. Data byte is output MSB first, SDA data line is valid
    '' only while the SCL line is HIGH. Data is always 8 bits (+ ACK/NAK).
    '' SDA is assumed LOW and SCL and SDA are both left in the LOW state.
    ___ackbit := 0
    ___data <<= 24
    ___repeat 8 ' Output data to SDA
    ______outa[SDA] := (data <-= 1) & 1
    ______outa[SCL]~~ ' Toggle SCL from LOW to HIGH to LOW
    ______outa[SCL]~
    ___dira[SDA]~ ' Set SDA to input for ACK/NAK
    ___outa[SCL]~~
    ___ackbit := ina[SDA] ' Sample SDA when SCL is HIGH
    ___outa[SCL]~
    ___outa[SDA]~ ' Leave SDA driven LOW
    ___dira[SDA]~~


    The part I was missing was "outa[SDA] :=" will only use the LSB of the right side, so the "& 1" is not necessary...... The fact that outa will only use the LSB makes a big difference in resolving my confusion.... I just assumed (wrongly) that is would use the entire 32 bits of the data variable....

    Which actually leads me to another question (and possibly a bad assumption)..... do all user-undefined variables default to "long" ?
  • kuronekokuroneko Posts: 3,623
    edited 2015-01-13 08:08
    tj4shee wrote: »
    ... do all user-undefined variables default to "long" ?
    In case you're referring to method parameters and local variables, yes. They are all longs.
Sign In or Register to comment.