STM32F103 DTR

[hyur]

I am using the STM32F103C8T6 board.

I am sending/receiving protocol by raising DTR to HIGH for serial communication. (with middleware)
I wanted to temporarily stop protocol transmission and reception by lowering the DTR line to LOW without unplugging the USB cable, but the protocol is still transmitted and received even if the DTR is lowered to LOW.

Does STM32 have a tendency to not go down to LOW again once DTR goes HIGH?

[ag123]

usb (serial) doesn't use DTR, you should design flow control in your protocol.
for practical purposes, usb serial can work without DTR.

[ag123]

XOn/XOff flow control
viewtopic.php?f=41&t=1661

sometimes for an even simplier implementation, I used the "simple minded" request-response protocol.
e.g. when a single char is received on the device, the device transmit a fixed block of data.
this works pretty well, really

[GonzoG]

With STM32 you can simply close USB connection (close COM port) on the host side. It can be detected by the MCU and it will stop sending data.
To detect if USB connection is active:

Code: Select all

if(Serial)
{  //do something if connection active
}

If USB connection is closed, "Serial" will return NULL and the condition will be false.

[hyur]

@GonzoG @ag123

It seems that I did not understand well or explain it incorrectly because of the lack of hardware or communication concepts.

I am using serial communication, not USB communication.
So, I am using NoflowControl and send and receive messages by connecting QT and STM32.

That's why the DTR setting is so important.
When DTR is raised to high for the first time, message communication starts.

However, I thought it was correct that communication would be interrupted if it was raised to high once and then lowered to low, but messages are still received from STM32.

[ag123]

If you are using usb (cdc) serial - i.e. the usb connector on blue pill, it is still usb.
even if say you are using a separate usb-uart dongle say to connect to the uart, it would depend on the setup, the support of the dongle, windows driver etc.
hence, an 'easier' way is to design flow control in the app (i.e. your sketch and the desktop app) that does not depend on the hardware features.
a trouble with usb (cdc) serial is that literally these 'flow control' features are not even literally defined in the spec.
https://www.usb.org/document-library/cl ... devices-12
DTR/RTS usb control signals are often 'abused' to for other purposes like toggling gpio pins instead of any thing to do with DTR/RTS.

for the on chip usb serial, if you prefer to use DTR to implement a custom flow control protocol, you can take a look at the api and codes
https://github.com/stm32duino/Arduino_C ... SBSerial.h
https://github.com/stm32duino/Arduino_C ... l.cpp#L184
There is apparently a Serial.dtr() method, which you can retrieve the DTR state.
You can use this in your sketch to monitor dtr() and stop or start transfers. e.g.

Code: Select all

void loop() {
	if (Serial.dtr())
		Serial.println("this is a very long message");
}

Note however, there would still be a small amount of data in the in/out bound usb buffers that gets cleared by the host at the next poll.

usb-serial isn't rs232, the host do all that polling and it is just data frames that jet between the in/out usb logical ports.
there is practically no 'control signals', all that are mimiced to make it look like 'rs232', but it is up to the device and app to implement those things.

[GonzoG]

The Serialx USART implementation is a 2 wire interface. There are no other pins for flow control. You have to do it by yourself, e.g.

Code: Select all

if(digitalReadFast(PA_1)) Serial.print();

or

Code: Select all

if( digitalReadFast(digitalPinToPinName(PA1)) )  Serial.print();

You can use USART with CTS/RTS signals but you would have to use HAL.
DTR is a RS232 signal. STM32 USART does not have it.

[fpiSTM]

hardware flow control configuration APIs are available since 2.3.0:
https://github.com/stm32duino/Arduino_C ... /pull/1634

[SHIPC]

hardware flow control configuration APIs are available since 2.3.0:
https://github.com/stm32duino/Arduino_C ... /pull/1634

However, the library file of version 2.3 only provides CTS and RTS control, which is often used for RS232 control. For RS485, there needs to be an IO to control whether 485 is in receiving mode or sending mode. Therefore, can you update relevant code files to realize that when serial port transmission is in progress, one IO is in high level? It automatically changes to the low level after sending. This is called DE control