ADC-SPI comapatiable how to give clk?

[MD18]

Hello,
I am working on stm32h7 series ,I have to configure ADS7046. My SPI clk is 50MHZ. I need to give greater then 15clk for communication.
so,
64*tclk+ACQ
64*(1/50MHz)+80ns
1.36Microsecond.
-So for CS low to High I need to give dealay of 1.36microsecond. This calculation is ri8 or wrong.I need help

 

[FvM]

No idea what you are calculating here.

As a starting point, assume that the ADC can be controlled with standard SPI library functions. STM32 hardware SPI interface can only generate n*8 clocks.

 

[MD18]

No idea what you are calculating here.

As a starting point, assume that the ADC can be controlled with standard SPI library functions. STM32 hardware SPI interface can only generate n*8 clocks.

Here are the procedure ,so according to that I did the above calculation

 

[KlausST]

Hi,

what do you want to achieve?
* normal conversion?
* offset calibration?
* abort offset calibration?

Is your /CS controlled by STM hardware or software?

Klaus

 

[MD18]

Hi,

what do you want to achieve?
* normal conversion?
* offset calibration?
* abort offset calibration?

Is your /CS controlled by STM hardware or software?

Klaus

1. Normal conversion
CS is handled by software method
How I can give the 15SCLk how I manged it.
The things that I understand is 15 or 18 clk*(1/50Mhz)+ ACQ time
according to this I have to calculate the time
-CS_LOW();
-SPI_READ();
-DElay(); //15 or 18 clk*(1/50Mhz)+ ACQ time
-SPI_High();
I am ri8 or wrong

 

[FvM]

You are thinking too complicated. You'll either apply 16 or 64 clocks with standard SPI interface. Additional tacq delay may be necessary or not, depending on how you schedule the next ADC cycle, which has been yet revealed.

 

[MD18]

You are thinking too complicated. You'll either apply 16 or 64 clocks with standard SPI interface. Additional tacq delay may be necessary or not, depending on how you schedule the next ADC cycle, which has been yet revealed.

My question is that how i have to give 15clk so I get the data, because they mentioned there after 15clk the data on SDO, How i know I get the data.

 

[KlausST]

Hi,

normal conversion:
* so no need to use "64" at all, neither "18"
* you don´t need to give exactly 15. As FvM mentioned give n times 8 clock cycles. 8 clock cycles are done by sending a (dummy) byte via SPI. If you want 16 bits, then just send 2 bytes.

so for normal conversion:
* clear /CS
* transmit 2 bytes
* set /CS
thats it.
No delay needed inbetween /CS LOW and /CS HIGH

The only thing you have to care for: just leave /CS = HIGH for at least 60ns. (20ns already done with the 16th data bit) before you start the next conversion.

***
Now some questions:
* do you use STMCube
* how do yo do SPI communication? with HAL? blocking? interrupt? DMA?
* how do you control the "start of conversion timing"?

--> show us your code

Klaus

--- Updated Apr 22, 2022 ---

added:

How i know I get the data.

Just believe in the interface. It will do like said in the datasheet Fig. 37.
First bit is "0" then D15, then D14 ....

this is standard SPI communication.
--> call the function to read 2 bytes and you will get them.

Klaus

 

[MD18]

Hi,

normal conversion:
* so no need to use "64" at all, neither "18"
* you don´t need to give exactly 15. As FvM mentioned give n times 8 clock cycles. 8 clock cycles are done by sending a (dummy) byte via SPI. If you want 16 bits, then just send 2 bytes.

so for normal conversion:
* clear /CS
* transmit 2 bytes
* set /CS
thats it.
No delay needed inbetween /CS LOW and /CS HIGH

The only thing you have to care for: just leave /CS = HIGH for at least 60ns. (20ns already done with the 16th data bit) before you start the next conversion.

***
Now some questions:
* do you use STMCube
* how do yo do SPI communication? with HAL? blocking? interrupt? DMA?
* how do you control the "start of conversion timing"?

--> show us your code

Klaus

--- Updated Apr 22, 2022 ---

added:

Just believe in the interface. It will do like said in the datasheet Fig. 37.
First bit is "0" then D15, then D14 ....

this is standard SPI communication.
--> call the function to read 2 bytes and you will get them.

Klaus

