00:36 <re_irc> <GrantM11235> What does the embedded rust job market look like these days? I am considering a career change

01:10 <re_irc> <jessebraham> There are at least some companies hiring for these positions. Espressif has assembled a small team to focus on Rust development (disclosure: employee). I've been in touch through work with a number of other companies interested in the space as well.

01:10 <re_irc> <jessebraham> With that said, seem to still be in the pretty early stages of all this, so I'd imagine it will take a number of years still for momentum to build.

04:55 <re_irc> <tamashi> Is it possible to change pwm period like "pwm.set_period()" after calling "pwm.split()"?

05:13 <re_irc> <korken89> corecode: Sure, if you want some inspiration you can check out smlang as well :)

05:15 <re_irc> <burrbull> tamashi: No. Or you are using whole Pwm structure (if supported by HAL) and can change period, or split it on channels and work with each channel independetly

05:15 <re_irc> <burrbull> * independently

05:15 <re_irc> <korken89> GrantM11235: If you are looking to move to northern Sweden, the embedded rust is strong here :D

06:46 <re_irc> <Christof Petig> jessebraham: I see enough independent activities towards Rust across automotive that I would say it already has gained momentum there. I can even predict a standards document published within this year.

06:52 <re_irc> <ryan-summers> That being said, standards documents aren't even necessarily required for safety critical systems. For medical devices, you just need to formally validate/qualify the language before you use it, and I've seen a lot of interest expressed by companies in this regard because of the safety that Rust offers

06:52 <re_irc> <ryan-summers> So yeah, I concur that embedded Rust is "already there". It's easier to get into the space at newer companies that don't have legacy systems, but even older companies are interested

06:53 <re_irc> <ryan-summers> It's just an investment overhead to undergo the formal validation/qualification processes, so as a result, established companies might just continue using C even though it's way more dangerous just because they don't have the time/resources to redo the validation/qualification process

06:53 <re_irc> <ryan-summers> But small, new companies have to do that work anyways, so there's no reason to not use a more modern, safer language for it

06:56 <re_irc> <ryan-summers> But in summary, there's jobs out there for sure. And any embedded Rust skills you develop also translate into general embedded skills, and there's plenty of those jobs as well

07:31 <re_irc> <korken89> ryan-summers: This is what we are doing in our company now

07:32 <re_irc> <korken89> We are talking with TUV on how to get a concept to SIL3 under the machine directive, while using Rust in our embedded and PC software

07:33 <re_irc> <korken89> So far, does not look like a big issue compared to going the C route. But we are in the early stages as well

07:33 <re_irc> <korken89> Hopefully I can give a talk on this in a year or two :D

07:51 <re_irc> <thejpster> GrantM11235: Ferrous Systems is a Rust Consultancy that does quite a bit of Embedded Rust. A bunch of us work there.

07:54 <re_irc> <thejpster> Christof Petig: Ferrocene (Ferrous Systems + AdaCore) are targeting to "bring Rust into ASIL-D level environments by the end of 2022"

08:05 <re_irc> <Ivan Levitskiy> Is there anyone here from Prague or Czech republic? Recently moved and would really like to find a local embedded community

08:31 <re_irc> <Christof Petig> thejpster: The first questions I regularly got when proposing Rust are about safety guidelines and a qualified compiler. So it looks like we will get both of it within this year. (There is also the ANSSI document if you need a guideline right now)

10:37 <re_irc> <yruama_lairba> hi, does someone already try to do a rtic task dedicated to logging throught an owned rtt_target channel?

10:40 <re_irc> <yruama_lairba> my idea is to allow to log some information without causing timing issue in interrupts because of lock

10:44 <re_irc> <yruama_lairba> at the moment i just created a enum allowing me to pass various datatype to the logging task, but i wondered if there was a better way

10:45 <re_irc> <ryan-summers> I've done it where you just enqueue the log entries into a FIFO, and then your logging task just periodically clears the FIFO out

