search

disk91 / stm32-it-sdk

Disk91 STM32 IoT SDK
https://www.disk91.com
GNU General Public License v3.0
45 stars 19 forks source link

UART reading speed #65

Closed zokl closed 3 years ago

zokl commented 3 years ago

I'm trying to read data from the UART interface. I have a data source of 300 7N1. If I use the polling mode of reading from the UART interface, there is a problem with the reception of some characters, the reception of the last bits is distorted. I guess there will be a failure somewhere in the timing.

I also tried to use the interrupt mode, but here I came across a problem that the interface gets stuck receiving the first character. It accepts the first one, but no other. In the project (https://github.com/disk91/itsdk-example-sigfox-sx1276), I found a mention of having to wait 300 ms or more when entering characters into the console. I looked at console.c and use a similar procedure to process characters. If I enter characters manually from the keyboard, reception works.

Do you know where the performance issues with reception speeds in IT mode come from? If I do the same reading procedure on HAL drivers, the reading is working.

disk91 commented 3 years ago

The 300ms wait is related to the USB virtual UART on ST devkit w/o traffic control. So this is not related to your problem here. It's strange to have a timing issue with low datarate, it is usually on high datarate. the SDK do not setup UART yet so it should come from the CubeMx setting. I don't see what could be different compared to higher speed in term of processing. Let me know if you find something to do to help a such setup working.

zokl commented 3 years ago

This behavior is very special on both USART interfaces. On USART1 I have a routed console and logging, on USART2 is my communication with a low-datarate device (power meter). It's weird that copying from the clipboard or typing fast on the keyboard can jam the console. It looks like RX callbacks have stopped coming.

I will try to investigate more in detail the behavior of IT callback flags.

disk91 commented 3 years ago

I assume my issue with the console is the stlink serial driver not correctly buffering more than the serial port on stm32 itself. Is you problem solved by the masking fix you proposed ?

zokl commented 3 years ago

I assume my issue with the console is the stlink serial driver not correctly buffering more than the serial port on stm32 itself. Is you problem solved by the masking fix you proposed ?

No, masking fix solves different problem :-(

disk91 commented 3 years ago

Ok, let me know if you find something :(

disk91 commented 3 years ago

is that fixed by the different last commit ?

zokl commented 3 years ago

is that fixed by the different last commit?

Hello,

No, last commits don't fix this issue. In my project, I switch to pull mode for UART reading because of the speed issue on RXIT for more chars received through the interface. I need to investigate this issue more deeply. RXIT affected the time calibration and boot process of my board too.

Please leave this issue open, I will try to find the problem.

zokl commented 3 years ago

I did some tests of the UART interface behavior. Slow speeds are greatly affected by frequency and voltage stability. As far as uart and text insertion speeds via clipboard in programs like minicom or picocom are concerned, here it is somewhere on the operating system level. Inserting SC:D or SS:2 through the protector does cause a problem. If I write my own interpreter and insert characters into an interface set to 38400 bps, everything runs fine even with a 5 ms character gap.

I would close this issue for now.

disk91 commented 3 years ago

There are different ways to fix that:

zokl commented 3 years ago

There are different ways to fix that:

  • use Interrupt based UART configuration
  • insert a time between characters as this problem usually comes from USB-UART converter with high input rate but no flow control) some serial application have this option ; it solves the issue.

Yes, int. based UART is a solution but I have a problem with your implementation. I have had tried it several months ago but it does not work on my Murata MCU.