Serial dropping bytes

[203Null]

I'm currently using a STM32F103RET6 and I tried to make a serial bridge with an esp8266 module over serial4. With my project, serial4 starts to drop bytes. However, with a barebone sketch, it works perfectly. The only two libraries I used in my project are Arpruss's USB HID and FastLED.

This works fine:

Output:


But after introducing Arpruss's USB HID library and forward serial4 to CompositeSerial, serial4 starts to lost bytes.
Sketch:

Output:


I'm not entirely sure what is causing issues like this. Maybe the library is influencing hardware serial's timer?

[stevestrong]

I don't think that you are "losing" byte on receiving side from Serial4, just that it is not printed on (USB) serial monitor.
I suspect a buffer overflow problem in the USB composite library.
It may happen that the USBComposite library version from Roger's core is not up to date.
You can download the latest version from here: https://github.com/arpruss/USBComposite_stm32f1
After you have updated and you are still facing the problem, you should post an issue there.

Btw, your program is buggy, because you read only one byte form Serial4 if (bl>>7) != 1 , but you have received 3. So the order of the next bytes will be shifted.

In order to monitor the Rx timings you could add some serial output of millis, just to be sure that Serial4 input buffer does not overflow.
Also, you could enable the timestamp display in the serial monitor.

[203Null]

I don't think that you are "losing" byte on receiving side from Serial4, just that it is not printed on (USB) serial monitor.
I suspect a buffer overflow problem in the USB composite library.
It may happen that the USBComposite library version from Roger's core is not up to date.
You can download the latest version from here: https://github.com/arpruss/USBComposite_stm32f1
After you have updated and you are still facing the problem, you should post an issue there.

Btw, your program is buggy, because you read only one byte form Serial4 if (bl>>7) != 1 , but you have received 3. So the order of the next bytes will be shifted.

In order to monitor the Rx timings you could add some serial output of millis, just to be sure that Serial4 input buffer does not overflow.
Also, you could enable the timestamp display in the serial monitor.

I do have the relatively new build of the library instead of the one that came with Roger's core and I do believe the issue is related to serial4 not reading the correct data instead of CompositeSerial having the issue. I did try using the data instead of printing them back and it's not working correctly either.

Also that (bl>>7) != 1 is intended. I'm reading headless midi from the serial, each data frame is 3bytes with the first byte's most significant bit as 1. It will skip the first byte until it finds the start of the data frame.

[stevestrong]

Try to add timing output combined with serial monitor timestamps, you will then see whether there is a timing difference between the versions w and w/o USB composite.

[weypro]

Actually I have the same issue of dropping bytes. I use Serial3. For example, when I send "AT", it returns "K" instead of "OK". I guess the usart of stm32 is the reason.

[mrburnette]

Actually I have the same issue of dropping bytes. I use Serial3. For example, when I send "AT", it returns "K" instead of "OK". I guess the usart of stm32 is the reason.

No, I would not believe that to be the case. Unfortunately, almost all serial problems are programmer introduced.
Post full code, or snippet that demonstrates issue. In future, please start a new thread and not assume your solution parallels an existing topic... hijacking a current thread is poor forum etiquette.

Ray

[MoDu]

FastLED, like any other bit-banged protocol delivery, blocks interrutps while bit-banging. The most likely scenario is that you're missing serial interrupts because you're hogging the interrupts on FastLED, ON TOP of the USB interrupts.