| 21 Oct 2020 |
 kevlan | Yeah, it looks to me like they switched the numbers to sorta match the core type. Except on the lines like the L5 where they didn't... | 15:32:20 |
 therealprof | The L series is special anyway. With the L4 there's now at least 4 different subtypes, too. | 17:33:38 |
 @mborges:matrix.org | Talking about GPIOs, is there any way to make a helpless::Vec of GPIOs that are in the same mode ? (Output<PushPull> for example)
I didn't find a solution atm, I'm quite new to Rust also. | 17:39:24 |
 hargonix | quite often HAls provide a .downgrade() or .degrade() method on their pin implementation that lowers the pin specific type into lower types that are more generic accross all Pins | 18:29:07 |
| 22 Oct 2020 |
 ryan-summers | Note that they are "more generic", but not completely generic - sometimes downgrade is only possible to a base type for each port. A workaround to this is to construct a special Enum that contains all of the types you want in your array. Then the enum is templated across all of the types you have - it's unergonomic for a ton of pins, but works well if you have an application where the pins won't be changing. | 15:17:10 |
| @mborges:matrix.org | Mmh okay, downgrading to the port is what I was able to get. I note the Enum idea, thanks. | 15:41:56 |
 TeXitoi | @mborges:matrix.org: that's what you want to port to your hal: https://github.com/stm32-rs/stm32f1xx-hal/blob/master/src/gpio.rs#L1121-L1237 | 17:47:46 |
 cavokz | Did anybody use rtt-target on stm32l4xx_hal with succes recently? | 18:15:41 |
| cavokz | I can flash but I don't get anything after the reset. | 18:16:16 |
| cavokz | The firmware runs correctly though. | 18:17:08 |
| @mborges:matrix.org | In reply to @texitoi:matrix.org
@mborges:matrix.org: that's what you want to port to your hal: https://github.com/stm32-rs/stm32f1xx-hal/blob/master/src/gpio.rs#L1121-L1237 I started with this one then switched with the one from the F4, which seems to not downgrade to a generic enough type | 18:17:31 |
| therealprof | We take PRs. ;) | 19:08:03 |
 yatekii | In reply to @domenico.andreoli:matrix.org
Did anybody use rtt-target on stm32l4xx_hal with succes recently? yep intensively for the last 3 weeks :) | 19:12:00 |
| @mborges:matrix.org | In reply to @therealprof:matrix.org
We take PRs. ;) I'll first try to have my implementation working so I understand how everything works :p | 19:15:10 |
| cavokz | yatekii: ok, so maybe it's something with the nucleo-l432kc.. or with my code. I'll post it asa I get to my pc. | 19:55:57 |
| yatekii | cavokz: RTT is only dependant on the chip :) | 20:03:03 |
| yatekii | and every ARM can do it provided it's not in WFI. then some have troubles, some can do it and some can't do it :) | 20:03:27 |
 uep | I thought the ones having trouble just needed some extra config to not turn off the debug interface when in that state? | 20:15:57 |
| uep | ie stm32.. are there others that also have problems and that's not a fix? | 20:16:21 |
| yatekii | In reply to @uep:matrix.org
ie stm32.. are there others that also have problems and that's not a fix? some m0 ones :) almost all bigger ones have it :) | 20:29:14 |
| yatekii | lpc845 | 20:29:47 |
| uep | ok | 20:29:48 |
| yatekii | they just lack a setting at all :) | 20:30:06 |
 pinealservo | cavokz: What debugger are you using, and if you're using cargo-embed, which version of that? | 20:33:08 |
| cavokz | In reply to @uep:matrix.org
I thought the ones having trouble just needed some extra config to not turn off the debug interface when in that state? This is what I'm already doing: https://github.com/cavokz/rtic-examples/blob/0bb43ee49b38f6a083028ad8e3e46856af2a1836/rtic_v5/heartbeat_stm32l4/src/main.rs#L33 | 22:23:59 |
| cavokz | In reply to @yatekii:matrix.org
and every ARM can do it provided it's not in WFI. then some have troubles, some can do it and some can't do it :) It's the wfi(), if I use the alternatives rtt works gorgeously. | 22:25:33 |
| cavokz | Thanks, knowing that I was on fault helped me a lot (as always) 😉 | 22:27:48 |
| yatekii | great :) in rtic you can simply avoid wfi with providing an idle() :) | 22:37:09 |
| 23 Oct 2020 |
 jamesmunns | It seems like a lot of us are working on the stm32l4xx lately :) | 01:16:15 |
| cavokz | In reply to @yatekii:matrix.org
great :) in rtic you can simply avoid wfi with providing an idle() :) Indeed. I'm coming from there (https://github.com/cavokz/rtic-examples/commit/0bb43ee49b38f6a083028ad8e3e46856af2a1836#diff-368f14401a091811982bfdcaf7673f148c7c9e468359de620811bf9ac0081e06), setting DBGMCU is enough for getting cargo-flash work even with wfi() but apparently is not for keeping RTT functioning. | 05:09:00 |
