I tried to use
uint32 spi_tx(spi_dev *dev, const void *buf, uint32 len) {
uint32 txed = 0;
uint8 byte_frame = spi_dff(dev) == SPI_DFF_8_BIT;
while (spi_is_tx_empty(dev) && (txed < len)) {
if (byte_frame) {
dev->regs->DR = ((const uint8*)buf)[txed++];
} else {
dev->regs->DR = ((const uint16*)buf)[txed++];
}
}
return txed;
}
If you write to it without checking if it’s empty you take the risk of overwriting a value that has not been sent yet, and will be lost.
EDIT: Checking the code you pasted, it already includes that check:
while (spi_is_tx_empty(dev)
If you write to it without checking if it’s empty you take the risk of overwriting a value that has not been sent yet, and will be lost.
EDIT: Checking the code you pasted, it already includes that check:
while (spi_is_tx_empty(dev)
If you write to it without checking if it’s empty you take the risk of overwriting a value that has not been sent yet, and will be lost.
EDIT: Checking the code you pasted, it already includes that check:
while (spi_is_tx_empty(dev)
If you reduce the flash wait cycles or raise the CPU clock, then the piece of code fails to do what one would expect from it.
You can find here a working version (PR still waiting for Roger…).
If you reduce the flash wait cycles or raise the CPU clock, then the piece of code fails to do what one would expect from it.
You can find here a working version (PR still waiting for Roger…).
If you reduce the flash wait cycles or raise the CPU clock, then the piece of code fails to do what one would expect from it.
You can find here a working version (PR still waiting for Roger…).
The spi_tx function is only used at the momoent by master SPI write, and is highly speed optimized.
I am not aware of any slave Tx implementation. If somebody needs such case, i think the best would be to use DMA for that.
The spi_tx function is only used at the momoent by master SPI write, and is highly speed optimized.
I am not aware of any slave Tx implementation. If somebody needs such case, i think the best would be to use DMA for that.
The spi_tx function is only used at the momoent by master SPI write, and is highly speed optimized.
I am not aware of any slave Tx implementation. If somebody needs such case, i think the best would be to use DMA for that.
https://github.com/stevstrong/Arduino_S … rc/SPI.cpp
You did not comment the latest commit, which answers some of your comments.
But there is one issue: it seems to be a “bug” in the SPI HW interface: when writing some data to DR register and is not followed by a read operation, this data is kept even if new data is written and read. So in case of read overflow the latest read data is lost, the very first received is maintained.
See a detailed description here: https://github.com/rogerclarkmelbourne/ … -277516813.
I think this is also the reason why some of the write functions have at the end a read operation.
And this is why the simple read operation just reads the latest data without writing something to the DR register. So everything has its point 
The workaround for this (additional first line in the transfer routines, as mentioned in my comment under the link) is the only thing not yet committed. If this line is added, then we can safely remove the readings from DR at the end of write functions (which would speed up a little bit the write operations).
https://github.com/stevstrong/Arduino_S … rc/SPI.cpp
You did not comment the latest commit, which answers some of your comments.
But there is one issue: it seems to be a “bug” in the SPI HW interface: when writing some data to DR register and is not followed by a read operation, this data is kept even if new data is written and read. So in case of read overflow the latest read data is lost, the very first received is maintained.
See a detailed description here: https://github.com/rogerclarkmelbourne/ … -277516813.
I think this is also the reason why some of the write functions have at the end a read operation.
And this is why the simple read operation just reads the latest data without writing something to the DR register. So everything has its point
The workaround for this (additional first line in the transfer routines, as mentioned in my comment under the link) is the only thing not yet committed. If this line is added, then we can safely remove the readings from DR at the end of write functions (which would speed up a little bit the write operations).
Let me add the comments here with links to the lines for clarity.
https://github.com/stevstrong/Arduino_S … I.cpp#L163
Why the change in that line, setting the peripheral to RX only?
I can understand removing the NSS software control, but the peripheral can be slave and transmit. Is there a problem if not set to RX only mode?
https://github.com/stevstrong/Arduino_S … I.cpp#L313
This is missing sending anything, all it is doing now is reading the byte in the RX fifo, if there is one already, which is not what would be supposed to do, or what it was doing before.
It needs to transmit something to get something in.
https://github.com/stevstrong/Arduino_S … I.cpp#L341
On this just to keep with the general use, and given that spi_is_tx_empty spi_is_busy are inlined, perhaps you can use them. Was there a performance improvement on not using them? just curious.
Why the change in that line, setting the peripheral to RX only?
I can understand removing the NSS software control, but the peripheral can be slave and transmit. Is there a problem if not set to RX only mode?
Why the change in that line, setting the peripheral to RX only?
I can understand removing the NSS software control, but the peripheral can be slave and transmit. Is there a problem if not set to RX only mode?
It means there is no bug, just the spec not conforming with my expectations.
I will add the read in the transfer function, remove the read from the write function and test it with display and sd fat.
It means there is no bug, just the spec not conforming with my expectations.
I will add the read in the transfer function, remove the read from the write function and test it with display and sd fat.
My one is “DocID13902 Rev 15“, and the mentioned info is on page 731 instead of 743.
My one is “DocID13902 Rev 15“, and the mentioned info is on page 731 instead of 743.
