Hi,
I have been continuing to get the MFRC522 library ported from wiring/mbed to libopencm3. The the issue off linking the cpp library is solved (see earlier messagen thx for the offlist reply) but I found quite few issues with the SPI-library, especially with assumption I had (and I think most people will have) and conventions used in the arduino/mbed libraries. 1/ The basic SPI-write transaction in master-mode looks like this: --- cut here --- cut here --- cut here --- gpio_clear(nss_gpioport,nss_gpios); spi_send(SPI0, data); gpio_set(nss_gpioport,nss_gpios); --- cut here --- cut here --- cut here --- This does NOT work. The reason is that the "spi_send" does not wait for the SPI-transaction to complete. So this means that you set the nss-line way to soon (actually somewhere while transmitting the 3th bit). The best way to solve this is by doing a spi_read afterwards (even if you do not use the data) which will make the processor wait for the SPI-transaction to finish. (alternatively, use "spi_xfer" which is a write-followed-by-read in one) 2/ Concider a scenario where you need to write two bytes over SPI. Then the following code looks logical: --- cut here --- cut here --- cut here --- gpio_clear(nss_gpioport,nss_gpios); spi_send(SPI0, data1); spi_send(SPI0, data2); spi_read(SPI0); // wait for SPI transaction to finish gpio_set(nss_gpioport,nss_gpios); --- cut here --- cut here --- cut here --- However, this does NOT work neither. The reason is that the "read" will just check if data is available in the SPI RX-register and if/when that is, return it. The problem here is that the first spi_send has also returned data, and -as you have not yet read it- that data is returned. Again, the NSS is set up again to early. 3/ Also the following will not work: (this is how you read data from the MFRC522) --- cut here --- cut here --- cut here --- gpio_clear(nss_gpioport,nss_gpios); spi_send(SPI0, address); spi_send(SPI0, 0); data=spi_read(SPI0); // wait for SPI transaction to finish gpio_set(nss_gpioport,nss_gpios); --- cut here --- cut here --- cut here --- The data data returned will be the result of the first SPI tranaction, not the 2nd one. OK. Sofar for my experience with the STM32F103 processor. Now, from the point of view of somebody writing/porting a library, isn't it logical that there are certain things we can assume to be correct for all processors? I think in this case, this would be: - a standard SPI transaction (read or write) will always wait for the transaction to terminate. - a SPI-read should always return the data of the last spi-transaction. So here is what I propose for the "spi_send": - At the end, add a "wait for data-available-in-RX-buffer" flag (which also signals the end of a transaction) - at the beginning, do a check if there is data in the SPI RX-buffer. If there is, read it (invalidating it) I think it is more logical to assume that -once you start a SPI_write- you are no longer interested in data return by previous transactions. Any comments or thoughts? Cheerio! Kr. Bonne. ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ libopencm3-devel mailing list libopencm3-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
