crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
dc740 has joined #rust-embedded
emerent has quit [Ping timeout: 265 seconds]
emerent has joined #rust-embedded
<re_irc>
<@istlf:matrix.org> Hi good people of Rust :) I'm an electrical engineer with some experience of writing C for STM32, but I am planning on trying to build something related to electronic music and I need to do some embedded programming for it. Rust seems like a very interesting choice, although also a little bit daunting! Are there any good reasons to NOT pursue Rust for this project and stick to good old C? Or is Rust mature enough to go for it?...
<re_irc>
...
<re_irc>
<@k900:0upti.me> For STM32 Rust is generally fine
<re_irc>
<@k900:0upti.me> As in no major features missing
dc740 has quit [Remote host closed the connection]
<re_irc>
<@boiethios:matrix.org> : My keyboard has a STM32, and I had a great time hacking on it with Rust :)
<re_irc>
<@istlf:matrix.org> Right - I was also thinking (and maybe this is not totally right), but at the end of the day the device shouldn't care - it's already compiled when it meets the SoC?
<re_irc>
<@istlf:matrix.org> Cool! I am planning on building a sequencer of sorts, maybe even a sampler if I can get that far.. So i've been looking at things like Espressif because I see that Elektron machines are using them (for isntance: https://www.nxp.com/part/MCF54454VP266#/ )
<re_irc>
<@sourcebox:matrix.org> Last time I had a look, I2S driver support for STM32 was not that great. Don't know if it has improved in the meantime.
<re_irc>
<@istlf:matrix.org> Okay, so this basically means that STM32 hasn't provided a library of sorts for Rust?
<re_irc>
<@sourcebox:matrix.org> There is support for most peripherals, but it's not equally good.
<Lumpio->
STmicro does not provide official libraries no (nobody does afaik)
<re_irc>
<@k900:0upti.me> STMicro does not provide any libraries for Rust officially
<re_irc>
<@k900:0upti.me> But there's a community made HAL that covers most of it
<re_irc>
<@istlf:matrix.org> Ah okay. Still trying to wrap my head around the whole embedded scene.. quite alot of variables (ie. companies, chipsets, etc etc)
<re_irc>
<@istlf:matrix.org> Hmm, my other problem is also that I was hoping to do it on a platform I could emulate on my pc, so I wouldn't have to flash the device everytime I wanna write new code
<re_irc>
<@istlf:matrix.org> (which was my experience using STM32Cube and that whole toolchain which honestly felt terrible)
<re_irc>
<@sourcebox:matrix.org> For the parts that do not depend on hardware, like DSP algorithms, you can test them on the PC.
<re_irc>
<@boiethios:matrix.org> Yes, it's super easy to split the firmware in several crates, one with the hardware instructions, and the other one which is hardware agnostic and that you can unit test, etc.
dc740 has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> There several HALs contributed by the community, this one here has I2S support (SAI peripheral). But I did not check it myself yet. https://github.com/David-OConnor/stm32-hal
dc740 has quit [Remote host closed the connection]
<re_irc>
<@istlf:matrix.org> Ok, so I need to wrap my head around
<re_irc>
1. crates in Rust and 2) unit testing. I have an old STM32 F4 discovery I will try and start out with; if I end up changing platform, I'm sure I'll be able to reuse alot of code anyway
<re_irc>
<@istlf:matrix.org> Uhh that looks very interesting actually.. Looks advanced, but I think my project will end up getting a bit complicated anyway, so really interested in things that talk about how to do it right from the beginning
<re_irc>
<@istlf:matrix.org> i mean, of course i am also trying to avoid premature optimization, but still.. I'll give it a read
<re_irc>
<@istlf:matrix.org> Thanks to everybody who chimed in
<re_irc>
<@burrbull:matrix.org> ask @yruama_lairba. Looks like he is also interesting in this and has already done something for i2s in f4xx-hal.
<re_irc>
<@burrbull:matrix.org> * .
<re_irc>
<@boiethios:matrix.org> : It's not a premature optimization, FWIW. I made the mistake to put all in one crate, at first, so I couldn't unit/integration test my code, and it ended up being a mess (with regressions each time I added a piece of code).
<re_irc>
When I decided to put the logic (which is quite complex) in its own crate, it was a painful experience. I was happy that I could write integration tests afterwards, though. Also, my code with the hardware instructions is really small, so there is less risk of error.
IlPalazzo-ojiisa has joined #rust-embedded
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]