ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc> <Clark Kozak> Omg I just had an idea for a beginner project / tutorial
<re_irc> A calculator with a RPI pico written in Rust!
<re_irc> What do I need for that?
<re_irc> Is this possible?! 16x2 LED, pico...some other things..
<re_irc> <9names (@9names:matrix.org)> a pico, a bunch of buttons, a screen, and a lot of patience
<re_irc> <9names (@9names:matrix.org)> if you want something portable you might find it easier to pick a board that comes with a lipo connector + PMIC/charge controller, so you don't have to worry about that aspect
<re_irc> <9names (@9names:matrix.org)> though you can also leave that until later, and/or get those as an add-on for a pico
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<re_irc> <Clark Kozak> Yesss patience I have! What board will have those aspects? Might as well check those out too...may want something novice friendly
<re_irc> <Clark Kozak> What buttons do yall suggest for this? Does it matter?
<re_irc> <newam> Keyboard keys would work, but they are big. You can also buy pre-built numpads.
<re_irc> <9names (@9names:matrix.org)> Adafruit Feather RP2040 and Pimoroni Pico LiPo are two that we already have BSPs for, but there are others (waveshare RP2040-Plus for example) - I'd go for whatever is available, local and cheap, feel free to apply your own metrics here
<re_irc> <9names (@9names:matrix.org)> for a larger pin matrix more pins is important but for a calculator you don't really need too many
<re_irc> <Clark Kozak> newam: That sounds like the way to go
<re_irc> <Clark Kozak> 9names: Okay sick good to know!! Thank you :D ill get the materials and might as well start coding too. Ill keep yall posted
<Lumpio-> An actual calculator keypad is probably the most annoying thing to source as a premade part, those arr usually pretty custom
<Lumpio-> are*
<Lumpio-> Unless you cannibalize one from a cheap calculator
<Lumpio-> If you can live with random keys a premade keypad and a bunch of tact switches for the functions would work
<Lumpio-> premade numeric keypad that is, as was mentioned
<Lumpio-> Or if 4 functions are enough, a 16 key keypad
<re_irc> <9names (@9names:matrix.org)> If anyone is interested in CMSIS-DAP performance, I did a bunch of performance testing with the probes I have over the last few days.
<re_irc> <nihal.pasham> Question: the "format_args_nl" macro seems to be giving me different results when formatting unicode,
<re_irc> output when printing in a "std" env
<re_irc> ❯ cargo run --example fit ..\boards\bootloaders\rpi4\apertis\signed-rpi4-apertis.itb
<re_irc> Compiling rustBoot v0.1.0 (C:\Users\Nil\devspace\rust\projects\rustBoot\rustBoot)
<re_irc> <nihal.pasham> Any pointers on what I'm missing here would be nice.
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <nihal.pasham> `no_std impl
<re_irc> fn log(&self, record: &Record) {
<re_irc> info!("\x1b[93m[{}]\x1b[0m {}", record.level(), record.args());
<re_irc> if self.enabled(record.metadata()) {
explore has joined #rust-embedded
<re_irc> <nihal.pasham> Question: the "format_args_nl" macro seems to be giving me different results when formatting unicode,
<re_irc> output when printing in a "std" env
<re_irc> ❯ cargo run --example fit ..\boards\bootloaders\rpi4\apertis\signed-rpi4-apertis.itb
<re_irc> Compiling rustBoot v0.1.0 (C:\Users\Nil\devspace\rust\projects\rustBoot\rustBoot)
<re_irc> <Bob McWhirter> 9names: This may or may not be representative of what is in your code.
<re_irc> <Bob McWhirter> Haha
<re_irc> <James Munns> 9names: Awesome writeup, thanks for doing that!
<re_irc> <Clark Kozak> Lumpio-: Thats a good idea. Lots of those at second hand stores
tokomak has quit [Read error: Connection reset by peer]
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
<re_irc> <yruama_lairba> Hi, does somebody know crates implementing HAL for a particular MCU peripheral ?
<re_irc> <yruama_lairba> i mean in the same spirit thant this crat try to do https://docs.rs/stm32_i2s_v12x/0.2.0/stm32_i2s_v12x/index.html
<re_irc> <newam> yruama_lairba: I made this for the HDMI-CEC peripheral: https://github.com/newAM/stm32-cec
<re_irc> There are some others out there for using timers with RTIC.
<re_irc> <newam> +STM32
<re_irc> <yruama_lairba> newan, do you have a doc to see how this hal works ?
<re_irc> <newam> Just what is in the readme. It wasn't made to be comprehensive, just enough to turn my TV on and off.
<re_irc> <yruama_lairba> ok, so still experimental stuff
<re_irc> <newam> Yeah, but fully functional. I have a Nucleo H7 gaffer tapped onto the back of my TV, use it a few times a week, works great.
<re_irc> <yruama_lairba> ok, but is your code generic enougth to work with other MCU having this peripheral without rewriting your crate ? (but eventually adding stuff in the MCU hal)
<re_irc> <firefrommoonlight> https://crates.io/crates/stm32-usbd
<re_irc> <newam> Yup, it will work with other chips, just have to make sure you follow the wall-of-text safety section: https://github.com/newAM/stm32-cec/blob/main/src/lib.rs#L245-L249
<re_irc> /// 1. The HDMI CEC source clock must be enabled.
<re_irc> /// 2. The HDMI CEC pin must be configured.
<re_irc> /// 3. The HDMI CEC peripheral should be reset before.
<re_irc> <firefrommoonlight> Tehre's a CAN one too
<re_irc> <newam> Oh, right, forgot about CAN entirely.
<re_irc> <dirbaio> hand-written PAC, huh
<re_irc> <yruama_lairba> ok, i'd like to see the MCU hal implenting the necessary stuff to make it work
<re_irc> <newam> yruama_lairba: You might be thinking more along the lines of stm32-metapac then?
<re_irc> <yruama_lairba> stm32-metapac ?
<re_irc> <newam> dirbaio: I need some mindless data entry to do while I am in boring meetings at work 😆
<re_irc> <yruama_lairba> i'm try to look how those kind of stuff are done because i'm planning to rewriting stm32_i2s.
<re_irc> <newam> Check out embassy: https://github.com/embassy-rs/embassy
<re_irc> and as someone once put it "the STM32 spreadsheet of doom": https://docs.google.com/spreadsheets/d/1-R-AjYrMLL2_623G-AFN2A9THMf8FFMpFD4Kq-owPmI/edit#gid=1972450814
<re_irc> <yruama_lairba> stm32 register version ??? I bookmark this stuff
<re_irc> <newam> yeah, the peripheral IP changes between chips, that's part of the reason writing an abstract STM32 driver is difficult.
<re_irc> <yruama_lairba> oops don't understand well this document
<re_irc> <yruama_lairba> to go bakc to stm32_i2s, there is a weird pattern to use it, you first build a HAL with MCU HAL an then you wrap this HAL into a stm32_i2s HAL
<re_irc> <yruama_lairba> i just wondered if it's a common pattern or if it is weirdly done
<re_irc> <dirbaio> it's a "weird" thing to share the same driver between HALs for different families (like F1 vs F4)
<re_irc> <dirbaio> stm32_i2s has
<re_irc> - an Instance trait that contains all the MCU-specific stuff https://github.com/samcrow/stm32_i2s/blob/master/src/lib.rs#L66
<re_irc> - the Driver struct, takes an Instance and then exposes all the functionality https://github.com/samcrow/stm32_i2s/blob/master/src/lib.rs#L104
<re_irc> <dirbaio> and then the HALs expose one struct implementing the Instance trait
<re_irc> <ted> are there good resources for how to write board support crates? I believe most of the stuff on this board has HAL crates but not sure where to go from here
<re_irc> <dirbaio> so you have to wrap the HAL struct into the Driver struct
<re_irc> <dirbaio> ideally you'd use the PAC singleton directly, like other in-HAL drivers
<re_irc> <dirbaio> but it's not possible because of the orphan rule: the HAL can't impl Instance (foreign trait) for the PAC struct (foreign struct)
<re_irc> <yruama_lairba> dirbaio, this crate try to exploit the fact that many chip use the same IP
<re_irc> <dirbaio> I know
<re_irc> <yruama_lairba> sorry, what you call 'HAL' and what you call 'Driver' ?
<re_irc> <dirbaio> HAL = the hal crate, for example "stm32f4xx-hal "
<re_irc> <yruama_lairba> the thing i find weird is the fact you seems to wrap a Hal driver into the stm32_i2s driver.
<re_irc> <yruama_lairba> i think thing would be less confusing if you just wrap the PAC struct
<re_irc> <yruama_lairba> i'm looking how things are done for https://docs.rs/stm32-usbd/0.6.0/stm32_usbd/bus/struct.UsbBus.html
<re_irc> <dirbaio> I explained above the reason for the double wrapping
<re_irc> <yruama_lairba> dirbaio, the double wrapping is because MCU hal can't implement a foreign trait on a pac peripheral
<re_irc> <yruama_lairba> that mean you could just wrap the pac peripheral directly to address this
<re_irc> <yruama_lairba> but this is not the practice
<re_irc> <dirbaio> you can't do it with the PAC peripheral becuase there are many PACs, each has a different type
<re_irc> <yruama_lairba> in fact, stm_i2s and stm32_usbd does the same pattern, but stm32_usb better named their stuff so it's less confusing
<re_irc> <yruama_lairba> thanks, missed this important detail.
<re_irc> <yruama_lairba> so, to fix the "consing pattern" i just need to change trait name and doc :p
<re_irc> <dirbaio> I think there's no way to share drivers across hals AND avoid the double wrapping
<re_irc> <yruama_lairba> * "confusing
<re_irc> <yruama_lairba> dirbaio, i'm ok with wrapping as long the inner and the outer thing have different and clear concept associte with them
<re_irc> <yruama_lairba> however, i start to wonder if it's ok to have a driver that just reexpose the peripheral detail in better way ( i actually need that)
<re_irc> <almindor> is it possible to ducument the meaning of the internal value for an enum? e.g. Variant(bool) /// document the meaninig of the bool itself
<re_irc> <dirbaio> enum Foo {
<re_irc> Variant(
<re_irc> /// blah
<re_irc> bool
<re_irc> <firefrommoonlight> That would be nice!
<re_irc> <firefrommoonlight> I just use comments, but it's a bit awk!
<re_irc> <firefrommoonlight> Or sometimes put it in the variant's doc comment
<re_irc> enum Foo {
<re_irc> <firefrommoonlight> AFAIK, this is the best we've got:
<re_irc> Variant(
<re_irc> bool
<re_irc> <firefrommoonlight> AFAIK, this is the best we've got:
<re_irc> /// Stores wheather it rained today
<re_irc> Variant(
<re_irc> enum Foo {
<re_irc> <firefrommoonlight> * weather
<re_irc> <newam> is there a crate out there to concat const byte arrays at compile time on stable?
<re_irc> const MOO: [u8; 2] = [1, 2];
<re_irc> const QUACK: [u8; 1] = [3];
<re_irc> e.g.
<re_irc> <newam> is there a crate out there to concat const byte arrays at compile time on stable?
<re_irc> e.g.
<re_irc> const QUACK: [u8; 1] = [3];
<re_irc> const MOO: [u8; 2] = [1, 2];