03:37 <firefrommoonligh> Praise be the lord. I misunderstood how LipO battery connectors work and have been sending 12v to an STM32 ADC pin for a while. The MCU still works!

04:14 <GrantM11235[m]> <GrantM11235[m]> "RIP to my stm32f103, I accidenta..." <- All the cool kids are doing it

04:17 <firefrommoonligh> Hah! Wow high five

05:55 <d3zd3z[m]> Does anyone know if the UF2 bootloader on the RP2040 will allow flash to be programmed at other than the beginning of the flash? I've tried making my own uf2 file of data I'd like to load at an offset, and it doesn't seem to be showing up. Only some of these devices have SWD connected, so I'm not sure how to program these.

06:56 <M9names[m]> It should be fine. You can also use picoboot to read/write flash when you're in the bootloader, so if you've hit a uf2 limitation you should still be able to program it.

06:56 <M9names[m]> Which offset are you loading to?

14:56 <thejpster[m]> https://blog.yoshuawuyts.com/what-is-a-team/

15:10 <therealprof[m]> That doesn't really make it clearer, just explains current status... 😅

15:22 <Noah[m]> Congrats to the ferrous folks on the massive achievement for certification of ferrocene :)

15:39 <dirbaio[m]> 📣 `heapless` v0.8.0 released!

15:39 <dirbaio[m]> changelog: https://github.com/rust-embedded/heapless/blob/main/CHANGELOG.md

16:06 <vollbrecht[m]> https://ferrous-systems.com/blog/officially-qualified-ferrocene/ time to tell your boss about it 😂

16:06 <vollbrecht[m]> RIP: links to ferrous-systems gets auto moded?

16:07 <vollbrecht[m]> no it was just my client acting up..

16:35 <barafael[m]> yeah, this is pretty big. Open source, identical to mainline basically, highest ASIL and SIL, pretty cheap. Incredible achievement.

17:04 <sourcebox[m]> <vollbrecht[m]> "https://ferrous-systems.com/blog..."; <- I think I need a new boss...

17:10 <AdamHott[m]> When I read that this is the first time qualification of the Rust compiler, I knew I picked the right new programming language! Congrats ferrous!

17:24 <ilpalazzo-ojiis4> Finally!

17:25 <ilpalazzo-ojiis4> Out of curiosity… what are Rust's competitors in being ASIL-D certified?

17:25 <ilpalazzo-ojiis4> I've heard there are some C compilers, proprietary and hideously expensive. Anything else?

17:25 <d3zd3z[m]> <M9names[m]> "It should be fine. You can..." <- > <@9names:matrix.org> It should be fine. You can also use picoboot to read/write flash when you're in the bootloader, so if you've hit a uf2 limitation you should still be able to program it.

17:25 <d3zd3z[m]> I'm trying to load at 0x10200000. It just doesn't seem to change the data there.

17:25 <d3zd3z[m]> > Which offset are you loading to?

17:26 <d3zd3z[m]> I guess I should look into picoboot.

17:54 <waveguide[m]> <ilpalazzo-ojiis4> "I've heard there are some C..." <- Presumably adacores tool chain for spark

17:54 <waveguide[m]> Need to certify RTIC now:)

17:55 <waveguide[m]> * RTIC now :)

17:59 <ilpalazzo-ojiis4> RTIC?

18:00 <AdamHott[m]> <ilpalazzo-ojiis4> "Out of curiosity… what are Rust..." <- ChatGPT tells me:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fhuneKwvpaUyexlPQPwGMtPl>)

18:01 <AdamHott[m]> And please let me know everyone if pasting long texts like this in the chat is super annoying.

18:01 <AdamHott[m]> I can stop

18:19 <lkostka[m]> HI.

18:19 <lkostka[m]> I have difficulty on how to approach different board designs in code. Board a has one mcu vendor while other one has different. Different pinouns efc. Same program logic. How do you approach those problems ?

18:25 <ilpalazzo-ojiis4> So, it's Ada, C(++), and Rust. Quite a small sample!

