Start timer on GPIO input High and change another GPIO

[sreyas40]

I'm trying to start a timer when input GPIO becomes high (on its rising edge), at the same time i want to pull another GPIO to low. This is time critical.

I'm using an external adc which will output a ready signal, at that time i want to pull CS pin to low and wait for a delay (tREAD), at the end of timer , want to pull the CS back high.

 Which is the best way to do, as i need the least latency.

I'm using Nucleo H723ZG

[gbm]

And what are the real values of these timing dependencies?

With tight timing I would use DMA triggered by EXTI and/or timer event generation capability for starting the timer.

[sreyas40]

a few nanoseconds tight.

This is a precision ADC, so whenever conversion is finished , the chip will raise a ready signal which for a few nanoseconds, when that happens i need to pull the cs low, for about 284ns, then i need to pull it backup before next cycle happens. A full cycle is about 600ns.

So what would be the best way for achieving this? If you have any learning materials like a video link, that would be very helpful

@TDK @gbm 

[TDK]

Is this everything? Just toggling CS doesn't get you any data so it doesn't seem very useful to me.

A few nanoseconds is probably outside of the capabilities. That's only 1 timer cycle. Would be better to quantify the requirement here.

[TDK]

If this is for an SPI transaction, you can do everything letting SPI control the CS pin. Depends on actual timing values, though. Look at delays after CS is pulled low.

[gbm]

Normally, one uses timer output to start the conversion, then, after the result is ready, it should be read using SPI. Conversion time + reading time must be >= conversion cycle time.

It's you who decides on starting the conversion and on conversion frequency, not the ADC.

[sreyas40]

I have selected the maximum frequency to get the max sampling rate. 

If i use NSS in hardware mode , if i call HAL_SPI_Recieve does the CS gets pulled low and high after reception automatically

[waclawek.jan]

The original description sounds to me as a single-shot, i.e. I'd use TIMx_CH1 (or TIMx_CH2) as Input (technically set to Capture) to the Slave-mode controller, set TIMx_SMCR.TS to respective TIxFPx, set TIMx_SMCR.SMS to Trigger, set One-Puse mode i.e. TIMx_CR1.OPM=1, set one of the remaining channels to Output Compare/PWM, and set its Fast Enable bit (TIMx_CCMRx.OCxFE=1). That would generate the complete pulse, but that won't start SPI.

If SPI would need to be started, I'd probably try something along DMA triggered by TIMx_DIER.TDE transferring some dummy data to SPI_TXD to start read transfer, but the 'H7 SPI is exorbitantly complex and I don't know its ins and outs, I don't use 'H7.

In other words, I believe this could be automated to run entirely in hardware; but details have to be worked out, based on deep enough knowledge of the chip. This may be clickable in CubeMX, if one knows where to click... but maybe not. I'm not a Cube user.

JW

[gbm]

For fixed, deterministic sampling rate, the conversion must be triggered by microcontroller's timer output. Knowing the ADC parameters, maybe you don't even need the ready signal from it. Maybe an interrupt from another channel of the same timer could be used to start the data transfer.