For what ever reason on the f0 usart_send has the following prototype:
void usart_send(uint32_t usart, uint8_t data);
So you should get an error if you try to sent it a short (uint16) value in
the data slot.
The doxygen comment is incorrect (which says it takes a 16 bit data word).
So my guess is that the fix is to change the prototype and call to use a 16
bit data byte and all will work as expected. Can you try changing both the
prototype and the function and test it on your setup?
--Chuck
On Thu, Dec 4, 2014 at 8:12 PM, Марко Краљевић <krasnaya.zve...@gmail.com>
wrote:
> Looks like the USART on F0 has the same problem, in 9 bit mode.
> data is a uint16_t.
> using this, as in usart_send();
>
> USART_TDR(USART2) = data;
>
> doesn't send the 9th bit. Instead it sends the LSB *again*, for reasons
> I'm not sure of.
> i.e.
> send 0x100 -> transmits 0x000 (!)
> send 0x001 -> transmits 0x101 (!)
> send 0x101 -> transmits 0x101
>
> however, if instead we use a 16 bit pointer, like this:
>
> uint16_t *txp;
> txp = (uint16_t *) &USART_TDR(USART2);
> *txp = data;
>
> it works as expected:
>
> send 0x100 -> transmits 0x100
> send 0x001 -> transmits 0x001
> send 0x101 -> transmits 0x101
>
> I can't figure out why though. USART_TDR() returns a MMIO32() which is a
> uint32_t*. Can't reason why that would make it write the lowest byte twice,
> instead of the two low bytes once..
>
> any ideas..?
>
>
> here is listing difference:
>
> uint16_t *txp = (uint16_t *) &USART_TDR(usart);
> *txp = data;
> 8000176: 8501 strh r1, [r0, #40] ; 0x28
>
>
> USART_TDR(usart) = data;
> 8000176: 1c03 adds r3, r0, #0
> 8000178: b2c9 uxtb r1, r1
> 800017a: 3328 adds r3, #40 ; 0x28
> 800017c: 7019 strb r1, [r3, #0]
>
> so with 16 bit pointer, it does a 16 bit write. without pointer it does an
> 8 (why??) bit one. which doesn't explain why bit 8 is mirroring bit 0.
>
> On 16 August 2014 at 05:23, Karl P <ka...@tweak.net.au> wrote:
>
>>
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> libopencm3-devel mailing list
> libopencm3-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
