Maybe Bob can comment on this but I thinks its just that inelegant. SPI
is not a "high level" interface standard, as such is not "aware" of what
the data is, just the user coding for it. Its up to the user ro throw away
irrelevant Rx data when Tx is active.
what i have observed is a repeat of data placed in the txbuffer, so a retransmission... but it's not the last piece of data ;-(
I guess something is either stuck in the fifo or the ringbuffer is not updating the low-level component because there nothing to transmit...
i did see a difference between psoc 4 hardware engine and psoc 5 udb component... now i want in 5lp basically the same behavior and having problems with the auto repeat data...
i did think of adding a some counterbits (so receiver can see the diff between new and stale/repeat data) but that just seems nasty !
my guess is that everybody using the spi-slave functionality must solve this issue, if the slave transmitted data is less then the number of bytes transferred by the master... so hopefully a lot of solutions exist to this fundamental problem... "what to transmit when no data is available in the buffer."
When no data is in the buffer, the last byte transmitted out of the FIFO will be repeated. Since this may not be what you want, why not set up a transmit buffer for this special case? This enables you to define yourself what has to happen.
Since for every bit (byte) sent by the master a bit (byte) is returned by the slave you may already indicate at the command-byte sent by master if (or how many) data is present.
thanks for the comments, and i have implemented a solution which is 'good enough' but (as already stated) a bit dirty...
(added a counter (3bit) in slave tx data, and in master receive routine compare new data which last 4) indeed ugly but good enough.
the data received from slave is (in my test) not the last, but the 2nd to last data put in the buffer. because I'm queuing commands in the slave (so at least results will be delayed in time...) adding information in the reply data from slave reflecting the amount of data in principle works, but is 'ugly' too... My command parser is knowledgeable about the number of bytes of payload... the low level transport channel is not aware of payload size and i really want to keep it that way ;-)
As stated before i did see a difference in behavior between SCB and UDB implemention, the SCB does behave 'better' because if does not repeat data from txbuffer but instead outputs all zero's of all one's, easy to detect ;-)
I do hope that somebody adds the 'what default data to transmit from SPI slave when no data is in txbuffer' to the API, naturally preserving compatibility etc. ;-) ???
again thanks Dana and Bob for looking at the options and your feedback is (was) highly appreciated !
Consider filing a CASE on this to "help" factory see this needed change.
Just give them a link to this to save yourself from repetition.
To create a technical or issue case at Cypress -
“Create a Case”
You have to be registered on Cypress web site first.