Jarrett[m] has quit [Quit: Idle timeout reached: 172800s]
owoday[m]1 has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has quit [Read error: Connection reset by peer]
Foxyloxy_ has joined #glasgow
Foxyloxy has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
<icanc[m]>
hi esden (@_discord_269693955338141697:catircservices.org) do you know anything about this?
smeding has quit [Quit: Lost terminal]
redstarcomrade has quit [Read error: Connection reset by peer]
grazianom[m] has quit [Quit: Idle timeout reached: 172800s]
tec4 has quit [Quit: bye!]
tec4 has joined #glasgow
esden[m] has joined #glasgow
<esden[m]>
icanc (@_discord_472470541962313729:catircservices.org) Hey sorry, your previous message fell through the cracks. 😦 We do have the option to pre pay customs to Canada. But we don't do that by default because it is not integrated into the pricing in the online store correctly. But if you send me an email before you place your order we can try to sort it out for you.
altracer[m] has joined #glasgow
<altracer[m]>
Having to roll like that (gd32e507, rp2040, at32f4xx) is a major reason why I abandoned openocd binaries and learned Black Magic Debug
<altracer[m]>
...two years ago.
<altracer[m]>
Then RPi mainlined their changes. Gigadevices did not, not for E50x. Arterytek doesn't care much either, zapb picked it up very recently.
<altracer[m]>
Speaking of probe-rs, it talks to BMP and BMDA now thanks to Xobs. Writing a Glasgow backend driver for either sounds like more paths forward (opportunities. BMD is in C.)
<whitequark[cis]>
I'm not sure I understand?
<whitequark[cis]>
isn't BMP a device that implements the gdb server in hardware?
bartdewaal[m] has quit [Quit: Idle timeout reached: 172800s]
vegard_e[m] has joined #glasgow
<vegard_e[m]>
the firmware gdbserver can be bypassed by using lower level commands
<whitequark[cis]>
yes, but how does glasgow come into it?
<vegard_e[m]>
I think the idea was that by making a glasgow applet that implements the same command set, you get probe-rs compatibility without modifying probe-rs
<whitequark[cis]>
i do not intend to emulate other USB devices with glasgow
<whitequark[cis]>
it's a support and compatibility nightmare and i will simply choose not to have it
<whitequark[cis]>
you go through the python framework or you fork the entire thing and now it's not my problem
<vegard_e[m]>
AIUI the protocol in question is TCP-based
<whitequark[cis]>
hm
<whitequark[cis]>
that would be fine but... isn't it a usb serial device?
<whitequark[cis]>
I guess I need to read up on BMP architecture because I feel like I understand nothing about it now
<whitequark[cis]>
but yeah to be explicit, a TCP protocol that is reasonably well defined is a-ok and in fact a preferred way to deal with this
<vegard_e[m]>
the BMP device itself is, but the ecosystem around it is bigger than just the device
<vegard_e[m]>
AFAIK the probe-rs support Xobs added was for Farpatch, which AIUI is effectively an esp32 port of BMP, doing wifi/TCP in place of USB/ACM
<whitequark[cis]>
hm. well, I'd want to look at the protocol at least
<vegard_e[m]>
I believe it's custom commands piggybacking on the gdbserver protocol, so I'm sure it's not as nice as a bespoke protocol 🙂
<whitequark[cis]>
uh, okay, no
<whitequark[cis]>
i do not want to look at that at all
<whitequark[cis]>
we do have a gdbserver, but
<whitequark[cis]>
that's a really cursed way to make a generic SWD probe
<vegard_e[m]>
I'm not sure what's more cursed of that or taking the CMSIS-DAP command set and running it over a non-USB transport
<whitequark[cis]>
anything involving gdb server protocol is especially cursed i think
<vegard_e[m]>
well, you'd only need the framing and the custom command set, but still, yeah
<whitequark[cis]>
the framing of the gdb server protocol is bad enough!
<whitequark[cis]>
thinking about this makes me really sad
<whitequark[cis]>
i'm going to go back to implementing an FPGA toolchain from scratch or something
<vegard_e[m]>
I've considered doing the CMSIS-DAP over custom transport before, but I don't really like CMSIS-DAP
<vegard_e[m]>
every time I touch it I get frustrated by how awfully underspecified it is, and the main value it has is that it's widely supported, and a custom transport wouldn't have that property
<whitequark[cis]>
i mean nobody really does CMSIS-DAP over TCP
<whitequark[cis]>
and if it's probe-rs specific i can roll whatever
<vegard_e[m]>
my problem is the orbtrace; its current form is CMSIS-DAP for debug, and some people have been asking for an ethernet version
MyNetAz has quit [Read error: Connection reset by peer]