<re_irc> <@lachlansneff:matrix.org> Is the VDDIO2 thing what I'm thinking it is? We need to power the MCU with 1.8V, but can power VDDIO2 with 3.3V and some pins will then output 3.3V?
<re_irc> <@adamgreig:matrix.org> yea
<Darius> most of the IOS are powered by VDDIO2 by the look of it
<Darius> a lot of micros have the CPU core powered at a lower voltage because it saves a lot of energy
<re_irc> <@adamgreig:matrix.org> afaik all stm32s have the core run at a low voltage around 1v8 or so, but most have an internal LDO to generate it from vcc, and run all the io at vcc
<Darius> yeah
<re_irc> <@adamgreig:matrix.org> but the low-voltage-only parts like this f098 expose them separately.. and some bigger pin-count parts do too so you can feed the 1v8 from an smps instead of using the internal ldo
<Darius> a lot/most have 5V tolerant IOs but that one doesn't
<re_irc> <@adamgreig:matrix.org> but then you can't so easily scale the voltage with the core speed
<re_irc> <@adamgreig:matrix.org> yea
<Darius> aimed at a different market perhas
<re_irc> <@adamgreig:matrix.org> i guess no one doing low power and 1v8 is likely to be using 5v devices
<Darius> yeah
fabic has joined #rust-embedded
<re_irc> <@therealprof:matrix.org> sourcebox:matrix.org: On thumbv6m an empty CS compiles into 12 instructions.
<re_irc> <@therealprof:matrix.org> Certainly could be better but it's not terrible.
PyroPeter has quit [Ping timeout: 268 seconds]
PyroPeter has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@mathias_koch:matrix.org> Anyone who can educate me on DWT/ITM PC sampling along the lines of https://interrupt.memfault.com/blog/profiling-firmware-on-cortex-m? I have it up and running with probe-rs, and am able to get all the PC sample traces for a short while, but then it just stops coming in, and i only receive timestamp packets from the device? The device is just running a loop with no WFI or similar, so i would expect the...
<re_irc> ... PC samples to keep coming in?
starblue has joined #rust-embedded
fabic has joined #rust-embedded
creich has quit [Ping timeout: 268 seconds]
fabic has quit [Ping timeout: 256 seconds]
emerent has quit [Ping timeout: 268 seconds]
emerent has joined #rust-embedded
creich has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
<re_irc> <@sourcebox:matrix.org> Is anyone familiar with the `embedded-time` crate?
<re_irc> <@sourcebox:matrix.org> We had this discussion yesterday with my SysTick stuff and the critical sections. Apart from this I want to use the SysTick as clock source. So I did this and it works:
<re_irc> <@sourcebox:matrix.org> ```rust
<re_irc> <@sourcebox:matrix.org> pub struct MillisClock;
<re_irc> <@sourcebox:matrix.org> impl Clock for MillisClock {
<re_irc> <@sourcebox:matrix.org> But my problem is now: how do I use this clock in a driver?
<re_irc> <@sourcebox:matrix.org> I already asked on GitHub for some hint, but without any answer:
<re_irc> <@sourcebox:matrix.org> Obviously, the compiler needs more information than I provide.
<re_irc> <@therealprof:matrix.org> You could try pinging them here. 😉 Peter
<re_irc> <@sourcebox:matrix.org> The part that does not work is try_into() with `Generic<<Clock as embedded_time::Clock>::T>`. There has to be a `Generic<u32>`.
<re_irc> <@sourcebox:matrix.org> This constraint has to go somehow into the where clause, I think.
<re_irc> <@dirbaio:matrix.org> `Milliseconds` has
<re_irc> <@dirbaio:matrix.org> ```rust
<re_irc> <@dirbaio:matrix.org> impl<SourceInt: TimeInt, DestInt: TimeInt> TryFrom<Generic<SourceInt>> for Milliseconds<DestInt> where
<re_irc> <@dirbaio:matrix.org> DestInt: TryFrom<SourceInt>,
<re_irc> <@dirbaio:matrix.org> so I guess the problem is the compiler can't prove `DestInt: TryFrom<SourceInt>`...?
<re_irc> <@dirbaio:matrix.org> maybe try adding `where u32: TryFrom<Clock::T>`
<re_irc> <@sourcebox:matrix.org> I try
<re_irc> <@sourcebox:matrix.org> That looks good even if I don't understand it.
<re_irc> <@dirbaio:matrix.org> embedded-time is quite complicated 🤣
<re_irc> <@sourcebox:matrix.org> I thought it should be the recommendation since e-h does not want to implement these things.
<re_irc> <@sourcebox:matrix.org> But thanks for the solution, that really helps.
Lumpio- has quit [Ping timeout: 264 seconds]
<re_irc> <@firefrommoonlight:matrix.org> u32 is simple!
<re_irc> <@sourcebox:matrix.org> Yes, but please forgive us long-term C++ developers that are not so used to have properties added to simple types.
Lumpio- has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> You don't need properties - I may have misjudged your use case, but for things like setting clock speeds, systick delays etc, u32s work well on their own, with the right API
<re_irc> <@firefrommoonlight:matrix.org> Where `1_u32` is associated with one tick, one Hz etc.
<re_irc> <@sourcebox:matrix.org> Yes, they do.
<re_irc> <@sourcebox:matrix.org> But embedded-time uses own types for that and they have to be converted.
<re_irc> <@firefrommoonlight:matrix.org> Where are they coming from in this case? Ie where was `embedded-time` introduced into your codebase?
<re_irc> <@sourcebox:matrix.org> embedded-time was introduced for the same reason as embedded-hal, but for dealing with clock instant and duration.
cr19011 has joined #rust-embedded
<re_irc> <@sourcebox:matrix.org> I have the SysTick providing the clock. The driver that use it should not be aware of the implementation, so there is an abstraction layer needed.
cr1901 has quit [Ping timeout: 264 seconds]
cr19011 is now known as cr1901
richbridger has joined #rust-embedded