<re_irc>
<@torne:matrix.org> Hey folks, is there a good way to get a similar kind of register interface that you get with `svd2rust` or `tock-registers` where you can do bitfield ops etc, but for registers on a remote peripheral (e.g. accessed over I2C)? I tried to work out a way to implement the `tock-registers` interface for it but couldn't get anywhere..
<re_irc>
<@firefrommoonlight:matrix.org> I think at the core of this, is that from an API perspective, this is a similar problem to that solved by SVD2Rust
<re_irc>
<@firefrommoonlight:matrix.org> But in terms of how our code works, it's a bit different. In that the MCU periphs become memory-mapped, but the device on a bus aren't. And we don't have SVDs to automate it
<re_irc>
<@firefrommoonlight:matrix.org> Ideally, coding with a high-level API is very nice. (subjective, but I think so!) You get that on the MCU level with HALs. For things like supporting an I2Cdevice, I think we have no way of getting the nice "SVD2RUST" like interface that's worth the trouble
<re_irc>
<@firefrommoonlight:matrix.org> Ie, You can write a high-level API that makes all the reg writes directly faster than you could try to make a PAC interface. And most I2C etc devices are relatively simple, at leaset compared to an MCU
<re_irc>
<@firefrommoonlight:matrix.org> So... Nice idea to have this functionality, but it's no easier it is to get it than it is to have a higher-level API. So given a choice, writing the high level API directly wins
<re_irc>
<@firefrommoonlight:matrix.org> If device makers published SVDs or something, it might be worth it
<re_irc>
<@firefrommoonlight:matrix.org> Exercise: Pick an external (I2C, SPI etc) device you use or would like to. Assume you have a high-level API for the bus, eg on HAL, and the datasheet for the device. Can you think of a faster or better way than typing up a file that does the writes directly based on the DS tables?
<re_irc>
<@firefrommoonlight:matrix.org> There's also so much weird shit, like this I2C device I'm using that has 9-bit fields, so I made a wrapper like this:
<re_irc>
<@firefrommoonlight:matrix.org> ```rust
<re_irc>
<@firefrommoonlight:matrix.org> /// This codec uses a non-standard 7-bit-address, 9-bit data setup, so we use
<re_irc>
<@firefrommoonlight:matrix.org> /// a custom function to manage this.
<re_irc>
<@firefrommoonlight:matrix.org> Or different types of memory on the device, like normal register that have one access procedures, and `EEPROM` with another
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
fabic_ has quit [Ping timeout: 260 seconds]
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 260 seconds]
<re_irc>
<@diondokter:matrix.org> It deserves much more love :P
<re_irc>
<@diondokter:matrix.org> Really need to port it over to a proc macro, especially now that proc macro support in rust analyzer is starting to get somewhere
<re_irc>
<@diondokter:matrix.org> Aaahhh! I really need to work on the device driver crate again...
<re_irc>
<@ryan-summers:matrix.org> I was about to say, it would be much better written that way :)
<re_irc>
<@ryan-summers:matrix.org> Then the syntax remains very close to pure rust structs
<re_irc>
<@ryan-summers:matrix.org> That being said, proc macros with custom attributes on struct fields can be a lot of work to write. Just look at serde
<re_irc>
<@diondokter:matrix.org> Yeah, need to experiment with it. But I really don't have the time. Maybe I could do some work on it at my job if they allow it? Who knows
tokomak has joined #rust-embedded
fabic_ has joined #rust-embedded
tokomak has quit [Ping timeout: 268 seconds]
troth has quit [Ping timeout: 258 seconds]
troth has joined #rust-embedded
troth has quit [Ping timeout: 245 seconds]
Amanieu has joined #rust-embedded
fabic_ has quit [Ping timeout: 258 seconds]
tokomak has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 264 seconds]
fabic_ has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> Hi everyone. I intend to write some drivers in the future and one thing I did not find out yet is how to deal with time, i.e. getting something like the well-known millis() and micros() functions for further calculations. Since I'm familiar with STM32 and have worked with the ST HAL in the past, I typically use the Cortex-M SysTick for this. So I wrote a crate that initializes the SysTick to a certain...
<re_irc>
<@sourcebox:matrix.org> But of course, the driver should not work with this crate directly but use an abstraction that gives an instant. So my question is now how to integrate this into something like embedded-hal.
<re_irc>
<@sourcebox:matrix.org> I've seen this already, but I think this is not intended to be used as monotonic time source.
<re_irc>
<@dirbaio:matrix.org> so it's likely that they'll be temporarily removed to be redesigned later for embedded-hal 1.0
<re_irc>
<@sourcebox:matrix.org> Basically I'm looking for something like an `Instant` type similar to what std offers.
<re_irc>
<@dirbaio:matrix.org> yeah it's not for a monotonic timesource
<re_irc>
<@dirbaio:matrix.org> a trait for that would be useful indeed
<re_irc>
<@sourcebox:matrix.org> There is this `embedded-time` crate, but I don't fully understand it.
<re_irc>
<@sourcebox:matrix.org> Also I'm asking myself if such a relatively simple thing needs another dependency.
<re_irc>
<@dirbaio:matrix.org> representing instants/durations is a giant can of worms
<re_irc>
<@dirbaio:matrix.org> ideally the traits would do it in a hardware-independent *and* zero-cost way
<re_irc>
<@dirbaio:matrix.org> but that's still an unsolved problem
<re_irc>
<@sourcebox:matrix.org> I could easily do my own thing with an Instant that is simply a u64 representing nanoseconds. But of course I would like to have something that is usable for the community.
tokomak has quit [Ping timeout: 268 seconds]
<re_irc>
<@dirbaio:matrix.org> that's probably your best bet for now :'(
<re_irc>
<@dirbaio:matrix.org> and feedback and proposals on how to design the traits in embedded-hal is always welcome :)
<re_irc>
<@sourcebox:matrix.org> You're right on this, but my impression is, that this topic is kind of stuck and does not advance at the moment. It seems that nobody has an exact idea how it can be addressed.
<re_irc>
<@sourcebox:matrix.org> Ok, let's think a little about it...
hifi has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> Is there already a common agreement that "something" should be inside `embedded-hal` that defines a monotonic time source?
<re_irc>
<@sourcebox:matrix.org> Or do the maintainers think it should be addressed separately?
<re_irc>
<@dirbaio:matrix.org> not sure about Monotonic
<re_irc>
<@dirbaio:matrix.org> but the main roadblock is defining a Duration trait/type (or Instant for Monotonic)
<re_irc>
<@dirbaio:matrix.org> that all time-related traits would use
<re_irc>
<@dirbaio:matrix.org> not sure if Monotonic has been discussed before, but I assume if the Duration/Instant stuff is resolved it wouldn't be too controversial to add it
<re_irc>
<@sourcebox:matrix.org> If you don't have a monotonic time time, what else would be the alternative? Timers are not really one, because the overflow quickly and are not suitable for multi-tasking.
<re_irc>
<@sourcebox:matrix.org> Imagine you use an RTOS with several tasks, there must be a way to get an instant for every task. No way to do this with a timer that is just tied to a certain function.
<re_irc>
<@sourcebox:matrix.org> So FreeRTOS as example just counts ticks.
<re_irc>
<@dirbaio:matrix.org> yeah totally
<re_irc>
<@adamgreig:matrix.org> https://crates.io/crates/fugit just got released which is an interesting new option for this stuff
<re_irc>
<@adamgreig:matrix.org> basically counts ticks, but also has const parameters to indicate the frequency of the ticks, such that you can compile-time convert most things as required
<re_irc>
<@adamgreig:matrix.org> (I understand the plan is for this to be used for rtic 0.6's monotonic in place of embedded-time)
<re_irc>
<@dirbaio:matrix.org> yup fugit looks very interesting
<re_irc>
<@dirbaio:matrix.org> I'm not sure whether e-h should use concrete Duration/Instant *types* or instead have Duration/Instant *trait*
<re_irc>
<@sourcebox:matrix.org> But fugit is already an implementation, isn't it?
<re_irc>
<@henrik_alser:matrix.org> adamgreig: Yes the idea is to have it working with your time library of choice instead of depending on embddded-time
<re_irc>
<@adamgreig:matrix.org> via another trait?
<re_irc>
<@adamgreig:matrix.org> I wonder if e-h could share the trait or something
<re_irc>
<@adamgreig:matrix.org> sourcebox: hm, lots of things can use timers as monotonic sources, even despite overflow since you can generally extend them to longer bit-widths in software (or often you just have to allow the monotonic count to overflow... counting ticks in u32 overflows every 30s or so for me iirc)
<re_irc>
<@adamgreig:matrix.org> (depends which ticks you're counting of course but even 1ms will overflow a u32 relatively soon)
<re_irc>
<@sourcebox:matrix.org> u32 at 1ms will overflow after about 50 days.
<re_irc>
<@sourcebox:matrix.org> I think it's up to the app developer to decide which overflow periods are acceptable. It highly depends on the purpose.
<re_irc>
<@sourcebox:matrix.org> It seems that some implementations already exist, what's missing are the traits to make it interoperable.
<re_irc>
<@adamgreig:matrix.org> yea. there's a lot of interest and there have been a bunch of discussions recently too
<re_irc>
<@adamgreig:matrix.org> including on potential trait designs
<re_irc>
<@adamgreig:matrix.org> it's a bit tough because it might be nicer to have a concrete type (saves generic types everywhere), but what size you store and how you deal with frequencies is a bit of a pain
<re_irc>
<@sourcebox:matrix.org> I just want to use something like `Instant::new().to_millis()` in my app code.
<re_irc>
<@adamgreig:matrix.org> core's Instant is generally considered both too big storage-wise (2xu64) and also too annoying (ns+secs, but often this isn't a helpful unit so you end up doing loads of integer division)
<re_irc>
<@henrik_alser:matrix.org> The Monotonic trait was changed so you can use any time library as long as it has Instant and Duration types
<re_irc>
<@adamgreig:matrix.org> ah, so the new rtic Monotonic trait is the only thing that needs to be implemented, and it no longer requires embedded-time's Clock?
<re_irc>
<@henrik_alser:matrix.org> Exactly!
<re_irc>
<@adamgreig:matrix.org> nice
<re_irc>
<@dirbaio:matrix.org> oh? link?
<re_irc>
<@adamgreig:matrix.org> maybe we end up with something like that in e-h for Delay and so forth
<re_irc>
<@sourcebox:matrix.org> So these traits are independent from rtic? That would be a requirement because rtic is ARM-only.
<re_irc>
<@adamgreig:matrix.org> those traits are tied to what rtic requires, they're probably not going to be useful in a general-purpose sense
<re_irc>
<@henrik_alser:matrix.org> I think korken89 is still working on that PR, don’t know if there’s anything written about it yet!
<re_irc>
<@sourcebox:matrix.org> So the embedded-hal lacks two types: Instant and Duration. But it is not clear how to define them. Am I wrong?
<re_irc>
<@adamgreig:matrix.org> That's right... but maybe it will never have types, only traits
<re_irc>
<@adamgreig:matrix.org> (using traits means users can bring their own types, eg a big 2xu64 type a la core, or some tiny u16 from a timer if that's what they want, but maybe this flexibility ends up being unhelpful or bad)
<re_irc>
<@sourcebox:matrix.org> But what's wrong about types representing ms, µs and ns?
<re_irc>
<@sourcebox:matrix.org> I've seen this approach on some crates.
<re_irc>
<@adamgreig:matrix.org> Which crates? The main problem is you now have three duration types, and you need to do division to turn any of them to/from the ticks that your system actually measures or uses
<re_irc>
<@adamgreig:matrix.org> Some crates want to talk about reciprocal time too for configuring clocks and communications interfaces, so if the underlying type is limited to integer ns you limit what frequencies you can talk about... but maybe this use case should be separate?
<re_irc>
<@dirbaio:matrix.org> if your timer counts in 32khz ticks, you want Duration to count 32khz ticks to avoid expensive divisions every time
<re_irc>
<@adamgreig:matrix.org> But probably clock frequencies are what's eventually used to determine the seconds to ticks conversion so they need to be involved somewhere
<re_irc>
<@sourcebox:matrix.org> It could also work without divisions in some cases.
<re_irc>
<@adamgreig:matrix.org> True, if your timer is helpfully counting ms or whatever
<re_irc>
<@sourcebox:matrix.org> Yes, that's the way I usually do it.
<re_irc>
<@adamgreig:matrix.org> But it seems probably better to at least support storing and manipulating ticks at the clock's native rate, and convert the human time units at compile-time
<re_irc>
<@dirbaio:matrix.org> depending on the hardware that's not possible
<re_irc>
<@adamgreig:matrix.org> So you write 10.ms() in your code and the compiler can turn it into 2678 cycles or whatever
<re_irc>
<@sourcebox:matrix.org> Counting is ms should be no requirement but possible to make benefit of if possible.
<re_irc>
<@adamgreig:matrix.org> I don't mean to discourage you here, just hopefully you see the various issues people have raised with every approach
<re_irc>
<@adamgreig:matrix.org> For a single use case it's usually ok to find something that works really well, like maybe you have a 1MHz timer and a u32 worth of microseconds is always enough for you and you just use that
<re_irc>
<@sourcebox:matrix.org> That's a question of the implementation and not the trait.
<re_irc>
<@sourcebox:matrix.org> I can use an implementation that fits for me, someone else can use another one.
<re_irc>
<@adamgreig:matrix.org> Yep, that's why there's this idea of using a trait for e-h instead of concrete types
<re_irc>
<@sourcebox:matrix.org> Isn't this just a misunderstanding here? E.g. a type `Milliseconds` won't hurt, it just has to define a `Millis` trait to be implemented, no matter how this is done.
<re_irc>
<@sourcebox:matrix.org> The implementation can then choose what it thinks is best for the use case to implement that.
<re_irc>
<@sourcebox:matrix.org> Same with ns, µs, seconds...
<re_irc>
<@sourcebox:matrix.org> But of course, default implementations should be provided.
<re_irc>
<@sourcebox:matrix.org> But in the end, I always need time units. E.g. when I use an SPI flash chip, the datasheet specifies times in ms for page erase etc.
<re_irc>
<@sourcebox:matrix.org> On the other hand, embedded-hal is already very specific - see delay.rs which defines DelayUs.
<re_irc>
<@sourcebox:matrix.org> There you have a trait that defines delay_ms() with a u32.
<re_irc>
<@dirbaio:matrix.org> DelayUs is temporary until the final holy grail Duration/Instant is done
<re_irc>
<@dirbaio:matrix.org> there's some discussion on the issue I linked
<re_irc>
<@dirbaio:matrix.org> tldr is using ms/us u32 everywhere is not nice
<re_irc>
<@dirbaio:matrix.org> but not having a Delay trait would be worse, so DelayUs was kept
<re_irc>
<@sourcebox:matrix.org> So breaking changes are already planned ;-)
<re_irc>
<@dirbaio:matrix.org> No.. plan is to add the delay using Duration as `Delay`, and leave `DelayUs`
<re_irc>
<@dirbaio:matrix.org> it's somewhat suboptimal, I'd rather remove it but.. 🤷
<re_irc>
<@sourcebox:matrix.org> From a pragmatic point of view, I'd like to have something that can be used in a managable time rather than a perfect solution that will never be found.
<re_irc>
<@adamgreig:matrix.org> (well, this is all in the unreleased e-h 1.0, which is breaking from 0.2 that also had DelayMs and generic over ints)
<re_irc>
<@sourcebox:matrix.org> I'm just saying this because of the long time the issues are outstanding.
<re_irc>
<@dirbaio:matrix.org> the goal of 1.0 is to not have to break it in a long time
<re_irc>
<@adamgreig:matrix.org> And we already have DelayMs and DelayUs in the currently released e-h 0.2 which can be used today
<re_irc>
<@dirbaio:matrix.org> (which is why I'd remove DelayUs from 1.0 :S )
<re_irc>
<@sourcebox:matrix.org> Yes, and e-h will hopefully be one of the most essential parts of the embedded ecosystem, so getting out the 1.0 is an important thing.
<re_irc>
<@adamgreig:matrix.org> But the conclusion most recently was that it seems like we won't work out what to do for Delay in 1.0 yet, so keeping a basic DelayUs for now and add it later
<re_irc>
<@dirbaio:matrix.org> but pelpe can keep using the 0.2 one :S
<re_irc>
<@adamgreig:matrix.org> Hm, I guess...
<re_irc>
<@sourcebox:matrix.org> But you cannot really mix 0.2 and 1.0 later, that could be a stopper.
<re_irc>
<@dirbaio:matrix.org> you can
<re_irc>
<@sourcebox:matrix.org> How to do that if traits and implementations differ?
<re_irc>
<@sourcebox:matrix.org> Are you sure that no collisions will happen in the whole dependency tree of an application?
<re_irc>
<@dirbaio:matrix.org> cargo treats different major versions of the same crate independently
<re_irc>
<@dirbaio:matrix.org> it's explicitly designed so you can do taht
<re_irc>
<@sourcebox:matrix.org> I know, but this does not work in all cases, I think.
<re_irc>
<@dirbaio:matrix.org> I'm pretty sure it does 🤷
<re_irc>
<@sourcebox:matrix.org> As soon as you have different definitions for the same symbol in the linker, it will break. But that is rare.
<re_irc>
<@sympatron:matrix.org> The symbols will always be different as long as you define it like dirbaio
<re_irc>
<@dirbaio:matrix.org> rust mangles all symbols so different crate versions get different symbol names
<re_irc>
<@sourcebox:matrix.org> C linkage?
<re_irc>
<@sympatron:matrix.org> except for `extern "C"` and `#[no_mangle]` stuff I think, but this will probably never be in e-h
<re_irc>
<@sourcebox:matrix.org> That's wanted I want to say.
<re_irc>
<@sourcebox:matrix.org> It is rare, but can happen especially with embedded.
<re_irc>
<@dirbaio:matrix.org> embedded-hal is all traits anyway
<re_irc>
<@dirbaio:matrix.org> no symbols :D
<re_irc>
<@sympatron:matrix.org> with other crates it could indeed
<re_irc>
<@sympatron:matrix.org> if I understood it correctly `cortex-m-rt` had this problem
<re_irc>
<@sourcebox:matrix.org> Yes, and this is exactly where I ran into it.
<re_irc>
<@dirbaio:matrix.org> embedded-hal will never do that since the whole point of it is allowing mixing versions
<re_irc>
<@sourcebox:matrix.org> Ok, that's good to know.
<re_irc>
<@adamgreig:matrix.org> c-m-rt has a specialist problem because it really cannot coexist with another version of itself, since it defines vector tables and so on
<re_irc>
<@adamgreig:matrix.org> Normally in Rust it's not a problem to mix versions, though still a bit annoying just for DelayUs
<re_irc>
<@davarice:matrix.org> is it possible to use the rust stdlib on a raspberry pi pico? ive been writing a program for the pi zero, but theres too much OS to reliably get the precision i need; i *can* start over but id prefer to just port what i have
<re_irc>
<@sourcebox:matrix.org> Pico is only Cortex-M0, so I doubt that.
<re_irc>
<@davarice:matrix.org> (the Correct™ thing to do would be to get a dedicated controller but ive already got the pico)
<re_irc>
<@davarice:matrix.org> and the target is `thumbv6m-none-eabi`, correct?
<re_irc>
<@sourcebox:matrix.org> Should be right.
<re_irc>
<@sourcebox:matrix.org> So what is your advice for dealing with Instant and Duration when I need to write a driver in the near future?
<re_irc>
<@sourcebox:matrix.org> Another topic: is there any concept in e-h for parallel interfaces? Typically, with a TFT, I use an 8-bit parallel port for data. I only write to the display, but it's also possible to read from port.
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<re_irc>
<@mygnu:matrix.org> Hey All, I'm very new to embedded. currently working on a hobby project using a STM32f103 blue pill.
<re_irc>
<@mygnu:matrix.org> Project involves reading some sensors and sending data to my PC via usb, I've got the usb serial working and can successfully send bytes back and forth to the device.
<re_irc>
<@mygnu:matrix.org> but I'm not sure about how to design the communication protocol? are there any standards best practices.
<re_irc>
<@mygnu:matrix.org> communication basically looks like
<re_irc>
<@sourcebox:matrix.org> Maybe there are some existing protocols, but what I currently do in such cases is using a request/response pattern. This may work or not in your use case.
<re_irc>
<@sourcebox:matrix.org> So the PC polls the information. If this is not an option, then the device can stream it without any request from the PC.
<re_irc>
<@mygnu:matrix.org> thanks, any good bad examples of request/response pattern
<re_irc>
<@sourcebox:matrix.org> Have a look at the STM32 internal bootloader as an example.
<re_irc>
<@sourcebox:matrix.org> This follows such a pattern.
<re_irc>
<@mygnu:matrix.org> thanks, let me ddg it, to the other question yes pc will have to poll for info otherwise its not needed
<re_irc>
<@sourcebox:matrix.org> With STM32 bootloader protocol I refer to the serial bootloader on the UART, not the USB one in DFU mode. The latter is much more complicated to handle.
<re_irc>
<@sourcebox:matrix.org> Thanks, I just had a look at the code.
<re_irc>
<@sourcebox:matrix.org> Seems that it iterates over the pins, not a good solution.
<re_irc>
<@adamgreig:matrix.org> yea.. I feel like I saw another parallel port abstraction at some point but I don't remember where. for parallel displays I usually use specific peripherals for it instead of gpio, either fsmc or ltdc on stm32
<re_irc>
<@sourcebox:matrix.org> GPIO on STM32 is fine, but the register should be written in one operation.
<re_irc>
<@sourcebox:matrix.org> But e-h does not specify anything like a slice of OutputPins, I think.
<re_irc>
<@sourcebox:matrix.org> The term "bus" should be appropriate.
<re_irc>
<@sourcebox:matrix.org> On STM32 DMA is also a good option - if you can afford the required RAM.
<re_irc>
<@therealprof:matrix.org> sourcebox:matrix.org: It's not easy trivial to implement that generically, even less so without reaching into the magic box of unsafety.
<re_irc>
<@therealprof:matrix.org> However the idea here is: If you can implement that interface, any display using `display-interface` will be able to use it. the `parallel-gpio` driver is simply the easiest (and possibly only) generic implementation which can literally work anywhere where the `embedded-hal` `OutputPin` traits are implemented.
<re_irc>
<@therealprof:matrix.org> Some STM32s have a FSMC/FMC peripheral for which the `display-interface` can also be implemented (and is e.g. on the F4). If that is available the display with render in lightning speed, but of course you're giving up the possibility to choose your pins freely and have to use the ones available for the FSMC/FMC interface.
<re_irc>
<@therealprof:matrix.org> Good old trade-offs. 😅
<re_irc>
<@torne:matrix.org> firefrommoonlight:matrix.org: The I2C-controlled PMU chip I'm writing a driver for has 119 registers and a high level API is going to be hundreds of functions including many that need to touch the same registers for unrelated reasons
<re_irc>
<@torne:matrix.org> so writing this high level API at all without some decent way to refer to bitfields inside registers etc seems like a challenge
<re_irc>
<@torne:matrix.org> also i'm already having to write my own documentation for the device since i'm interpreting a bad machine translation of the chinese datasheet for it, so writing that in the form of usable code isn't necessarily adding any significant work if there's sufficiently good tool/macro/etc support :)