<re_irc>
<@tholmie:matrix.org> Hey all, I made a profiling crate built for embedded called [https://docs.rs/embedded-profiling/latest/embedded_profiling/](embedded-profiling) using korken89 's great `fugit` library. At this point I'm pretty happy with where it's at performance-wise but there are some non-idealities in some spots. Check it out and let me know what you think! I hope it's useful to someone.
Tabs has joined #rust-embedded
Tabs has quit [Read error: Connection reset by peer]
Tabs has joined #rust-embedded
Tabs has left #rust-embedded [AndroIRC]
cr1901 has quit [Remote host closed the connection]
<re_irc>
<@hendrik:henku.de> Is there a dedicated room for programming AVR with rust?
<re_irc>
<@tholmie:matrix.org> Looks like there’s a link to a chat room on the website: https://www.avr-rust.com
<re_irc>
<@sillyfreak:sillyfreak.space> Rust Embedded is a space, you can "Explore Rooms" and will find [avr-rust/Lobby](https://app.element.io/#/room/#avr-rust_Lobby:gitter.im)
<cr1901>
agg: Just as a heads up, unlikely to be here for the meeting tomorrow. If things change, I'll let you know
<re_irc>
<@robgal519:matrix.org> Hi, i have a beginner question, I worked with Zephyr RTOS, and code that is being written is platform independent. During compilation, it is picked for what platform I will compile the project, and Zephyr will pull all required code, to run on the selected platform. Is it possible to do something similar in Rust ? I would like to be able to create some simple application, for STM, and just recompile it for...
<re_irc>
... nRF, and providing that those uC have the same required peripherals, everything should just work. So just to summarize, is it possible to create portable embedded code in Rust ?
<re_irc>
<@jamesmunns:beeper.com> Basically in Rust, we tend to fall into a pattern where:
<re_irc>
<@jamesmunns:beeper.com> * You initialize all your peripherals (e.g. SPI, I2C) in a platform-specific way (since every platform is a bit different
<re_irc>
<@jamesmunns:beeper.com> * But once you hit "steady state" operational mode, you rarely have to change your code to move between different platforms, even big jumps like Cortex-M to Linux!
<re_irc>
<@jamesmunns:beeper.com> Most drivers for things like sensors ONLY rely on the `embedded-hal` traits, so they should work on nearly any platform.
<cr1901>
that doesn't rely on interrupts to talk to the peripheral* :)
<re_irc>
<@adamgreig:matrix.org> cr1901, ack
<re_irc>
<@jamesmunns:beeper.com> cr1901 I disagree with that, most of my drivers just expose a callback interface, but hey, if you feel like starting a fight, go off :D
<re_irc>
<@jamesmunns:beeper.com> I'm off to finish writing `defmt-bbq` so I can log stuff over USB and RS-485.
<cr1901>
Those are your drivers. That's good :D.
<re_irc>
<@robgal519:matrix.org> James Munns: Thank You, for the advice, I will get to work than :D so just to understand this correctly, If I want to add another platform, I will have to rewrite only the initialization code, that is below embedded-HAL, and do some magic on Cargo site, to pull correct files and crates into compilation ?
<cr1901>
Now if only everyone else did that. And there was a unified way to present these callbacks regardless of your MCU platform available in Rust :o
<re_irc>
<@jamesmunns:beeper.com> robgal519:matrix.org: Not even magic, most drivers will do something like say "I need a SPI interface". So in your initialization code, you do platform-specific things to initialize your SPI interface, then give the interface to the driver.
<re_irc>
<@jamesmunns:beeper.com> For example STM32 might require you to setup RCC registers, while nRF52 doesn't. But once you have something that implements the `Spi` trait(s), you just hand that over to the driver (say, some kind of display).
<re_irc>
<@jamesmunns:beeper.com> Then the display driver doesn't care about what kind of SPI interface it has, just that it has one.
<re_irc>
<@jamesmunns:beeper.com> So we would say that Display driver is "Generic over types that implement the SPI interface".
<re_irc>
<@robgal519:matrix.org> ok thank you :) That gave me some confidence to dig a little deeper, I will try to make some simple projects, maybe I will learn something along the way ;D
<re_irc>
<@jamesmunns:beeper.com> You got this!
<re_irc>
<@firefrommoonlight:matrix.org> How tough switching will be depends on which onboard peripherals you use
<re_irc>
<@firefrommoonlight:matrix.org> If any problems or questions arise, ask
<re_irc>
<@dbrgn:matrix.coredump.ch> Is the systick timer always enabled on ARM hardware? There's a table for the STM32L071xx that lists power consumption for different peripherals (including timers), but SYSTICK is not among them.
<re_irc>
<@tholmie:matrix.org> I’ve worked with chips that power off systick in pretty much any low power state. As soon as the core gets clock gated
<re_irc>
<@9names:matrix.org> the default systick clock source is the core clock, providing an external clock for it is optional.
<re_irc>
<@9names:matrix.org> you don't need to power it off to have it be effectively non-functional when the core is clock gated.
<re_irc>
<@therealprof:matrix.org> dbrgn:matrix.coredump.ch: No, there are cores which do not have SYSTICK.
<re_irc>
<@dbrgn:matrix.coredump.ch> therealprof ok. but for a core that has SYSTICK, is there any benefit in not using it, and using another timer instead for scheduling (possibly lower power consumption)?
<re_irc>
<@therealprof:matrix.org> No idea. SYSTICK is somewhat basic but well defined which makes it useful. I can totally imagine it not being very efficient.