USB to 2 serial ports-STC8H tests, and bugs

jm***

I have this board, and

one post here suggests this

assistant /USB-CDC is a serial port, it will add 10M/6M/5M/4M/3M/2.5M/2M/1.5M/1M bps serial port communication speed for everyone to choose

but it seems the actual soue code is doing this (from download uart.c)

case 14400, 19200, 28800, 38400, 57600,115200,230400,460800,921600, SetMCLK(0); //主时钟 22.1184MHz
case 1500000:            SetMCLK(2); //主时钟 30MHz
elseif(baud < 1000000)
   SetMCLK(1); //主时钟 24MHz
else
   SetMCLK(3); //主时钟 40MHz
复制代码

so I can measure 10M,5M,3.3333M,2.5N,2M,1.6667M,1.428571M etc (40M/(4*N) as the source code suggests - so far, as expected.

but when I try bursts of data, it fails above 256 characters ?

I can send files of 64,128 etc bytes ok, but sending 1024 bytes, sees only 256 emerge from the UART Pin, when checked with other hardware.

a) The code appears to be simply polling - is there a fixed version that can send correct data ?

b) There are also many stop bits, at 5Mbd is there a fixed faster version that sends expected 1 or 2 stop bits, without the wasted time ?

D_Wo***

I don't know your code, but I suggest you check this:
length of RxBuffer and TxBuffer

You can use a variable that is set to 0 every time it is received, with a baud rate time of+1 every other time.
When it is greater than a certain number, the reception is considered complete

神***

STC8H8K64U,  USB-LIB  use xdata VERSION  ?

奥古***

Hey Buddy, you can change the source code, 1024 bytes apart, send loop
by ninidog

Debu***

If the MCU can only receive 256 bytes, you need to check that the receive buffer size is not overflowing.

Debu***

If the buffer is insufficient, you can use XDATA area as the buffer for data receiving.

代码***

Based on the information provided, it seems that the board is not able to handle burst data above 256 characters when sending at higher baud rates like 5Mbd. This could be due to various reasons like inadequate buffer size or the code not optimized for high-speed data transmission.

To address the issue:

a) You may need to optimize the code for high-speed data transmission by implementing interrupt-driven UART communication instead of polling. This will free up the CPU to perform other tasks while transmitting the data.

b) To reduce the wasted time caused by excessive stop bits, you can consider using a more efficient protocol like UART with hardware flow control (CTS/RTS) or even switch to a faster protocol like USB if possible.

It's important to note that achieving high-speed data transmission requires careful consideration and optimization of all components involved, including hardware, software, and protocols.

Debu***

If you use official routines, you can use the XDATA version of the USB-CDC library.

jm***

The Board was ordered from AliExpress and the code on the chip inside the board, is whatever it shipped with. I have downloaded no new code.
ie this 256 byte overflow flaw is in all boards, as-shipped.
If I send small packets, with long enough pauses between (mouse clicks) there is never an issue - I can send thousands of bytes, provided they are in blocks less than 256 bytes.
If I check 384 byte file, it sends just 128 bytes, even at low BAUD of 9600.  ie failure is independant of BAUD speed.

jm***

Debu*** 发表于 2023-5-8 15:13
If the MCU can only receive 256 bytes, you need to check that the receive buffer size is not overflo ...

This is PC -> MCU -> UART send, I have not done receive tests test.
I did not expect PC-send to lose characters.