See also https://github.com/libopencm3/libopencm3/issues/318
This is a known issue, f3 has the same spi peripheral, and it regularly catches people, not just with libopencm3! On 08/16/2014 03:28 AM, Марко Краљевић wrote: > Today I started first work with STM3F0 series (F030, in 20 pin tssop. Should > be > useful for small things, and very cheap). > > After setting SPI to 8 bit mode, a single uint8_t write to the SPI_DR will > write > *two* bytes. (first your byte, and then a blank byte). > > Looking into this a bit, the SPI controller works somewhat differently on > these, > and seems to ignore what it is set to if you write 16 bits to it. If that > makes > sense. > > So, for reference, spi_send function: > > void spi_send > <https://libopencm3.github.io/docs/latest/stm32f1/html/group__spi__defines.html#ga1fcf7661af69bcf8999ae3f6d102fd8b>(uint32_t > spi, uint16_t data) > { > /* Wait for transfer finished. */ > while (!(SPI_SR > <https://libopencm3.github.io/docs/latest/stm32f1/html/group__spi__defines.html#gae14de4e25f63b18a43dc0f20bdc4fe8e>(spi) > & SPI_SR_TXE > <https://libopencm3.github.io/docs/latest/stm32f1/html/group__spi__defines.html#ga5bd5d21816947fcb25ccae7d3bf8eb2c>)); > /* Write data (8 or 16 bits, depending on DFF) into DR. */ > SPI_DR > <https://libopencm3.github.io/docs/latest/stm32f1/html/group__spi__defines.html#ga9e95e2b653dfa3add622205d9cb0ddb5>(spi) > = data; > } > > Since data is a uint16_t, it writes 16 bits to the SPI_DR, which it interprets > as two 8bit transfers on a 'F0, apparently. Doesn't matter if you pass a > uint8_t > to spi_send(); nor does the following work: > > uint8_t data = 0x55; > SPI_DR(spi) = data; > > as SPI_DR() must return a _16 bit_ pointer. I guess GCC then promotes your 8 > bit > uint to a 16 bit one. > > The only thing that seems to work, is to have an 8 bit pointer to SPI_DR, > something like this: > > uint8_t *spi_8ptr; > spi_8ptr = (uint8_t *) &SPI_DR(spi); > > while (SPI_SR(spi) & SPI_SR_BSY); > *spi_8ptr = data; > > Though that will break 16bit transfers... Not sure what the best way to fix > this > is? Anyone else work with SPI on F0? I guess there could be SPI_DR8(); and > SPI_DR16(); but that's a little hokey... as all the higher level functions > will > need to be either duplicated in 8/16 versions, or have a 8/16 bit argument > breaking everything. > > Anyway, that is all for now > mark > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > libopencm3-devel mailing list > libopencm3-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libopencm3-devel > ------------------------------------------------------------------------------ _______________________________________________ libopencm3-devel mailing list libopencm3-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
