STM32F103 Bluepill UART problem

[TadyTheFish]

Aaaaa ok that clears things. I will play around but that pause between bytes is for sure causing me problems. But I agree it shouldn't be a problem since we have a start and a stop bit. Maybe Profibus works different
Thank you

[ag123]

I did some digging

Code: Select all

Serial2.begin(19200,SERIAL_8E1);

Code: Select all

Serial.println(((USART_TypeDef *) USART2_BASE)->CR1,BIN);

gives me

Code: Select all

 11010100101100

there is something a little strange about this, the specs for CR1 says the top 2 highest bits should be zero. but it appears as 11 at the left.

previously what you have got is

Code: Select all

Serial1.println(((USART_TypeDef *) USART1_BASE)->CR1,HEX);

i get ...

Code: Select all

212C

that should read like

Code: Select all

0b0010 0001 0010 1100

[TadyTheFish]

The prevoious post was incorrect. It was for Serial1. I am using Serial2

[ag123]

either way, hopefully those settings literally helped, you may likely be right about the 9 bit lengths part given the findings
if you need 8E1, you may need to turn on the 9th bit like ABOSTM suggest

it may read something like

Code: Select all

	// 9 bits, turn on parity control 
	((USART_TypeDef *) USART2_BASE)->CR1 |= USART_CR1_M | USART_CR1_PCE;
	// parity selection 0 Even bit (we need to zero out that bit)
	((USART_TypeDef *) USART2_BASE)->CR1 &= ~ USART_CR1_PS;
	// 00 1 stop bit (we need to zero out both bits)
	((USART_TypeDef *) USART2_BASE)->CR2 &= ~ USART_CR2_STOP_Msk;

you can find those definitions in the file system/Drivers/CMSIS/Device/ST/STM32F1xx/Include/stm32f103xb.h
https://github.com/stm32duino/Arduino_C ... xb.h#L9465

you can do a print of that register before and after setting that register this way. a difference would probably point to a possible bug from the expected settings

[TadyTheFish]

You said that the top two bits should be zero. Bit13 is USART enable.. this one should be 1 like it is

Code: Select all

Serial2.begin(BAUD,SERIAL_8E1);
Serial1.println(((USART_TypeDef *) USART2_BASE)->CR1,BIN);

gives me

Code: Select all

0b11010100101100

[ag123]

oops my goof
what you posted actually reads like

Code: Select all

0b11 0101 0010 1100

so the two ones on the left isn't the highest 2 bits rather the whole 16 bits word look like

Code: Select all

0b0011 0101 0010 1100

and is the same thing
this seem to be a setting for an 8E1 settings, note the 9 bit setting for the M bit

note also that the stop bit settings is in CR2 register, not visible here

[TadyTheFish]

Sorry I misslead you.. I only posted the relevant 13 bits.
So to summarize everything cheks out?
9bits is set because of the extra parity bit?

[ag123]

i think the M bits set the 9 bits data width (including the parity), and the parity flags in CR1 register parity enabled even seem to say the frame will look like this

start | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | parity | stop

[TadyTheFish]

I just hooked up the mega328 slave that is working.
the gap between bytes is the same as the gap from the PLC. It starts a new byte as soon as the parity bit is sent
It seems that the mega USART woks differently as of the one on the STM

[ag123]

i assume that both avr and stm are sending 9 bit (8 bit + 1 parity) and 1 start and stop bits?
another thing is to check the CR2 register as the stop bits setup is in the CR2 register
according to RM0008 there are several choices

Code: Select all

Bits 13:12 STOP: STOP bits
These bits are used for programming the stop bits.
00: 1 Stop bit
01: 0.5 Stop bit
10: 2 Stop bits
11: 1.5 Stop bit
The 0.5 Stop bit and 1.5 Stop bit are not available for UART4 & UART5.

so just in case it is sending 2 stops instead of the default 1 stop bit, you may like to check CR2 if it is indeed the case

you may like to try using, the buffer write call for the uart e.g.
Serial2.write(buffer, size);
instead of
Serial2.write(byte)
by putting all the bytes that you want to send in the buffer it could possibly queue up all the bytes end to end without gaps
i think the implementation works by sending the next byte as soon as one byte is transmitted. possibly interrupt driven.
normally, this shouldn't have an issue as stm32 runs in the mhz ranges.
but if you insert one byte in the queue, interleaving between bytes in Serial2.write(byte), it could possibly cause gaps

you may also like to try the libmaple core, but as it goes libmaple core is a community core
and if the line discipline flags are not handled, you may be left with setting the registers.
libmaple core isn't as feature packed (or even complete) as the official core. but few reasons i stuck with it is it is very lean. binaries tend to be rather small, i got myself a little more familiar with the codes, they seemed slightly simplier than the official core. so you may like to check that out.
i tend to patch the (libmaple) core to get the features i wanted, but those are custom and are not necessarily committed in the community core as it may not be relevant to others.