To be honest I wasn't even using usart_send(), and rather just using
USART_TDR() directly... so it's a bigger problem than just usart_send()'s
argument type, and seems to be related to the size of pointer to the
usart's TDR register (which is just DR on the other STM32's I've dealt
with. F0 seems to have split tx/rx into TDR and RDR).
Though I did notice while configuring that the USART_STOPBITS_1 macro was
coming up undefined, despite being in usart_common_all.h, and presumed
something silly was happening there too..
On 4 December 2014 at 22:35, Chuck McManis <chuck.mcma...@gmail.com> wrote:
> I've added it as issue #371, usart_recv is also broken. Basically the f0
> should be using usart_common_all.h for its prototypes (which would have
> caught this) rather than its own home grown versions. I'll try to figure
> out how I could test this on my nucleo board. Perhaps using a soft serial
> port on an arduino to send 9 bit values.
>
> --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
