Comments inline... kristoff <krist...@skypro.be> wrote: > 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)
yes. use spi_xfer if you want simple. > > > 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. toggle CS dont_care = spi_xfer(data1) data = spi_xfer(data2) toggle CS ? > > > 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. No, not at all. This means the cpu is busy waiting, burning power, doing nothing. > - a SPI-read should always return the data of the last spi-transaction. isn't it already doing that? I mean, spi_read is just returning the data register right? > > > 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) absolutely not. what's wrong with spi_xfer for this case? If you're talking about other apis, it's very often that you only have one api, spi_xfer, and "write" and "read" are just whether you send garbage or ignore the reply with the spi_xfer style method. > > - at the beginning, do a check if there is data in the SPI RX-buffer. If > there is, read it (invalidating it) spi_xfer will effectively already do this? > > 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. so... use spi_xfer? If you want simple mbed arduino apis, use spi_xfer. The others are if you want to have more control and write your own non-blocking code. The spi_common_all.c file could probably use documentation updates to make this clearer maybe. Cheers, Karl P
signature.asc
Description: OpenPGP Digital Signature
------------------------------------------------------------------------------ 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
