Giters

klonyyy / MCUViewer

Real-time embedded variable & trace viewer

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Feature Request] UART and simple protocol support

FluxSwitch opened this issue · comments

commented

Version/Branch:

1.0.0/ main

Operating system:

Windows

Debug probe:

No debug probe

Details:

Hello,

I am truly impressed by the interactive experience of the waveform display in your design of MCUViewer.

Like you, I work in power electronics domain and I sincerely hope for a software oscilloscope that offers high sampling rates, high refresh rates, and beautiful, intuitive operation. This is particularly crucial when debugging applications like the FOC current loop, where accurately monitoring transient changes is necessary. Your design of MCUViewer perfectly fulfills these needs (once again, I am amazed!).

Currently, MCUViewer can only be used with specific debugging tools. I earnestly hope you will consider adding UART interface support to MCUViewer. This would extend the software's applicability to any MCU, such as Infineon, TI, Renesas, etc. (almost all MCUs come with a UART interface).

Additionally, during power electronics debugging, EMI interference can easily occur. The most commonly used RS232/485 in the industry can effectively solve long-distance signal transmission issues, and this is also based on UART communication.

Finally, if you are interested in adding this feature, please consider the following design suggestions while keeping it as simple as possible:

  1. The protocol should include a sequence number or timestamp field to detect packet loss and avoid misinterpretation of waveform data.
  2. CRC checksum (for data integrity, this should be essential).
  3. Waveforms can be drawn in a ZOH (Zero-Order Hold) step shape, which will facilitate interpreting digital control timing (similar to MATLAB's plotting style).
  4. A simple request-response exchange mechanism, akin to the Modbus protocol.
  5. Expandable monitoring channel count (typically, 8 to 32 channels is already the limit for oscilloscopes).

This is for your reference. Thank you!

Screenshots/Video:

No response

commented

Hello! RS232/485 is something I considered as well. I did not yet implement it as it requires additional work on the targets side, and is not completety non-invasive. Even though I think it's worth to consider it. I'm adding it to the Future TODO list. Cant promise anything time-wise, but if more peope request it it'll definitely happen faster :)
BTW thanks for the designs suggestions - I will keep these in mind for sure!