1.I generate the code using stm32cubemx
2.Using polling method, ans SPI CS is software method .I am using HAL libabry.
HAL_GPIO_WritePin(GPIOE, SPI_CS1_Pin, GPIO_PIN_RESET);
HAL_SPI_Receive(&hspi3, ADC_Val, 2, 100);
HAL_Delay(1);
HAL_GPIO_WritePin(GPIOE, SPI_CS1_Pin, GPIO_PIN_SET);
printf("%d\n\r",ADC_Val);

 

[KlausST]

Hi,

ADC_Val needs to be an array of bytes. at least 2.

As already mentioned you don´t need to add a delay. But it won´t hurt either.

Did you test the above code?
* What do you expect?
* what happens?

I guess the printf won´t work on an array of bytes this way. Maybe a more experienced programmer can verify this.
(In my opinion you have to use ADC_Val(0) and ADC_Val(1) individually)

Klaus

Btw: do you have a logic analyzer or a DSO?

 

[MD18]

Hi,

ADC_Val needs to be an array of bytes. at least 2.

As already mentioned you don´t need to add a delay. But it won´t hurt either.

Did you test the above code?
* What do you expect?
* what happens?

I guess the printf won´t work on an array of bytes this way. Maybe a more experienced programmer can verify this.
(In my opinion you have to use ADC_Val(0) and ADC_Val(1) individually)

Klaus

Btw: do you have a logic analyzer or a DSO?

I doesnot test the code yet because i get stuck in how I give the clk pulses to it. I will make that correction above.
uint8_t Test[]={10,20};
uint8_t ADC_Val[2];
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
/* USER CODE END WHILE */
HAL_GPIO_WritePin(GPIOE, SPI_CS1_Pin, GPIO_PIN_RESET);
HAL_SPI_Transmit(&hspi3, Test[0], 2, 100);
HAL_SPI_Receive(&hspi4, ADC_Val[0], 2, 100);

HAL_GPIO_WritePin(GPIOE, SPI_CS1_Pin, GPIO_PIN_SET);
printf("%d\n\r",ADC_Val[0]);
printf("%d\n\r",ADC_Val[1]);
HAL_Delay(1000);
Is this correct

 

[FvM]

HAL_Delay(1) is inappropriate. Why would you insert a delay of 1 ms?

HAL_SPI_Receive() is working in blocking mode, the transfer has completed when it returns. Respectively you can immediately deassert chip select. tacq delay has to be insert, if necessary at all, before the next adc read cycle. In your code, printf() will have generated already much more delay.

In practice, tacq becomes interesting if you are planning maximum speed ADC operation through DMA.

--- Updated Apr 22, 2022 ---

HAL_SPI_Transmit(&hspi3, Test[0], 2, 100);
HAL_SPI_Receive(&hspi4, ADC_Val[0], 2, 100);

What's the purpose of using 2 SPI handles?
The receive call has been correct before, now it's using wrongly ADC_Val[0] (byte data) instead of ADC_Val (pointer).

 

[MD18]

HAL_Delay(1) is inappropriate. Why would you insert a delay of 1 ms?

HAL_SPI_Receive() is working in blocking mode, the transfer has completed when it returns. Respectively you can immediately deassert chip select. tacq delay has to be insert, if necessary at all, before the next adc read cycle. In your code, printf() will have generated already much more delay.

In practice, tacq becomes interesting if you are planning maximum speed ADC operation through DMA.

--- Updated Apr 22, 2022 ---

HAL_SPI_Transmit(&hspi3, Test[0], 2, 100);
HAL_SPI_Receive(&hspi4, ADC_Val[0], 2, 100);

What's the purpose of using 2 SPI handles?
The receive call has been correct before, now it's using wrongly ADC_Val[0] (byte data) instead of ADC_Val (pointer).

Master intiate the clk if I send the 2 bytes then 16clk cycle that are given so I get the ADC data ri8.

 

[KlausST]

Hi,

Omit the "HAL_SPI_Transmit" ...

I used the phrase "transmit" as general SPI phrase.
But indeed the HAL_SPI_Receive already does the "dummy byte transmit"

Test the code.

What about scope and logic analyzer? Use it if you have.

Klaus

 

[MD18]

Hi,

Omit the "HAL_SPI_Transmit" ...

I used the phrase "transmit" as general SPI phrase.
But indeed the HAL_SPI_Receive already does the "dummy byte transmit"

Test the code.

What about scope and logic analyzer? Use it if you have.

Klaus

Thank you so much , i will test the code.