This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
HI,
I am trying to interfece ADS1292R ECG AFE with TM4C1294NCPDT TIVA C micro controller.
I have configured SSI0 as below.
void SPI_Setup()
{
SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);
SSIDisable(SSI0_BASE);
GPIOPinConfigure(GPIO_CONFIG_SSI0CLK);
GPIOPinConfigure(GPIO_CONFIG_SSI0RX);
GPIOPinConfigure(GPIO_CONFIG_SSI0TX);
GPIOPinConfigure(GPIO_PA3_SSI0FSS);
GPIOPinTypeSSI(GPIO_PORTA_BASE, (GPIO_PIN_2 | GPIO_PIN_4 | GPIO_PIN_5 | GPIO_PIN_3 )); // SPI0
SSIAdvModeSet(SSI0_BASE,SSI_ADV_MODE_LEGACY);
SSIConfigSetExpClk(SSI0_BASE, // SPI0
40000000, // System Clock for SSI clock
SSI_FRF_MOTO_MODE_1, // Data frame format (polarity 0, phase 1)
SSI_MODE_MASTER, // Configure as Master
SSI0_SPEED, // Set speed
8); // Byte-long word length
SSIEnable(SSI0_BASE);
}
My Connections are shown in the attached file
TIVA C Controller---- ADS1292R
PN4 ------ARD_PWDN/RESET
PQ0------ARD_START
PQ1------ARD_DRDY
PA3-------ARD_CS
PA4-------ARD_MOSI
PA5-------ARD_MISO
PA2------ARD_SCK
I am trying to write the registers of ADS1292R through TIVA C controller. I could see the data and clock on oscilloscope as expected but I am unable to confirm if the ADS has received data properly.
I have followed the data sheet of ADS to write single register in following way
First byte----Write Opcode | Register address
Second Byte--- (no of registers to write-1)
Third Byte----- Register Data
Now I tried back to read the written register, what I expect is to read the value back which I have written already, Read is done through following way.
First byte----read Opcode | Register address
Second Byte--- (no of registers to read-1)
Third Byte----- 0x00
But I am unable to read the written value back.I am reading some other value from same register. Hence I am unable to understand where the issue is.
Also is the values read from registers is of 2's complement format or not?
NOTE: RESET bar pin of ADS is held high before performing SPI writes.
Expecting a quick reply.
Thanks and Regards,
Janardan M
Janardan M80 said:Expecting a quick reply.
Such ... proves "SO GOOD" to know. Might any other "expectations" - serve you - even further?
Have you considered that your post arrives during a "weekend" - and that (even) highly skilled Vendor Agents - are entitled to (some) respite? Does your "Expectation" direct the, "Promotion of your post" - above ALL OTHERS? (even those arriving prior to yours - which also - are "highly important" to their authors?)
Those "Expecting" - or claiming "Urgent" - are most likely to induce diametrically opposite response...
Your posting - otherwise - was "Quite Good" - until that (ugly/ off-putting) "Expectation" reared.. With "that said" - follows several comments - in your (no longer expectant) behalf!
You should "be aware" that (both) "SPI data OUT from the Master" - and "IN from the Slave" - are "commonly clocked" via the SPI Master. Thus - the data returned from the Slave - will be valid upon the "next SPI Put" (read via an "SPI GET") and not in "unison w/the SPI PUT" - as your writing (appears) to suggest.
Your careful charting of SPI Data Received - as returned upon the very next "SPI PUT's clocking" (via SPI GET) should reveal the Slave Device's "Sequenced Pattern of Data Response" - which MUST be one clocking cycle (behind!) (that so the Slave device has (some) chance to absorb your "Command or Data Request" (arriving one SPI PUT cycle earlier) - and only then, (upon the next "SPI Put") "Ready & Produce a Response."
Hi,
Thanks for the response, I was not aware that word "Expectation" would annoy someone that much, I am well aware that using those words would not promote my post. I will make sure not to use those words here on.
I understand that SPI shares same clock for transmit and receive , it works as virtual ring topology.
Please find the below timing diagram.
What I understand from the timing diagram is that I need to send opcode1 , then opcode2 and then I will receive the Register data.
So for receiving the register data the clock is to be provided from master hence I sent 0x00 which would initiate clocking.
Please find the below code for the reference.
SSIDataPut(SSI0_BASE, RREG|0x01); // Opcode1
SSIDataPut(SSI0_BASE, 0x00); // Opcode 2
SSIDataPut(SSI0_BASE, 0x00); // Send a dummy data to initiate clocking
SSIDataGet(SSI0_BASE, &retVal); // Read Recived data from FIFO
What I understood is SSIDataGet API fetched the data which is received and placed in FIFO.
Is my understanding wrong? does SSIDataGet API provides necessary clocking to receive data from slave?
Thanks and Regards,
Janardan M
The reasons for, "Expectation's dislike" have been detailed - we have passed beyond that.
Your diagram is clear - yet properly extracting SPI Data which is (sufficiently) offset (as yours appears) usually requires extra care. It is normal that following (each) "SPIDataPut()" with an "SPIDataGet()" will serve to your advantage - as "the dummy data" received w/each "SPIDataPut()" may be exhausted via the following, "SPIDataGet()."
In your specific case - each "Opcode" sent - will return "dummy" data - thus you'll have 2 dummy data elements to (reject). Your Slave's data diagram shows, "Desired Data" - commencing upon the "Third SPI Clocking" - which is only generated via your employ of a third, "SPIDataPut()." And you were (indeed) clever enough to recognize just that. Yet the "single" - "SPIDataGet()" you launch - will recover "illegal or dummy data ONLY" - (sent by the Slave during your first, SPIDataPut()) - not the "Reg Data" you desire.
I believe that your creating "PAIRED, SPIDataPut() followed by SPIDataGet() transactions" - rather than that, "3 SPIDataPut() Sequence" (back to back to back) - will better enable your capture of the "real/sought" Slave SPI Data.
It (often) proves best to identify the simplest Slave Register - which enables your, "eased & clear identification" of the Slave's (pardon) "expected and/or listed" Data Response. By targeting such Register - w/ "Known & Insured Content" you "Enhance your recognition" of "REAL DATA RECOVERY" - as opposed to "Unwanted, Dummy Data."
I believe that "KISS" directed - small, focused, measured SPI experimentation (examining SPI Received Data) - will build (both) your confidence & understanding. Bon chance, mon ami...