Need SHIFTIN help

Capt. Quirk

I am trying to interface a 12 bit MAX6675 Type K thermocouple chip to the SX28 & 52 proto board. I know that when·I need to ShiftIn more than 8 bits, 2 ShiftIn statements are required. The data sheet says the chip requires 16 Clk cycles to complete a conversion. Bit 15 is a dummy bit, 14 thru 3 are data and 2 thru 0 are for configuration bits. The sheet also indicates a MSBPRE configuration. I used Dr. Tracy Allens BS2 code for the SX and all I was able to get were all %00000000 or %11111111 per byte.

I started working on this back in April and as time constraints got tight, I chose to use a BS2P-40 instead and·I had no problem getting the P-40 to work with the drop in code from Dr. T.A.(lol). The only big difference I can see between the P-40 and the SX is the "Transmission Rate"·of the SX is twice as fast as the P-40.·((sx)~ 6 µs·&·~ 83 kBits/Sec·and (p-40) 18 µs & ~ 42 kBits/Sec)

Since I can't seem to get a BYTE value returned except for 0 or 255, I figure there must be a timing issue between the 2 chips, but I haven't been able to find a combo that works. Any help would be greatly appreciated.

<---Bill

Post Edited (Capt. Quirk) : 7/2/2007 8:44:50 AM GMT

JonnyMac

In SX/B the you must preset the clock line for SHIFTIN and SHIFTOUT as those routines simply invert it. Also, you're adding the two result bytes together so you can never get anything beyond 255, and with all the division you do after I'm surprised you get anything but zero.

Let me suggest you update your code like this:

Dio             PIN     RC.4 INPUT
Clk             PIN     RC.3 OUTPUT
CS              PIN     RC.2 OUTPUT

result          VAR     Word
thC             VAR     Word

' =============
  PROGRAM Start
' =============

Start:
  CS = 1

Main:
  PAUSE 1
  Clk = 0
  CS = 0
  SHIFTIN  Dio, Clk, MSBPOST, result_MSB
  SHIFTIN  Dio, Clk, MSBPOST, result_LSB
  CS = 1

  thC = result >> 3
  thC = thC */ 640
  thC = thC / 10

  'BREAK
  GOTO Main

The data sheet suggests reading a bit after the falling edge of the clock, hence MSBPOST. Note that when you declare a word in SX/B that it creates to byte aliases for the _LSB and _MSB and that's what are used in the SHIFTIN calls. Once you get this working you can modify the SHIFTIN with the speed multiplier to increase the transmission speed.

I just noticed something else: You have two lines that are doing division; */ 640 is like multiplying by 2.5, then you divide by 10. You can wrap that into one line like this:

thC = thC ** $4000

Post Edited (JonnyMac) : 7/2/2007 3:40:15 PM GMT

Capt. Quirk

Thanks JonnyMac,

It has a heartbeat, but the values are closer to Fahrenhiet than Centigrade. I am in the process of taking it off the·PDB, to try eliminate any other errors. I have more questions, but it will be this evening before I can post them.

Thanks again

Bill

Capt. Quirk

As you may have guessed, I thought the SHIFTIN - SHIFTOUT commands had complete control over the pins. So in the old Shiftin example I questioned why I needed to bring the Clk to LOW or declare DIR Control. Stupid me, never looked at the new examples.·Also turned out to be MSBPRE in order to get the right data, but your math was right on.

A couple questions:

(1) The MAX6675 required the same 250ms delay for both the SX28 and the BS2P-40, the SX may have been a little less stable at that delay than the P-40 (delays less than 140 ms provided no data). I thought that since the P-40 was an "Interpeted" chip that it would require more time than the SX & SX/B. After CS goes high and forces a calculation, is there still some sort of clock support still going to the 6675 chip, it sure seems like a long time for a modren device to give a result?

(2) The "SpeedMult", Does it increase the Clk rate or the Transfer rate. In the 0831 example it's easy to understand that it has a max rate of 400Kb/sec, but with the 6675 the only data I saw in the PDF was that it had a max clock rate just above 4 Mhz. Also, how fast is the Shiftin Clk anyway, @ 6 us per complete cycle it must be much slower than the resonator? and does the Clk speed change with each different resonator?

Thanks

Bill

Post Edited (Capt. Quirk) : 7/4/2007 9:25:47 PM GMT

Bean

Bill,
The help file says the transmission rate is about 83Kbits per second. The "speedmult" will multiply that rate, but only until the delay become zero.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
“The United States is a nation of laws -· poorly written and randomly enforced.” - Frank Zappa

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·

Capt. Quirk

I am trying to better understand how best to use the SPEEDMULT and why there needs to be a 250ms PAUSE with the use of my Max6675 chips. I understand the idea of reducing delay because of the Help File Example, of the ADC0831 and increasing the 83Kb/s to 332 Kb/s out of a possible 400 Kb/s that the 0831 is capable to supply..

