ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<re_irc> <GrantM11235> What does the embedded rust job market look like these days? I am considering a career change
<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.
<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.
ymwm__ has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
explore has joined #rust-embedded
jackneillll has joined #rust-embedded
jackneilll has quit [Ping timeout: 256 seconds]
<re_irc> <tamashi> Is it possible to change pwm period like "pwm.set_period()" after calling "pwm.split()"?
<re_irc> <korken89> corecode: Sure, if you want some inspiration you can check out smlang as well :)
<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
<re_irc> <burrbull> * independently
<re_irc> <korken89> GrantM11235: If you are looking to move to northern Sweden, the embedded rust is strong here :D
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
<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.
chordtoll has joined #rust-embedded
<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
<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
<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
<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
<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
Rahix has quit [Quit: ZNC -]
Rahix has joined #rust-embedded
<re_irc> <korken89> ryan-summers: This is what we are doing in our company now
<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
<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
<re_irc> <korken89> Hopefully I can give a talk on this in a year or two :D
<re_irc> <thejpster> GrantM11235: Ferrous Systems is a Rust Consultancy that does quite a bit of Embedded Rust. A bunch of us work there.
<re_irc> <thejpster> Christof Petig: Ferrocene (Ferrous Systems + AdaCore) are targeting to "bring Rust into ASIL-D level environments by the end of 2022"
<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
<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)
<re_irc> <yruama_lairba> hi, does someone already try to do a rtic task dedicated to logging throught an owned rtt_target channel?
<re_irc> <yruama_lairba> my idea is to allow to log some information without causing timing issue in interrupts because of lock
<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
<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
<re_irc> <ryan-summers> Have done that successfully with a USB-serial based log backend
<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
<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
starblue has quit [Ping timeout: 240 seconds]
<re_irc> <yruama_lairba> formatting overhead due to write!() ? i already pay that anyway
<re_irc> <ryan-summers> Yeah, exactly
<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
<re_irc> <ryan-summers> In your case, you would then send them over the owned RTT channel
starblue has joined #rust-embedded
<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
<re_irc> <yruama_lairba> ok, my write instead is done in the logging task
<re_irc> <ryan-summers> That's honestly just a design/implementation choice
<re_irc> <yruama_lairba> i don't know so much about heapless
<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
<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
<re_irc> <ryan-summers> Which is super useful to have with a fixed-size container
<re_irc> <yruama_lairba> ryan-summers: it's planned
ymwm__ has quit [Read error: Connection reset by peer]
ymwm has joined #rust-embedded
ymwm has quit [Max SendQ exceeded]
ymwm has joined #rust-embedded
ymwm_ has joined #rust-embedded
ymwm has quit [Ping timeout: 256 seconds]
<re_irc> <yruama_lairba> ouch, using a task to log all stuff from interrupt revelead missing priority issue.
ymwm_ has quit [Ping timeout: 240 seconds]
ymwm_ has joined #rust-embedded
ymwm_ has quit [Ping timeout: 272 seconds]
<re_irc> <firefrommoonlight> How would y'all handle reading from multiple SPI "registers" to a buffer via DMA?
<re_irc> <firefrommoonlight> I'm suspicious the answer involves being clever with 0-padding the buffers you send
<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
<re_irc> <ryan-summers> If you need to automate a sequence of SPI transfers, it's more complicated
<re_irc> <firefrommoonlight> Thank you
<re_irc> <firefrommoonlight> I wonder if (device dependent) you could transfer the registers to read upfront , and the receive would work as expected
<re_irc> <firefrommoonlight> Ie 2 separate DMA transfers
<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
<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.
<re_irc> <firefrommoonlight> So, that begs a question... Datasheet time
<re_irc> <firefrommoonlight> Well .. they ARE sequential...
<re_irc> <firefrommoonlight> Perhaps designed with this in mind
ymwm_ has joined #rust-embedded
ymwm_ has quit [Remote host closed the connection]
<re_irc> <TheSirC> Quick question : is there a guide somewhere to port new microcontrollers to the toolchain?
<re_irc> I am thinking of those really inexpensive Padauk ones ( that got reverse engineered (
<re_irc> <K900> You need LLVM to support it
<re_irc> <K900> And I think Rust also requires at least 16-bit wide operations
<re_irc> <TheSirC> K900: That sounds like a nice insurmountable task. Noted!
<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
<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?
<re_irc> <9names (> You can access the peripheral registers directly throughout the PAC. HALs will typically expose the PAC they use as "hal::PAC"
<re_irc> <9names (> In your instance: "stm32fxx::pac" should work
<re_irc> <9names (> * "stm32f1xx::pac"
<re_irc> <9names (> You can access the peripheral registers directly throughout the PAC. HALs will typically expose the PAC they use as "hal::pac"
<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.
<re_irc> <firefrommoonlight> What are you trying to do specifically?
<re_irc> <dirbaio> tamashi: you can "steal" PAC singletons from thin air with "let tim: pac::TIM1 = unsafe { core::mem::transmute(()); }"
<re_irc> <dirbaio> then use that to do raw register writes while using the HAL at the same time
<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
<re_irc> <dirbaio> but if you're careful it's fine
<re_irc> <tamashi> Currently I need to enable/disable complementary pwm channels after setting up pwm, however the hal only supports normal channels atm.
<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.
<re_irc> /// Set output polarity. See docs on the `Polarity` enum.
<re_irc> <firefrommoonlight> Here's the timer methods I've been using for that:
<re_irc> pub fn set_polarity(&mut self, channel: TimChannel, polarity: Polarity) {
<re_irc> match channel {
<re_irc> <firefrommoonlight> I'm posting this #1: As one way to set up a HAL API for that
<re_irc> <firefrommoonlight> (That's just one step though in setting up complementary PWM. You also have to enable combined PWM mode IIRC)
<re_irc> <firefrommoonlight> and #2: PAC direct access syntax for what you're doing
<re_irc> <firefrommoonlight> *I should probably rethink that API and documentation though
<re_irc> <firefrommoonlight> *Actually yea I think those fns do the same lolll
<re_irc> <firefrommoonlight> And you'd set one channel to "Polarity::ActiveHigh", and the other to "Polarity::ActiveLow"
<re_irc> <firefrommoonlight> STM32 timers: You can do so much with them, but they're complicated!
<re_irc> <firefrommoonlight> You could be using timers all the time and have only scratched the surface
<re_irc> <firefrommoonlight> *NVM those don't do the same thing
<re_irc> <firefrommoonlight> ccxp vs ccxnp
<re_irc> <firefrommoonlight> If that works for you, you could PR whatever HAL you're using with it
<re_irc> <firefrommoonlight> Or just use the relevant lines wrapped with something like this:
<re_irc> }
<re_irc> (*pac::TIM2::ptr()).ccer.modify...
<re_irc> unsafe {
<re_irc> <firefrommoonlight> Or use Dirbaio's syntax to get the singleton
Foxyloxy_ has quit [Ping timeout: 256 seconds]
Foxyloxy has joined #rust-embedded