<AnkitSangwan[m]>
A while back I asked in another channel why anyone would go for an RTOS over something like Embassy and RTIC. I was told that RTOS were used in time sensitive application where harm may be caused to a human if the application is not on time. The downside of using RTOS being its complexity. As far as I understand, this is mainly a difference of how priority is handled in RTOS vs Embassy/RTIC. Is VFD (Variable Frequency Drive)
<AnkitSangwan[m]>
one of those applications which absolutely must not be programmed in Embassy/RTIC since the one I am planning would most definitely be handling 1 Phase 220V and probably even 3 Phase 440V in the future? I just want to clarify that the harm would not be directly through the electricity but may be caused due to the unexpected behaviour of the motor if the frequency is out of whack. Not to mention the potential loss of a good
<AnkitSangwan[m]>
motor in less extreme cases.
<Darius>
I think you are over thinking the terms - they are not that proscriptive
<Darius>
the question is more can _you_ guarantee the behaviour of whatever you choose to suit your safety requirements
<AnkitSangwan[m]>
Can the behaviour technically be guaranteed in Embassy/RTIC? Can it be done easily or do people have to jump hoops to do it?
<AnkitSangwan[m]>
From what I have seen, it might be possible in both Embassy/RTIC. I am not so sure after looking at some others grasping at straws wrt to priorities. So any answer from someone who knows the pitfalls is greatly appreciated.
nex8192 has quit [Ping timeout: 245 seconds]
crabbedhaloablut has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<AnkitSangwan[m]>
* From what I have seen, it might be possible in both Embassy/RTIC. I am not so sure after looking at some others grasping at straws wrt to priorities. So any answer from someone who knows the pitfalls is greatly appreciated.
<AnkitSangwan[m]>
* From what I have seen, it might be possible in both Embassy/RTIC. I am not so sure after looking at some others online struggling wrt priorities as well. So any answer from someone who knows the pitfalls is greatly appreciated.
<AnkitSangwan[m]>
* From what I have seen, it might be possible in both Embassy/RTIC. I am not so sure after looking at some others online struggling wrt priorities/timings as well. So any answer from someone who knows the pitfalls is greatly appreciated.
<AnkitSangwan[m]>
<AnkitSangwan[m]> "From what I have seen, it..." <- Edited for clarity.
<AnkitSangwan[m]>
* From what I have seen, it might be possible in both Embassy/RTIC. I am not so sure after looking at some others online in a situation similar to mine struggling wrt priorities/timings as well. So any answer from someone who knows the pitfalls is greatly appreciated.
<AnkitSangwan[m]>
* From what I have seen, it might be possible in both Embassy/RTIC. Though I am not sure after looking at some others online in a situation similar to mine struggling wrt priorities/timings as well. So any answer from someone who knows the pitfalls is greatly appreciated.
<AnkitSangwan[m]>
Also I know that the main difference between RTOS and Embassy/RTIC is the former's strict adherence to timings. I am just not sure if VFD (Variable Frequency Drive) is one of those cases where RTOS is needed as it does fall under strict time limitations guaranteed by RTOS but is also seems attainable through both Embassy/RTIC. Also the fact that the use case is not complex enough to warrant using a full blown RTOS. Programming
<AnkitSangwan[m]>
in both RTIC and Embassy is feels so satisfying that I would rather not choose anything else if possible. I just want an expert opinion.
<diondokter[m]>
<AnkitSangwan[m]> "Can the behaviour technically be..." <- What kind of guarantee do you need? Mathematical proof?
<diondokter[m]>
If you need realtimeness, then RTIC can do that for you quite easily if you're careful with your resource locking.
<diondokter[m]>
With Embassy you can create a second high-priority scheduler that might be good enough as well
M9names[m] has joined #rust-embedded
<M9names[m]>
the main difference between RTOS and RTIC is nothing at all. RTIC is an RTOS.
<M9names[m]>
but having time-slicing brings it's own difficulties when it comes to realtime guarantees.
<M9names[m]>
it doesn't provide time-slicing, which is something that some other RTOS support, so if you have multiple tasks at the same priority and one runs for too long it will block the other from running.
<M9names[m]>
there is no tooling that i'm aware of for proving that a task meets timing requirements, so you'll have to follow best practices, do your own measurements to verify this yourself.
<M9names[m]>
you would have needed to do this anyway, regardless of whether you used an RTOS or not.
LakshyaSingh[m] has joined #rust-embedded
<LakshyaSingh[m]>
Hey all is anyone familiar with how to run benchmark tests on embedded device i was trying to build with criterion but I dont think that works out
<diondokter[m]>
LakshyaSingh[m]: Probably best to just note the start time and the end time for each run, do a couple of runs and average it out
<LakshyaSingh[m]>
diondokter[m]: yeah I can work with that was just hoping if there might be some standard crate for the same
<diondokter[m]>
Not that I know of
nex8192 has joined #rust-embedded
<dirbaio[m]>
📣 `embedded-io`, `embedded-io-async`, `embedded-io-adapters` v0.5.0 released :rocket:
<lulf[m]>
I've reviewed and approved, but don't have access to merge
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
Will do in a sec
<ryan-summers[m]>
Do you need it released on crates.io as well?
<ryan-summers[m]>
Ah, lulf has permissions for that. Should be good to go :)
<lulf[m]>
dirbaio: done
<dirbaio[m]>
thanks guys ❤️
<ryan-summers[m]>
Working like a well-oiled machine ;)
<ryan-summers[m]>
Although we should get lulf merge
<ryan-summers[m]>
* lulf merge merge permissions on embedded-nal eldruin
<dirbaio[m]>
can I has too?
<ryan-summers[m]>
Ping eldruin, I don't think I have permissions to add people etc.
<lulf[m]>
Probably dirbaio need it more than me these days.
<lulf[m]>
s/./ and is making actual changes/
<dirbaio[m]>
aaand embassy updated to embedded-io :D
<dirbaio[m]>
* to embedded-io 0.5 :D
eldruin[m] has joined #rust-embedded
<eldruin[m]>
soooo.... 2 new r-e-c members?
<dirbaio[m]>
should we release embedded-hal 1.0.0-rc1?
<eldruin[m]>
do we need to do the whole open a PR to the r-e-c/meta repository dance?
<ryan-summers[m]>
Do we have a formal process written down? I actually didn't know lol. I don't know if we're as formal as the actual WG, but not a bad idea. What's our requirement on approvals etc?
<eldruin[m]>
> We need maintainers! If you're interested in updating some of the projects we care for, open an issue on this meta repo, or submit a PR on this README adding yourself to the Maintainers section.
<eldruin[m]>
dirbaio[m]: The only thing missing is the migration guide. It sounds better to have one for an rc, but it is certainly no requirement
<eldruin[m]>
uhh, it already has a lot of text
<dirbaio[m]>
yea the one in the PR looked quite complete already
<dirbaio[m]>
probably needs updating a bit
<dirbaio[m]>
do you want me to take a look?
<dirbaio[m]>
then we release rc1 with a 1st version of the migration guide
<eldruin[m]>
I think it needs a fair bit of rewrite because we keep restructuring things
<eldruin[m]>
give me until the meeting next week. If I have not done it, we release rc1 nevertheless
<dirbaio[m]>
okay!
<dirbaio[m]>
thanks 🙃
<dirbaio[m]>
* thanks for taking care of it 🙃
<eldruin[m]>
sure, it will certainly need a review/improvement round
<M9names[m]>
hmm... to implement `transaction for` e-h 1.0 i2c master would require repeated-start, yeah?
<M9names[m]>
should i just leave `transaction` as `unimplemented!()` for a chip that only allows for simple write and read?
<ryan-summers[m]>
Well, if you're the only user of the i2c-master code, yeah. If you're writing it for a HAL whether others may be using it, you need to implement it because you have no control of whether or not driver crates will call into it
<M9names[m]>
i don't get to say what the hardware supports though. transaction is a mandatory part of the I2c trait for 1.0.
<M9names[m]>
so my choices are to ignore the invariants of transaction, to implement read+write and have an `unimplemented` block in transaction, or to not implement 1.0 traits at all.
<ryan-summers[m]>
... your hardware doesn't support a repeated start?
<M9names[m]>
correct
<ryan-summers[m]>
Is that even I2C compliant then?
<M9names[m]>
¯\ (ツ)/¯
<ryan-summers[m]>
Mind if I ask the chip?
<M9names[m]>
bl602
<M9names[m]>
i could be wrong about it's abilities, but i don't think i am.
<ryan-summers[m]>
Wow, uhh, that's an interesting I2C peripheral design
<M9names[m]>
the number users of this hal, for the last couple of years, is approximately 1.
<M9names[m]>
just trying to choose the least-bad option of what is presently available.
<M9names[m]>
as the only user, i'm going to say that i'm okay with i2c support being pretty bad, and documenting that it's just not going to work with a lot of chips.
<ryan-summers[m]>
Indeed, I think you just have to make it unimplemented()
<ryan-summers[m]>
Tbf the peripheral itself seems pretty bad? Why does it even have PKTLEN as a register value?
<M9names[m]>
¯\(ツ)/¯ it's a weird chip
<ryan-summers[m]>
Alternatively, you could mimic a restart by doing a stop then `start
<ryan-summers[m]>
* Alternatively, you could mimic a restart by doing a stop then `start`. This is usually fine for most I2C devices
<ryan-summers[m]>
I've not really seen many chips that truly require a restart condition. Usually, it's a WRITE(internal addr pointer), RESTART, READ(). But if you replace the RESTART with STOP, START it still does the same thing
<M9names[m]>
i'll start with unimplemented for now, will see what i can get away with later. thanks!
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
Does e-h make any assumptions how to deal with returned errors? E.g. if you get an parity error from a UART, on chips like STM32 you have to clear a flag. How should that be done, because e-h doesn't have functions for it?
<ryan-summers[m]>
It's expected that the HAL should check and clear error flags before/after transactions
<ryan-summers[m]>
The embedded-hal API doesn't need to specify that
<ryan-summers[m]>
The invariant should be "The HAL should work regardless of previous state". There shouldn't be an expected "recovery" API in the event of faults IMO
<sourcebox[m]>
So you have to clear the error either inside the function that returns it or in any following function?
<ryan-summers[m]>
The HAL should be checking and clearing the bit wherever it exposes the UART API
<ryan-summers[m]>
Yeah, I'd say likely in following functions. Makes it more robust. You can also just clear it right after you see it
<sourcebox[m]>
I wonder if it would make sense to drop a note about that somewhere in the docs.
<ryan-summers[m]>
It would not hurt! I've fixed this in at least 1 or 2 HALs so far :)
<ryan-summers[m]>
Many HALs were written "optimistically" - in reality, hardware rarely behaves ;)
<sourcebox[m]>
Yes, that's what I'm also currently doing.
<sourcebox[m]>
For the latest e-h alpha, is there already a reference implementation that uses it? The STM32F1 HAL which is mentioned as reference still uses 0.2.
<sourcebox[m]>
Ideally, a HAL would also use timeouts for anything that could cause inifinite loops, but how to specify them?
dhylands[m] has joined #rust-embedded
<dhylands[m]>
<sourcebox[m]> "Ideally, a HAL would also use..." <- Yes - I had to recently copy/paste Xilinx i2c drivers to add timeouts to the the infinite loops. For smbus there is a max transaction timeout of 25 msec, which is what I used. (This was C code and not rust but the language is immaterial). Drivers should NEVER have infinite loops. Someday something fails and that infinite loop hangs things up.
<ryan-summers[m]>
<dhylands[m]> "Yes - I had to recently copy/..." <- Watchdogs are designed as a fail safe for this by the way. Many times embedded apps _do_ have infinite loops and just rely on the watchdog for catching truly infinite issues
<whitequark[cis]>
<ryan-summers[m]> "Watchdogs are designed as a fail..." <- if your I2C bus hangs you may not be able to recover from it other than via a board reset
<dhylands[m]>
<whitequark[cis]> "if your I2C bus hangs you may..." <- Fortunately, on our satellite we can power cycle individual peripherals. If the peripheral has a RESET line that’s hooked up that’s often sufficient to unlock the bus.
<dhylands[m]>
* the bus, and if RESET doesn’t do it (or the device has no reset) then power cycling the peripheral always seems to work.
<sourcebox[m]>
<dhylands[m]> "Fortunately, on our satellite we..." <- I have the watchdogs also running, but regard them as last resort. firefrommoonlight mentioned some code guidelines from NASA and I'm sure these don't even allow simple wait-while-busy loops.
<ryan-summers[m]>
<sourcebox[m]> "I have the watchdogs also..." <- I do safety critical medical devices, and the watchdog timer is explicitly utilized as a risk mitigator in a ton of formal analysis. Same deal with some firmware I wrote at SpaceX
<ryan-summers[m]>
ryan-summers[m]: NASA generally requires 2 fault tolerance though, whereas medical devices are 1-fault tolerance. That generally drivers how you use it as a mitigator
<dhylands[m]>
<ryan-summers[m]> "NASA generally requires 2..." <- We often have redundant sensors on our satellite so that when one fails we can switchover to another, or we’ll limp along and do best effort with the remaining sensors (once the satellite is launched there is no fixing). We also use watchdogs, but for simple things like bus lockup, it’s way faster to recover by power cycling one sensor than to reboot the system. And when
<dhylands[m]>
you’re travelling at 20,000 km/hr you want to minimize the time that you’re not in control.
<ryan-summers[m]>
dhylands[m]: SpaceX handles one of the faults by triplicating the entire rocket and voting between the 3 systems to make any decisions
<ryan-summers[m]>
ryan-summers[m]: Or at least they did back when I was there. We also had, for example, 3 traces coming from a button into the microcontroller and voted on those as well
<ryan-summers[m]>
ryan-summers[m]: Fault tolerance is a very interesting topic
<sourcebox[m]>
<ryan-summers[m]> "Fault tolerance is a very..." <- What do you typically with higher level drivers like sd card when the card doesn't repond?
<sourcebox[m]>
* you typically do with higher
<ryan-summers[m]>
sourcebox[m]: Ultimately there's only two options. Either retry, or reboot and try again later
dc740 has joined #rust-embedded
<dirbaio[m]>
<sourcebox[m]> "For the latest e-h alpha, is..." <- embassy hals (nrf, stm32, rp) have fairly complete impls of e-h 1.0 (both blocking and async). there are other HALs too, I think ESP's
<dirbaio[m]>
* think ESP's for example
dc_740 has joined #rust-embedded
<dirbaio[m]>
9names: i2c `write_read()` already needs a repeated start (it does start, write, restart, write, stop. it is NOT the same as a `write()` and then a `read()`, and many i2c chips don't work if you do that). So I find it hard to believe the hardware can't do that 😓
<dirbaio[m]>
perhaps it's just underdocumented
dc740 has quit [Read error: Connection reset by peer]
dc__740 has joined #rust-embedded
dc__740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Client Quit]
dc_740 has quit [Ping timeout: 245 seconds]
emerent has quit [Ping timeout: 245 seconds]
emerent has joined #rust-embedded
<sourcebox[m]>
dirbaio: Just another question: with the current transaction API, is there a safe way to do a bus scan, i.e. to check if a device just responds to an address?
<dirbaio[m]>
you can do a 0-len read or a 0-len write
<dirbaio[m]>
same as before
<dirbaio[m]>
* same as in 0.2
<sourcebox[m]>
dirbaio[m]: That's what I'm currently doing, wasn't sure if that always works though.
<dirbaio[m]>
can't see why it wouldn't work
<dirbaio[m]>
perhaps a HAL might be doing weird things on 0-len
<dirbaio[m]>
so maybe docs should say that it's explicitly allowed and has to work
<sourcebox[m]>
The ST HALs have a "isDeviceReady" function for that. I believe they check the NACK flag to accomplish it.
<sourcebox[m]>
But since a device can just do an ACK, and not a NACK, it should be quite similar.
<dirbaio[m]>
isn't that the same as doing a 0-len write?
<dirbaio[m]>
the 0-len write would be succesful if the device ACKs the address, or would return a NACK error otherwise
<firefrommoonligh>
Needs lots of tuning, but getting there
mgudel[m] has joined #rust-embedded
<mgudel[m]>
Hi everyone, I am looking for a low priced general purpose uC for various projects.
<mgudel[m]>
Chips like the PY32F003 or CH32V003 seem to be the cheapest one can get (~0.1€), but Rust (and LLVM for RV32EC) support isn't quite there. Everything else like stm32 series or pic32, ATsam, ATmega, ... start at a way higher pricepoint with atleast 1.3€.
<mgudel[m]>
Is there anything in between, which has decent rust support and doesn't require much peripheral components (internal oscillator, internal flash, ...)?
<firefrommoonligh>
firefrommoonligh: Watch dog timer is a step beyond this. Good practice, but not first line of defense
<firefrommoonligh>
firefrommoonligh: My rough prefs: #1: Don't block. #2: timeout with error handling. #3 Watchdog
<firefrommoonligh>
<ryan-summers[m]> "SpaceX handles one of the faults..." <- Space shuttle did this with 5x comps top
<firefrommoonligh>
firefrommoonligh: If more than a one disagreement happened, it would execute an automatic deorbit depending on details
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
<ryan-summers[m]> "Or at least they did back when I..." <- Used to do this for medical stuff too
pbsds has joined #rust-embedded
henrik_alser[m] has joined #rust-embedded
<henrik_alser[m]>
mgudel: Hi! Maybe look at the stm32g0 line? Also i’m curious what you’re making that requires such extreme levels of cost optimization?
<GrantM11235[m]>
Don't forget to filter by "In Stock" 😬
<TomB[m]>
sometimes you can find people offloading part stocks as well
<TomB[m]>
like "buy this partial reel of X for pennies on the dollar"
<TomB[m]>
* partial reel/tray of
<dirbaio[m]>
I've done some stuff with the hc32f005 which is ARM so nicely supported, and is ~$0.40
<dirbaio[m]>
works nicely
<firefrommoonligh>
So, it's 2023. Where are my H7s?
<henrik_alser[m]>
<dirbaio[m]> "I've done some stuff with the hc..." <- The stm32g030k8t6 is also in this price range, but times 2 on most specs iirc. Works nicely with embassy-stm32 etc :)
<dirbaio[m]>
if you can buy it 🙃
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
dirbaio[m]: Never had problems sourcing from JLC/LCSC :p
<henrik_alser[m]>
Lcsc has like 84k in stock :)
<JamesMunns[m]>
(for the stm32g0 line)
<JamesMunns[m]>
The STM32G030F6P6 is my go-to cheapo part
<JamesMunns[m]>
sub 0.50 in singles, down to sub-0.30 in 1k
<JamesMunns[m]>
tssop-20 isn't the best package, size wise or pin count, but usually it's okay. there's a uqfnp-28 package too for some of the g030 and g031 parts I use when I need the next bump up
<henrik_alser[m]>
(But half the flash right?)
<JamesMunns[m]>
yeah that tssop one is 32K flash, 8K RAM
<JamesMunns[m]>
which is fine for little "single job" replacements, like you can make your own 14 pin I2C port expander for less than the cost of an existing one
<JamesMunns[m]>
or like, "8 gpios plus a smartled output and an adc input" sort of glue logic lol
<dirbaio[m]>
it's crazy that you can get MCUs that cheap yep
<JamesMunns[m]>
Yeah, 64MHz + 32 bit at "a few for a dollar" pricing is pretty neat what you can do with it.
<FreeKill[m]>
<JamesMunns[m]> "or like, "8 gpios plus a..." <- I insist that we keep smartled around as an adjective
<FreeKill[m]>
Like startled
<JamesMunns[m]>
I think the STM32C0 are supposed to be even more cost optimized, but they haven't really started selling in quantity, and the places I've found them are more expensive than the g0. The g0 has been around for 5+ years or so at this point, and seemed to start showing up in stock in the last 2-3 years. I've used them for a lot of projects during the corona-chip-shortage timeline, since they were new they didn't seem to fall out of
<JamesMunns[m]>
stock like the other STM32Fx and Lx lines did when people started chip hopping to find stock
<JamesMunns[m]>
FreeKill[m]: The rust crate for ws2812b/sk6812/etc/etc is called `smartled-rs`, and it's easier to say than like "one wire programmable RGB LEDs" lol
<JamesMunns[m]>
the C0 line really looks like "what if that G0 chip only had one uart and one spi port and two timers instead of 3/2/4 of those"
<JamesMunns[m]>
just really dummy simple and small silicon footprint, I guess.
<JamesMunns[m]>
(and even less RAM and flash)
<JamesMunns[m]>
but like, might make sense if you are making a little one wire pwm fan controller or something instead of something fully digitial
<henrik_alser[m]>
…In the millionths
<JamesMunns[m]>
yeah, where saving 0.02/unit on the BOM is worth making your sw devs upset they have to fit everything in 2KiB of RAM lol
<henrik_alser[m]>
Exactly
<JamesMunns[m]>
but yeah, in the millions, pennies start mattering again :D
<henrik_alser[m]>
It’s easy to fall into this trap even when it makes no sense lol
<henrik_alser[m]>
Then spend 100€ on the enclosure
<JamesMunns[m]>
(I do more "low volume, high margin", or "low volume, proof of concept" stuff, so usually unit costs matter a lot less, so throwing $5-20 at a problem to make it go away is usually the right choice)
likewise[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
<henrik_alser[m]> "Then spend 100€ on the enclosure" <- It is amusing how injection molding seems to be the price limiter these days. Ie, for a small run, the mold will cost OOM more than the rest
ithinuel[m] has joined #rust-embedded
<ithinuel[m]>
Sean Lyons
<firefrommoonligh>
Hence the rise of alternatives; I"ve been using PolyCase's machining service to print/machine OTS enclosures with the ports/labeling etc required
<firefrommoonligh>
Costs a few hundred USD for a batch instead of a few tens of thousdans...
<firefrommoonligh>
And 3d-printed enclosures look like ass; change my mind
SeanLyons[m] has joined #rust-embedded
<SeanLyons[m]>
ithinuel: howdy!
<ithinuel[m]>
SeanLyons[m]: Oh sorry, I had my phone in my pocket.
<henrik_alser[m]>
firefrommoonlight: Yeah! I mostly make big rack units, the enclosure is usually by large the most expensive part
<mgudel[m]>
> mgudel: Hi! Maybe look at the stm32g0 line? Also i’m curious what you’re making that requires such extreme levels of cost optimization?
<mgudel[m]>
Wasn't really for the extreme cost optimization but it had me wondering, because you can apparently get a uC for like 10-20 cents but also a fully featured esp32c3 module with pcb antenna 4MB Flash etc. for just under 2€. We had multiple situations at my local makerspace where someone brought a huge amount of {insert random part here}, which would had otherwise been thrown away, and we came up with some silly way to use them.
<mgudel[m]>
Often that involves a uC of some kind, but just slapping a esp32 onto everything just felt a bit wastefull.
IlPalazzo-ojiisa has joined #rust-embedded
M9names[m]1 has joined #rust-embedded
<M9names[m]1>
<dirbaio[m]> "9names: i2c `write_read()` alrea..." <- Funny you should mention that... bl602-hal also does not support eh 02 i2c write_read, but that was a seperate trait in 0.2 so not implementing it was the obvious solution.
<M9names[m]1>
Slightly nicer to have a linker error if you try to use it anyway, but, as had been said already, any compliant i2c master should support it so I'm okay with a runtime panic
<dirbaio[m]>
there's a lot of i2c chips that require write_read
<dirbaio[m]>
you simply can't use them with the BL604? 😭
<dirbaio[m]>
that makes no sense
crabbedhaloablut has quit []
IlPalazzo-ojiisa has quit [Remote host closed the connection]
lynaghk[m] has quit [Quit: Idle timeout reached: 172800s]
<henrik_alser[m]>
<dirbaio[m]> "there's a lot of i2c chips..." <- Only like...most
dngrsspookyvisio has quit [Quit: Idle timeout reached: 172800s]
GenTooMan has quit [Ping timeout: 246 seconds]
ragarnoy[m] has joined #rust-embedded
<ragarnoy[m]>
hey, is there any reason why I often see defmt's unwrap! macro being regularly used ?
<ragarnoy[m]>
oh right thanks, i ended up on defmt_macro's doc which had no explanations so i was lost lol
<dirbaio[m]>
differences are:
<dirbaio[m]>
- it uses defmt for printing the error message which is more efficient
<dirbaio[m]>
- if you compile with `build-std-features=panic_immediate_abort` to reduce code size bloat due to `core::fmt`, you lose panic messages from the regular panic/unwrap, but not the defmt-based ones