10:46 <re_irc> <ryan-summers> Have done that successfully with a USB-serial based log backend

10:47 <re_irc> <ryan-summers> I used a heapless MPMC queue of strings, and then had the actual log::log impl serialize the log entry and put it into the queue

10:48 <re_irc> <ryan-summers> You incur a formatting overhead when you actually do the log, but it's not in a critical section, so you don't pay _too_ much

10:51 <re_irc> <yruama_lairba> formatting overhead due to write!() ? i already pay that anyway

10:52 <re_irc> <ryan-summers> Yeah, exactly

10:52 <re_irc> <ryan-summers> I just did the write! directly in log::log's "log()" function and enqueued the formatted string into a heapless::MPMC queue, then had a separate task read from the queue and actually send the logs wherever they needed to go

10:52 <re_irc> <ryan-summers> In your case, you would then send them over the owned RTT channel

10:53 <re_irc> <ryan-summers> And if you guarantee that the RTT channel is only ever written by that task and isn't shared in other contexts, no critical section is required

10:53 <re_irc> <yruama_lairba> ok, my write instead is done in the logging task

10:54 <re_irc> <ryan-summers> That's honestly just a design/implementation choice

10:54 <re_irc> <yruama_lairba> i don't know so much about heapless

10:56 <re_irc> <yruama_lairba> i guess i can continue a bit with to use my enum system and change the system when i really need something more ergonomic

10:56 <re_irc> <ryan-summers> Honestly, look up heapless. It's just a tool for data structures when you don't have a heap (e.g. Strings and Vecs), but also supports more complex things, like multi-producer-multi-consumer queues and hashmaps

10:56 <re_irc> <ryan-summers> Which is super useful to have with a fixed-size container

11:18 <re_irc> <yruama_lairba> ryan-summers: it's planned

13:17 <re_irc> <yruama_lairba> ouch, using a task to log all stuff from interrupt revelead missing priority issue.

15:20 <re_irc> <firefrommoonlight> How would y'all handle reading from multiple SPI "registers" to a buffer via DMA?

15:20 <re_irc> <firefrommoonlight> I'm suspicious the answer involves being clever with 0-padding the buffers you send

15:24 <re_irc> <ryan-summers> That _really_ depends on the SPI device you're talking to. If it allows multiple register reads per transaction by auto-incrementing an internal register pointer, it's easy

15:25 <re_irc> <ryan-summers> If you need to automate a sequence of SPI transfers, it's more complicated

15:28 <re_irc> <firefrommoonlight> Thank you

15:29 <re_irc> <firefrommoonlight> I wonder if (device dependent) you could transfer the registers to read upfront , and the receive would work as expected

15:30 <re_irc> <firefrommoonlight> Ie 2 separate DMA transfers

15:32 <re_irc> <ryan-summers> Most SPI peripherals will have some type of internal address pointer that auto-increments if you read past the end of one register, which lets you read a whole sequence of regs with a single transfer

15:33 <re_irc> <ryan-summers> But if you want to read non-sequential register addresses, it's a more complex dance of setting up multiple DMA transfers and triggers etc.

15:34 <re_irc> <firefrommoonlight> So, that begs a question... Datasheet time

15:35 <re_irc> <firefrommoonlight> Well .. they ARE sequential...

15:35 <re_irc> <firefrommoonlight> Perhaps designed with this in mind

18:09 <re_irc> <TheSirC> Quick question : is there a guide somewhere to port new microcontrollers to the toolchain?

