Other Parts Discussed in Thread: ADS1258
Dear Support,
We implemented electronic boards housing a RM46L852 and two Analog Devices AD7124 ADCs.
The ADCs are separately and exclusively connected to MibSpi Ports (MibSpi3, MibSpi5) of the RM46 running a safety OS.
We run the ADCs in the single conversion mode, while each ADC is configure to automatically run a sequences of 9 different
conversions.
Similar to the TI ADS1258 these ADCs buffer only one conversion result of a sequence, forcing the µC to read each conversion
after a finished conversion. The AD7124 does not have a separate pin for indicating a finished conversion (not_RDY like the TI
ADS1258 ), but does it by pulling down the data output line (DOUT). Therefore we connected the ADCs DOUT lines to GIO pins
of the RM46. After each start of conversion these GIOs are sensed as low trigger CPU interrupt. While such an interrupt starts the
readout out the dedicated ADC Channel Data via its related MibSPI port in master mode.
Thus all parameterization, control and readout of the ADCs is actually controlled by the CPU, though we know, that such things are
better done by DMA access.
So far this way is choosen to avoid any interferences with our safety related test of the CPU Memory additionally running.
Now for time critical sensor implementations we run into an unacceptable high CPU load caused by this kind of ADC driver.
Therefore we need to find a solutions and like to check the possibility of using MibSPI transfer groups.
Our Datasheet and Technical Reference Manual inspection showed no functional obstacle for autonomously reading the mentioned
ADCs via the MibSpi transfer groups.
The read ADC Buffers on each MibSpi are:
- 9 x 8 Bit command register
- 9 x 8 Bit status register
- 9 x 24 Bit data register
- 9 x 24 Bit error register
Which sums up to 576 Bit, or 72 Byte.
We like to know, if TI agrees with our idea of reading this ADCs conversion sequences via transfer groups?
Additionally it would be helpful to receive some advice, guidance or even examples for such an implementation, if possible?
A further question results from the fact, that the DOUT line is identical to the not_RDY line for the chosen ADCs.
It means, since prior or further transmissions on the same MibSpi port always include DOUT/not_RDY low levels, the trigger of
the groups needs to be enable/disable between each conversion data reading. As I found, this is possible by doing it like the
midspiSetfunctional()method of mibspi.c is doing, isn’t it?
By reading the Technical Reference Manual and the Datasheet we found mismatching explanations about the interaction of transfer
groups with memory.
The Datasheet says, that each MibSPI port has a dedicated memory providing 128 buffers to the transfer groups. By this we assume,
that the MibSPI periphery has a separate memory independent or at least somehow hardware separated from the CPU memory.
On the other hand the Technical Manual talks about DMA accesses. These may induce intercations of transfere groups or accumulated
data on the same memory range as the CPU. Therefore our safety related tests on the CPU memory may detect a lot of errors due to
hardwares direct accesses on the CPU memory (CPU RAM DMA).
The Technical Manual claims DMA as an option and a separate hardware of 128 buffers is described in the Datasheet and the
Technical Manual. Thus my impression is, that these bufferes are exactly invented to overcome such safety issues, isn't it?
Therefore we need to ask, if someone from TI Side can give us a definitiv statement about a hardware base separation of the 128 MibSPI
buffers from the CPU memory?
Otherwise it seems like we are not willing to take the risk.