But in the case of the Max6675's data sheet, no such value exists. The 6675 data sheet does say that it has a maximum clock rate of 4.3Mhz. The data sheet also says that·the calculation of·what the 6675 has just measured, is forced by bringing CS high again. That suggests to me that the 6675 is still dependent on the SX to continue its clock rate in order to produce a result that is readable for the SX.

It also appears that the SX SHIFTIN Clock rate is directly tied to its transmission rate. If that's the case, than the SX clock rate is only 166hz, so for a device like the 6675 that is capable of working at 25,903 times faster than the SX's normal transmission rate, I guess the 1/4 second delay is normal and the 8 bit·speed multiplier and SX/B is inadequate for this application?

So is SASM the alternative? can SASM supply a 4Mhz clock speed to the MAX6675, when I use a 4 mhz or greater resonator? in order to eliminate the 1/4 second pause and how much of the above is correct.



Thanks, Bill

Capt. Quirk

I am asuming the transmission rate·/ clock cycle is software based. Since SX/B is converted to SASM, is there a way to increase the rate beyond the "Speedmult's" 8 bit range in the begining of the program or create a custom hardware based clk cycle that can interact with SXB?

JonnyMac

The data sheet you reference says the conversion can take up to 0.22 seconds (Page 2, conversion time) so it make sense to have at least a 250 ms delay between attempted readings. And as it's a synchronous device it will work fine at "normal" SX speeds (notice that there is no minimum specification on clock frequency) -- you seem to be wrapped around the axle on a non-issue. Start with getting the code working, then work on making it fast.

Capt. Quirk

Thanks, code has been working fine. I am just trying to learn from it, and my mistakes I made from choosing the hardware I did and the programming issues it caused. I figure·there is always a·"work-around" for anything and also a learning experience too. (I have tried all the Speedmult values and I wasn't able to reduce the pause statement without loosing data stability)

I bought a PSC because the pause statements the 6675 used were longer than a servo refresh time, but I didn't expect that the PSC wouldn't work because of those same delays, within the master program. So please excuse me for beating a dead horse, but I am a tad-bit fixated, lol.

The chip seems to need 16 clk cycles to pass the data & 42 clock cycles to produce a result after CS goes high? and if a clock cycle·is the same as flashing an LED, it seemed possible to eliminate the delay by using the same way you flash an LED faster. Then maybe the PSC would work.

Bill

·

Conversion Time (Note 2) (typical) 0.17,·(max)·0.22 s (missed that, but there was no minimum, leaves room for optimism)




Post Edited (Capt. Quirk) : 7/9/2007 5:26:28 PM GMT

Capt. Quirk

getting the code working, then work on making it fast said...

That's what I am trying to do, it just seems like the clock speed is the weak link. Gunthers book only talks about I2C, but he did mention a SPI VP. So I found the PDF and I'll take that as far as I can.

Bill



·

JonnyMac

I really think it's the 0.22 second conversion time that's what's killing overall throughput. You have to design your code to the manufacturer's worst-case spec, so I don't think changing the clock speed is really going to have an appreciable impact. You can certainly prove it by writing manual code -- even in SX/B which compiles to straight assembly; which you could optimize after if needed.

FUNC READ_6675
  CS = 0
  Clk = 0
  NOP
  FOR tmpB1 = 0 TO 15
    Clk = 1
    NOP
    Clk = 0
    NOP
    tmpW1 = tmpW1 << 1
    tmpW1.0 = Dio      
  NEXT
  CS = 1
  RETURN tmpW1
  ENDFUNC

Bean

Jon,
I agree. 0.22 seconds is a LOT of clock cycles. Like going 100MPH between city red lights, you're really not going to get there any faster.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never argue with an idiot.· They'll drag you down to their level then beat you with experience.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·

Capt. Quirk

Sorry·Terry·and Jon. Please accept my apology.

Berfore this thread it was my impression that ADC's and other devices that used ShiftIn & Shiftout only used ShiftIn to transfer it's data to the SX (correctly). I had never thought about the time a chip, like the max6675 did in between Shiftin cycles. Until I read the 6675 data sheet and it said that bringing CS low cuts off any conversion that is in process and that CS high would start the conversion process.

So, I thought there had to be a clock source to·drive the 6675's conversion process work and that's why I (incorrectly) thought speeding up the clock speed would eliminate the·calculation delay of the 6675 chip.

But Jon's code, only showed 16 clock cycles and Bean's comment about racing between stop lights made sense. So now I know that the 6675 really is that slow.·Also Jon's comments about designing your code around a manufactures worst case, is very necessary and how·important it is to understand a data sheet before I buy any new chips again. Also I now understand how these style devices work and exactly how to write code for them because of your help.

Thank you very much

Sincerely

Bill Mazzacane




Post Edited (Capt. Quirk) : 7/11/2007 10:48:37 AM GMT