SPI interfacing... is it supposed to be painful?

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

I've used UART for MIDI with no problems. Now I want to try a SPI A/D converter. Every SPI chip I've looked at has completely different timing requirements. Some transmit zeros until the nth bit in a sequence, some need shifted clocks, some use rising edges and some use falling edges.

The SPI peripherals in the microcontrollers I've seen can compensate for rising vs. falling edges and clock phase, but not the data offsets. Is it normal to have to code a driver just to handle SPI transfers for every SPI device you use? I'm not even talking about initialization routines, just getting bits back and forth. It looks like I will have to do so much manually that it is barely worth using a peripheral.

Is there a trick somewhere that I am overlooking?

urbanscallywag · Joined: Nov 30, 2007 Posts: 317 Location: sometimes

What microcontroller are you using? Its been awhile since I've done any uC stuff, but this shouldn't be that hard.

As you discovered there should be a clock polarity control and a clock phase control. Between the two you should be able to anything that is SPI compatible.

I would start with an app note from the uC vendor, the should have worked out all the details for you. Smile

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

urbanscallywag · Joined: Nov 30, 2007 Posts: 317 Location: sometimes

In that case does indeed sound like a headache. Sad

Do they have I2C A/D that meet your needs? Or maybe I2C to another uC as a SPI bridge?

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

Okay, so putting aside all the SS# pin conflict business...

For the moment I am trying to get the SPI peripheral to control an A/D at all. I am not using any other peripherals, but am still not having luck. The A/D I am using is a TLC3548. It looks really straightforward from the data sheet, but I am not getting the dsPIC SPI peripheral to actually control it.

The datasheet for the TLC3548 shows that the chip select signal should be high between writes. The SPI peripheral in the dsPIC doesn't seem able to generate an active low chip select signal. It can generate a sync pulse, but that is not the same. Does it not matter?

blue hell · Posted: Tue Jan 06, 2009 6:02 am Post subject:

I'm not really an expert here, but I have used SPI on a PIC 18 and I happen to have the pic24/30/33 ref manuals at hand, so here are my two cents.

From the data sheet (family reference manual (39699b chapter 23)) :

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

I could not get the free running SPI clock to stop between data even when I thought I disabled framed mode. I am sure that I am not setting something up correctly. Frame mode is not specifically important to me, just that I have some way to keep the dsPIC and TLC synchronized. The TLC supports framed modes or chip select to control it.

When SSx is a slave select signal does that mean it's an input to make the dsPIC a slave, or it's an output to enable a slave?

Sorry I have to run to work right now. I'll have more details later.

urbanscallywag · Joined: Nov 30, 2007 Posts: 317 Location: sometimes

Blue Hell, I'm with you on bit banging state machines, but at that point I'd rather be using VHDL than assembly. Wink

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

If I could handle the slow speed I'd do bit banging in a heart beat. It's so much easier...

I went back through and made absolutely sure everything related to framed mode was disabled. The clock is no longer free running, so that is progress!

I'm not getting any data back from the A/D converter even in test mode, but I can still mess with the clock polarity/phase options.

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

Darn, no intelligible data for any combination of clock settings. I wish there was an easy way to tell if the problem is in my SPI interface or in the commands I'm sending to the A/D.

The A/D is a TLC3548, by the way.

blue hell · Posted: Wed Jan 07, 2009 7:04 am Post subject:

I remember it to be quite a puzzle to get clocks & data OK for the spi flash devices I've used ... and then the bit order and then the commands & addresses ... a scope with a freezable screen is always helpful for this, if you have one ... are you getting any response at all from your device (or just ones or zeros) ? an issue with 8 vs 16 data bits maybe?

But whatever you do, don't give up, it /will/ work eventually!

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

I won't give up! Being around helpful people keeps me motivated, also.

I have a scope, but it's very old with no freeze functions. It shows that my clock is running in 16-bit spurts, which is a good sign. The oscilloscope shows that *something* is coming out of the A/D over SPI, but it is not a healthy logic signal. It is only about half a volt peak to peak. It also does not change no matter what command I send. It actually looks a lot like the chip select signal. It also picks up noise from my hand.

You mention bit order... do I need to reverse the order of the bits before I send them? It looks like according to the data sheets everything is shifting MSB first so I'm alright.

blue hell · Posted: Thu Jan 08, 2009 2:04 pm Post subject:

Looks like the line is hi-z then, is CS ok? It should always send hard bits I think when CS is active.

Bit reversal is more an issue for an all software implementation, it should be auto-ok here.

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

I found one problem. The datasheet did not mention it that I could see, but the application notes I found say the TLC3548 has to receive a "A000h" command after it is first powered up to start running.

I put that in my code, and now I am seeing hard bits coming out the TLCs SDO pin. The microcontroller is not recognizing them as data, though. It always reads the SPI RX buffer as being 0.

I'm starting to feel like a USB logic analyzer would be a worthwhile purchase for this kind of stuff.

blue hell · Posted: Sun Feb 01, 2009 3:23 pm Post subject:

Is any of the following happening?

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

I finally broke down and bought a USB logic analyzer for stuff like this.

There is data coming back from the chip now (and the microcontroller sees it), but it doesn't make much sense. No matter what command I send to the A/D, I either get 0x4003 or 0xE7E1 coming out of it. Whether it is one or the other is randomly chosen by the chip at power-up.

That is, it will either power up and continuously respond 0x4003 to everything, or power up and continuously respond 0xE7E1 to everything.
0xE7E1 is 14840 after decoding, which is somewhat close to 16384 (that is, 2^14). 0x4003 is 4096 after decoding. That's 2^12.

I don't get it.

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

I am so tired of being stuck on this. At this point I would pay someone to get me a working combination of schematic + code to make the A/D run. Getting communication working is only 5% of my design, but it is taking 95% of the time.

blue hell · Posted: Tue Mar 17, 2009 7:27 pm Post subject:

What can i say ... communications between devices is one of the hardest parts to get right. I went through the converter's data sheets again a couple of days ago but didn't see any cotchas jump out ... then I looked at the application notes and thought you might not have seen those, but you mentioned 'm ... so I can't be of much help, someone having actually used the converter might know.

skrasms · Joined: Feb 21, 2008 Posts: 121 Location: Portland, OR

blue hell · Posted: Thu Mar 19, 2009 6:13 am Post subject:

Good work to not give up thumright