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.

ADS131A02: Datasheet errors and general documentation issues/questions

Part Number: ADS131A02

Hi again,

Sorry, but I now have more questions following on from the previous ones:-

9) As per datasheet (RevD) table 13, are the RREG and RREGS commands really identical and only distinguished from each other by writing 'nnnn nnnn' = zero for RREG and writing 'nnnn nnnn' = non-zero for RREG?

10) Datasheet (RevD) figure 76 shows the first word response to RREGS as being "Ack(RREGS)", but, table 13 (last column) says it should be "RREGS". However, according to table 14 an 'Ack' of RREGS should just be a replay of the command, i.e. of the form '001a aaaa nnnn nnnn' shown in table 13, BUT, the last row of table 14 shows a different RREGS response of the form '011a aaaa nnnn nnnn'. Which is the correct response?

Thanks

Dave

  • Hi Dave,

    The RREG and RREGS commands are basically the same, but their Command Status Responses are different. 

    The response to a RREG command (i.e. nnnn nnnn = 0x00) takes place in the next frame and consists of two bytes: first, the address byte, then the data byte. Additional 0x00 are used to pad the LSBs as necessary, depending on the selected word size.

    The response to a RREGS command (i.e. nnnn nnnn > 0x00) takes place in the next several frames. The response word in the first frame following the command simply echos the command. The response in the next frame will contain the first two registers of data (i.e. address aaaa data, address aaaa + 1 data). Each register's data is one byte, and the two registers' data are contained in the MSBs of the word with zero-padding for 24 and 32 bit word sizes.

    For further clarification, where you see "Data" in Figure 75 and Figure 76, those words contain conversion data.

    Best Regards,

  • Hi Ryan,

    Thanks for the response but now it has got worse--- or one of us is missing the point....

    For the RREG (singular) command.....

    Ignoring the padding of zeroes at the end - which I understand and is not the problem....

    You said: "The response to a RREG command (i.e. nnnn nnnn = 0x00) takes place in the next frame and consists of two bytes: first, the address byte, then the data byte."

    Datasheet section 9.5.3.7 says :- "The response contains an 8-bit acknowledgement byte with the register address and an 8-bit data byte with the register content." This agrees with your statement above.

    BUT, table 13 says the response is 'REG' which is defined in table 14 to be (001a aaaa dddddddd).
    ie the first byte is NOT just the address.... it has the top 3 bits set to '001'.

    So please can you clarify which is the correct response for a RREG.

    For the RREGS (plural) command.....

    You said: "The response to a RREGS command (i.e. nnnn nnnn > 0x00) takes place in the next several frames. The response word in the first frame following the command simply echos the command.

    This agrees with figure 76 which shows the response to be "Ack(RREGS)". ie an echo of the command.

    BUT, table 14 defined the response as (011a aaaa nnnnnnnn) and this is NOT the same as "Ack(RREGS)" which is (001a aaaa nnnnnnnn) .
    ie the top 3 bits are different.

    So please can you clarify which is the correct response for a RREGS.

    Thanks
    Dave

  • Hi Dave,

    Yes, the first 3 bits of the command status response for the RREG command echo the same op-code used to send the command (2h). This op-code is AND'd with the address ((aaaa aaaa)b) to form the first byte in the response word, followed by one byte worth of register data ((dddd dddd)b).

    In order to distinguish the command status response for RREGS from the response for RREG, we send back a different op-code in the first byte of the response. In the frame following the RREGS command, the response will begin with 6h AND'd with the address ((aaaa aaaa)b). This is what is referred to as the ACK(RREGS) word in Figure 76. Understandably, this may seem a bit confusing since the op-code at the beginning of the RREGS command status response (6h) does not match the op-code used to send the RREGS command (2h). We did this intentionally; otherwise, the response to RREG and RREGS would look identical.


    Best Regards,

  • Hi Ryan,

    Thanks for the reply.

    I think you mean ORed with the address not ANDed with the address though.

    Please will you get the documentation clarified on these points though. It is very misleading and contradictory in the places indicated.

    Anyway, I have some code running now so we have got something right between us.

    Thanks again

    Dave