STM32H743 & LTC1403 SPI Timing

[Max (max_moritz)]

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.

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.

Der Conversion Start Pin liegt zum Glück am TIM16 des STM32, aber wie 
man diesen in Kombination mit dem SPI verwendet um den Puls zu erzeugen 
und anschließend mit der SPI Übertragung zu starten ist mir leider 
unklar, bzw. ob das überhaupt ein Ansatz ist.
Hättet ihr eine Idee / Herangehensweise um die Kommunikation richtig zu 
implementieren?

Vielen Dank für eure Hilfe und ein schönes Restwochenende!

[Clemens L. (c_l)]

> 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).

[Mi N. (msx)]

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.

[Thomas F. (igel)]

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.

[Jens B. (dasjens)]

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

[Hannes J. (Firma: _⌨_) (pnuebergang)]

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.

[Mi N. (msx)]

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 ;-)

[Johnny B. (johnnyb)]

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...

[Roland E. (roland0815)]

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.

[Max (max_moritz)]

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.

[Thomas F. (igel)]

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:

    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_SET);
    __NOP();
    __NOP();
    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_RESET);

Und dann kann man mit der SPI weiter machen.