<re_irc>
<@jamesmunns:beeper.com> How fast are the UARTs?
<re_irc>
<@jamesmunns:beeper.com> (looks like the TIR1000x could be 1200bps up to 115200)
<re_irc>
<@jamesmunns:beeper.com> If you'd like my hacky suggestion, I'd say:
<re_irc>
- Lower the baudrate as low as you can stand
<re_irc>
- use an MCU with some kind of port-based DMA, maybe something STM32
<re_irc>
- DMA the 8-bit port into a buffer
<re_irc>
- periodically swap the buffers and decode into 8 fifos
<re_irc>
<@jamesmunns:beeper.com> so if you can get down to like, 9600 baud, have the DMA latch the port at like 19.2khz or 38.4khz, and process blocks at a time
<re_irc>
<@jamesmunns:beeper.com> oh, or use an rp2040 and write 4 little PIO state machines to do it for you
<re_irc>
<@jamesmunns:beeper.com> I'd _probably_ bet you couldn't do it cheaper than an rp2040, even with the flash and clock. Then you can use SPI or even I2C to connect up to the ESP32
<re_irc>
<@jamesmunns:beeper.com> using something like an stm32g0 with the port method I described above would probably still be reasonable too. at 64MHz and 38.4kHz sample rate, you'd have 1666 cycles to process each sample, which should be more than enough with a little bit of trickery.
<re_irc>
<@dngrs:matrix.org> did you intentionally not @ them?
<re_irc>
<@jamesmunns:beeper.com> they are on IRC, I assume they get the same ping.
<re_irc>
<@dngrs:matrix.org> ah!
<re_irc>
<@jamesmunns:beeper.com> cr1901 (just in case, I DID mean to at them)
<cr1901>
Good thing this is meant for no_std/no_alloc apps
<cr1901>
Well, I'll have to find some way to constrain tok safely that takes leak() into account
<cr1901>
jamesmunns: Thank you, you did as I asked. Please note that OurToken::new() is deliberately unsafe, and I'm looking for the subset of possible program states where calling new() would actually always be safe
<re_irc>
<@jamesmunns:beeper.com> If you haven't read the ghost cell paper by ralfj, it might be worth a read?
<re_irc>
<@jamesmunns:beeper.com> But yeah, you need to ensure the borrow lives shorter than the token OR the storage. I could have done that without box/leak, by dropping the rc.
<cr1901>
Anyways embedded-hal taking &mut sucks, I don't want to use a refcell to share between int handler and main thread
<cr1901>
So I've been playing around with this idea. I'll read GhostCell and study your example (b/c I don't actually understand it rn and am tired)
<cr1901>
yea that's not good :o
<re_irc>
<@jamesmunns:beeper.com> In cmim I use the VECTACTIVE to gate access without a real mutex (tho that only allows access from a single interrupt), and embassy has a mutex that does the opposite, enforces you are in thread mode (so there can be no preemption)
<cr1901>
AIUI refcell gets around the drop problem b/c the borrow is tied to the refcell's lifetime
<re_irc>
<@jamesmunns:beeper.com> Yup, mutex does too, you're bound to the lifetime of the MutexGuard which is <= than the Mutex itself
<re_irc>
<@grantm11235:matrix.org> It is the second most popular vscode extension when you search "toml". The most popular one ("Better TOML") only does syntax highlighting, not formatting
<re_irc>
<@dirbaio:matrix.org> : oh yep that seems to be it
<re_irc>
<@dirbaio:matrix.org> ffs why don't people check the diffs before opening a PR
<re_irc>
<@dirbaio:matrix.org> oh yesss this seems to kill it
<re_irc>
"[toml]": {
<re_irc>
},
<re_irc>
"editor.formatOnSave": true,
<re_irc>
"editor.formatOnSave": false
<re_irc>
<@xiretza:xiretza.xyz> : "git commit --all" was a mistake
<re_irc>
and you can always check it after opening, and amend if needed... I always do, sometimes find some detail that has slipped through...
<re_irc>
<@dirbaio:matrix.org> but even if you do, github shows the diff again before pening the PR