ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
ymwm_ has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent has quit [Killed ( (Nickname regained by services))]
emerent_ is now known as emerent
ymwm_ has quit [Remote host closed the connection]
fabic_ has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
gsalazar has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
fabic_ has quit [Ping timeout: 246 seconds]
<re_irc> <gauteh> Hi, is there any reason to leave out defmt log in devices that go out in the field. There's a small chance I will be debugging them.
<re_irc> <korken89> gauteh: Leave out as in disable completely or not?
<re_irc> <korken89> Just use the "DEFMT_LOG" level when building the binary
<re_irc> <gauteh> As in unsetting DEFMT_LOG
<re_irc> <korken89> Set "DEFMT_LOG=off"
<re_irc> <gauteh> Yeah, but I mean, there's a small chance I need to attach and look at the output - so if the overhead is not too great I'd leave it on
<re_irc> <korken89> Then leave it on :)
<re_irc> <gauteh> :D great!
<re_irc> <korken89> E.g. in our products we run "DEFMT_LOG=error"
<re_irc> <korken89> To only have error logging in the field
<re_irc> <gauteh> Ok!
<re_irc> <korken89> We do however transport all defmt data to a server and decode logs from all units in the field
<re_irc> <korken89> So we never "connect to the device"
<re_irc> <gauteh> Ok
<re_irc> <korken89> Depending on what works the best for you :(
<re_irc> <korken89> * :)
<re_irc> <gauteh> I do have a similar option for low-volume logging
<re_irc> <gauteh> I have notecards attached
<re_irc> <gauteh> I log panics and some manually formatted errors, but haven't had time to set it up with defmt yet.
<re_irc> <korken89> Nice
explore has quit [Quit: Connection closed for inactivity]
fabic_ has joined #rust-embedded
<re_irc> <caspinol> As a side effect of different app i'm working on i accidentally made a LCD touch controller driver. I didn't touch driver crate anywhere so decided to release it
<re_irc> <caspinol> +find
fabic_ has quit [Ping timeout: 256 seconds]
fabic_ has joined #rust-embedded
crabbedhaloablut has quit [*.net *.split]
crabbedhaloablut has joined #rust-embedded
vancz has quit [Quit: vancz]
Foxyloxy has quit [Quit: Textual IRC Client:]
vancz has joined #rust-embedded
vancz has quit [Client Quit]
vancz has joined #rust-embedded
<re_irc> <riskable> If my code is referencing a "const" in another file in my crate and I put a little alias at the top like, "const NUM_LEDS: usize = config::LEDS_NUM_LEDS;" will that end up adding to my program size or will the compiler optimize that sort of thing away?
<re_irc> <K900> "const" values are not stored in a fixed location in the resulting binary
<re_irc> <K900> They're effectively substituted at compile time
<re_irc> <riskable> K900: Ahh, so then it shouldn't matter if I add little shortcuts like that at the top of my files then ๐Ÿ‘
<re_irc> <riskable> What if I changed the type though? "const NUM_LEDS: usize = config::LEDS_NUM_LEDS as u16;" Would that matter?
<re_irc> <riskable> I assume not
<re_irc> <riskable> What if I changed the type though? "const NUM_LEDS: u16 = config::LEDS_NUM_LEDS as u16;" Would that matter?
<re_irc> <K900> Same thing
Foxyloxy has joined #rust-embedded
fabic_ has quit [Ping timeout: 248 seconds]
fabic_ has joined #rust-embedded
cr1901_ is now known as cr1901
<re_irc> <riskable> I'm having trouble working with embedded_hal's "DynPin". I have:
<re_irc> let millivolts: u16 = pin.into()).unwrap();
<re_irc> ...and this is the error I'm getting:
<re_irc> let pin: &DynPin = analog_pins.get_pin::<Infallible>(mux).unwrap();
Amadiro has joined #rust-embedded
neceve has joined #rust-embedded
fabic_ has quit [Ping timeout: 256 seconds]
<re_irc> <riskable> Why doesn't embedded_hal just require that various HALs include a function or table or similar that lets you return a "DynPin" to its original type (say, "Pin<Gpio26, FloatingInput>") without having to know the precise type in question? I mean, it already stores a "DynPinId" which could--in theory--be used later to look up what pin it used to be. That way you could make something like an array of "DynPin"s and pull the...
<re_irc> ... exact pin out of said array like so: "my_dynpins_array[26].get_pin()". Then "get_pin()" would simply look at the pin number it had when it was created and simply return something like "return match Self::PINS { 0 => Gpio0, 1 => Gpio1, ... }"
<re_irc> <riskable> * <pin_id> { 0 => Self::PINS.0, 1 => Self::PINS.1,
<re_irc> <dirbaio> how would that work? you can't make a function that returns a random type depending on runtime
<re_irc> <dirbaio> "impl DynPin { fn get_pin(self) -> ???? }"
<re_irc> <riskable> Yeah I get it now. Sigh
<re_irc> <newam> You could use dynamic types with vtables, but that seems... wrong for GPIOs.
<re_irc> <riskable> Why give each pin a specific type then? Why not just have a Gpio struct with an "impl" that takes the pin number as the first argument?
<re_irc> <dirbaio> maybe HALs could impl TryInto to convert from degraded to concrete types
<re_irc> <dirbaio> like, you can convert from DynPin to Gpio12, but that'd fail if the DynPin is not actually gpio 12
<re_irc> <dirbaio> I don't think any HAL does
<re_irc> <dirbaio> not sure what you'd use it for
<re_irc> <dirbaio> riskable: in most chips, a given peripheral can only use a limited set of pins. For example SPI0 SCK can only be Gpio12 or Gpio16
<re_irc> <newam> riskable: You can only implement traits e.g. alternate functions for concrete types.
<re_irc> You could use const generics I suppose, but that doesn't solve the problem.
<re_irc> <dirbaio> Having a different type per pin allows checking that at compile time
<re_irc> <riskable> It's more like: I need to know what the precise pin type (e.g. "Gpio26") is ahead of time. I can't write a dynamic function that just takes a "DynPin" and passes it to "".
<re_irc> <newam> riskable: impl AdcPin for Gpio26 {}
<re_irc> no?
<re_irc> fn read<P: AdcPin>(pin: &mut P);
<re_irc> <riskable> I can write a function that takes "DynPin" but "" requires a pin-specific type and there's no way to convert it back without providing that specific type when calling "into()"
<re_irc> <dirbaio> is this for the "make a firmware portable across boards" thing?
<re_irc> <riskable> dirbaio: Yeah, haha
<re_irc> <riskable> I'm _so close_!
<re_irc> <dirbaio> make the board-specific code construct the entire adc/spi/i2c/etc peripherals, and/or export type aliases
<re_irc> <riskable> There's functions like "set_high()" and "is_low()" etc etc for "DynPin" but you can't pass a "DynPin" to ""
<re_irc> <riskable> So it works fine for digital IO operations but not analog
<re_irc> <dirbaio> //
<re_irc> //
<re_irc> pub type AdcPin1 = GPIO28;
<re_irc> pub type AdcPin2 = GPIO29;
<re_irc> <newam> riskable: What is stopping you from adding an analog pin trait?
<re_irc> <riskable> dirbaio: Right, I've already got something like that... "pub type AnalogPins = (Pin<Gpio27, Input<Floating>>, Pin<Gpio26, Input<Floating>>);"
<re_irc> <riskable> ...and that'd be in the board-specific ""
<re_irc> <dirbaio> neat
<re_irc> <riskable> Then when I want to read a specific pin I do this:
<re_irc> let millivolts: u16 = match mux {
<re_irc> 0 => analog_pins.0).unwrap(),
<re_irc> 1 => analog_pins.1).unwrap(),
<re_irc> <dirbaio> if you make the all the code use that, you should never need to degrade to DynPin
<re_irc> <riskable> ...where "mux" would represent a specific analog multiplexer (and the pin it's connected to)
<re_irc> <riskable> ...but doing it this way requires that every board-specific "" have this _super_ repetitive code that does all the ADC operations/checks and whatnot. There seems to be _literally_ no way I can write a function that iterates over a list of ADC pins and reads them
<re_irc> <riskable> +(generic)
<re_irc> <riskable> I mean, it's not a deal-breaker but it's _super_ annoying
<re_irc> <riskable> ...because if I was just implementing a keyboard matrix that strictly used digital IO I wouldn't have this problem
<re_irc> <K900> Do we have anything QMK-ish for keyboard firmware in Rust yet?
<re_irc> <K900> Specifically targeting stm32
<re_irc> <ruabmbua> Hm I think some laptop vendor has written all their FW + keyboard FW in rust
<re_irc> <ruabmbua> Or was I dreaming? ;-P
<re_irc> <newam> system76 I think?
<re_irc> <riskable> K900: Well there's some board-specific firmwares out there. Most use Keyberon: (I'm using it too)
<re_irc> <riskable> I'm trying to make a QMK-like firmware for analog keyboards (though I supposed you could use it for regular ones too) and it's turning out to be really, really freaking hard because there's no way to handle analog reads in a generic sort of way. 90% of the code ends up being board-specific.
<re_irc> <dirbaio> riskable: the HALs should support DynAdcPin for that
<re_irc> <riskable> dirbaio: No HALs have "DynAdcPin". I just checked haha
<re_irc> <riskable> The way it works in "rp2040_hal" is the ADC-specific pins end up getting a special "impl Channel<Adc> for Pin<Gpio26, FloatingInput>" (one for each Gpio<num>)
<re_irc> <riskable> ...and "" only takes pins that have that "impl"
<re_irc> <dirbaio> yeah
<re_irc> HAL could have a "struct DynAdcPin<Adc>" and "impl<Adc> Channel<Adc> for DynAdcPin<Adc>"
<re_irc> <dirbaio> so you can use either concrete or degraded types
<re_irc> <riskable> That would be fantastic
Abhishek_ has quit [Quit: Connection closed for inactivity]
<re_irc> <dirbaio> someone asked about this in the embassy channel today
<re_irc> <dirbaio> and that's what we're going to do
<re_irc> <dirbaio> the nice thing is it still prevents using non-adc-capable pins at compile time
<re_irc> <firefrommoonlight> I wonder how generisiable ADC reads are. I can't comment since I'm only familiar with STM32, and offboard (eg I2C) ADCs
<re_irc> <firefrommoonlight> For multiple channels on STM32 internal, my intuition is to use a sequence via DMA
<re_irc> <firefrommoonlight> in continuous mode, or triggered using a basic timer, depending on details
<re_irc> <firefrommoonlight> (I speculate it wouldn't translate directly to a diff platform)
<re_irc> <firefrommoonlight> Maybe circular, maybe not, depending on the specifics
<re_irc> <firefrommoonlight> Gets even more interesting if you're combining reads from multiple ADC periphs
<re_irc> <firefrommoonlight> *I need to review this stuff; ADC is one of the more complicated periphs, (probably in a tie with timers...)
<re_irc> <firefrommoonlight> There's also the injected vs direct choice
<re_irc> <firefrommoonlight> *If you're just using a single channel, things get simpler
<re_irc> <riskable> firefrommoonlight: Yeah in future boards I'm thinking about running all multiplexer channels through another multiplexer that connects to a single pin on the MCU. It will take up three more GPIO pins but it should simplify the logic quite a lot and also make it so you can have _absurd_ amounts of analog inputs if the ADC speed is fast enough ๐Ÿ‘
<re_irc> <riskable> I calculated that with an STM32F411CEU6 Black Pill you can realistically get 2560 analog inputs using the multiplexers-through-a-multiplexer setup and still come in just barely under 1ms to read them all ("((3+12)/42)*2560 == 914.29"ยตs)
<re_irc> <riskable> Of course you still need clock cycles to actually figure out if a key is pressed and whatnot so _in reality_ you're probably better off using a few less than that ๐Ÿ˜
<re_irc> <riskable> OK I'm mostly done with moving all the board-specific stuff into its own "src/bin/<board>" directory. The resulting "" is ~650 lines. About half of that is boilerplate and the other half is hardware-specific stuff. I will be able to reduce it further once I figure out how to handle displays.
neceve has quit [Ping timeout: 240 seconds]
<re_irc> <Lachlan Sneff> Just started getting compile errors for defmt. Something about an unsafe function?
<re_irc> error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
<re_irc> --> /Users/lachlansneff/.cargo/registry/src/
<re_irc> |
<re_irc> <newam> "defmt = "=0.3.0"" will fix that. Not sure about the root cause though.
<re_irc> <Lachlan Sneff> That works, thank you
<re_irc> <kelleyk> Is anyone aware of a good example of an "embedded_hal"-aware GPIO expander driver?
<re_irc> <kelleyk> I'm using an MCP23017 in my design and I've found two different drivers, but neither provides an "OutputPin"-style interface which makes them hard to use with other crates.
<re_irc> <kelleyk> Wondering if there's an option I'm missing before I go start writing something; and if I do, a good example of a driver for another chip would be great, since I'm still learning to be a Rustacean.