Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MU messages not always fully delivered to 00_SignalDuino.pm #7

Open
auron-muc opened this issue Feb 3, 2023 · 1 comment
Open

MU messages not always fully delivered to 00_SignalDuino.pm #7

auron-muc opened this issue Feb 3, 2023 · 1 comment

Comments

@auron-muc
Copy link

I had massive problems trying to get some FLAMINGO FA22RF to work on a USB-Maple-Signalduno.
I used the PCB by Ranseyer, and other protocols were going just fine.
When monitoring from vscode after uploading via platformio, all messages looked valid, too.

I finally added a lot of debugging output 00_Signalduino.pm (and even DevIO.pm) an noticed that quite a lot of times during the massive flood of messages a new MU; was sent without the previous message being ended with a \003\n

I think it all is due to the TX message buffer sometimes being overwritten, if the polling USB client is too slow. The buffer is only 64 Bytes by default.
[ https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/system/libmaple/include/libmaple/usart.h ] -> USART_TX_BUF_SIZE

I tried increasing the buffer to 255 by adding "-D USART_TX_BUF_SIZE=255" to the build options in platformio.ini, but that did not help. Neither did adding the define to compile_config.h
My current solution is to add a flush() to every print() by modifying the macro in output.h

I will attach a diff

@auron-muc
Copy link
Author

output.h.diff.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant