ADS7229 example code communication question

Thank you so much.

I'm trying to talk to your TI ADS7229 A/D from an NXPCortex-M3 microcontroller, the LPC1758, as I have a small-volume, low-power application.  The LPC1758 is advertised to have a 50 Mbps "SSP" which stands for Synchronous Serial Port.  This SSP can be configured to be compatible with a "4-wire TI SSI" where they say SSI stands for Synchronous Serial Interface.  I'm guessing that by "SSI" they are talking about the TI Multi-channel Buffered Serial Port.  What do you think?  Think there's any hope of me getting this connection to between an LPC1758 and your ADS7229 to work (at the ADS7229's 1 Msample/sec rate)?  Have you ever heard of anyone successfully communicating with your A/Ds over NXP's SSP?

Hi aflynn,

Some of our (Stellaris) processors have a similar peripheral option - it's similar but not exactly the same thing as the McBSP that you would find on the C6713.  If I am not mistaken, you would have only 17 clocks per transfer (16 with SS low, 1 with SS high).  This should not really be an issue as you can run the ADS7229 with a true SPI interface using only 16 clocks in the SSP mode.  Using a timer or some other means to produce the CONVST input, I suspect you can get clsoe to the full speed interface of the ADC - I've never used the LPC1758 so I don't know for sure what it is capable of.

Tom,

Thank you for your quick reply.  I'm a little confused though.  When you say I should be able to "run the ADS7229 with a true SPI interface", what exactly do you mean?  The ADS7229 can spit out a conversion result at 1 MSample/sec, so to clock the 16 bits, you'd need a serial clock of at least 16 Mbps, wouldn't you?  I thought a true SPI interface maxed out at 12.5 Mbps.  That's why I was thinking I'd need to use something other than SPI. 

What do you think?

-aflynn

Hi again aflynn,

The only limit I am aware of in an SPI interface is the ability of the master to receive data from the slave.  Transmission of data to/from a slave device is dependent on the master generating a clock.  The master sends data synchronous to the SCLK and the slave responds in kind, which is why both must have the same clock/data phase relationship (drive on falling edge, read on rising or vise versa).  The limiting factor then would be the slave's ability to send data back to the master so that valid data is received on the proper clock edge.  Transmission problems arise when cable and trace length cause the delay of data from the slave to the master.  When the delay exceeds 1/2 SCLK - less any required setup/hold times - data corruption is imminent.

In the McBSP port found on devices like the TMS320C6713, the transmit and receive functions are actually independent.  The McBSP port has CLKx and CLKr, FSx and FSr, Dx and Dr which can account for delay on the way down and back - essentially you can send the frame sync and clock from the transmitter back to the receiver by looping it back at the target device – essentially eliminating the effects of transmission delay.  This is part of what is missing in the SSI 'emulation' mode.  Transmit and receive are still dependent on one clock - the SCLK generated by the master, you can't account for receive delay by routing the transmit clock back to a receive clock input.

Hmm.  So where did the SSI come from?  Is it any sort of standard ... or is it something that TI created ... or NXP created ... or ???  Have you ever heard of it before?

To be honest, I'm not really sure of the history.  As I understand it, SPI was developed by Motorola, IIC (or I²C) by Philips, not sure who first coined the SSI - or even if it means the same thing to different semiconductor vendors, I'm not aware of a standard per se.