cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<re_irc>
<@762spr:matrix.org> how would one go about defining a struct with a generic string field?
<re_irc>
I am using the embedded graphics simulator, I have a button object with optional text. The embedded graphics text object needs a &str. Obviously the struct needs an owned String type, but since the eventual target will be no_std, I would like it to be compatible with heapless::String. Can I do this with a generic trait binding? What am I looking for?
<re_irc>
<@762spr:matrix.org> in my struct I have:
<re_irc>
But I don't know how to restrict S to types that can convert to &str to be used with embedded graphics Text
<re_irc>
"text: Option<S>,"
<re_irc>
<@helloworldterabyte:matrix.org> Does anyone know why I am getting this error the trait "DMASet<StreamX<DMA1, 2>, _, stm32f4xx_hal::dma::PeripheralToMemory>" is not implemented for "stm32f4xx_hal::serial::Rx<stm32f4xx_hal::│ pac::UART4>". I can see that trait is implemented in the stm32f4 dma traits.
<re_irc>
<@helloworldterabyte:matrix.org> * HAL in the dma/traits.rs file.
<re_irc>
<@helloworldterabyte:matrix.org> * "the trait "DMASet<StreamX<DMA1, 2>, _, stm32f4xx_hal::dma::PeripheralToMemory>"is not implemented for"stm32f4xx_hal::serial::Rx<stm32f4xx_hal::│ pac::UART4>``.
<re_irc>
<@helloworldterabyte:matrix.org> * the trait "DMASet\<StreamX\<DMA1, 2>, \_, stm32f4xx\_hal::dma::PeripheralToMemory>"is not implemented for"stm32f4xx\_hal::serial::Rx\<stm32f4xx\_hal::│ pac::UART4>\".
<re_irc>
<@helloworldterabyte:matrix.org> Does anyone know why I am getting this error:
<re_irc>
the trait "DMASet\<StreamX\<DMA1, 2>, \_, stm32f4xx\_hal::dma::PeripheralToMemory>"is not implemented for"stm32f4xx\_hal::serial::Rx\<stm32f4xx\_hal::│ pac::UART4>\".
<re_irc>
I can see that trait is implemented in the stm32f4 HAL in the dma/traits.rs file.
<re_irc>
<@helloworldterabyte:matrix.org> * "DMASet<StreamX<DMA1, 2>, _, stm32f4xx_hal::dma::PeripheralToMemory> is not implemented forstm32f4xx_hal::serial::Rx<stm32f4xx_hal::pac::UART4>".
<re_irc>
<@helloworldterabyte:matrix.org> * "the trait DMASet<StreamX<DMA1, 2>, _, stm32f4xx_hal::dma::PeripheralToMemory> is not implemented for stm32f4xx_hal::serial::Rx<stm32f4xx_hal::pac::UART4>".
<re_irc>
<@helloworldterabyte:matrix.org> I got USART6 working, However it cannot find a trait for UART4
<re_irc>
<@762spr:matrix.org> IDK if this is the right way to do it or not, but I got it working:
<re_irc>
"let text = self.text.as_ref().unwrap().as_ref();"
<re_irc>
and
<re_irc>
The double .as_ref() makes me question if this is the right thing to do, BUUUUT it does wok so unless anyone has abetter suggestion I'm going to run with it 😅
<re_irc>
<@helloworldterabyte:matrix.org> Hi,
<re_irc>
I have been digging into DMA in the STM32F4 HAL crate.
<re_irc>
I noticed that the USART1,USART2,USART3,USART6 have DMASet<..> trait implemented for the pac as well as the hal.
<re_irc>
Is there a reason to do so?. I am trying to use UART4 with DMA but it is giving me a trait not implemented error. I have gotten USART6 working so far.
<re_irc>
I have been digging into DMA in the STM32F4 HAL crate.
<re_irc>
<@helloworldterabyte:matrix.org> Hi,
<re_irc>
I noticed that the USART1,USART2,USART3,USART6 have DMASet<..> trait implemented for the pac as well as the hal.
<re_irc>
Is there a reason to do so?. I am trying to use UART4 with DMA but it is giving me a trait not implemented error. I have gotten USART6 working so far.
<re_irc>
However, UART4,UART5 only has the trait implmented for the pac.
<re_irc>
Is there a reason to do so?. I am trying to use UART4 with DMA but it is giving me a trait not implemented error. I have gotten USART6 working so far.
<re_irc>
<@helloworldterabyte:matrix.org> Hi,
<re_irc>
I have been digging into DMA in the STM32F4 HAL crate.
<re_irc>
I noticed that the USART1,USART2,USART3,USART6 have DMASet<..> trait implemented for the pac as well as the hal.
<re_irc>
Is there a reason to do so?. I am trying to use UART4 with DMA but it is giving me a trait not implemented error. I have gotten USART6 working so far.
<re_irc>
<@helloworldterabyte:matrix.org> Hi,
<re_irc>
I have been digging into DMA in the STM32F4 HAL crate.
<re_irc>
I noticed that the USART1,USART2,USART3,USART6 have DMASet<..> trait implemented for the pac as well as the hal.
<re_irc>
Is there a reason to do so?. I am trying to use UART4 with DMA but it is giving me a trait not implemented error. I have gotten USART6 working so far.
<re_irc>
However, UART4,UART5 only has the trait implmented for the pac.
<re_irc>
Is there a reason to do so?. I am trying to use UART4 with DMA but it is giving me a trait not implemented error. I have gotten USART6 working so far.
<re_irc>
Is there a reason to do so?. I am trying to use UART4 with DMA but it is giving me a trait not implemented error. I have gotten USART6 working so far.
<re_irc>
<@xiretza:xiretza.xyz> it looks like none of the "Rx<UART*>" are DMA-enabled, maybe it only works for "Rx<USART*>"? or it could just be an oversight
<re_irc>
<@helloworldterabyte:matrix.org> I am looking on the reference manual and both UART seems to have DMA channels
<re_irc>
<@helloworldterabyte:matrix.org> I see, I will play around with it and try to get it to work. Thank you very much.
<re_irc>
<@helloworldterabyte:matrix.org> Ok, I got the DMA to work with UART4. All I needed to add was the DMASet<..> trait to the dma_map!(..) macro. I can open up a pull request if need be?, I know the DMA is going undergoing a fair bit of changes.
<re_irc>
<@sydbayeck:matrix.org> I didn't find any messege about "defmt 4", why this happen?
<re_irc>
<@sydbayeck:matrix.org> I'm using nix flake to manager my develop environment. Unfortunately, the latest version of "probe-run" in nix is just which i'm using. If I need a newer one, I have to pack by myself.
<re_irc>
So, I choose to use old version "defmt" ......
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> you can "cargo install probe-run"
<re_irc>
<@korken89:matrix.org> : That sounds weird, as it's something that breaks for the user it's an "public API" breaking change - even if not an Rust function or data API. Oh well.
<re_irc>
I wonder how one creates a tool that can support both v3 and v4, it seems from the comment that old support is dropped in favor of v4?
<re_irc>
<@datdenkikniet:matrix.org> it seems to be completely impossible due to the "links" that "defmt" specifies. So the only "real" way seems to be to just clone "defmt" at the respective versions and compile them into a single, stand-alone crate?
<re_irc>
<@datdenkikniet:matrix.org> I don't think there is a way to conditionally enable or disable a "links", at least...
<re_irc>
<@jamesmunns:beeper.com> I think probe run could support both even if defmt has two exclusive versions?
<re_irc>
<@jamesmunns:beeper.com> The decoder crate doesn't (or shouldn't?) use the same links trick
<re_irc>
<@datdenkikniet:matrix.org> doesn't the decoder need to link against two versions of "defmt" as well?
<re_irc>
<@datdenkikniet:matrix.org> * compile/use two versions of "defmt" somehow
<re_irc>
<@datdenkikniet:matrix.org> oh, nope apparently not. Then I misspoke
<re_irc>
<@datdenkikniet:matrix.org> Ah: can't do the "multiple versions of the same crate" with patch versions, it seems
<re_irc>
<@datdenkikniet:matrix.org> Unfortunately, still can't do the "multiple versions of the same crate" trick with patch versions, it seems
<re_irc>
<@datdenkikniet:matrix.org> if I'm not missing something, this basically means that "wire versions can break on patch releases" practically prevents a one-crate-parses-all version from being made without just cloning the project and stuffing it in the same project
<re_irc>
<@jamesmunns:beeper.com> I thought i'd done that before, but I don't have proof. There are other ways they could swing it tho.
<re_irc>
<@datdenkikniet:matrix.org> * twice and stuffing it in the same crate
<re_irc>
<@datdenkikniet:matrix.org> * change
Socker has joined #rust-embedded
Socke has quit [Ping timeout: 255 seconds]
<re_irc>
<@jannic:matrix.org> IMHO defmt-decoder should either support decoding older wire formats, or it should at least do a semver bump so users of that crate caring about compatibility can link to both versions.
<re_irc>
<@andrewgazelka:matrix.org> so I am looking through the data sheet for the STM32H742xI. Do you know if I can obtain this table data as a CSV without OCR'ing?
<re_irc>
<@andrewgazelka:matrix.org> there's a dozen or so pages in the exact same format and I want to make my own auto-generated PAC extension to "stm32h7" that includes alternate function meanings
<re_irc>
<@andrewgazelka:matrix.org> instead of just "::into_alternate<const N: u8>" I could have something like "into_tim15_ch1"
<re_irc>
<@ryan-summers:matrix.org> : If you're using the H7 HAL, you can just directly call "pa1.into_alternate()" and not specify N if you provide the pin to a HAL driver (i.e. SPI). Rust type system will figure out the correct alternate mode
<re_irc>
<@ryan-summers:matrix.org> It's pretty cool in my opinion :)
<re_irc>
<@andrewgazelka:matrix.org> yea that's nice... honestly I feel like the way pins are done should still be reworked though
<re_irc>
<@andrewgazelka:matrix.org> I hate having to look at source code to figure out which pins I need to input
<re_irc>
<@andrewgazelka:matrix.org> maybe they should be an enum or sometihng ¯_(ツ)_/¯
<re_irc>
<@ryan-summers:matrix.org> Huh? Why would you need to do that?
<re_irc>
<@ryan-summers:matrix.org> I'm assuming then you have something like a breakout board and are trying to find IO ports for your peripherals of choice then?
<re_irc>
<@ryan-summers:matrix.org> +(i.e. not fixed hardware on a PCB)
<re_irc>
<@andrewgazelka:matrix.org> for example this is an extension trait for "stm32h7xx_hal::pac::TIM15"
<re_irc>
<@ryan-summers:matrix.org> You can look at docs.rs much easier than source code
<re_irc>
<@ryan-summers:matrix.org> Also this is only really an issue when hardware layouts aren't fixed. In general, it's a HW engineers job to select the proper ports for various peripherals etc
<re_irc>
<@ryan-summers:matrix.org> Which often happens long before code exists
<re_irc>
<@ryan-summers:matrix.org> But i feel your pain if you're looking for intellisense support to tell you what pins to use in the hardware layout
<re_irc>
<@ryan-summers:matrix.org> But I agree, the docs for this are pretty awful. CubeMX has a pin planner that I've heard many people like
<re_irc>
<@admin:orangemurker.com> : Yeah. I usually plan out the pin layout in CubeMX and then just write code based on the layout I made.
<re_irc>
<@andrewgazelka:matrix.org> : yup. I generally use this. I think it would just be super cool if the HALs were. designed in a way that people didn't need to use the CubeMX
<re_irc>
<@andrewgazelka:matrix.org> I feel like it's possible
<re_irc>
<@andrewgazelka:matrix.org> *use it for most things
<re_irc>
<@ryan-summers:matrix.org> I'd be open to seeing a PR proposal. I don't personally know of a great way to do it. Enum is an interesting idea for sure
<re_irc>
<@ryan-summers:matrix.org> But I don't know how well it will work across multiple part families?
<re_irc>
<@andrewgazelka:matrix.org> yea ¯_(ツ)_/¯ i feel they might be kinda jank tbh
<re_irc>
<@andrewgazelka:matrix.org> but at least Intellisense wise they would work super well
<re_irc>
<@ryan-summers:matrix.org> Yeah, it's a cool thought
<re_irc>
<@ryan-summers:matrix.org> I;ve always hated the pin typenums as well. They've improved, but still not perfect
<re_irc>
<@firefrommoonlight:matrix.org> As a pin-typestate-hater, I must admit I like the "into_alternate()" functionality
<re_irc>
<@firefrommoonlight:matrix.org> * admit I like the "into_alternate()" API
<re_irc>
<@firefrommoonlight:matrix.org> Ie if the firmware knows what peripheral the pin is associated with, it might as well set the correct alternate. This isn't a degree of freedom; it's required if the peripheral is set up correctly
<re_irc>
<@firefrommoonlight:matrix.org> Cube sort of does that
<re_irc>
<@firefrommoonlight:matrix.org> In the HAL I use, the peripheral modules don't know anything about the pins; you have to manually choose the correct alt, which is unnecessary with that mentality
<re_irc>
<@firefrommoonlight:matrix.org> Perhaps a diff way of approaching it would be an enum you pass to the Peripheral constructor, where you choose from a list of available pins. Nice in theory (I think, without having tried it!), but would rely on correct knowledge of which pins are options, which varies significantly among variants for STM32
<re_irc>
<@firefrommoonlight:matrix.org> So, something like this:
<re_irc>
And the peripheral would configure the pin for you, or not. (IIRC dirbaio was using an API like this before. Maybe that's what Embassy does?)
<re_irc>
let i2c_baro = I2c::new(SdaPin::B8, SclPin::B9, I2cConfig::default());