<dcz[m]>
okay, thanks! now I can see the answer. I kind of skimmed that part of the book
Socke has quit [Quit: WeeChat 4.7.1]
Socke has joined #rust-embedded
<thejpster[m]>
<JamesMunns[m]> maybe just something to note if LLVM/LLD actually does decide that they hate the idea of using full JSON blobs as virtual symbol names
<thejpster[m]>
the correct answer is to mangle them. dirbaio proposed hex encoding them and counter-proposed using Rust name mangling, and then the PR stalled.
<thejpster[m]>
* them and I counter-proposed using
<dirbaio[m]>
right
<dirbaio[m]>
this is another point in favor of mangling 🤣
<thejpster[m]>
but these kinds of changes require an update to the Wire Format Version, and a co-ordinated roll-out of compatible defmt-decoder and defmt-print and probe-rs updates
<thejpster[m]>
It sounds like the project consider it a stable-to-nightly regresssion so if LLVM doesn't fix it, they might apply a patch to rustc to fix the escaping
<dirbaio[m]>
yeah 🫠
xnor has quit [Quit: WeeChat 3.4]
<dirbaio[m]>
IMO if we're the only ones using backslashes and quotes in symbol names we're going to keep running into issues with it
<thejpster[m]>
but I'd go any any kind of encoding that keeps A-Z, a-z and 0-9 as-is. I'm flexible about what we do with the rest.
<thejpster[m]>
just speaking as someone who teaches defmt, and likes to open the symbol table and go "look, tada! strings in your symbol names"
KevinPFleming[m] has joined #rust-embedded
<KevinPFleming[m]>
(just catching up here)... ergot sounds really fantastic and could replace the protobuf-over-uart stuff I've been building my project, except... my 'host' is going to be ESPHome, which is decidedly not Rust.
<JamesMunns[m]>
Interesting! On a PC host, I'd say it's pretty reasonable to make an "adapter" service that speaks ergot on one side and REST/whatever on the other side. Not sure if I have any answer for non-rust embedded
<KevinPFleming[m]>
I could consider making a Rust library with CXX bindings but that would be work... and I'd also need to build an Interface to use the ESPHome UART. Not trivial.
<JamesMunns[m]>
yep, might not make sense!
Vaishnav-sabari- has quit [Quit: Idle timeout reached: 172800s]
ouilemur has quit [Quit: WeeChat 4.7.1]
ouilemur has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.5.2]
nqv has joined #rust-embedded
<dcz[m]>
I think I might actually start using ergot. Except my first serious project is a serial-console-like thing so there's no use in another protocol :)
<JamesMunns[m]>
Up to you :), if there's anything I can help with, let me know! If you end up wanting to multiplex things separately (stdin/stdout/stderr, logging, telemetry, bootloader, etc.) over the same pipe, I think it'll work well!
<JamesMunns[m]>
one of my maybe controversial opinions is "you probably don't want a serial console for an MCU", IMO you're almost always better off with structured data! But I'm sure someone can come up with counter examples :)
<JamesMunns[m]>
(and that's almost certainly more of a matter of taste rather than fact 🙂 )
<dcz[m]>
oh that's a good point... I spent a lot of time trying to squeeze another USB endpoint for the data pipe, but I only can have one at a time
<dcz[m]>
so maybe I can multiplex it and sidestep the whole problem
<JamesMunns[m]>
yep, that's exactly what ergot gives you! Many sockets/endpoints over the same "pipe"
<dcz[m]>
(I'm building something like the BusPirate, except it forwards the protocols using a separate stream. BP replaces the interactive stream which is very annoying)
<dcz[m]>
the downside is that the host program now needs to be a lot more complex. No more YOLO bulk transfers
<JamesMunns[m]>
I'm certainly interested to see how it goes for you!
<dcz[m]>
if it goes like my average project, I'll let you know in about 5 years :X
nqv has quit [Ping timeout: 248 seconds]
<JamesMunns[m]>
the interface I use on that side is to expose embedded-hal proxy objects: you create an object that holds a ref to the NetStack, and calls some embedded-hal proxy methods
<dcz[m]>
okay this is real cool and also what I hoped to have
<JamesMunns[m]>
I have a version of that which works on postcard-rpc/poststation (poststation is a paid multitool for postcard-rpc, I plan to add ergot support for it too) instead of ergot, similar vibe tho not exactly the same, here for i2c: https://github.com/OneVariable/poststation-util/tree/main/examples/i2c-passthru
<dcz[m]>
thanks for showing me. I might come back to this once I'm not overwhelmed with architecture. For now I'm starting with a bit of interactive control not unlike bitbanging just to learn the knobs of embedded-hal and understand how to structure the whole mess
<JamesMunns[m]>
Always happy to chat! It's definitely a thing in my backlog that I want, and i'd be more than happy to have someone else build it :D
<JamesMunns[m]>
it's _very_ useful for prototyping: you don't have to reflash the device, and can do all your debugging/logging/gdb'ing on the host side!
<ubik[m]>
I need a quick hack to convert a 3.3v GPIO into 5V. Would this work?
<ubik[m]>
(I have some 4N35 lying around)
nqv has joined #rust-embedded
<ubik[m]>
hm... it seems to work, but not fast enough for my needs
davidmpye[m] has joined #rust-embedded
<davidmpye[m]>
<JamesMunns[m]> That would be great! Mostly looking for someone who can throw something like that together quickly, because I haven't done it before :D
<davidmpye[m]>
Does it go any faster if you put the resistor and gpio onto the collector and emitter straight to gnd?