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

User avatar
By cal
#21599 Moin and hello to the ESP8266 enthusiasts!

for the impatient, here is the tale: https://github.com/cal101/cal_gdbstub/b ... kyTale1.md

For some time I am working on a way to debug an ESP8266 without using further hardware like a JTAG adapter
(viewtopic.php?f=9&t=1871) or using an emulator (viewtopic.php?f=9&t=26).

I took the way of writing a gdb stub as mentioned here: viewtopic.php?f=9&t=3734

The source code is not ready for publication but I decided to publish atleast a library.

https://github.com/cal101/cal_gdbstub

Please let me know what you think about it.
Let me know what aspects need to be addressed next to make it more useful.
Feel free to open issues for bugs and enhancement requests but keep discussions in the forum.

The first tale: https://github.com/cal101/cal_gdbstub/b ... kyTale1.md

I have some ideas about more tales like how Blinky meets the watch dog or how Blinky gets "interrupt"ed,
tell me if you want to hear them or have other ideas.

Have fun,
Cal
User avatar
By cal
#21667
kenn wrote:I'm waiting for the version with illustrations. Will it be out by Christmas? ;)

Nice work. Does it only function with the esp-open-sdk? I'm currently wedded to the Sming framework.

You don't want me to make illustrations, believe me ... :D

The main part of the stub should run with all xtos based environments. The rtos based maybe more work.
I just recently made the stub work with the sdk instead of nodemcu which I integrated it first with.
If you are familiar with sming inner workings and the gcc/ld integration we may give it a try.
I choosed the blinky example as a base so one can easily see the integration points.
The stub needs to integrate in the debug vector and in the uart code. The later one needs some abstraction but
I wanted to wait for some real requirements before giving it the proper shape.
Things get a little bit tricky when sharing cpu between firmware and debug stub.

Cal