<vancz>
from what little ive seen so far zephyr docs are really great
DemiMarieObenou4 has quit [Quit: Idle timeout reached: 172800s]
<vancz>
<pie_> i reeeeeally shouldnt right now, but it looks like it might not be too hard to bring up a gdb stub impl based on QEMUs existing infra, and that might make debugging/verifying the OS behavior easier
<vancz>
<pie_> i guess i should also add vcd recording enable/disable if that were to work hrmblgrmbl
<vancz>
would be kind of neat to have GDB helping out with VCD samples
<vancz>
have a vcd dump for a breakpoint interval or something
<vancz>
of course you again dont require qemu for that, so i wonder if anyone has already done anything similar for say verilator
<vancz>
basically the only addition is imlementing a gdb stub
<vancz>
whats the bad stuff? <zyp[m]> IME zephyr is a mixed bag; some parts are pretty nice and some of the APIs it provides are pretty awful
<zyp[m]>
some stuff is very boilerplate-heavy, functions taking non-const read buffer pointers, some of the functions taking callback pointers don't let you pass a context pointer to the callback, some stuff assumes a single global instance for something you could want multiple instances of
<zyp[m]>
all the internal functions takes a dap_context argument, but the public functions you can actually call doesn't, and only ever passes the single global instance
<zyp[m]>
so if you're e.g. building a custom testjig board for a DUT with multiple microcontrollers, you could easily define up a swd interface towards each in the board definition, but you're only allowed to register a single CMSIS-DAP driver handling one of them