Shift_in giving more digits than asked for

c07Brian.Kester

I am programming a MS5607 Altimeter sensor using SPI on a Propeller C on a Propeller Activity Board and have run into a strange occurrence using the "shift_in" function... here are the relevant pieces of the code:

unsigned int D1;
low(CS);
shift_out(SDI, SCL, MSBFIRST, 8, ADCread);
D1=shift_in(SDO, SCL, MSBPRE, 24);
high(CS);

I would expect a value of 2^24 or less, but I am getting a higher value. When I display using print("%b", D1), I am getting a binary number with 25 digits. I tried breaking it down into 3 separate reads of 8 bits each, but the display for each read was 9 digits long. Has anyone seen this or have any idea what I may be doing wrong?

kuroneko

Looks like this particular mode for shift_in is broken.

case MSBPRE:
      vi = bits - 1;
      vf = -1;
      inc = -1;
      [COLOR="#FF0000"]value |= (input(pinDat) << bits);[/COLOR]
      break;

Find shiftIn.c and change the initial shift to bits-1. This then would need a re-compile for the relevant libraries.

That said, a few more changes are needed to connected parameters but this is the main indicator.

Andy Lindsay (Parallax)

Brian, sorry for the bug.

Kuroneko, thank you for the correction.

Here is a recompiled simpletools library. Please replace the libsimpletools folder in ...Documents\SimpleIDE\Learn\Simple Libraries\Utility with the one int the attached zip and let us know if your data looks correct.

kuroneko

@Andy: just wondering, you apply the first bit inside the case statement but you do the same again (before clocking for *PRE) in the loop. Isn't that redundant (and dangerous given the use of OR)?

c07Brian.Kester

Kuroneko, thank you! I really appreciate your willingness to dig deeper into the library function. I'm definitely too much of a novice to have had any chance of catching that.

Andy, your attached file does appear to have fixed the problem. I'm now getting reasonable values from a sensor I thought was hopeless. I'm still not getting the exact values I would expect, but that just needs more testing, I think. I need a truth value to compare against, but that's a whole separate issue. The bug only seems to have caused issues in cases where the device might transmit inactive high and where the variable length was not constrained to the exact number of bits of the input. I also just have a knack for breaking code...