ESP8266 Community Forum

I would definitely be interested in using such a thing (from time to time)!
Helping to develop it would be way over my head though

Thanks!
John

I'm using the serial port to talk to an attached uC, so it's kind'a "booked" already. Now, if GDB ran over the wifi...
I'm also concerned about the size of the stub. I'm pretty hard up against the 236KB limit (OTA update). I suppose I could use serial-upload during debug and thereby go over the 236KB or use a 4MB flash module for debug, but that's all extra hurdles...
I don't want to discourage you, though

tve wrote:I'm using the serial port to talk to an attached uC, so it's kind'a "booked" already. Now, if GDB ran over the wifi...
I'm also concerned about the size of the stub. I'm pretty hard up against the 236KB limit (OTA update). I suppose I could use serial-upload during debug and thereby go over the 236KB or use a 4MB flash module for debug, but that's all extra hurdles...
I don't want to discourage you, though

Moin tve,

yes, double use of serial is a problem. I did most of the development of my gdb stub testing with nodemcu
and switching between terminal and gdb is no fun but doable to some degree.
See "tale" link for an use case.
I abstracted the I/O in the hope to be able to switch to UDP/TCP later.
Currently the stub runs at cpu exception level.
That has several disadvantages:
- no usage of higher level firmware functions like udp/tcp
- code must be in iram
- serial is polled
So code size is a problem.
I am not sure how to single step a single xtos task only while other wifi tasks continue to run.
But first step will be thinking about running the debugger stub at user level.
90 % of my gdb use cases work and I got no feedback that someone else tried to follow the steps of blinky by actually running it.

Will see,
Cal

Yes, but wishing for SWD on a chip with limited pinout.