00:01 <rmsyn[m]> e.g. 8-bit microcontrollers need 8 registers for the 64-bit interface, and only one for the 8-bit interface. So, they could override the default 8-bit interface to avoid temporarily converting to-from a 64-bit value

00:02 <JamesMunns[m]1> This would mean that ever driver crate (e.g. a serial port that needs some delay) would need to have implementations for all of Timer8..Timer64

00:03 <rmsyn[m]> right, which is why a single trait with all the different bit width interfaces might be better

00:03 <JamesMunns[m]1> as mentioned before, I'd definitely suggest writing a little example code from the perspective of the:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/UezaShEugTFjGYliosjXuQps>)

00:04 <JamesMunns[m]1> I'm not sure if I could imagine how you would make that all work, and allow that level of flexibility, but some code would make it much easier for me to understand!

00:05 <JamesMunns[m]1> like, it can be fake code you can run in the playground, using std Instant/Duration under the hood for demonstration, but just defining all the pieces and wiring it up end-to-end is extremely useful for discussion, and to make sure we're all discussing the same concrete things!

00:06 <rmsyn[m]> that makes sense, just wanted to float the idea before digging into actual implementation. I'll look back at old `embedded-hal` versions for whats is generally expected from the trait

00:07 <JamesMunns[m]1> It's a tricky topic, that's why I suggest sketching it out first. It's very easy to suggest things that work well from one perspective, but end up being hard to use practically!

00:07 <JamesMunns[m]1> (or make one aspect very easy, and other aspects much harder/impossible)

00:09 <rmsyn[m]> right, I generally have the same experience writing library code. Unit tests are great for exercising the API (basically what you're suggesting). will see what comes together, and post back with results.

00:12 <JamesMunns[m]1> https://github.com/rust-embedded/embedded-hal/issues/359 is the best overall discussion I'm aware of right now, it's still sort of an open question of what API is possible! It could be something like embassy-time, which is generally a lot like std's Instant and Duration (measured since time of boot roughly), or something else. It would be good to note if you're proposing something other than that.

00:13 <JamesMunns[m]1> rmsyn[m]: oh, and specifically on this, I even think having the body of the functions stubbed out with `todo!()` is totally fine for demonstrating that the API compiles (e.g. a compile-test vs a unit-test), as long as you mention roughly how it would be done in practice. This can help make iteration speed easier for you!

00:19 <rmsyn[m]> sure, I think this might take a bit of review over the differences among the current available options/approaches. looks like there are: `embedded-time`, `fugit`, (others?)

00:19 <rmsyn[m]> `embassy-time` ...

00:25 <JamesMunns[m]1> groundhog

00:25 <JamesMunns[m]1> (similar API, but explicitly a rolling timer, vs embassy which is assumed to be "infinite range")

00:27 <rmsyn[m]> embassy also uses a `u64` for its `Duration` type, no generics

00:27 <rmsyn[m]> how does it achieve "infinite range" with a `u64`?

00:28 <JamesMunns[m]1> Even at microsecond precision, that's room for like 500 years

00:29 <rmsyn[m]> ok, so practically infinite, not actually (as in, no practical use-case cares)

00:29 <JamesMunns[m]1> oh sorry, at NANOSECOND precision it's 500 years, at microsecond precision it's 500k years

00:31 <JamesMunns[m]1> for reference, at 1mhz, a u32 rolls over after 71mins. This is probably good enough for an API that uses that for like single delays or so (if it is documented), but probably not acceptable for an API that tracks total time since boot!

00:32 <rmsyn[m]> ok, was also thinking about edge-cases like users measuring events in pico- and femto-seconds. but those use-cases probably are tracking events for very long

00:32 <rmsyn[m]> it also is inefficient for smaller microcontrollers

00:33 <JamesMunns[m]1> IMO we will likely need to support at least down to microsecond precision (nanos would be nice), and maybe an hour for "short lived" timers/ranges, and probably 1-10y for "time since boot" ranges

00:34 <rmsyn[m]> one of the biggest things that keeps popping up is to also avoid epoch rollover/overflow events

00:35 <JamesMunns[m]1> yep. I used groundhog effectively, but I dunno if I would propose it as an e-hal option

00:35 <JamesMunns[m]1> it was pretty much "promise to hold it right", e.g. if you had a 1mhz timer, just know that you should never try to measure a time delta of >71m

00:36 <JamesMunns[m]1> but for example, embassy-time explicitly supports much smaller timers, like 16-bit ones, but it requires an interrupt every 1/2 period to accurately track rollovers + timer deltas.

00:37 <JamesMunns[m]1> so at 1mhz + 32 bit hardware timer, it only fires that interrupt every ~35m, but at 1mhz + 16-bit timer, it has to fire every 35ms.

00:38 <JamesMunns[m]1> er, 32.5ms, but you get the idea

06:32 <RobertJrdens[m]> <cr1901> "RobertJrdens[m]: https://docs.rs..." <- Only for the special case of an HBF-FIR.

10:18 <therealprof[m]> I'm back from vacation. I noticed a few pings but I only briefly skimmed the backlog. Let me know if there's still something that still requires my attention.

10:39 <David[m]12> <firefrommoonligh> "Use macros if the syntax becomes..." <- James Munns: sure, let me know if you have any ideas

10:39 <David[m]12> David[m]12: I whipped up something quick by using `UnsafeCell<Option<T>>`, will send it over to see what you think a lil later

18:53 <pkoevesdi[m]> Hey, maybe someone here can help me with this: I have a working elf file ("external loader" from the STM world) and want to make an "flash algorithm" (rust world) out of it to flash rust programs into external memory with probe-rs / cargo. I get the error 'Failed to find 'FlashDevice' symbol in ELF file' and there I'm stuck. More details here: https://users.rust-lang.org/t/create-own-flash-algorithm-from-binary/108885/6 ?

19:02 <danielb[m]> target-gen can eat the keil FLM loaders but I guess the STLDR ones are just different enough by not including the FlashDevice info

19:03 <danielb[m]> can you share the source of your loader?

19:28 <pkoevesdi[m]> As a matter of fact, Idin't have the source (yet). I'll ask the programmer.

19:28 <pkoevesdi[m]> s/Idin/I don/

19:29 <pkoevesdi[m]> It's from here: https://github.com/cturvey/stm32extldr/tree/main/h7_is25lp128

19:30 <danielb[m]> I doubt he'll give it up if he's looking for $80+ donations

19:30 <danielb[m]> I meant the source that you started working on and isn't working properly

19:30 <pkoevesdi[m]> There are some other folders that contain the flm files.

19:31 <pkoevesdi[m]> Yes, I have made some attempts directly in rust. It got stuck when trying to run target-gen test.

19:31 <pkoevesdi[m]> I haven' prepared it (yet) to be pushed publicly.

19:33 <danielb[m]> maybe target-gen test isn't working... you can build your project with cargo build and run target-gen elf on the output

19:34 <pkoevesdi[m]> So, an approach could be to work myself in into Keil? Hmm, totally new construction site for me.

19:34 <pkoevesdi[m]> I'm busy learning rust.

19:39 <pkoevesdi[m]> <danielb[m]> "maybe target-gen test isn't..." <- Thanks for the hint. Now I'm torn: go further that route to take the working external loader and try around with this - can needed symbols be added into the ready elf file, without recompiling everything becuse of the lacking source? Or go on working on the rust-sourced flash algoritm. With that: I got a working rust program that manges (read, write, erase etc.) the flash memory,

19:39 <pkoevesdi[m]> but that attempt failed when trying to compile it into a flash algorithm. It compiled and got flashed (with target-gen test), but gut stuck in run time at a point, where it ran fine as a standalone program. I plan to prepare it to enable people (here) to look at it.

19:42 <pkoevesdi[m]> Or, third route: start working with Keil / .flm...

19:43 <danielb[m]> if the flash algorithms you found don't conform to [this](https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/flashAlgorithm.html#CreateFPA) at least roughly (I'm not sure we respect the sector data), there's no guarantee they will work at all even if you manage to add the missing symbol

