Options for flow control?

[xobs]

We have a first example of gdbstub running on real hardware 🎉!

However, we immediately ran into an issue with flow control: betrusted-io/xous-core#361 (comment)

I'm going to try and mitigate it by using a ringbuffer to fill with characters as data comes in, and I'm going to try and get more information on what's actually going on in the protocol.

gdb supports set remoteflow on which appears to use CTS/RTS when using a real serial port, however those singals tend to not be connected.

It may just be that my approach of running gdbstub in an ISR is not a good one, but what options are there within the protocol itself to handle flow control?

[daniel5151]

To answer your direct question (re: flow control): I don't believe this is something gdbstub can handle for you automatically.

Sniffing around the GDB source code, it seems that set remoteflow simply sets some client-side serial port params, and doesn't actually result in any packets being sent over the GDB RSP to the stub.

I suspect that this is something you'll have to fix as part of your implementation (e.g: by improving your UART based Connection implementation).

Let me know if this lines up with your investigation, and if so, I'll just close this issue out as unactionable on my end.

---

Taking a step back through, it seems that there's been quite a bit of activity on that linked issue in the hours since you've posted this issue.

Based on my reading of the thread, it seems most of the issues are just unforeseen implementation issues when running on physical hardware? If so, I'm afraid there's not much advice I can offer on my end (aside from general questions about the GDB RSP)

That said, if you keep investigating and you think there's a bug / missing feature on gdbstub's end, please feel free to re-engage here by opening new issues.

[xobs]

Part of the reason for the failure was, indeed, a misunderstanding of the hardware.

However, I do think there is one thing that may be useful to implement, and that's making noack an optional feature. The noack option seems to be useful for error-free links such as TCP, but is left in for unreliable links such as serial.

Might it make sense to make noack an optional include, in order to prevent gdb from taking advantage of it? At worst it would involve making this optional:

gdbstub/src/stub/core_impl/base.rs

Line 115 in 3c00732

";QStartNoAckMode+",

At any rate, something to think about. Since this is not a blocking issue I'll close this for now.

[daniel5151]

Funny you should bring that up, since it just so happens optional noack (#134) will be landing shortly, as part of @bet4it's work in #135.

I'll cut a new point release when that gets merged in.