<adamhott[m]>
Hey all, I was trying to test with a voltmeter on a board, and connected the red probe to the positive rail on the board and the black probe to the ground rail of the board. When I connected them, I got a spark and the board started to smoke. What could have happened?
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
Were your multimeter probes plugged in to the current-measuring jack on your multimeter?
<adamhott[m]>
yes
<GrantM11235[m]>
That'll do it. It is basically a short circuit
<GrantM11235[m]>
The black probe should always be plugged in to the "COM" jack. If you are measuring current, the red should be plugged in to the "10A" jack on the left, otherwise it should be plugged in to the jack on the right
<AnandGedam[m]>
Do we have rust support for Renesas RL78 mcu family
<K900>
But at least it's an ESP32 so they shouldn't be expensive to replace
<AnandGedam[m]>
I do have requirement for RL78 family of mcus
<K900>
AnandGedam[m]: Nope
<GrantM11235[m]>
Since it was a short between power and ground, it's more likely that a regulator was fried
<GrantM11235[m]>
Were you trying to measure the 5v rail or the 3.3v rail?
<adamhott[m]>
I'm not sure how much power this gives off, it's connected to a 7.4 Li-Ion Battery
<adamhott[m]>
that's why I wanted to measure
<Darius>
most regulators will thermally limit themselves
<Darius>
they are very robust these days, IMO it is likely OK
<Darius>
(linear ones)
<GrantM11235[m]>
Which points did you connect the multimeter to?
<adamhott[m]>
the points that power the servos
<adamhott[m]>
I'm trying to get the servos for this robot to work for another board
<adamhott[m]>
how do I measure the amps though?
<GrantM11235[m]>
You need to put the multimeter in series with the circuit. That means you need to disconnect a wire and connect the multimeter to both ends to connect the circuit again through the meter
sneakernet[m] has quit [Quit: Idle timeout reached: 172800s]
<GrantM11235[m]>
In order to measure the current, you need the current to flow through the meter
<GrantM11235[m]>
Pro tip, when you are done measuring current, immediately switch the probe back to the voltage/resistance jack. If you forget that it is in the current jack, you will short something out the next time you try to measure a voltage
<adamhott[m]>
Ah solid!
<adamhott[m]>
thanks so much!
BenoitLIETAER[m] has joined #rust-embedded
<BenoitLIETAER[m]>
Guys, any decent way `defmt::error!()` would be able to format/print the `e` in `Err(e) => defmt::error!("Error: {:?}", e)` ? 🤔
<BenoitLIETAER[m]>
(Of course, the trait Format is not implemented in the crate behind the error...which is dumb/strange)
<andresovela[m]>
I'm building a Rust library that uses the log crate, which I will use in a C project. What's the best way to get the library logs in the C program?
<andresovela[m]>
Is there a logger implementation that facilitates this already?
<diondokter[m]>
<andresovela[m]> "Is there a logger implementation..." <- I don't know of one. But it's likely not very difficult
<diondokter[m]>
In principle, create a logger that calls a C function with a level integer and a cstr containing the log message
<andresovela[m]>
Yeah, that's what I'd do as well
<andresovela[m]>
But it seems like it'd be a pretty standard thing to do so I thought there'd be something already
NishanthMenon has quit [Ping timeout: 255 seconds]
SanchayanMaity has quit [Ping timeout: 255 seconds]
<thejpster[m]>
Just in case you wondered what Arm code looks like on something other than a Cortex-M. Note you *have* to use assembly code to boot the thing, and there's no useful library (that I know of) to do this stuff for you.
<thejpster[m]>
Don't necessarily trust my critical-section implementations - I think they are right but they haven't been robustly tested.
phycrax[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Also I think I found a rustc bug. If I change that demo to run on armv7r-none-eabihf, I get an error about the start-up code not working because VFP2 support is missing. But it works fine in debug profile, using cargo. It doesn't work fine if I don't use cargo, or if I enable optimisations.
<JamesMunns[m]>
<thejpster[m]> "Also I think I found a rustc bug..." <- very possible, tho I wonder if it's using an optimized memcpy that's using vfp registers
andar1an[m] has joined #rust-embedded
<andar1an[m]>
When it comes to riscv for rust embedded, is there anything I can read about VLA?
<JamesMunns[m]>
VLA as in "Variable Length Arrays"?
<andar1an[m]>
Vector length agnosticism, but i think that aligns
<JamesMunns[m]>
Ah or "Vector Length Agnostic" RVV instructions?
<JamesMunns[m]>
(VLA's are a function call feature)
<andar1an[m]>
Cool, this seems like a really interesting feature
<JamesMunns[m]>
you can use inline assembly, but I don't think there's too much to help you out there, at the moment, for RVV in general, tho I'm not familiar with VLAs in RVV at all, personally. Maybe someone else here is :)
<andar1an[m]>
I'm just learning more about risc-v with lunch, this isn't urgent. Just thought this would be best place to ask haha
<andar1an[m]>
I have followed for a while but have never gotten into the nitty gritty
<andar1an[m]>
Seems there is a 1.0 ratified vector spec now
<JamesMunns[m]>
Now just got to wait 3-5 years for all the taped out designs which are already using rvv 0.7 instead to come out, so the new ones taped out using 1.0 can be ready :D
<andar1an[m]>
There is this board in the video called the canmv-k230 which seems to use it already
<andar1an[m]>
Glad I discovered this lauriewired channel on YT haha. This is informative
<JamesMunns[m]>
ah neat! I've just seen a lot of T-Head designs (C906, C910, etc) still on rvv 0.7, but I imagine they'll switch over soon
<andar1an[m]>
I dk much about assembly, but it naively reminds me abit of g-code haha
<andar1an[m]>
Seems it was invented around the same time as some earlier assembly languages haha. Makes sense maybe
<JamesMunns[m]>
Hey all, I'm going to be guest-running the meeting today, I'll use GitHub Discussions again, if you have any items to add to the agenda, please feel free to add here:
<JamesMunns[m]>
(I'll reping closer to the top of the hour, but adding it here so folks have time to add stuff)
<JamesMunns[m]>
Hey @room, it's about that time again! I'm running the meeting this week, we'll use GH Discussions, please add any agenda items above, and we'll get started in ~5m!
therealprof[m] has joined #rust-embedded
<therealprof[m]>
@jamesmunns:beeper.com Great. Just read the message from Adam asking whether I'd be able to run today. 😬
<JamesMunns[m]>
Perfectly timed :D
<JamesMunns[m]>
(realized I copy/pasted the old date, in case it was confusing anyone :D)
<JamesMunns[m]>
This is still "early early discussion" and not "made decision", but I'm open to feedback now or in the future!
<JamesMunns[m]>
I think the next step (if there isn't immediate "this is a bad idea" feedback), would be to write up a slightly more formal version of my comment there, and also reach out to the other WGs in the launching pad.
<diondokter[m]>
I read it and I think it's broadly good. And at least better that the current situation
<diondokter[m]>
s/that/than/
<JamesMunns[m]>
For context: I'm the Rust Council Representative for the Launching Pad team, which includes the currently existing WGs, and one of my main charters is "figure out what to do with the WGs" :D
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
How do you think it interacts with the launching pad team and its sub-teams? Does it give them all somewhere to end up?
<adamgreig[m]>
Ah, you have preempted my question :p
<JamesMunns[m]>
adamgreig[m]: yeah, IMO the difference was:
<JamesMunns[m]>
* ping teams are "self serve", anyone can add themselves, no responsibilities
<JamesMunns[m]>
* advocacy groups are smaller, nominated representatives, that have some ability to inform decision making, raise RFC concerns, etc.
<JamesMunns[m]>
agreed the goals are overlapping, it's possible "ping teams" become the informal precursor to being nominated to become an advocacy subteam? Unclear, but good to note for the RFC :D
<jannic[m]>
I wonder how fixed the assignment should be. A ping group today may gain responsibilities that should make it a project or a team tomorrow. And vice versa.
<JamesMunns[m]>
Any other concerns or "how would that work" questions before I move to the next target? (again, trying to gather stuff to talk about in the RFC :D)
<adamgreig[m]>
Not from me, sounds like a good plan to me!
<JamesMunns[m]>
s/target/topic/
<adamhott[m]>
It's well thought through James Munns thanks!
<diondokter[m]>
The only thing for me is that I think it'd be good for the ecosystem if we could still label things like 'embedded-hal' as 'official'
<diondokter[m]>
Not sure if that fits in the new modem
<diondokter[m]>
s/modem/model/
<adamgreig[m]>
Yea, there would have to be some thought about which crates go to the new project team and which stay in the now-not-as-official group
<diondokter[m]>
Lots of companies I speak with would not like it if the fundamental crates were unofficial, even when that's not different from what it is right now
<JamesMunns[m]>
yeah, it's possible we could promote embedded-hal to part of the rust-lang orga.
<diondokter[m]>
Optics are very important
<adamgreig[m]>
E-h is an obvious "keep official" but the architecture crates, runtime crates, tools like svd2rust, ...
<JamesMunns[m]>
that's a separate conversation, but definitely one to have.
<adamgreig[m]>
If we can't get the new project team that looks after crates to exist we probably want something else that remains at least as official as the wg
<adamgreig[m]>
Even if it's like, rename to sig and have officially associated or endorsed SIGs?
<JamesMunns[m]>
adamgreig[m]: I think that kinda puts us back where we are :D
<adamgreig[m]>
Yea :p
<JamesMunns[m]>
Another option is to form something outside the project, but maybe related, like the "safety critical consortium" the foundation put together?
<adamgreig[m]>
Depends how the project feels about a new libs subteam starting that runs a bunch of adopted crates, anyway, but it could be all part of the same discussion
<diondokter[m]>
JamesMunns[m]: Maybe? Companies don't seem to have a problem with something like tokio and that's not official either.
<diondokter[m]>
But it's got to have *some* status at least
<adamgreig[m]>
(I have to run now, thanks James Munns!)
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
just a follow-up on looking at the `panic`s in `rust-embedded/riscv`: they are basically two types of panics - ranged indices and `unimplemented` (for non-riscv targets)
<rmsyn[m]>
I proposed a some solutions for ranged indices: const_asserts, a `RangedIndex` type, and fallible functions
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
<rmsyn[m]>
I tried to get compile-time errors for the non-riscv target `unimplemented` calls, but `unimplemented` seems like the most workable solution
<JamesMunns[m]>
(reading about RangedIndex now)
<JamesMunns[m]>
I will say re: your RangedIndex stuff, there is a fair bit of friction when using types like this, there was a lot of pushback on using even like NonZero integers for embedded-hal interfaces.
takkaryx[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
(risc-v team is definitely welcome to decide otherwise! But I remember the discussion in the context of embedded-hal)
<rmsyn[m]>
is there a issue/PR where I can read up on what was decided elsewhere?
<JamesMunns[m]>
It might be in the minutes, or maybe someone else remembers? It's a vague memory for me :D
<JamesMunns[m]>
(looking)
<GrantM11235[m]>
It was the new pwm trait, NonZero was proposed for the denominator
<JamesMunns[m]>
> No consensus yet, NonZero removes a possible panic but makes the ergonomics worse
<rmsyn[m]>
re: `do_thing` and `try_do_thing` < I like this approach, too. as long as we comment that `do_thing` panics when xyz invariants are violated
<diondokter[m]>
Ah with your ranged index it clamps the values. I don't think that's a good idea because it can introduce subtle bugs in the program
<diondokter[m]>
I'd rather it panics at that point
<diondokter[m]>
Having try_ alternatives seems nice though
<rmsyn[m]>
diondokter: I agree, I'm in favor of fallible functions, too. it makes the error condition explicit, and doesn't fail silently (like you were alluding to)
<rmsyn[m]>
I was trying to explore as many options as possible
<adamhott[m]>
I've gotta run all, thanks!
<rmsyn[m]>
:wave:
<diondokter[m]>
diondokter[m]: One reason against this is that a panic is always at an exact position.
<diondokter[m]>
If the non-try function calls the try function and just unwraps it, then the meaning of it can be lost
<JamesMunns[m]>
diondokter[m]: > <@diondokter:matrix.org> One reason against this is that a panic is always at an exact position.
<JamesMunns[m]>
> If the non-try function calls the try function and just unwraps it, then the meaning of it can be lost
<JamesMunns[m]>
you can use track caller
<diondokter[m]>
But that can be solved by having one error variant for each possible error
<diondokter[m]>
JamesMunns[m]: Hmmm... not sure how that helps?
<rmsyn[m]>
> one error variant per possible error
<JamesMunns[m]>
Sorry, by "lost context" do you mean "we don't know who called the panicking function"?
<rmsyn[m]>
that tends to be more-or-less how I approach things in my own libraries
<rmsyn[m]>
or, at least one-error-variant-per-kind
<diondokter[m]>
JamesMunns[m]: No, the other way around. Where in the function was the error returned
<diondokter[m]>
* error returned?
<rmsyn[m]>
diondokter: wouldn't you want to have a debugger hooked up for that kind of context anyway?
<rmsyn[m]>
in which case you have a backtrace regardless
<rmsyn[m]>
is there a general doc for how panics are the defacto way to do error-handling in embedded?
<JamesMunns[m]>
(you can see the panic gives you the callers line, not the callee)
<GrantM11235[m]>
It really depends on how the function will be used. If it is a function where the index is dynamic and could be based on an untrusted input, then a try_ function makes a lot of sense. If it is a function that will be called with a constant/literal index 99% of the time, then I think a try_ function is unnecessary, just document when the normal function will panic.
<diondokter[m]>
JamesMunns[m]: Yeah, but I want to know about line 3, not line 15
<rmsyn[m]>
diondokter: what I'm saying is if you want that kind of context you are probably debugging something already
<JamesMunns[m]>
diondokter[m]: got it! That helps my understanding.
<JamesMunns[m]>
for what it's worth:
<diondokter[m]>
rmsyn[m]: In 90% of my embedded Rust project I have no debugger setup configured because I can usually do without. I think that's a great feature!
<JamesMunns[m]>
* I think you will have multiple opinions on "best practices"
<JamesMunns[m]>
* If we keep discussing it, you will probably continue getting new and repeated opinions
<rmsyn[m]>
what I'm asking about, is that the impression I have from the rest of Rust is to avoid panics at all costs
<diondokter[m]>
But again, it's a small issue that can be worked around with good clear errors
<JamesMunns[m]>
rmsyn[m]: I think different people have different opinions
<rmsyn[m]>
this "panic to get context" is something very divergent from the rest of rust error handling
<JamesMunns[m]>
some people want "no panics ever", some people want "clear panics for unusual stuff"
<diondokter[m]>
rmsyn[m]: Not sure what the prevalent opinion is, but e.g. embassy is full of runtime asserts
<diondokter[m]>
diondokter[m]: But only for things you *could* know ahead of time
<bartmassey[m]>
The hierarchy of failure is "doesn't fail" > "fails recoverably" > "panics" > "does the wrong thing"
<JamesMunns[m]>
I feel like the current topic will consume the next 13m, just wanted to make sure you got a chance to spotlight this.
<therealprof[m]>
s/that//
<bartmassey[m]>
Giving an index different from what was asked for will very likely make a program "do the wrong thing"
<rmsyn[m]>
even when the index asked for is garbage?
<bartmassey[m]>
Yeah, that was about it. Just wanted to let people know where we are. As the minutes say, feedback really welcome
<therealprof[m]>
rmsyn[m]: Especially when the index is garbage, you want to let the caller know about it rather than doing something unexpected.
<bartmassey[m]>
If the index asked for is garbage, your program has a bad bug. I'd personally rather have it stop right there and tell me so, rather than compound the error with potentially awful consequences.
<rmsyn[m]>
anyway, I appreciate the feedback so far. I think we are probably going to move forward with fallible functions in the form of `do_thing` and `try_do_thing`
<jannic[m]>
rmsyn[m]: If you have GPIOs 1-7 and the caller says please set GPIO 8 high, silently setting GPIO 7 to high is _most likely_ worse than just panicking.
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
index out of bounds is a programmer error, it should panic :P
<rmsyn[m]>
and what does your panic handler look like? a huge match statement of error handlers? do you print the error and blow up the runtime? do you just hand back control to the main program?
<therealprof[m]>
rmsyn[m]: Uhm, are you thinking in terms of C++ exceptions?
<bartmassey[m]>
Got to go — next meeting. See you next week! 👋
<rmsyn[m]>
I am thinking in terms of the `panic_handler` implementation you have to provide to a Rust embedded binary
<rmsyn[m]>
:wave:
<therealprof[m]>
Panics are final. Sometimes a bit less but in general there's no coming back from a panic.
<rmsyn[m]>
how do you handle that OoB index?
<diondokter[m]>
rmsyn[m]: I don't think you're meant to recover from that.
<diondokter[m]>
All I've seen people do in production is log + reboot
<GrantM11235[m]>
Fix the bug in you code that leads to an OoB index?
<therealprof[m]>
The "right" panic handler depends on the application, but they're usually rather simple.
<rmsyn[m]>
right, so now your whole binary blows up because of an off-by-one error, which can absolutely be handled by a library user that has proper error handling in place
<dirbaio[m]>
you can't "handle" a programmer error
<dirbaio[m]>
"handling" it requires fixing the bug and flashing a new firmware
<rmsyn[m]>
instead, you're not giving them that choice, you're saying "this should panic" ALWAYS
<diondokter[m]>
There was discussion last week about this too. You can't recover from e.g. setting pin 17 out of 16 to high
<JamesMunns[m]>
I'm going to wrap up the meeting here, and remind everyone to remember the CoC, assume good intent, and be polite.
<JamesMunns[m]>
Please don't get heated.
<JamesMunns[m]>
Have a good week everyone!
<JamesMunns[m]>
(you're all welcome to continue this discussion, if you'd like!)
<rmsyn[m]>
you can say, return an error "17 is out of range, valid range is 0 -> 16"
<jannic[m]>
If you calculate how strong to hit the break to get your car to stop before crashing into some obstacle, you might just clamp to max breaking power instead of panicking if your calculation tells you that you won't manage to stop before crashing anyway.
<therealprof[m]>
rmsyn[m]: Indeed, but error != panic.
<diondokter[m]>
rmsyn[m]: Well yeah, but it's a hardcoded thing. So there's not really anything you can do to recover from that
<GrantM11235[m]>
rmsyn[m]: What do you do with that information at runtime?
<rmsyn[m]>
sure, you can print the error and shut down gracefully
<jannic[m]>
s/break/brake/
<diondokter[m]>
But giving the additional try_ functions is the middle ground here. People can pick what they want for their application
<GrantM11235[m]>
rmsyn[m]: Yeah, that's what panic handlers are for
<rmsyn[m]>
an maybe even, idk log the errors to some form of persistent storage you may have setup
<dirbaio[m]>
you panic, and then the panic handler prints the error and shuts down gracefully
<rmsyn[m]>
diondokter: i agree, giving users something that looks and behaves like the rest of Rust is the goal
oneDragon[m] has quit [Quit: Idle timeout reached: 172800s]
<therealprof[m]>
dirbaio[m]: ... or starts over.
<jannic[m]>
s/break/brake/, s/breaking/braking/
<rmsyn[m]>
ok, I think we mostly agree on this. that's why I was asking about some sort of primer on using the panic handler for error handling in embedded rust
<GrantM11235[m]>
rmsyn[m]: OoB indexing causes panics in normal rust
<rmsyn[m]>
like when its safe and correct to panic, when its dangerous, when it should be avoided, etc
<therealprof[m]>
There's no hard and fast rule. Also what to do when a firmware panics depends very much on the application.
<rmsyn[m]>
then general approaches with concrete examples sounds like a good primer to me
<rmsyn[m]>
i'd be happy to work on such a document with someone more experienced with embedded dev
<therealprof[m]>
For a LED display it might be fine to render a sad face and just halt. For others you might simply start over. For applications with safety guarantees you want to fail safe.
<rmsyn[m]>
that last part is what i want to know more about
<rmsyn[m]>
what does "fail safe" look like
<therealprof[m]>
Depends...
<diondokter[m]>
That's very different for a robot arm vs a car breaking system
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok>
For example you may be doing robot arm control and need to bring it to a stop first etc.
<JamesMunns[m]>
it's also hardware dependent
<andreas[m]>
and whether your hw supports something like slightly delayed lockstep execution on two cores etc
<JamesMunns[m]>
sometimes you have electronic failsafes, so the best thing to do is reset, which might raise some "startup" pin, that automatically turns off all the FETs and hits the brakes
<GrantM11235[m]>
You might want to immediately kill power to a motor, or you might want to ramp down the power in a controlled way
<JamesMunns[m]>
(another general +1 is that there is no One Good Technique, it is very situation dependent, there are many right answers, as well as uncountable "definitely wrong" answers :) )
<diondokter[m]>
Generally I've found that in Rust you generally want to log the panic and then intentionally hardfault (on cortex-m) and then do the shutdown/recovery. Some hardware can respond to the hardfault
<rmsyn[m]>
right, and I want to be able to point to something (and self-reference): here are numerous examples of safe ways to fail, here are some definitely wrong patterns to avoid
<rmsyn[m]>
plus a guide on how to ensure code follow the safe path as often as possible
<JamesMunns[m]>
maybe I need to start up an "office hours" stream again :D
<vollbrecht[m]>
I think if safety, or 'no panic allowed' or something is mandated, than it make sense to go divide and conqure by just not running a single executable in many cases. Something like [hubris](https://github.com/oxidecomputer/hubris) where you isolate stuff from one another or you use other system of isolation like classical virtualization, so your overall system don't care if a driver panics, and just restart the driver.
<vollbrecht[m]>
But i think then you are also often in a niche case (but obvious very valid casae) and the question arises if that is necessary for the rest of the ecosystem to have this very strict sense. Strictness is often nice because it gives clear boundaries, but it also tends to be tiresome in other places if you don't really need it.
<vollbrecht[m]>
* I think if safety, or 'no panic allowed' or something is mandated, than it make sense to go divide and conqure by just not running a single executable in many cases. Something like [hubris](https://github.com/oxidecomputer/hubris) where you isolate stuff from one another, or you use other systems of isolation like classical virtualization, so your overall system don't care if a driver panics, and just restart the driver.
<vollbrecht[m]>
But i think then you are also often in a niche case (but obvious very valid casae) and the question arises if that is necessary for the rest of the ecosystem to have this very strict sense. Strictness is often nice because it gives clear boundaries, but it also tends to be tiresome in other places if you don't really need it.
<vollbrecht[m]>
also funny site note i just saw that other people even writing "papers about it" https://dl.acm.org/doi/pdf/10.1145/3623759.3624549 - titlle : "Panic Recovery in Rust-based Embedded Systems"
pronvis has joined #rust-embedded
pronvis has quit [Read error: Connection reset by peer]
Lumpio- has joined #rust-embedded
<bartmassey[m]>
That's actually a neat little paper, I think. Thanks for the link!
<bartmassey[m]>
Do we have a Matrix channel for Discovery Book / embedded beginners? If not, do we want one?