Discuss here different C compiler set ups, and compiling executables for the ESP8266

User avatar
By tve
#22114 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 ;-)
User avatar
By cal
#22119
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