19:44 <danielb[m]> if there is no cmsis-pack for your device (and you said it's a custom one), there is no keil flm to work with

19:44 <danielb[m]> what remains is to write your own, and there the language doesn't matter. the output needs to be an .elf that has the required symbols that target-gen can read

19:45 <pkoevesdi[m]> danielb[m]: Yes, that I found out too (see here: https://community.st.com/t5/stm32cubeide-mcus/facing-issue-while-creating-external-flash-loader/m-p/681617/highlight/true#M27852)

19:46 <pkoevesdi[m]> danielb[m]: Ok, good to know, that the Keil route then will not be much better.

19:49 <pkoevesdi[m]> danielb[m]: If writing my own, I'd prefer rust, because the main user program and the boot loader is supposed to be in rust too, and my flash "demo" is already working in rust. Ok, so thanks to Your input, it seems most promising to go (back) to my rust source. Next weekend I'll make it to a readable repo with comprehensible error description, and maybe ask again for help here? Thank You very much!

19:49 <danielb[m]> please ask in #probe-rs:matrix.org it's a bit more on-topic there

19:50 <danielb[m]> but circling back a bit, what did you mean by "where it ran fine as a standalone program"? if you flash a flash algorithm, it will do nothing by itself

19:51 <pkoevesdi[m]> No, of course, I added a main (test) routine calling the flash algorithm functions. I used https://github.com/probe-rs/flash-algorithm-template

19:51 <pkoevesdi[m]> Like this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/upjRBwnXTGTjjKXNyIKrcFKQ>)

19:52 <pkoevesdi[m]> * Like this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AyfsyDRzxDxaKOEPmsXqPuKE>)

19:52 <pkoevesdi[m]> * Like this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ihZKAQBHaawLpeTSPRuttWJV>)

19:53 <pkoevesdi[m]> * Like this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dAvMYdXXkxCoKQcNeDMpQKOA>)

19:54 <pkoevesdi[m]> So, all functions from the template work ok, but as soon as I run it with target-gen test, It gets stuck at runtime in the init function when configuring the rcc.

19:55 <pkoevesdi[m]> But, I don't expect You people here to help without the full source. I'd like to make a working repo and then ask again here.