<re_irc>
<@adamgreig:matrix.org> reference manual: read back the LC bit to see if it's lower-case, works for all utf-8
<re_irc>
<@adamgreig:matrix.org> errata manual: only works for ASCII. just checks bit 7.
<re_irc>
<@firefrommoonlight:matrix.org> jamesmunns:beeper.com: That's what doesn't work
<re_irc>
<@firefrommoonlight:matrix.org> *Actually maybe I've been missing the &?
<re_irc>
<@firefrommoonlight:matrix.org> I'll try it later. Appreciate the help guys!
<re_irc>
<@jamesmunns:beeper.com> * `x` is a `[u8; 3]` - no bueno
<re_irc>
<@jamesmunns:beeper.com> yeah, in this case:
<re_irc>
<@jamesmunns:beeper.com> * `&x` is a `&[u8; 3]` - no bueno
<re_irc>
<@jamesmunns:beeper.com> * `&x[..]` is a `&[u8]` - which will work!
<re_irc>
<@firefrommoonlight:matrix.org> Great news! I'm doing a lot of array debugging these days
<re_irc>
<@jamesmunns:beeper.com> :D
<re_irc>
<@dirbaio:matrix.org> gotta debug these arrays fast
<re_irc>
<@dirbaio:matrix.org> aint nobody got time for slow array debugging
<re_irc>
<@jamesmunns:beeper.com> I'm just too lazy to set up a serial port, most of the time :p
<re_irc>
<@firefrommoonlight:matrix.org> New DEFMT now works with cortex-m-rt 7 too
<re_irc>
<@jamesmunns:beeper.com> speed is whatever
<re_irc>
<@firefrommoonlight:matrix.org> Haha sometimes the prints are still enough to screw up the audio. I have them on a timer
<re_irc>
<@jamesmunns:beeper.com> yeah, if I have something kick off DMA, I'll log AFTER the transaction has started or whatever
<re_irc>
<@jamesmunns:beeper.com> I don't know what our typical logging times look like anymore
<re_irc>
<@jamesmunns:beeper.com> dirbaio did a ton of work for that in 0.3
<re_irc>
<@firefrommoonlight:matrix.org> So, obviously printing something every buffer flip breaks the audio entirely
<re_irc>
<@firefrommoonlight:matrix.org> the timer just causes it to skip
<re_irc>
<@jamesmunns:beeper.com> it's a shame we need a critical section in defmt
<re_irc>
<@firefrommoonlight:matrix.org> Potentially there could be issues printing from the DMA buffer while it's being actively written to, which I have no guard against, but again, fine for debugging
<re_irc>
<@jamesmunns:beeper.com> i don't know if it would really be possible to (efficiently) remove it tho
<re_irc>
<@dirbaio:matrix.org> it was mostly code size though. I think it's somewhat faster but I think there's still qiute a bit of low hanging fruit for speed
<re_irc>
<@jamesmunns:beeper.com> i would think rzcobs would probably help relieve buffer pressure in MOST cases though
<re_irc>
<@jamesmunns:beeper.com> maybe not u8 arrays tho
<re_irc>
<@dirbaio:matrix.org> yeah disabling it might be faster
<re_irc>
<@dirbaio:matrix.org> unless you're printing so much that the probe speed is the bottleneck
<re_irc>
<@jamesmunns:beeper.com> if rzcobs is similar to rlercobs (which was even more complex), it was still pretty damn fast
<re_irc>
<@firefrommoonlight:matrix.org> I use that anyways for my stuff, although I put the boilerplate at the bottom of main instead of splitting lib.rs with a bin folder like in it
<re_irc>
<@dirbaio:matrix.org> it's decently fast
<re_irc>
<@dirbaio:matrix.org> but it makes rtt writes byte-by-byte
<re_irc>
<@jamesmunns:beeper.com> ahhh
<re_irc>
<@dirbaio:matrix.org> and rtt writes have fences and dmb's and stuff I think
<re_irc>
<@jamesmunns:beeper.com> hm
starblue has quit [Ping timeout: 240 seconds]
<re_irc>
<@dirbaio:matrix.org> hm, rtt-target has fences
<re_irc>
<@dirbaio:matrix.org> defmt-rtt has acquire/release atomics which I think emit dmb's too
<re_irc>
<@jamesmunns:beeper.com> most targets dont have dcache though
<re_irc>
<@jamesmunns:beeper.com> so it shouldnt be THAT expensive (a nop)
<re_irc>
<@jamesmunns:beeper.com> the compiler fences are probably a bigger impact
<re_irc>
<@dirbaio:matrix.org> plus there's a lot of logic when doing a write
<re_irc>
<@dirbaio:matrix.org> that's repeated for each byte
<re_irc>
<@dirbaio:matrix.org> and I don't think the compiler can optimize it away due to the atomics
<re_irc>
<@jamesmunns:beeper.com> it would be interesting to make a bbqueue like interface to fill into, then drain it in idle
<re_irc>
<@jamesmunns:beeper.com> if you have a mutex, you can just take the writer anyway, spsc doesn't matter
starblue has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> writing to a bbqueue is about as fast as writing to rtt, isn't it?
<re_irc>
<@dirbaio:matrix.org> similar complexity (?)
<re_irc>
<@jamesmunns:beeper.com> way faster
<re_irc>
<@dirbaio:matrix.org> why
<re_irc>
<@jamesmunns:beeper.com> you only pay the fence/atomic cost on grants and commits, not per byte
<re_irc>
<@jamesmunns:beeper.com> I mean
<re_irc>
<@jamesmunns:beeper.com> with 1 byte messages, yes
<re_irc>
<@jamesmunns:beeper.com> but if you're formatting 5/10/15/100 bytes, way less overhead
<re_irc>
<@jamesmunns:beeper.com> not even volatile writes
<re_irc>
<@dirbaio:matrix.org> ah, take 1 big grant, fill partially, commit?
<re_irc>
<@jamesmunns:beeper.com> yeah
<re_irc>
<@dirbaio:matrix.org> but you don't know the max frame len
<re_irc>
<@jamesmunns:beeper.com> take another if you run out
<re_irc>
<@dirbaio:matrix.org> it might even be bigger than the bbqueue buffer len
<re_irc>
<@jamesmunns:beeper.com> yeah, fair
<re_irc>
<@jamesmunns:beeper.com> no free lunch, etc.
<re_irc>
<@jamesmunns:beeper.com> but like...
<re_irc>
<@dirbaio:matrix.org> hehe then you're back to doing quite a few checks for each byte
<re_irc>
<@jamesmunns:beeper.com> I don't log a lot of 4K structures :p
<re_irc>
<@jamesmunns:beeper.com> it's apples to oranges, but I can get 100s of gbit/sec on a desktop processor using bbqueue, it's like... 5-10 atomic ops per grant/release
<re_irc>
<@jamesmunns:beeper.com> and thats it
<re_irc>
<@dirbaio:matrix.org> 🚀
<re_irc>
<@jamesmunns:beeper.com> it's like, "measure the speed of your L1/L2 cache" fast.
<re_irc>
<@jamesmunns:beeper.com> would be the parts in the critical section
<re_irc>
<@jamesmunns:beeper.com> it would probably be more overhead for an interned string though
<re_irc>
<@jamesmunns:beeper.com> which would just be like, 5-10 bytes
creich has quit [Remote host closed the connection]
creich_ has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> it's kinda the same order of complexity as rtt
<re_irc>
<@dirbaio:matrix.org> imo if you want to make defmt faster you have to optimize rtt
<re_irc>
<@dirbaio:matrix.org> not add another queue in front
<re_irc>
<@jamesmunns:beeper.com> yeah, amortization helps a lot for big buffers though :p
<re_irc>
<@jamesmunns:beeper.com> yeah, also fair
<re_irc>
<@jamesmunns:beeper.com> I mean, you could rewrite rtt to use bbqueue's algo
<re_irc>
<@dirbaio:matrix.org> you could do the "take big allocation, fill, commit" with rtt too
<re_irc>
<@dirbaio:matrix.org> where "commit" means "update the write ptr"
<re_irc>
<@jamesmunns:beeper.com> e.g. MAKE rtt bbqueue
<re_irc>
<@jamesmunns:beeper.com> so you can stride your data the same way
<re_irc>
<@jamesmunns:beeper.com> yeah
<re_irc>
<@jamesmunns:beeper.com> exactly
<re_irc>
<@jamesmunns:beeper.com> rtt (from the target side) is just another DMA engine
<re_irc>
<@newam:matrix.org> Everything looks like io_uring these days :D
<re_irc>
<@dirbaio:matrix.org> ringbuffers all the way down
<re_irc>
<@jamesmunns:beeper.com> 🌎️ 🧑🚀 🔫 🧑🚀
<re_irc>
<@jamesmunns:beeper.com> "Always has been."
<re_irc>
<@jamesmunns:beeper.com> "Wait, it's all circular buffers?
<re_irc>
<@jamesmunns:beeper.com> bip buffers are just fancy ringbuffers where you can push/pop chunks at a time, which matches MOST DMA use cases better than one-in-one-out.
<re_irc>
<@jamesmunns:beeper.com> (and bbqueue is a bip buffer derivative)
<re_irc>
<@dirbaio:matrix.org> chonky ringbuffers
<re_irc>
<@dirbaio:matrix.org> you push/pop chonks
<re_irc>
<@dirbaio:matrix.org> chonki boi
<re_irc>
<@jamesmunns:beeper.com> quick, submit a PR to rename "framed" to "chonked"
<re_irc>
<@luojia65:matrix.org> Brief: 240MHz, DSP, Wi-Fi 3, Bluetooth, IoT, while board cost less than 1 USD
<re_irc>
<@grantm11235:matrix.org> The datasheet says 802.11 b/g/n, isn't that Wi-Fi 4?
<re_irc>
<@luojia65:matrix.org> Oh sorry, should be 4, thanks for mentioning GrantM11235
<re_irc>
<@9names:matrix.org> luojia65: how is the state of Rust C-Sky support
PyroPeter has quit [Ping timeout: 250 seconds]
PyroPeter has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> osten_music:matrix.org: add `.bank1()` etc before the register and it'll work the same as on other STM32s. Turns out the periph isn't much different from other STM32s, but the PAC is set up differently
<re_irc>
<@korken89:matrix.org> dirbaio:matrix.org: Yeah it seems like a cargo bug..
<re_irc>
<@firefrommoonlight:matrix.org> Also, some of the CR1 names are different
<re_irc>
<@firefrommoonlight:matrix.org> Done, but not tested. Check for H7 feature flags:
<re_irc>
<@firefrommoonlight:matrix.org> Ignore the L5 security stuff
<re_irc>
<@luojia65:matrix.org> 9names: Seems like LLVM developer backend is already useable, trying to build Rust on it recently. Like m68k, the rust support should be available recently (if more people on it)
creich_ is now known as creich
<re_irc>
<@korken89:matrix.org> My hunt to support multiple `defmt` versions continue. Does anyone see a problem with the approach I mention here to use a range of versions? https://github.com/knurling-rs/defmt/issues/625
<re_irc>
<@korken89:matrix.org> I'm unsure of unintended consequences.
<re_irc>
<@korken89:matrix.org> As I see it this should leave it to the final user crate (probably the binary) to select the version
<re_irc>
<@korken89:matrix.org> (and seems to work in my test)
<re_irc>
<@gauteh:matrix.org> Hi. I'm continuing my struggle to get interrupts to fire on Ambiq Apollo 3. I now suspect there is something up with the bootloaders. It comes with a pre-shipped bootloader that is documented to be a "physical part of the chip" (whatever that means). It takes up the memory up to 0xc000. After that another bootloader (from sparkfun) lives up to 0x10000. I've put my code after 0x10000 (by specifying that FLASH...
<re_irc>
... starts there in memory.x). So it seems that vector with interrupts end up there. Could this be the issue? The sparkfun bootloader is possible to overwrite (using JLink). But the ambiq "secure" bootloader is a pain in the neck to overwrite. It seems to be protected in some way, and I'm not even sure it is possible to remove.
<re_irc>
<@gauteh:matrix.org> Or is the interrupt vector copied into RAM on start? I'm utterly confused.
troth has quit [Ping timeout: 264 seconds]
<re_irc>
<@9names:matrix.org> if it's a cortex-m3 or above there's a register (VTOR) for setting an offset to the vector table. I expect the first bootloader will do this for you.
<re_irc>
<@9names:matrix.org> you could check the sparkfun bootloader to see if it puts the vector table at 0xc000
<re_irc>
<@gauteh:matrix.org> It's a cortex-m4. The sparkfun bootloader is the 2nd bootloader, so ideally it should set the VTOR to 0x10000 then?
<re_irc>
<@9names:matrix.org> yeah, i would think so
<re_irc>
<@gauteh:matrix.org> Ok, thanks. That's a good starting point.
<re_irc>
<@9names:matrix.org> it also looks like there's an option to disable the bootloader rom being mapped to 0x0 so it would boot direct from flash. i assume it has some sort of protection or is a fuse-style single-write memory though, so maybe you cannot clear it.
troth has joined #rust-embedded
<re_irc>
<@gauteh:matrix.org> Yes. There is some one-time-protection. It's not very documented in the ambiq docs, maybe it's a cortex-m feature? Have not figure out how to unlock that memory
<re_irc>
<@gauteh:matrix.org> Yes. That was what I was hoping to, but could not get it to boot when I put my image there.
<re_irc>
<@9names:matrix.org> how are you loading your image on to the device?
<re_irc>
<@gauteh:matrix.org> Using JLinkGDBServer and gdb-multiarch
<re_irc>
<@9names:matrix.org> the bootloader is very likely to be checking for magic values somewhere in flash before accepting your firmware. probably best to try with https://github.com/sparkfun/Apollo3_Uploader_ASB until you're sure your firmware is working properly
<re_irc>
<@gauteh:matrix.org> ah ok!
<re_irc>
<@9names:matrix.org> once it's working, you can spend the time working out what you need to calculate and where to put it to make the bootloader happy
<re_irc>
<@gauteh:matrix.org> It works fine if I put it at 0x10000, now I need to put the sparkfun bootloader back at 0xc000
<re_irc>
<@gauteh:matrix.org> (it works fine except interrupts at 0x10000)
<re_irc>
<@lulf_:matrix.org> Feels like they have very narrow/specific integrations, which on one hand is great for focus, but I wonder how it would scale as they get bigger
troth has quit [Ping timeout: 260 seconds]
<re_irc>
<@gauteh:matrix.org> Thanks a lot. I've learned a lot today!
<re_irc>
<@gauteh:matrix.org> So the VTOR points to somewhere within the sparkfun bootloader, 0xed04. Should it point to 0x10000 in my rust program (the start of FLASH)? or is it offset something?
troth has joined #rust-embedded
<re_irc>
<@9names:matrix.org> the secure bootloader should set VTOR to 0xc000 which is the start of the sparkfun variable loader binary. the sparkfun loader should set VTOR to 0x10000 before jumping to your code
<re_irc>
<@gauteh:matrix.org> right! so maybe thats not happening. the secure bootloader source code has mention of VTOR, but the sparkfun bootloader does not (as far as I can see).
<re_irc>
<@9names:matrix.org> that's a bit disappointing. easy option would be to patch the sparkfun bootloader to do it before calling goto.
<re_irc>
<@gauteh:matrix.org> Yes. Complicates things a bit for a generic HAL.
<re_irc>
<@9names:matrix.org> for generic hal you could replace the sparkfun code at 0xc000 with your application, but then i assume you'll have to deal with whatever the secure bootloader requires.
<re_irc>
<@9names:matrix.org> disabling secure boot entirely and just having flash mapped at 0x0 would be best but you'll have to work out how to do that.
<re_irc>
<@gauteh:matrix.org> `p/x $0xE000ED04` should give me the value at register in gdb right?
<re_irc>
<@gauteh:matrix.org> Yes. There is probably a magic value check, since booting works fine if I put svl back. I think I will end up putting code at 0x10000 for the time being and figure out how to update vtor.
<re_irc>
<@gauteh:matrix.org> `x/2 0xE000ED04` => `0x00000000 0x0000c000`, so it points to the start of the SVL bootloader.
<re_irc>
<@adamgreig:matrix.org> Urgh, I hate bootloaders that don't set vtor for you, very annoying
<re_irc>
<@adamgreig:matrix.org> That sure explains all your problems though
tokomak has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
<re_irc>
<@gauteh:matrix.org> OMG it works. I officially owe a couple of beers to people in here.
<re_irc>
<@gauteh:matrix.org> rprintln!("Setting VTOR to 0x10000");
<re_irc>
<@gauteh:matrix.org> }
<re_irc>
<@gauteh:matrix.org> let SCB = &*cortex_m::peripheral::SCB::ptr();
tokomak has quit [Read error: Connection reset by peer]
dreamcat4 has quit [Ping timeout: 264 seconds]
darknighte has quit [Ping timeout: 256 seconds]
SanchayanMaity has quit [Ping timeout: 268 seconds]
nohit_ has joined #rust-embedded
edm_ has joined #rust-embedded
edm has quit [Ping timeout: 268 seconds]
nohit has quit [Ping timeout: 268 seconds]
nohit_ is now known as nohit
edm_ is now known as edm
dreamcat4 has joined #rust-embedded
darknighte has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
darknighte has joined #rust-embedded
darknighte has quit [Changing host]
nohit has quit [Ping timeout: 260 seconds]
darknighte has quit [Ping timeout: 264 seconds]
SanchayanMaity has quit [Ping timeout: 260 seconds]
dreamcat4 has quit [Ping timeout: 250 seconds]
edm has quit [Ping timeout: 250 seconds]
SanchayanMaity has joined #rust-embedded
edm has joined #rust-embedded
darknighte has joined #rust-embedded
dreamcat4 has joined #rust-embedded
nohit has joined #rust-embedded
<re_irc>
<@newam:matrix.org> Are there any Windows users here who want to help me debug a linker failure on Windows (and only Windows) when updating to defmt 0.3 in the stm32-rs bxcan crate?
<re_irc>
<@neltnerb:matrix.org> Hi, to briefly introduce myself, I have been doing embedded firmware for a while mostly in C with a bit of assembly and C++ without a RTOS, and I think it would be good to try to work with Rust instead. I mostly design the PCBs so my firmware is usually pretty simple and it'd be nice if I could make it simple and reliable more easily.
<re_irc>
<@neltnerb:matrix.org> I am going to read through the rust-embedded book and other references, but wanted to ask if the STM32F3DISCOVERY development board would still be the recommendation for a first eval board.
<re_irc>
<@ryan-summers:matrix.org> The STM32F3 discovery's have been pretty hard to get hands on as of late. What has the discovery book been rewritten with?
<re_irc>
<@adamgreig:matrix.org> micro:bit
<re_irc>
<@adamgreig:matrix.org> if you already know about embedded hardware and firmware you might not be the target audience for the discovery book, which teaches a lot of embedded basics at the same time
<re_irc>
<@adamgreig:matrix.org> you might find you can do just as well writing some firmware for a board you've already made or have to hand, and perhaps reading through the discovery book or the embedded book to see the rust parts
<re_irc>
<@neltnerb:matrix.org> I also don't know any Rust yet, for what it's worth.
<re_irc>
<@adamgreig:matrix.org> what microcontrollers are you used to using?
<re_irc>
<@neltnerb:matrix.org> I like the ESP32 and STM32 but since I started on assembly they mostly feel the same except for proprietary IDEs
<re_irc>
<@adamgreig:matrix.org> at the moment stm32 is pretty widely supported in rust, and a lot of people use them, however espressif have someone full time working on rust support for esp32 and especially with the risc-v variant i think it's quite easy to get going, so either is probably a good choice
<re_irc>
<@neltnerb:matrix.org> Really if I can get it working on any target I'll be satisfied =)
<re_irc>
<@adamgreig:matrix.org> (ST have not done anything for rust support, as far as I know)
<re_irc>
<@ryan-summers:matrix.org> As a completely biased opinion, I would say STM32 is probably the best to get started with due to the widest support + user base
<re_irc>
<@ryan-summers:matrix.org> But I live in a bubble
<re_irc>
<@adamgreig:matrix.org> i liked living in an stm32 bubble until this year when i stopped being able to buy any stm32s -_-
<re_irc>
<@neltnerb:matrix.org> thanks! yeah, most people I know doing preliminary projects use STM32 and the ones doing production runs all switch to qualcomm
<re_irc>
<@adamgreig:matrix.org> but it's not like you can buy ixmrt or atsam stuff very well either so... should pick up rp2040 i guess
<re_irc>
<@ryan-summers:matrix.org> My day job is MSP430 and I really don't want to work on a 64KB processor in Rust
<re_irc>
<@ryan-summers:matrix.org> I imagine it's fine at high optimiations, but still
<re_irc>
<@neltnerb:matrix.org> Thanks for the ideas, I might start with the ESP32 then since I have old boards that I used it on that I can rewrite their firmware for.
<re_irc>
<@adamgreig:matrix.org> in any event, you could definitely buy the f3discovery, or micro:bit board (which might be more available) and follow the discovery book, but you probably don't need to in order to pick up rust on your own stm32s
<re_irc>
<@neltnerb:matrix.org> oh, micro:bit is an eval board. sure, that works if it'll follow the book better
<re_irc>
<@ryan-summers:matrix.org> Yeah, if you have hardware you're already familiar with, I'd start there
<re_irc>
<@ryan-summers:matrix.org> Figure out how to twiddle registers, then look at existing HALs.
<re_irc>
<@ryan-summers:matrix.org> What's the alternative to the discovery book? The ebedonomicon?
<re_irc>
<@ryan-summers:matrix.org> For more in-depth dive in embedded+rust
<re_irc>
<@adamgreig:matrix.org> the embedded book
<re_irc>
<@ryan-summers:matrix.org> A read through https://docs.rust-embedded.org/embedonomicon/ will give you a solid grasp on the underlying mechanisms if you're comfortable with embedded already as well
<re_irc>
<@adamgreig:matrix.org> you could also join #esp-rs:matrix.org (and #stm32-rs:matrix.org ) matrix rooms
<re_irc>
<@ryan-summers:matrix.org> I liked the embedonomicon personally, since I like knowing what the -rt and such are doing as well
<re_irc>
<@adamgreig:matrix.org> especially #esp-rs:matrix.org should be a good place to get you going with rust on esp32, and it will depend on whether your existing esp32 is the xtensa cpu or the risc-v cpu
<re_irc>
<@adamgreig:matrix.org> (you're also always welcome to ask any questions in here)
<re_irc>
<@neltnerb:matrix.org> Thanks, I'll do that. I fully expect to spend half my time figuring out how to actually compile and upload firmware properly.
<re_irc>
<@sajattack:matrix.org> compiling in Rust is easy `cargo build`
<re_irc>
<@ryan-summers:matrix.org> That actually likely won't be your biggest problem with cargo
<re_irc>
<@ryan-summers:matrix.org> And probe-rs
<re_irc>
<@adamgreig:matrix.org> you might be pleasantly surprised compared to a lot of C projects!
<re_irc>
<@ryan-summers:matrix.org> The tooling in rust is top-notch
<re_irc>
<@neltnerb:matrix.org> neat
<re_irc>
<@ryan-summers:matrix.org> Definitely look at probe-run and probe.rs for debuggers/programmer support
<re_irc>
<@ryan-summers:matrix.org> and cargo-flash
<re_irc>
<@adamgreig:matrix.org> I think probe-rs even has/will soon have built-in support for the new esp32 internal usb-jtag probe
<re_irc>
<@yatekii:matrix.org> adamgreig: it's on master since yesterday :)
<re_irc>
<@yatekii:matrix.org> no guarantees for 100% bugfree operation but seems to work so far
<re_irc>
<@yatekii:matrix.org> vscode support is also improving :)
<re_irc>
<@ryan-summers:matrix.org> I was using the gdb stub the other day and was pleasantly surprised. Much nicer experience than OpenOCD
<re_irc>
<@ryan-summers:matrix.org> Glad to see that all landing nicely
<re_irc>
<@neltnerb:matrix.org> very neat. as long as I don't have to manually tell it to blow fuses I'll be happy.
<re_irc>
<@yatekii:matrix.org> neltnerb:matrix.org: you will have to use official ESP tooling for that
<re_irc>
<@sympatron:matrix.org> Personally I wouldn't start with ESP32 since it's not natively supported at the moment. So getting the toolchain running is probably more difficult and you will find a lot more examples for STM32. ESP32 support is still quite lacking as far as I know.
<re_irc>
<@neltnerb:matrix.org> This would also be fine with me, I've gone far enough to use their cube configurator so they're not too foreign
<re_irc>
<@sympatron:matrix.org> Especially if you don't know Rust, you don't want to wrestle with the Rust language and toolchain at the same time.
<re_irc>
<@neltnerb:matrix.org> huh, this discovery board looks familiar, I wonder if i already have one
<re_irc>
<@adamgreig:matrix.org> esp32-c3 is risc-v and so natively supported, but I think even the xtensa stuff is now pretty easy to build these days, there's a guide here: https://github.com/esp-rs/rust
<re_irc>
<@adamgreig:matrix.org> and espressif themselves have pre-built binaries you can just download
<re_irc>
<@adamgreig:matrix.org> (even so, it is still easier to build for cortex-m cpus like stm32)
<re_irc>
<@sympatron:matrix.org> And you can use Embedded Rust's major selling points RTIC and/or embassy
<re_irc>
<@neltnerb:matrix.org> I look forward to learning what those mean :-)
<re_irc>
<@neltnerb:matrix.org> there are 9 STM32F3DISCOVERY on digikey if anyone is having a hard time finding them
<re_irc>
<@sympatron:matrix.org> adamgreig: Yeah, I know. I didn't say it's not usable. I it probably a lot better now. But I wouldn't necessarily recommend it for beginners. Also Elmo probably already has standard ESP32 not ESP32-C3
<re_irc>
<@neltnerb:matrix.org> it is true, my ESP32s are from like 2017
fabic has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> Has anyone done plotting with rust (host side)?
<re_irc>
<@ryan-summers:matrix.org> I'm looking to see if it would be possible to essentially livestream plots of data. E.g. re-render plots at faster than 50fps or so, with lots of data points
<re_irc>
<@jacobrosenthal:matrix.org> ryan-summers:matrix.org: Theres lots of one off ways, where you load the data and use plotters or python macro to fire off a graph. Not much for continous Ive seen. There was some poc stuff in cargo embed branches but its hard to decide where to configure the graphing coming out of the rtt channels. Preamble to the data? What standard format? Theres also a concept kicking around of defmt style digging...
<re_irc>
... the plotting params out of the elf file...
<re_irc>
<@ryan-summers:matrix.org> No, I have the data coming in a livestream over UDP from the embedded target at like 50MB/s, so I want to ingest that in a host-side app for display
<re_irc>
<@ryan-summers:matrix.org> Currently using python, but figured a native rust app would be a lot faster on the rendering
<re_irc>
<@firefrommoonlight:matrix.org> neltnerb:matrix.org: RTIC is a lightweight framework that manages interrupts in a clever way, and provides some timer abstractions. Embassy is a framework that allows you to use Async syntax, and includes built-in peripheral-support abstractions
<re_irc>
<@adamgreig:matrix.org> try doing a 3d plot in 18 lines of rust without inline_python, lol
GenTooMan has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> that's not live obviously, but it's not hard
<re_irc>
<@adamgreig:matrix.org> the bonus is that if you're doing all the number crunching in rust and just final visualisation in python you still get a lot of the rust speedups
<re_irc>
<@ryan-summers:matrix.org> Yeah that's actually not a bad idea
<re_irc>
<@ryan-summers:matrix.org> Then we can get rid of our current bokeh webserver js frontend
<re_irc>
<@adamgreig:matrix.org> there _are_ rust native plotting libraries, and more now than when I was doing this, but last I looked they still were not half as easy to use or featureful as matplotlib
<re_irc>
<@ryan-summers:matrix.org> And just use matplotlib windows
<re_irc>
<@adamgreig:matrix.org> (especially at the time I wanted 3d plots which was harder to find)
<re_irc>
<@adamgreig:matrix.org> I'm looking to soon write something in egui as more of a dedicated app, and egui has some primitive plotting built in which also looks reasonably extensible
<re_irc>
<@adamgreig:matrix.org> plus then works on webgl or native win/lin/mac/etc, which is kinda slick
<re_irc>
<@adamgreig:matrix.org> but obviously a bunch more work, better suited for more mature development than the quick and dirty plots I was using python for
cr1901 has quit [Read error: Connection timed out]
<re_irc>
<@adamgreig:matrix.org> ryan-summers:matrix.org: that said, back in 2017 I had an 80Mbps data stream from an stm32f7 running rust/smoltcp going into python+matplotlib live: https://twitter.com/adamgreig/status/873901071013425152
<re_irc>
<@adamgreig:matrix.org> not much has changed since :P
<re_irc>
<@adamgreig:matrix.org> (I appreciate 80Mbps is << 50MB/s though!)
<re_irc>
<@ryan-summers:matrix.org> We can decimate if we need to, it's no biggie
<re_irc>
<@ryan-summers:matrix.org> But that's pretty responsive
<re_irc>
<@adamgreig:matrix.org> python was also doing the fft and stuff there
<re_irc>
<@korken89:matrix.org> mathias_koch:matrix.org: An interrupt cannot preempt itself so it should be fine
<re_irc>
<@korken89:matrix.org> Plus as you have &mut self interface it would be UB if it could as you would be breaking the aliasing rule :)
<re_irc>
<@mathias_koch:matrix.org> Happy to get that confirmed 👍️ Thanks
<re_irc>
<@korken89:matrix.org> Np
<re_irc>
<@firefrommoonlight:matrix.org> Re plotting. There's a plotting lib I used a while back that worked pretty well
<re_irc>
<@firefrommoonlight:matrix.org> Lately... and this sound janky and is related to my (solved!) woes about demft print sizes.... Copying arrays printed from `defmt` into a python repl lol
<re_irc>
<@firefrommoonlight:matrix.org> So, I print the thing with defmt, copy from one terminal tab. In another with `ipython` up, I type`x = `, then paste, then plot with python as normal
<re_irc>
<@firefrommoonlight:matrix.org> Or I make it an np array if I want to do vectorized ops on it etc
<re_irc>
<@firefrommoonlight:matrix.org> Janky, but is working for my use atm
<re_irc>
<@dirbaio:matrix.org> hehehe
<re_irc>
<@firefrommoonlight:matrix.org> *Also re the plotting lib I used a while back. Compiling and running was *still* faster than using Julia's JIT!
<re_irc>
<@dirbaio:matrix.org> I have a crap python script to plot some stuff that works like `cargo run blahblah | python plot.py` :D
<re_irc>
<@firefrommoonlight:matrix.org> I also do the opposite, and generate filter coeffs in python, then paste into Rust, and run using the wrapped `CMSIS-DSP_SYS` C api
<re_irc>
<@firefrommoonlight:matrix.org> This isn't how they told me FFI works
<re_irc>
<@firefrommoonlight:matrix.org> That looks nice
<re_irc>
<@newam:matrix.org> Does anyone know if a shield exists to display the MSRV from the new `rust-version` field?
<re_irc>
<@newam:matrix.org> Hmmm, the crates.io API doesn't have an endpoint for that, time to go digging.
<re_irc>
<@ubik:matrix.org> is there a way to set directly the PLL dividers using `stm32f4xx-hal`? I can only seem to be able to set them indirectly through `.i2c_clk(...)`
<re_irc>
<@ubik:matrix.org> I'm trying to set the I2S PLL clock to ~12.3MHz and tried `let clocks = rcc.cfgr.use_hse(16.mhz()).sysclk(84.mhz()).i2s_clk(12300.khz()).freeze();`
<re_irc>
<@ubik:matrix.org> but it says it cannot find a valid PLL config
<re_irc>
<@firefrommoonlight:matrix.org> I'm a fan of a sensible default(s), where you customize specific fields A/R
<re_irc>
<@firefrommoonlight:matrix.org> The solvers in stm32yxx-hals underestimate the DOF of STM32's clock system
<re_irc>
<@firefrommoonlight:matrix.org> You need something much more clever and with more checks to attempt that approach. It's easier to work from scalers up
fabic has quit [Ping timeout: 256 seconds]
emerent_ has joined #rust-embedded
emerent has quit [Killed (erbium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
crabbedhaloablut has quit [Remote host closed the connection]