18:09 <re_irc> I am thinking of those really inexpensive Padauk ones (https://youtu.be/VYhAGnsnO7w) that got reverse engineered (https://free-pdk.github.io/)

18:21 <re_irc> <K900> You need LLVM to support it

18:21 <re_irc> <K900> And I think Rust also requires at least 16-bit wide operations

18:41 <re_irc> <TheSirC> K900: That sounds like a nice insurmountable task. Noted!

18:43 <re_irc> <xiretza> if you're willing to get hacky, you might get away with transpiling to C and then using whatever C compiler you can get your hands on

20:30 <re_irc> <tamashi> When using a hal crate such as "stm32f1xx-hal" is it possible to gain access to the underlying peripherals registers? I need to do some manual configuration which isn't implemented by the hal, however currently it seems like my only option is to rewrite a lot of stuff without the hal as I can't seem to do both things at the same time?

20:34 <re_irc> <9names (@9names:matrix.org)> You can access the peripheral registers directly throughout the PAC. HALs will typically expose the PAC they use as "hal::PAC"

20:35 <re_irc> <9names (@9names:matrix.org)> In your instance: "stm32fxx::pac" should work

20:36 <re_irc> <9names (@9names:matrix.org)> * "stm32f1xx::pac"

20:36 <re_irc> <9names (@9names:matrix.org)> You can access the peripheral registers directly throughout the PAC. HALs will typically expose the PAC they use as "hal::pac"

20:39 <re_irc> <tamashi> Yes this is possible, but if I use a hal function that e.g. borrows a timer I cannot configure it through hal::pac later. I'm very new to rust so might be missing something.

20:39 <re_irc> <firefrommoonlight> What are you trying to do specifically?

20:39 <re_irc> <dirbaio> tamashi: you can "steal" PAC singletons from thin air with "let tim: pac::TIM1 = unsafe { core::mem::transmute(()); }"

20:40 <re_irc> <dirbaio> then use that to do raw register writes while using the HAL at the same time

20:40 <re_irc> <dirbaio> it's of course a workaround, you might break the HAL if you do register writes that the HAL doesn't expect

20:40 <re_irc> <dirbaio> but if you're careful it's fine

20:41 <re_irc> <tamashi> Currently I need to enable/disable complementary pwm channels after setting up pwm, however the hal only supports normal channels atm.

20:43 <re_irc> <tamashi> Thanks dirbaio I will give that a try. I don't mind it being a hack or temporary solution if I can avoid reimplementing the stuff that already works.

22:59 <re_irc> /// Set output polarity. See docs on the `Polarity` enum.

22:59 <re_irc> <firefrommoonlight> Here's the timer methods I've been using for that:

22:59 <re_irc> pub fn set_polarity(&mut self, channel: TimChannel, polarity: Polarity) {

22:59 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/8254b54c0f0e87982595144fa58b7736655500fe83fd40cccae519f80497c175 (21 lines)

22:59 <re_irc> match channel {

22:59 <re_irc> <firefrommoonlight> I'm posting this #1: As one way to set up a HAL API for that

22:59 <re_irc> <firefrommoonlight> (That's just one step though in setting up complementary PWM. You also have to enable combined PWM mode IIRC)

22:59 <re_irc> <firefrommoonlight> and #2: PAC direct access syntax for what you're doing

23:00 <re_irc> <firefrommoonlight> *I should probably rethink that API and documentation though

23:01 <re_irc> <firefrommoonlight> *Actually yea I think those fns do the same lolll

23:01 <re_irc> <firefrommoonlight> And you'd set one channel to "Polarity::ActiveHigh", and the other to "Polarity::ActiveLow"

23:01 <re_irc> <firefrommoonlight> STM32 timers: You can do so much with them, but they're complicated!

23:02 <re_irc> <firefrommoonlight> You could be using timers all the time and have only scratched the surface

23:02 <re_irc> <firefrommoonlight> *NVM those don't do the same thing

23:03 <re_irc> <firefrommoonlight> ccxp vs ccxnp

23:04 <re_irc> <firefrommoonlight> If that works for you, you could PR whatever HAL you're using with it

23:05 <re_irc> <firefrommoonlight> Or just use the relevant lines wrapped with something like this:

23:05 <re_irc> }

23:05 <re_irc> (*pac::TIM2::ptr()).ccer.modify...

23:05 <re_irc> unsafe {

23:05 <re_irc> <firefrommoonlight> Or use Dirbaio's syntax to get the singleton