<dirbaio[m]>
the nRF52840-MDK USB dongle doesn't have a builtin probe
<dirbaio[m]>
you can't use probe-rs with it without extra hardware
notgull has quit [Ping timeout: 256 seconds]
<swaits[m]>
dirbaio[m]: Ahh, ok, thanks. Was going down the Embassy getting started page to play around with this stuff. Looks like I'll need to source more hardware.
<dirbaio[m]>
or the [raspberry pi debug probe](https://www.raspberrypi.com/products/debug-probe/), bit more expensive, more convenient form factor maybe, runs the same picoprobe firmware so both work equally well
<swaits[m]>
Cool. I guess these connect to the I2C or SWD pins? Thanks for the help!
<dirbaio[m]>
yes, SWD
<dirbaio[m]>
you have to connect SWDIO, SWCLK, GND from the probe to the nrf52840 dongle
HumanG33k has quit [Ping timeout: 256 seconds]
HumanG33k has joined #rust-embedded
HumanG33k has quit [Ping timeout: 268 seconds]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
stuw1 has joined #rust-embedded
HumanG33k has joined #rust-embedded
HumanG33k has quit [Excess Flood]
HumanG33k has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<cgc17[m]>
What does it mean to “degrade to a generic pin struct” when calling degrade() on a pin?
<JamesMunns[m]>
In Rust often we have a specific type for each GPIO. Which means Port 1, Pin 13, might have a specific type like `P1_13` or `Pin<P1_13>`. This means that each GPIO doesn't need to store its pin/port index, it is known at compile time.
<JamesMunns[m]>
This is neat, but it means you can't for example put three different pins in an array: They are all different types!
<JamesMunns[m]>
"degrading" or "type erasing" means you get something of a single type `Pin` or something, where the pin/port ID are stored as a variable at runtime
<JamesMunns[m]>
In the past, embedded rust used to be "compile time maximalism", so that 1) the compiler could help us catch bugs, like making it a compile time error when you try to set up a UART with a pin that doesn't support that; or 2) reduce RAM usage for storing things the compiler could keep track of.
<JamesMunns[m]>
However, over time, we've realized that it is awesome to have that in some places, and really painful and annoying to have it in other places.
<cgc17[m]>
Ahh that is very helpful. Thank you!
<cgc17[m]>
Another question... I noticed when my board starts up that the OUTCLR and OUTSET exactly offset each other. i.e., they are identical bit values (this is on nRF52833 / microbit) and that as soon as I write anything to OUTCLR, even just read it then write it to itself without changes, that then OUTSET changes to 0 without me doing so and then I can set pins from there via OUTSET.
<cgc17[m]>
It's not a problem, but being new to embedded I'm just curious why that is. Are OUTCLR and OUTSET somehow linked and initialized together and the first write to OUTCLR is intended to clear OUTSET?
<JamesMunns[m]>
Referring to the reference manual, both fields READ the current pin value
<JamesMunns[m]>
but writing 1 to CLR sets the pin low, and writing 1 to SET sets the pin high
M9names[m] has joined #rust-embedded
<M9names[m]>
Leaving work, heart
<JamesMunns[m]>
M9names[m]: Wrong chat? :D
<JamesMunns[m]>
<cgc17[m]> "Another question... I noticed..." <- > <@cgc17:matrix.org> Another question... I noticed when my board starts up that the OUTCLR and OUTSET exactly offset each other. i.e., they are identical bit values (this is on nRF52833 / microbit) and that as soon as I write anything to OUTCLR, even just read it... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dinofsTRyCQaIVyQSApVdrIr>)
<JamesMunns[m]>
whereas reading from outset and writing back to it would do nothing (you are setting all the pins that are already set)
<JamesMunns[m]>
(the bigger differences is that let _x = ...; and let _ = ...; act differently
<JamesMunns[m]>
* (the bigger differences is that let _x = ...; and let _ = ...; act differently)
<JamesMunns[m]>
the former is a "regular binding" that happens to ignore unused warnings, the latter can never be referenced. The bigger difference is that the former gets dropped at the end of scope like any other variable, while the latter is dropped immediately.
user1__ is now known as stuw1
<lch361[m]>
Thanks for the info. Didn't know about immediate drop with let _
<JamesMunns[m]>
lch361[m]: Yeah, I feel like a ton of folks get bit by that once before they learn about it.
Darius has quit [Quit: Bye]
Darius has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
Guest74 has joined #rust-embedded
Guest74 has quit [Client Quit]
Socke has quit [Ping timeout: 264 seconds]
Socke has joined #rust-embedded
notgull has joined #rust-embedded
<mameluc[m]>
James Munns: should I put an array of bytes or a struct in to groundcell? I guess just an array so I can do the validation/sync myself?
lehmrob has joined #rust-embedded
<JamesMunns[m]>
I think you could put an array, or use GroundedArrayCell
<JamesMunns[m]>
I can't offhand remember when exactly you'd prefer `Cell<[T; N]>` vs `ArrayCell<T, N>`, I think the latter has some built-in indexing methods to keep you from footgunning if not all the elements are always init'd, like if you were making a channel or allocator or something.
<JamesMunns[m]>
functionally they should both work mameluc
<JamesMunns[m]>
(like, if you had an uninit [T; N], and you wanted the 5th item, and you used slice::from_raw_parts when not all the parts are init, oops now you have UB!)
IlPalazzo-ojiisa has joined #rust-embedded
<mameluc[m]>
I think it is GroundedCell I want. I don't need "half of the data". I just don't understand how to validate the data if I get a *mut MyStruct* back
<mameluc[m]>
s/*/`*/, s/*/`/
<JamesMunns[m]>
Ah!
<mameluc[m]>
but *mut MyStruct is just a raw pointer right?
<firefrommoonligh>
I'm a fan of partial-eq for all copy-type enums too!
<firefrommoonligh>
s/partial-eq/`PartialEq`/
<firefrommoonligh>
s/partial-eq/`PartialEq`/
lehmrob has quit [Ping timeout: 276 seconds]
<cgc17[m]>
<JamesMunns[m]> "> <@cgc17:matrix.org> Another..." <- Interesting… I was thinking only those that I write a 1 to in outclr would be set low since the docs say it’s affecting individual bits. Can you help me understand that piece? It seems I should expect everything goes low but I’m missing some intuition there / thinking about this wrong.
<JamesMunns[m]>
When you read it, only the high bits will be high. If you write back the same value, you will clear all the high bits
<cgc17[m]>
Ha ohhh
<cgc17[m]>
I see now! Read a 1 and write a 1 read again would be a 0.
<cgc17[m]>
Obvious now on re-reading the docs but I wasn’t putting that together across the read/write. Thanks
<cgc17[m]>
My brain was reading the 1s in outclr as cleared, but they are high not cleared.
<JamesMunns[m]>
Yeah, you read the current state, but you write the pins you want to clear.
danielb[m] has joined #rust-embedded
<danielb[m]>
<vollbrecht[m]> "funny anecdote because of this..." <- considering that probe-rs generated logs at like 40MB/s I think this one change extends the lives of lots of SSDs now :D
user1_ has joined #rust-embedded
stuw1 has quit [Ping timeout: 246 seconds]
user1__ has joined #rust-embedded
user1_ has quit [Ping timeout: 260 seconds]
notgull has quit [Ping timeout: 268 seconds]
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
I've got an oscillator but am worried about frying it. To test a sensor I think I can power it separately using another board, then use the oscillator's logic analyzer to get readings from the SDA and SCL outputs using IC2 protocol, which can be setup in the oscillator's software. Would this setup isolate the oscillator from being fried?
<AdamHott[m]>
My mistake, I misspoke, I'm not testing the sensor, I'm testing the output from the SDA and SCL outputs from the microcontroller.
notgull has joined #rust-embedded
Lumpio[m] has joined #rust-embedded
<Lumpio[m]>
By oscillator do you mean oscilloscope?
<AdamHott[m]>
yes
<AdamHott[m]>
my mistake!
<Lumpio[m]>
I think it's pretty unlikely you would "fry" it probing your sensor circuit - the way that can happen is either if you have way too much voltage (which you don't) or you couple a high energy power supply to earth ground via the scope probe's earth clip
<AdamHott[m]>
The most power that the scope can provide is 5V, I'd only be using that for a power supply at this point
<Lumpio[m]>
The latter usually does not happen when dealing with electronics that are not power supplies because most power supplies people use with electronics are isolated from mains earth, but it's good to keep it in mind of course.
<Lumpio[m]>
Your scope provides power..? What kind of scope is it
<AdamHott[m]>
Digilent Analog Discovery 3
<Lumpio[m]>
Ooooh. Okay, I dunno about the input protection in that then. Usually when I think oscilloscope I think of like your usual desktop scope.
<AdamHott[m]>
oh right, yes I needed something compact
<Lumpio[m]>
It says the digital inputs can take up to 5V
<AdamHott[m]>
this one is pretty small
<AdamHott[m]>
thanks, I am trying to figure this out, looking forward to studying more
emerent_ has joined #rust-embedded
emerent has quit [Killed (mercury.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
WSalmon__ has joined #rust-embedded
cmaiolino2 has joined #rust-embedded
richardeoin has joined #rust-embedded
lch361[m] has quit [Ping timeout: 264 seconds]
cmaiolino has quit [Ping timeout: 264 seconds]
WSalmon has quit [Ping timeout: 264 seconds]
Lumpio[m] has quit [Ping timeout: 264 seconds]
richarde1 has quit [Ping timeout: 264 seconds]
<AdamHott[m]>
ok thanks so much!
lch361[m] has joined #rust-embedded
Lumpio[m] has joined #rust-embedded
barnabyw[m] has joined #rust-embedded
<barnabyw[m]>
read the manual and look for the absolute maximum voltage ratings of the different inputs. IIRC the AD2’s analog inputs support ±24V and the logic inputs are 5v tolerant, so I‘d guess similar or better for the AD3
notgull has quit [Ping timeout: 260 seconds]
<AdamHott[m]>
<barnabyw[m]> "read the manual and look for the..." <- ok great, found the manual. Thanks for your suggestion for the AD3, seems like a really good choice!
stuw1 has joined #rust-embedded
user1__ has quit [Ping timeout: 256 seconds]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
I've led and mentored GSoC Mentor Orgs before, including a 12-year stint as Portland State University. I'd be happy to help if folks here thought it would be cool to try Rust Embedded for GSoC.
<bartmassey[m]>
I see the general Rust GSoC thread. Is there an Embedded thread? I'm wondering whether Rust Embedded should be its own GSoC Org with its own projects? But maybe not.
Ecco_ has joined #rust-embedded
<Ecco_>
Hi there :) Dumb question: is there any Rust support for hardware AES on STM32?
<adamgreig[m]>
hi @room! meeting time again, agenda is https://hackmd.io/0rKBF7k3SCKEIFSHP4N32Q, please add anything you'd like to announce or discuss. we'll start in a few mins
<adamgreig[m]>
ok, let's start! quick announcement that svdtools 0.3.9 is now out with some improvements to the html page generation https://crates.io/crates/svdtools
<adamgreig[m]>
any other announcements?
<adamgreig[m]>
ok, next up is a couple of new embedded-hal things, let's see if there's discussion about them to be had today
<jannic[m]>
I think the choice of providing a Voltmeter/Ammeter is quite arbitrary. Sure, in the end one measures a voltage, but in most cases it's some other measurement one is interested in which only gets converted to a voltage.
crabbedhaloablut has quit []
therealprof[m] has joined #rust-embedded
<therealprof[m]>
jannic[m]: Also, one can't measure current directly, only by going through a resistor and measuring the voltage drop. The choice of resistor matters.
<adamgreig[m]>
well, there are other ways of measuring currents, but I think the point would be that the trait provider includes the conversion factor so you have something that just gives you amps
<burrbull[m]>
jannic[m]: Also voltage can be also converted by level.
<adamgreig[m]>
still, yes, I think it's hard to understand what generic driver would need the traits
<GrantM11235[m]>
Also it require some expensive math, which may also lead to rounding errors
<jannic[m]>
adamgreig[m]: That's why I wrote arbitrary - not useless. You could say the same about a trait that includes the conversion for brightness measurements or temperature measurements or whatever.
<adamgreig[m]>
yea, exactly, it's basically the same justification as a Thermometer or Lightmeter trait
<adamgreig[m]>
could feasibly be useful and you can see how you'd implement it and how it might be used - and maybe even neat to have every sensor driver implement some common trait that you can poll to get the current reading in some shared units
<jannic[m]>
I'd say that's out of scope for e-h.
<adamgreig[m]>
but it's very different to the traits we have in e-h and it's not clear amps/volts are any more special than those other types of meter?
crabbedhaloablut has joined #rust-embedded
<eldruin[m]>
it aims more to the generic app use-case than the current generic driver use-case e-h currently focus on
<GrantM11235[m]>
Any driver that *does* need a trait like this would probably be better off defining it's own trait (or just using something like `impl FnMut() -> i32`)
elpiel[m] has joined #rust-embedded
<elpiel[m]>
It makes sense to have such utilities but indeed it makes more sense to be out of e-h
<adamgreig[m]>
the original motivation of providing an e-h trait for ADCs seems more grounded, if anything, but there's so many hard decisions to make with such a thing
<GrantM11235[m]>
Lol, don't worry, it's in embedded-hal-bus, not the main crate
<adamgreig[m]>
GrantM11235: do you want to discuss now, or give some time for people to read the issue?
<GrantM11235[m]>
I'm not sure that I have anything to say that isn't in the issue, but I am happy to answer any questions
<jannic[m]>
GrantM11235: would it be possible to poison the shared bus globally (ie. without tracking which CS was the culprit?)
<GrantM11235[m]>
Yes, that is a possiblility
<jannic[m]>
That would limit the things you could do for recovery, but could make the implementation easier.
<jannic[m]>
Just always return an error after the CS failure happened.
<GrantM11235[m]>
It still wouldn't be zero cost for the vast majority of people who use infallible pins though
<adamgreig[m]>
I guess you could have two impls, one where the pins are infallible, one where they're not and it checks the poison?
<jannic[m]>
Having a single boolean flag is quite close to zero for a shared SPI bus implementation.
<GrantM11235[m]>
Yes, that is another possibility. I don't think the poison/fallible version needs to be in our crate though. It is very rare to need it and anyone who needs it can write it themself
<adamgreig[m]>
yea, it's worth remembering this is just some convenient shared bus helpers we provide in a different crate and are typically used directly by end users
<adamgreig[m]>
so it wouldn't be wild to say "they only work on infallible pins for <reason>, if you need fallible pins try <suggestion>"
<adamgreig[m]>
could be we still provide an alternative that works with fallible pins though, since someone has to
<thejpster[m]>
I think zero cost is irrelevant in any blocking implementation
<GrantM11235[m]>
adamgreig[m]: It wouldn't just be one impl though, it would be an exclusive impl, a critical-section impl, a refcell impl, etc
<adamgreig[m]>
even so
<GrantM11235[m]>
If we tell people to write their own poison impl, they can just choose whichever impl they actually need
<adamgreig[m]>
sure, but not much downside just providing them with them
<adamgreig[m]>
the shape is already known
<adamgreig[m]>
wouldn't be surprised if there's a few fallible CS pins from people using port expanders to address lots of SPI devices or something, so it might come up?
<GrantM11235[m]>
Yeah, but how many of those people actually want to do something to handle the error? I think most would be happy enough to just wrap the pins in a panicking adapter
<adamgreig[m]>
yea, probably so
<GrantM11235[m]>
I did have another idea for how to do poisoning in a zero cost way btw, but it only works if all the chipselects on a bus have the same error type
<GrantM11235[m]>
Instead of tracking the poison state with a bool, you would use a shared `Option<CsError>`. For infallible pins, this is a ZST and it is a no-op to check it
<adamgreig[m]>
cute
<GrantM11235[m]>
The problem is that DeviceError::Cs would have to be a reference to the error, which is always the size of a pointer, even if it is infallible
<GrantM11235[m]>
So DeviceError isn't zero cost anymore
<GrantM11235[m]>
Unless we require the CsError to be Copy or Clone
<adamgreig[m]>
that seems likely to be more annoying overall than requiring infallible pins :P
<GrantM11235[m]>
Should I make a PR for option 1 so that we can see how it would look?
<adamgreig[m]>
sounds good, yea. maybe including the infallible wrapper?
<jannic[m]>
If I'm not mistaken, the one case I know where a shared SPI bus is used with a fallible CS is the Neotron Pico BIOS. And it's also a case where the error types are not uniform. There is one infallible CS on a GPIO pin which selects the multiplexer chip, which in turn can set the CS pins for multiple other devices.
<jannic[m]>
(But then, this implementation also just panics in case anything goes wrong...)
<adamgreig[m]>
is the mux chip itself programmed over spi or..?
<jannic[m]>
Exactly.
<adamgreig[m]>
wow
<adamgreig[m]>
how do you tell it when to assert/deassert the cs? or is it on a separate spi bus to the shared cs pins?
<adamgreig[m]>
but, right, it seems like fallible cs might not be as rare as you'd imagine because it's going to be tempting to stick them all on an io expander when there's a lot of devices
<jannic[m]>
Using another GPIO pin to en/disable the multiplexer chip. At least if I'm not talking nonsense. thejpster should know it :-)
<adamgreig[m]>
(but even so, panicking is probably ok, it's not likely the spi will actually fail either...)
<adamgreig[m]>
* the spi to select a pin will actually
<GrantM11235[m]>
adamgreig[m]: Should that go in embedded-hal-bus? It would be nice if we had a general utilities crate to put it in
<adamgreig[m]>
I think probably better to have it in -bus than to make a new -utils / -adaptors crate?
<adamgreig[m]>
but easy to move it around while it's a PR
<GrantM11235[m]>
Maybe we should just rename e-h-bus to e-h-utils? We can decide that later though
<GrantM11235[m]>
For the record, dirbaio said he preferred option 3 when I brought his up in the chat last week
<adamgreig[m]>
well, thanks for writing up the issue to discuss it on!
<adamgreig[m]>
burrbull, did you want to talk about the svd2rust unsafe writer thing here?
<burrbull[m]>
yeah. I'd want to hear some feedback
<burrbull[m]>
now it is only non-generic part
<adamgreig[m]>
so bits() becomes unsafe always, and set() is safe but only available when writing is safe?
<burrbull[m]>
yes. before bits() safe or unsafe depending on register restriction. after bits() always unsafe, set() (or other name) present only when safe restrictions
<jannic[m]>
I think I've seen cases where there was a safe variant() in addition to an unsafe bits(). Was that just an artifact of some strange SVD? The result seems to be basically the same.
<burrbull[m]>
#788 about bits() on register. Not a field.
<burrbull[m]>
* clarification. #788 about bits() on register. Not a field.
<adamgreig[m]>
it sounds sensible to me. I think having bits() be sometimes-safe sometimes-unsafe was pretty confusing
<adamgreig[m]>
can't think of a better name than set() either but maybe someone else can
<adamgreig[m]>
* I can't think of a better name than set() either but maybe someone else can
<adamgreig[m]>
write is already taken after all
<thejpster[m]>
probably better than peek and poke
<adamgreig[m]>
maybe it should be write_raw() or something though
<jannic[m]>
<jannic[m]> "I think I've seen cases where..." <- It was this one:
<romancardenas[m]>
Looks like the compiler is printing an (spurious?) error about using a missing mul instruction for riscv32imac targets in debug mode. While it raises an error, it also produces a valid binary. In release, no error is triggered.
<romancardenas[m]>
Has anyone noticed something like this? Where should we open an issue to track this?
<M9names[m]>
I have run into it, and seem to recall seeing an upstream issue for it as well.
<thejpster[m]>
sounds like a compiler bug. You could ask in the t-compiler zulip or open a ticket in rust-lang/rust (do a search first)