USB to 2 serial ports-STC8H tests, and bugs
本帖最后由 jmg 于 2023-5-8 16:10 编辑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_Works 于 2023-5-8 15:08 编辑
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-LIBuse xdata VERSION?
Hey Buddy, you can change the source code, 1024 bytes apart, send loop
by ninidog If the MCU can only receive 256 bytes, you need to check that the receive buffer size is not overflowing. 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. If you use official routines, you can use the XDATA version of the USB-CDC library. 本帖最后由 jmg 于 2023-5-8 16:08 编辑
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.
DebugLab 发表于 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.