tokomak has joined #rust-embedded
starblue2 has joined #rust-embedded
starblue1 has quit [Ping timeout: 258 seconds]
fabic has joined #rust-embedded
zBeeble42 has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
GenTooMan has quit [Ping timeout: 252 seconds]
GenTooMan has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
neceve has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> therealprof: they wrote you a love letter: https://www.digikey.com/en/maker/blogs/2020/understanding-stm32-naming-conventions
<re_irc> <@9​names:m​atrix.org> "They follow a clever naming convention"
<re_irc> <@9​names:m​atrix.org> "Almost all models of the STM32 family of MCUs will follow these naming conventions."
<re_irc> <@9​names:m​atrix.org> I can almost hear the author's heart breaking while reading the article
<re_irc> <@j​amesmunns:m​atrix.org> They follow it! Except when they don't!
<re_irc> <@d​irbaio:m​atrix.org> conveniently missing the cursed -A, -X, -N suffixes
<re_irc> <@d​irbaio:m​atrix.org> like STM32L151R6 vs STM32L151R6-A
nohit has joined #rust-embedded
<re_irc> <@r​yan-summers:m​atrix.org> chrysn: Any chance you could take a look at https://gitlab.com/chrysn/std-embedded-nal/-/merge_requests/2 when you have some free time? I'd like to get the std-embedded-nal in parallel with embedded-nal, as I rely on it for some of my integration tests etc.
<re_irc> <@c​hrysn:p​rivacytools.io> ryan-summers: just coming back from vacation; i'll priorize it in the backlog.
<re_irc> <@c​hrysn:p​rivacytools.io> (and thanks for the work there!)
<re_irc> <@r​yan-summers:m​atrix.org> No worries, just wanted to make sure you knew about it incase you weren't monitoring the repo :)
fabic has joined #rust-embedded
richardeoin has joined #rust-embedded
GenTooMan has quit [Ping timeout: 258 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
<re_irc> <@z​uubek:m​atrix.org> Hey all, I was wondering if anyone can point me to any resources online that have a decent code structure/organization I can follow and learn from. Specifically I am looking at how best to organize modules pertaining to peripherals UART/CAN/SPI as opposed to having them all in main (majority of examples online). I...
<re_irc> ... am new to rust (but not embedded) and I understand that the ownership model makes this much trickier than in C but I am struggling to find examples of how this can be done
tokomak has quit [Ping timeout: 272 seconds]
<re_irc> <@n​ewam:m​atrix.org> Zuubek: Welcome! This sounds like me a few months ago 😀
<re_irc> <@n​ewam:m​atrix.org> One of the things to know is that rust (unlike C) is based on modules instead of the filesystem.
<re_irc> <@n​ewam:m​atrix.org> Plan out what kind of module layout you want first (`module::nested::MyStruct`) instead of planning what file layout you want.
<re_irc> <@n​ewam:m​atrix.org> As for an actual example this is good: https://doc.rust-lang.org/rust-by-example/mod/split.html
<re_irc> <@z​uubek:m​atrix.org> newam that certainly helps!
<re_irc> <@z​uubek:m​atrix.org> I guess maybe I was just trying to find a couple of larger firmware project written in rust which I could read and learn through exploration
<re_irc> <@n​ewam:m​atrix.org> Zuubek: This isn't exactly a beacon of excellence (I was learning when I did both versions of this project), but I redid a simple C project in rust as a learning exercise, might be helpful for you to compare:
<re_irc> <@n​ewam:m​atrix.org> https://github.com/newAM/ambientsensor-rs
<re_irc> <@z​uubek:m​atrix.org> Thank you, I will have a look
<re_irc> <@n​ewam:m​atrix.org> The RTIC (interrupt driven execution framework) examples are also good, but you have to use your imagination on how to build a bigger system with all these little examples:
neceve has quit [Ping timeout: 258 seconds]
<re_irc> <@n​ewam:m​atrix.org> oh, and the awesome embedded rust list is good too:
<re_irc> <@n​ewam:m​atrix.org> There's only one firmware project there, but it is substantial.
<re_irc> <@n​ewam:m​atrix.org> https://github.com/ah-/anne-key
neceve has joined #rust-embedded
<re_irc> <@r​yan-summers:m​atrix.org> We use RTIC for a _very_ large project: https://github.com/quartiq/stabilizer
<re_irc> <@n​ewam:m​atrix.org> Anyone know of a way to run doctests on target?
<re_irc> <@n​ewam:m​atrix.org> The best way I have found is making an example then doing `#[doc = include_str!("../examples/on_target.rs")]` in the docstring
<re_irc> <@r​yan-summers:m​atrix.org> What do you mean by "on target"? Does `cargo doc` not suite your needs?
neceve has quit [Remote host closed the connection]
<re_irc> <@n​ewam:m​atrix.org> running documentation examples for the microcontroller on the microcontroller to ensure that the code is valid
neceve has joined #rust-embedded
<re_irc> <@r​yan-summers:m​atrix.org> Ahhhh gotcha. Sorry, haven't done that personally. You could look into the embedded-hal mock though and see if that might suite your needs?
<re_irc> <@n​ewam:m​atrix.org> Yeah I have used that for a crate before, this is unfortunately for use with on-chip peripherals.
starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 240 seconds]
<re_irc> <@h​enrik_alser:m​atrix.org> Zuubek: Welcome! ✨ As for the peripheral modules we organize them in HAL crates, but maybe you’re talking about the apps themselves? They’re usually organized more by function than by peripheral… Any specific chip family you’re interested in?
<re_irc> <@h​enrik_alser:m​atrix.org> (Regarding trickyness, remember everything is at least as tricky in C to get it right, just that the compiler doesn’t care if you shoot yourself in the foot. So in many ways Rust is much easier because the compiler’s got your back)
<re_irc> <@h​enrik_alser:m​atrix.org> (It can even tell you how to fix it)
<re_irc> <@f​irefrommoonlight:m​atrix.org> newam: This seems to be like a big failure point with the rust embedded ecosystem. Ie, easy to fix, and high value to people considering rust for embedded.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Exampls for HALs, EH drivers etc tend to be too... simple? And don't resemble code you'd use for a non-trivial example
<re_irc> <@f​irefrommoonlight:m​atrix.org> It makes someone considering using them wonder "How do I adapt this for my project", and "All the examples are really basic... Is this even a suitable language/library"?
<re_irc> <@f​irefrommoonlight:m​atrix.org> *I'm guilty of this too
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie I'd rather a library provide a single example that shows full project structure, control flow etc featuring that lib, than 10 blinky-equivalent examples
<re_irc> <@h​enrik_alser:m​atrix.org> firefrommoonlight: I guess we need both, i’m generally looking for minimal scoped examples because it’s easier for me to see what is needed for what i’m trying to do. I’d hate to browse through thousands of lines of code just to find how to use the i2c peripheral or whatever
<re_irc> <@f​irefrommoonlight:m​atrix.org> Good point - I agree minimal-scoped is valuable too
<re_irc> <@z​uubek:m​atrix.org> firefrommoonlight That is the problem I am currently facing!
<re_irc> <@z​uubek:m​atrix.org> henrik_alser I am using the stm32f4xx_hal with an STM32F4 Discovery board, currently looking to connect the USART to CAN to be able to send data to and from the board to a CAN bus. I have each individual component working in a main function but having trouble coming up with a structure where I can...
<re_irc> ... compartmentalize those peripherals in their own modules and use a higher level module to connect the two. I intend to add additional functionality like a shell and maybe a SPI flash but I'm currently stuck on the project structure and flow control
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's how I've been doing it, but should add others too. I'd like to publish code for a future commercial project. The one I'm currently about to release is too complex/messy, and includes a few odd workaround I'd rather not publish yet
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hmm... So, I have a conductivity module using stm32 that plugs into RPi etc, and makes use of DAC, GPIO, I2C, and UART. Maybe I should publish that as an example
<re_irc> <@f​irefrommoonlight:m​atrix.org> Btw, of note, it's interesting to look at say, a HAL lib, and see things like project structure, mutexes, RTIC etc as perhaps out of scope... but if you need those things to use your HAL...
<re_irc> <@n​ewam:m​atrix.org> ```rs
<re_irc> <@n​ewam:m​atrix.org> /// Sample the V<sub>BAT</sub> pin.
<re_irc> <@n​ewam:m​atrix.org> /// This is internally connected to a bridge divider, the converted digital
<re_irc> <@n​ewam:m​atrix.org> ///
<re_irc> <@n​ewam:m​atrix.org> Wow that's a giant wall of text, I was hoping it would make those collapsable.
<re_irc> <@n​ewam:m​atrix.org> Also interestingly you cannot use `dev-dependencies` macros in documentation, it has to be a regular `dependencies`.
GenTooMan has quit [Ping timeout: 258 seconds]
<re_irc> <@n​ewam:m​atrix.org> Oh... oh no.
<re_irc> <@n​ewam:m​atrix.org> This runs during a regular build. Well, this idea is going in the rubbish bin.
GenTooMan has joined #rust-embedded
<re_irc> <@h​enrik_alser:m​atrix.org> Zuubek: I can highly recommend you to check out RTIC
<re_irc> <@f​irefrommoonlight:m​atrix.org> Whether you decide to use RTIC or not going forward, the event-based project structure it forces you into is very nice, and sufficiently general
<re_irc> <@n​ewam:m​atrix.org> If you are curious I keep an up-to-date list of rust RTOS options here: https://arewertosyet.com/
<re_irc> <@n​ewam:m​atrix.org> Some of them are not really RTOS', just execution frameworks, but you get the idea.
<re_irc> <@f​irefrommoonlight:m​atrix.org> I may be projecting a bit from JS, but frameworks add complexities in ways which aren't obvious, and becoming dependent on them without underlying the underlying concepts (How to set up and use ISRs, global state etc) is a trap, and you can become a "React programmer" or "RTIC programmer", helpless...
<re_irc> ... withou tit
<re_irc> <@f​irefrommoonlight:m​atrix.org> If you're building something with multiple independent processes/apps that don't directly interact etc, it makes sense. If not... maybe
<re_irc> <@f​irefrommoonlight:m​atrix.org> Of course, we all rely on abstractions at varying levels... so make a smart call for your use cases
<re_irc> <@f​irefrommoonlight:m​atrix.org> I built a damn rust-based WASM React-like framework... and now my websites are HTML+CSS+small amounts of targetted JS that do deliberate manipluations
<re_irc> <@f​irefrommoonlight:m​atrix.org> If you enjoy Async (Eg in non-embedded Rust, JS etc), then embassy is nice
<re_irc> <@n​ewam:m​atrix.org> I would recommend sticking to what compiles on stable for newcomers, which is RTIC or just doing your own thing with interrupts and masking/unmasking IRQs.
<re_irc> <@n​ewam:m​atrix.org> Some of the nightly features can produce a cacophony of compiler diagnostics.
<re_irc> <@z​uubek:m​atrix.org> I did see RTIC as a nice solution to my problem but wanted to tackle it without the added complexity of a paradigm shift. I plan to try it out eventually but would like to be more familiar with Rust before I do.
<re_irc> <@z​uubek:m​atrix.org> I think my problem may be two fold - Lack of experience with Rust and approaching the problem in the same format I would if I were writing it in C. I could do it all from main but that just seems wrong and not scalable. I intend to play around with it this weekend and see what I can come up with.
<re_irc> <@z​uubek:m​atrix.org> Appreciate the help, folks!
<re_irc> <@a​damgreig:m​atrix.org> Zuubek: maybe have a look at https://github.com/probe-rs/hs-probe-firmware as another firmware example
<re_irc> <@a​damgreig:m​atrix.org> in general the "how should I organise the project" question is a general rust one rather than especially embedded-specific, I think
<re_irc> <@a​damgreig:m​atrix.org> not having alloc and being wary of returning large results on the stack might change how you design some function signatures, but otherwise it's the same concept of modules and functions on structs and so on
<re_irc> <@z​uubek:m​atrix.org> adamgreig I think this is what I was looking for!
<re_irc> <@a​damgreig:m​atrix.org> one thing of note in that project is a separate bsp crate alongside the firmware crate, both in the same workspace and repo
<re_irc> <@a​damgreig:m​atrix.org> so most of the "writing to registers" stuff is in the bsp crate, and the application-level logic is more in the firmware crate
<re_irc> <@a​damgreig:m​atrix.org> for more sophisticated projects you'd often put even more stuff in a separate crate which builds on std and you can write tests for in the normal way, and the binary for the actual embedded hardware can then just pull in that well-tested code for the final embedded build
<re_irc> <@h​enrik_alser:m​atrix.org> Zuubek: I guess it also depends on whether you’re a ”bottom up” vs ”top down” learner, some people need to see things happening to stay motivated on following a project through and don’t have the interest/time to first reinvent their own concurrency model etc
<re_irc> <@h​enrik_alser:m​atrix.org> Personally for me rtic strikes a good balance between being low level and still providing the convenience i always ended up needing to implement myself in cumbersome ways and lets me spend my energy on application code but still without obscuring too much of what’s really going on at a hardware level
<re_irc> <@h​enrik_alser:m​atrix.org> `</fanboy>` Good that there’s options out there for everyone!
<re_irc> <@d​khayes117:m​atrix.org> I need to cut my teeth on RTIC sometime. Is the F3Discvoery board a good one to use it on, or maybe the nrf52840?
<re_irc> <@h​enrik_alser:m​atrix.org> dkhayes117: Yes both of these are great options!
<re_irc> <@d​khayes117:m​atrix.org> Perfect, I have both 😀
GenTooMan has quit [Ping timeout: 272 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ok, published this example: https://github.com/David-OConnor/stm32-hal/tree/main/examples/conductivity_module
<re_irc> <@f​irefrommoonlight:m​atrix.org> It's for a module you plug into a raspberry pi or w/e to measure electrical conductivity
<re_irc> <@f​irefrommoonlight:m​atrix.org> And is for something I flash and sell, albeit it's quite niche due to not being standalone
GenTooMan has quit [Ping timeout: 258 seconds]
<re_irc> <@n​ewam:m​atrix.org> Are there any crates for rational numbers that are more embedded friendly?
<re_irc> <@n​ewam:m​atrix.org> I return clock ratios as fractions and leave it up to the user if they want to use floats or not.
<re_irc> <@n​ewam:m​atrix.org> I have been using [num_rational::Ratio](https://docs.rs/num-rational/0.4.0/num_rational/struct.Ratio.html), but it is made for data science, and it is not ergonomic when it comes to casting to a float.
<re_irc> <@n​ewam:m​atrix.org> Also it's a little more panicy than I would like for embedded (e.g. no `saturating_mul` style functions).
GenTooMan has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Tuple of numerator and denominator
<re_irc> <@f​irefrommoonlight:m​atrix.org> Divide and cast using built-in functionality
<re_irc> <@f​irefrommoonlight:m​atrix.org> Use a struct if you want named methods
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 258 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> newam: arewertosyet.com is cool! maybe a little blurb about each option would be interesting?
<re_irc> <@n​ewam:m​atrix.org> Yeah I should do that, I keep poking at these things often enough 😀
<re_irc> <@t​herealprof:m​atrix.org> jamesmunns: Thanks. I knew most of those already (and it's missing the latest families), unfortunately they didn't answer the most important question: "Why?!?" 😅
neceve has quit [Ping timeout: 258 seconds]
<re_irc> <@f​irefrommoonlight:m​atrix.org> Agree on the blurbs; those frameworks do quite different things
<re_irc> <@n​ewam:m​atrix.org> What's the best supported (or most ubiquitous) chip for embedded-rust right now?
<re_irc> <@n​ewam:m​atrix.org> Just thinking about making an example program with each RTOS.
Wetmelon has joined #rust-embedded
<re_irc> <@d​khayes117:m​atrix.org> newam: Cortex-m and nRF52840
Wetmelon has quit [Read error: Connection reset by peer]
tokomak has joined #rust-embedded