STM32H743 & LTC1403 SPI Timing

The duty cycle of CONV can be arbitrarily chosen to be used as a frame sync signal for the processor serial port.

Das LRCLK-Signals von I²S sollte damit funktionieren (das Timing hat dann 32 Bits pro Sample).

Max schrieb:

Die größte Problematik liegt darin, dass der ADC einen kurzen Puls zum Anstoßen der nächsten Messung benötigt, in der Mitte dieses Pulses muss nun auch die SCK anfangen zu takten.

Das sehe ich anders. CONV kann auch länger anliegen, wobei lediglich die setup time >= 3 ns beachtet werden muß, damit das oberste Datenbit nach vier Takten am Ausgang erscheint.

Max schrieb:

Die größte Problematik liegt darin, dass der ADC einen kurzen Puls zum Anstoßen der nächsten Messung benötigt, in der Mitte dieses Pulses muss nun auch die SCK anfangen zu takten.

Wirklich in der Mitte? Die Zeiten im Timing-Diagramm sind doch üblicherweise min-Zeiten.

Ich lese das Timing-Diagramm so: CONV high, t4 warten, CONV low. Jetzt die SPI starten und 16 Bit einlesen. Die ersten beiden Bits werden dann verworfen da der Sender noch Hi-z ist. Die restlichen 14 werden ausgewertet.

Max schrieb:

Hallo zusammen,

Moin

Die größte Problematik liegt darin, dass der ADC einen kurzen Puls zum Anstoßen der nächsten Messung benötigt, in der Mitte dieses Pulses muss nun auch die SCK anfangen zu takten. Das ist natürlich mit einem GPIO Write so natürlich nicht möglich.

Nö. Erstens ist es möglich, dann halt Bitbanging und 2ens: RTFM: t4 Minimum Positive or Negative CONV Pulse Width (Note 6) 4 ns

Seite 14 des Datenblatts gib noch ein paar Hinweise:

The duty cycle of CONV can be arbitrarily chosen to be used as ...

Was da steht bedeutet "im Rahmen der grundsätzlichen Timing-Vorgaben kann CONV ansonsten so lang oder oder kurz sein wie es dir passt."

Ebenso steht da

It is also good practice to keep the width of the low portion of the CONV signal greater than 15ns to avoid ...

Also nicht zu lange High bleiben, so das Low mindestens 15 ns ist. Oder mit den dort aufgeführten Problemen leben.

Insgesamt interpretiere ich die gesamte Information so, dass man sogar notfalls den Wandler auch an eine normale 16-Bit SPI Schnittstelle hängen kann, wobei CONV dann wie Chip-Select bedient werden kann. U.a. ist t3 ja 0. Dann hat man allerdings Performance-Einschränkungen.

Wenn es ganz schlimm mit der Anbindung wird, kann man vielleicht noch was aus folgenden basteln:

The rising edge of CONV starts a conversion, but subsequent rising edges at CONV are ignored ... until the following 16 SCK rising edges have occurred and track mode starts again.

Ich denke so in die Richtung CONV durchlaufen zu lassen und SCK mit t2 Verzögerung aus CONV generieren. Das habe ich jetzt aber nicht zu Ende durchdacht und im Datenblatt stehen auch Einschränkungen wie reduzierte Wandlungsgeschwindigkeit.

Hannes J. schrieb:

Insgesamt interpretiere ich die gesamte Information so, dass man sogar notfalls den Wandler auch an eine normale 16-Bit SPI Schnittstelle hängen kann, wobei CONV dann wie Chip-Select bedient werden kann. U.a. ist t3 ja 0. Dann hat man allerdings Performance-Einschränkungen.

Das 'notfalls' würde ich streichen, wobei wohl ingesamt 18 Bit verwendet werden müssen. Wenn man das 'select'-Signal weder automatisch noch manuell generieren möchte, könnte man beispielsweise auch 3 x 8 Bit verwenden und zur Ausgabe der Taktimpulse die Bytes 0x80, 0x00, 0x00 senden, wobei man CONV mit MOSI verbunden hat. Im Grunde eine ganz einfache Geschichte.

Vermutlich hat der TO aber Probleme mit dem H7xx-SPI, welches mit seinen vielen Möglichkeiten und FIFOs auch einige Stolpersteine bereithält. Da muß man die richtige LIB finden ;-)

Mi N. schrieb:

Vermutlich hat der TO aber Probleme mit dem H7xx-SPI, welches mit seinen vielen Möglichkeiten und FIFOs auch einige Stolpersteine bereithält.

Ja das ist so. Der H7 ist eine tolle "Maschine". Aber es wird schnell mal sehr kompliziert. Nur schon mit DMA, was man für schnelle Sachen nutzen möchte, gibt es viele Hürden zu überwältigen. Beispielsweise, dass verschiedene Peripherien an verschiedenen DMA-Controllern hängen und diese wiederum nur auf bestimmtes RAM zugreifen können, wo man dann die Buffer passend (32-bit aligned) hinplatzieren muss...

Max schrieb:

Hallo zusammen,

ich probiere aktuell die Kommunikation zwischen dem LTC1403 ADC und einem H7 ans laufen zu bekommen. Als Neueinsteiger in die ST Familie doch etwas schwerer als gedacht.

...

Du denkst viel zu kompliziert und zäumst das Pferd von hinten auf.

Den 'CONV'-Impulst generierst du dir über einen (bielbigen) Portpin (gern auch per Timer). Danach, startest du die SPI und holst deine Daten ab.

Und das Ganze dann wieder von Vorn.

Roland E. schrieb:

Den 'CONV'-Impulst generierst du dir über einen (bielbigen) Portpin (gern auch per Timer). Danach, startest du die SPI und holst deine Daten ab.

Wie würde dafür Pseudocode mit ST HAL aussehen? Einen Puls per Timer auf dem Conv Pin zu erzeugen habe ich bereits ausprobiert, aktuell scheitert es an der Synchronisiation zwischen Timer / Puls und dem Starten der SPI. Wenn ich mir die SCK und den Conv Pin auf dem Oszi angucke sind diese absolut nicht zueinander synchron.

Max schrieb:

Einen Puls per Timer auf dem Conv Pin zu erzeugen habe ich bereits ausprobiert, aktuell scheitert es an der Synchronisiation zwischen Timer / Puls und dem Starten der SPI.

t4 Minimum CONV Pulse Width ist 4ns. Da kann man doch ein beherztes __NOP(); benutzen:

1

    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_SET);

2

    __NOP();

3

    __NOP();

4

    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_RESET);

Und dann kann man mit der SPI weiter machen.