USB and COM port share one command buffer
@Yukti007 がすでに取り組んでいます。
2026年10月13日 から。
評価
この issue はまだ評価されていません。
説明
Describe the bug
The Krake reads text commands from two ports: the USB serial port and the RS-232 COM port. Both ports put their characters into the same command buffer, with the same character counter. If one port has sent part of a command but not the end-of-line yet, characters from the other port get added to the end of it. The Krake then runs one wrong command made from pieces of both.
Short Summary of the expected behavior:
Each port's commands are handled separately. A command from one port is never mixed with characters from the other port.
Short Summary of the buggy behavior:
A half-finished line from one port gets finished by characters from the other port. This can give the wrong alarm level, the wrong message text, or a lost alarm.
To Reproduce
Found by reading the code. Not yet tested on a real Krake board. Suggested steps to confirm:
- Connect a Krake to a PC by USB and open a serial monitor at 115200 baud, with line ending set to "No line ending".
- Connect a second serial terminal to the COM port (DB9, RS-232).
- On USB, type
a2Pumpand send it (no newline is sent). - On the COM port, send
a5Firewith a newline. - See error: the Krake shows a level 2 alarm with the text "Pumpa5Fire" instead of a level 5 alarm with the text "Fire".
Expected behavior
The COM port command a5Fire should give a level 5 alarm with the text "Fire". The unfinished text on USB should stay with the USB port and not affect the COM port.
Screenshots
None. Not yet tested on hardware.
Hardware description
Model: Krake (GPAD_API firmware), checked against main at commit b6ea4b3 (2026-09-20)
Serial Number: N/A (found by reading the code)
Other: Affects any Krake with both the USB serial and the COM port connected.
Test Equipment
Model: N/A (not yet tested)
Serial Number: N/A
Additional context
Where in the code:
- One shared buffer:
Firmware/GPAD_API/GPAD_API/gpad_serial.cpplines 34–35
https://github.com/PubInv/krake/blob/b6ea4b3eaf0e93a580cad7cdc9f8c1541860ff06/Firmware/GPAD_API/GPAD_API/gpad_serial.cpp#L34-L35 - One shared character counter (
static size_t writeIndex):gpad_serial.cppline 54
https://github.com/PubInv/krake/blob/b6ea4b3eaf0e93a580cad7cdc9f8c1541860ff06/Firmware/GPAD_API/GPAD_API/gpad_serial.cpp#L54 - Both ports use the same function, one after the other, in
loop():GPAD_API.inolines 2591 and 2595
https://github.com/PubInv/krake/blob/b6ea4b3eaf0e93a580cad7cdc9f8c1541860ff06/Firmware/GPAD_API/GPAD_API/GPAD_API.ino#L2591-L2595
Why it happens: processSerial() keeps a half-finished line in the buffer between calls, but there is only one buffer and one counter for both ports. Nothing records which port the half-finished line came from. It is not two tasks running at once: everything runs in loop(), one call after the other.
Side effect: if one port sends a line that is too long, the buffer is cleared. That also throws away the other port's half-finished command and cancels pending alarm audio (gpad_serial.cpp lines 107–113).
How likely: low to medium. Most setups use one port at a time, but it is easy to hit while debugging with a serial monitor open.
Possible fix: give each port its own buffer and its own character counter, passed into processSerial(). The comment at gpad_serial.cpp lines 45–46 already suggests making the buffer a parameter.
Related: #283 (shared global variables).
- 主要言語
- C++
- スター
- 9
- フォーク
- 6
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
PubInv/krake のほかの issue
-
web page publish and main loop share the MQTT send queue対応中かも @Yukti007 が 12 日前に担当しました。 オープンHigh Priority regression test type: bug
-
Firmware, Krake Loosing Broker Settings back to a Default対応中かも @nk25719 が 24 日前に担当しました。 オープンtype: bug
-
Hardware, LB0007 Not Playing Alarm File再び着手できるかも @nk25719 が 31 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
-
Mini MP3 File Names and File Order For Reliable Play Back, Both GPAD_API and Factory Test再び着手できるかも @Yukti007 が 33 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンdocumentation
-
難易度 5/5 1週間以上 初心者へのやさしさ 15/100
似ている issue
-
area:decoder area:libnvmpi bug P3
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
gjrtimmer/jetson-nvmpi#164 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
redis/memtier_benchmark#850 ·
メンテナーはふだん 1 日以内に返信
-
bug-unconfirmed
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
メンテナーはふだん 1 日以内に返信
-
Status: Needs confirmation Status: Needs triage
難易度 1/5 1〜3時間 初心者へのやさしさ 77/100
FreeCAD/FreeCAD#33863 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
pawelsalawa/letos#5839 ·