Hello,
I've a question about the handling of the ECSPI slave select signal in master mode: the connected slave device uses a protocol where the first byte is the number of following bytes for both command and answer.
In half-duplex, for commands it is known how many bytes must be transferred and the device will send padding bytes if no answer is available. But receiving the answer needs the first byte read to be evaluated to know how many additional bytes must be read. For full-duplex, the first byte received must be evaluated when transmitting a command to decide if the master must send additional padding bytes. In any case, the slave select signal must not be deasserted within commands/answers.
Now, I wonder if this can be achieved by the ECSPI hardware or if the SS signal should be implemented by GPIO function.
The only way I see for using the ECSPI SS signal is using wait states and clearing the SS_CTL flag. According to the reference manual this should be possible, but it's not clear if the wait state only applies if the Tx FIFO is empty or if it's applied after each byte.
Any recommendations/suggestions?
Regards
Solved! Go to Solution.
Hi
>> I can assume it's not possible to let the ECSPI hardware handle this?
SPI IP(hardware) will cooperate with cs-gpios, which is controled by ecspi driver.
>> GPIO is the recommended way?
Yes, right.
Best regards
Harvey
Hi @Raal
cs can be realized by gpio as below.
cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
Please refer to the link as reference. imx8mn-evk.dts\freescale\dts\boot\arm64\arch - linux-imx - i.MX Linux kernel (codeaurora.org)
Best regards
Harvey
Hello @Harvey021
thank you for that link. So, I can assume it's not possible to let the ECSPI hardware handle this? GPIO is the recommended way?
Regards
Hi
>> I can assume it's not possible to let the ECSPI hardware handle this?
SPI IP(hardware) will cooperate with cs-gpios, which is controled by ecspi driver.
>> GPIO is the recommended way?
Yes, right.
Best regards
Harvey