tmedicci commented on issue #13855:
URL: https://github.com/apache/nuttx/issues/13855#issuecomment-2450386272
> Hello @tmedicci
>
> In the file esp_spi_slave.c, there is the following function: `static void
spislave_prepare_next_tx(struct spislave_priv_s *priv) { if (priv->tx_length !=
0) { ... } else { ... } } ` Currently (in my fork), in the else condition, I am
"setting" the TX buffer to 0x00. The behavior is correct this way. So, to
answer your question: no, I do not encounter any issues if I set up the buffer
for each transmission.
>
> In my experience, I haven’t come across any MCU manufacturers that have
loopback behavior in SPI slave mode. Therefore, I believe we need to align this
behavior to ensure that applications developed for different devices behave
consistently. This adjustment needs to be made either through a workaround like
mine in the lower-half or by replicating the IDF behavior in our 3rd-party
setup.
>
> [EDIT] @tmedicci , About the usage case... Our behavior is different than
IDF, In IDF, slave prepare 10 bytes to sent in next transmission (an example),
when master assert CS, 10 bytes will be sent and master will receive 10 bytes
and next bytes will be zero. In our case, master will receive 10 bytes and
"trash" from last transaction ( if it has more than 10 bytes).
@FelipeMdeO , I still couldn't get it: what is the behavior of the slave
device if you call `write` on the SPI slave peripheral? (without any
workarounds in the lower-half).
For instance,
[this](https://github.com/apache/nuttx-apps/pull/2765/files#diff-dead2eb073549457bc060b883d743bc2e76c95c785b1b68fe66df4ac7e493863)
example writes back the read content. If you modify it to write any other
data, does the tx_buffer behave as expected?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