18:27 <waveguide[m]> I wonder too how many modifications to whatever base compiler the various certified compilers built and sell...

18:27 <waveguide[m]> ferrocene being effectively rustc is pretty amazing

18:27 <waveguide[m]> * and sell have...

18:28 <waveguide[m]> wonder if I could get some extra eyes on this... https://github.com/imxrt-rs/imxrt-hal/blob/1fd948607014e246dbebf65491d6efaf69d04c86/src/common/sai.rs as its still not clear to me this is the best path

18:29 <waveguide[m]> the C equivalent driver https://mcuxpresso.nxp.com/api_doc/dev/721/group__sai.html

18:30 <waveguide[m]> funnily the mcux sdk doc examples are using deprecated calls (SAI_TxInit)

18:30 <waveguide[m]> and deprecated ideas around a Tx handle

18:31 <waveguide[m]> * funnily the mcux sdk doc examples are using deprecated calls (SAI_TxInit) and a seemingly deprecated tx handle

21:17 <barafael[m]> <lkostka[m]> "HI...." <- > <@lkostka:matrix.org> HI.

21:17 <barafael[m]> > I have difficulty on how to approach different board designs in code. Board a has one mcu vendor while other one has different. Different pinouns efc. Same program logic. How do you approach those problems ?

21:17 <barafael[m]> Put the program logic in its own crate which only depends on embedded-hal, if possible

22:17 <NaomiLiu[m]> hey all!

22:21 <NaomiLiu[m]> I guess I have a general RTIC question regarding best practices -

22:21 <NaomiLiu[m]> I have a task with a shared resource (status enum that's read by other tasks), along with some peripherals in Local that are exclusively owned

22:23 <NaomiLiu[m]> the only thing that's being locked is the status enum, but I'm controlling the peripherals during the lock in order to not be preempted

22:23 <NaomiLiu[m]> that is:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OKYUQRlZjkFKbhcYxKpimBca>)

22:24 <NaomiLiu[m]> sol_pwr itself doesn't need to be locked since only this task has access to it, but it seems like an antipattern to use a separate, but logically related lock for this

22:25 <dirbaio[m]> why do you need to avoid preemption?

22:26 <NaomiLiu[m]> hmm, I don't know honestly

22:26 <NaomiLiu[m]> the innate urge to prematurely optimize, i guess

22:27 <dirbaio[m]> :D

22:27 <dirbaio[m]> anyway, if you want to avoid ALL preemption you need to take a critical section.

22:27 <dirbaio[m]> RTIC's locks are fine-grained, they won't prevent all preemption, only preemption by other tasks that might access sol_state

22:27 <dirbaio[m]> there might be a higher-priority task that doesn't use sol_state, that can still preempt you

22:28 <NaomiLiu[m]> but control flow just continues on after the interrupt handler returns, correct?

22:28 <dirbaio[m]> yep

22:29 <dirbaio[m]> i'd say, if you have an actual reason to avoid preemption, like "if there's more than X microseconds between power disable and pwm disable, the hardware lights on fire", use a critical section

22:29 <NaomiLiu[m]> similar to syscalls

22:29 <dirbaio[m]> if you don't, just move the code outside the lock

22:30 <NaomiLiu[m]> nice, ty!

22:32 <NaomiLiu[m]> this task is pretty low priority - I'm controlling some solenoids and have a few bulky caps on which I'm limiting inrush current at power-on. The caps charge slowly through resistors until the rail voltage is steady, at which point I enable a PMOS

22:33 <NaomiLiu[m]> each solenoid has its own PMOS which are triggered thru high-priority software tasks

22:34 <NaomiLiu[m]> this is for a keyboard. a disgustingly overengineered keyboard

23:01 <d3zd3z[m]> <d3zd3z[m]> "I guess I should look into..." <- I'm not quite sure where picoboot it, google is taking me to a modchip for Nintendo. Presumably, this is a tool for talking to the booloader over USB?

23:04 <dirbaio[m]> https://github.com/raspberrypi/picotool