<andres[m]>
Could you suggest a really well made device driver (like driver for SHT31 or any device) that uses I2C and latest embedded hal traits - bonus if there is async support.
<andres[m]>
I would like to see how state of the art driver would look like.
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
Darius has quit [Ping timeout: 258 seconds]
<JamesMunns[m]>
Has anyone else here written some kind of data structure where you wish you could be "generic" over whether that data structure is on the heap (on desktop) or in static(desktop or embedded)?
<JamesMunns[m]>
I run into this a lot for queues/channels mostly (bbqueue, some of the async stuff in mnemos), and trying to write a library that structures how to do this in a reasonably safe way.
<JamesMunns[m]>
If you have written (or tried to write) a data structure like this, could you lemme know? Interested in getting feedback on it at some point
<JamesMunns[m]>
Only other folks I can think of is korken89 and the heapless folks, tho not sure how often there's desire for arc/heap flavors of heapless types :D
<dirbaio[m]>
there's the allocator api in std (the `A` in `Vec<T, A>`)
<JamesMunns[m]>
That's true! Though unstable still iirc?
mabez[m] has joined #rust-embedded
<mabez[m]>
<JamesMunns[m]> "Has anyone else here written..." <- > <@jamesmunns:beeper.com> Has anyone else here written some kind of data structure where you wish you could be "generic" over whether that data structure is on the heap (on desktop) or in static(desktop or embedded)?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MWPqIbsrsoQKzAxFOwyDiANP>)
<dirbaio[m]>
that apparently allows inline storage
<JamesMunns[m]>
dirbaio[m]: I think this is a good way of framing what I'm trying to abstract over tho! I want it to be possible *with the same type* to either alloc as many as you want using `Arc`s, or exactly once using a static (sort of a single-use allocator).
<dirbaio[m]>
both Allocator and Storage look incredibly complicated
<dirbaio[m]>
to support growing potentially in-place etclol
<JamesMunns[m]>
It's very much "you want inner mutability of a ?Sized collection" shaped, but that's a useful shape for queues, channels, etc.
<JamesMunns[m]>
It also stores inline, for better or worse, which means you can't realloc larger, but I don't generally need that, and static applications wouldn't be able to anyway.
<JamesMunns[m]>
JamesMunns[m]: oh also bump/slab allocators I suppose too!
<JamesMunns[m]>
making it derefmut actually is problematic for me, since I want to use this for shared (inner mutability) data, like the storage of a channel
<dirbaio[m]>
it wouldn't allow resizing tho, `Vec<u8, Heap>` would still have a max size set at creation time :|
<dirbaio[m]>
dynamically allowing resizing or not would be annoying, you'd have to make push() dynamically be fallible or infallible
<JamesMunns[m]>
yeah, that's out of scope for what I'm doing, honestly.
<dirbaio[m]>
JamesMunns[m]: I think you can do this with `mem: &Mutex<S::Mem<T>>`
<JamesMunns[m]>
mnemos has typical alloc collection support, but prefers collections with a fixed, preallocated, bounded flavor.
<dirbaio[m]>
iike, "how is the memory allocated" and "how is the memory shared" are somewhat orthogonal
Jonas[m]1 has joined #rust-embedded
<Jonas[m]1>
<harishkumara> "> <@larunite:matrix.org> But..." <- I would use a Raspberry Pi Pico. I am a beginner too, the experience using Raspberry Pi Pico has been very good.
<dirbaio[m]>
or `mem: Arc<Mutex<S::Mem<T>>>` if you want Arc
<JamesMunns[m]>
dirbaio[m]: sure, totally fair. Just noting that *always* having a derefmut isn't always okay
<JamesMunns[m]>
and I write a lot of data structures where I'm writing the synchronization myself
<dirbaio[m]>
sure
<dirbaio[m]>
but the synchronization doesn't have to be within the allocator
<dirbaio[m]>
you can add it on top
<JamesMunns[m]>
if you build something better than what I linked, I promise you I will use it :)
<dirbaio[m]>
welp I don't know if I can 🤪
<dirbaio[m]>
for starters, the GAT on Borrowed gives a very weird lifetime error I don't know how to solve 🤪
<JamesMunns[m]>
but my current work is generally the shape that all of mnemos' collections are in.
<diondokter[m]>
But DerefMut is not implemented for [T; N]
<diondokter[m]>
s/eveywhere/everywhere/
<dirbaio[m]>
I don't want to require T: 'static tho
<dirbaio[m]>
sometimes creating `Vec<&'a Foo>` is useful
<diondokter[m]>
Yeah true
<diondokter[m]>
But then you probably have to have a lifetime on the storage trait
<diondokter[m]>
Or... maybe there's a trick with higher ranked lifetimes...
<dirbaio[m]>
adding a lifetime on Storage would force doing `Vec<T, 'a, Borrowed<'a>>`
<dirbaio[m]>
which is ugly
<dirbaio[m]>
perhaps
<dirbaio[m]>
`Vec<T, 'a, Borrowed>` and `Vec<T, 'static, Heap>`
<dirbaio[m]>
* 'static, Heap>` is doable
<dirbaio[m]>
but that's still ugly
<dirbaio[m]>
and will run into problems with `Vec<&'a Foo, 'static, Heap>` because `&'a Foo: 'static` doesn't hold
<diondokter[m]>
But then you still couldn't store references on the heap.
<diondokter[m]>
Though... maybe you're not able now anyways?
<dirbaio[m]>
you'd have to do `Vec<&'a Foo, 'a, Heap>`
<diondokter[m]>
Yeah
<dirbaio[m]>
forcing that extra "artificial" lifetime param on the non-borrowed cases
<dirbaio[m]>
* non-borrowed cases sucks
<Jonas[m]1>
I am a beginner that try to make a "hello world" for nRF52840 - have only built some stuff with the rp-hal so far. But I struggle to get some "hello world" code building. I get errors about "LLVM ERROR: Global variable '_ZN9defmt_rtt6handle4NAME17ha6af41dac448aa67E' has an invalid section specifier '.data': mach-o section specifier requires a segment and section separated by a comma." both for defmt-rtt and nrf52840-pac any
<Jonas[m]1>
ideas on what this might be related to?
<dirbaio[m]>
Jonas: missing --target
<dirbaio[m]>
set it in .cargo/config.toml or pass it to cargo every time
<Jonas[m]1>
dirbaio[m]: thanks! that seem to be the problem.
<Jonas[m]1>
dirbaio[m]: yes, this is what I had done, but seem like it did not work. But passing it as a flag with `--target` did fix the problem. Thanks.
gmarull[m] has joined #rust-embedded
<gmarull[m]>
Hi all, not sure if this is the right place, but I have this noob question: I've been evaluating https://github.com/stm32-rs/stm32-rs vs https://github.com/adamgreig/stm32ral, and the ral seems much more ergonomic (coming from C). However, unless I got things wrong, svd2rust based PACs seem more popular. Any opinions, suggestions?
<dirbaio[m]>
gmarull: well you're in for more fun, there's a 3rd pac: stm32-metapac
<dirbaio[m]>
diondokter[m]: `where for<'a> T: 'a;` is equivalent to `where T: 'static`
<diondokter[m]>
Hmmmm...
<dirbaio[m]>
"for every possible lifetime, T outlives it"
<dirbaio[m]>
the "every possible lifetime" includes the 'static lifetime
<diondokter[m]>
I guess
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
gmarull: I still use stm32ral on all my projects because I like it and I think it's the neatest way to do lots of register manipulation, but the svd2rust PACs are very popular for building HALs (perhaps not least because svd2rust has been around a long time), and stm32-metapac is the most modern option, with the additional advantage of being very compatible across different stm32s
<diondokter[m]>
dirbaio[m]: Ah haha, yeah, we were thinking too difficult
<dirbaio[m]>
no GATs needed even
<JamesMunns[m]>
Yeah, for my stuff I think I'm leaning to "always owned, either heap or static"
<Jonas[m]1>
<Jonas[m]1> "yes, this is what I had done..." <- found the problem, I had a typo in the filename of `.cargo/config.toml`
<JamesMunns[m]>
it makes the lifetime issues less of an issue.
<gmarull[m]>
adamgreig[m]: Thanks for the answer. Coming from C (Linux/Zephyr), having a `read/write_reg` macro feels much more natural. Is the tooling in the stm32ral repo generic enough to handle other vendor SVD files?
<adamgreig[m]>
yes; a few other projects have copied stm32ral.py to make their own pac for different manufacturer chips
<adamgreig[m]>
there's a couple of bits that are stm32 specific or are about generating for lots of families that each have lots of members but it's not too bad
<adamgreig[m]>
you should check out chiptool at the same time though, which is used for stm32-metapac
<dirbaio[m]>
that wouldn't work with slices tho, you'd still have to pass the slices in somehow
<dirbaio[m]>
but it would work for switching it between inline and heap
<dirbaio[m]>
well you can do `S: Storage<Foo> + Storage<Bar>`, but that's leaking implementation details
<dirbaio[m]>
like, you might want Foo/Bar to be private
<dirbaio[m]>
(but again, for slices, if they're private how's the user supposed to allocate the slice?)
<dirbaio[m]>
grrrr
<dirbaio[m]>
seems there's a tradeoff
<dirbaio[m]>
- nicer API, but no Borrowed
<dirbaio[m]>
- less nice API, but Borrowed support
<dirbaio[m]>
like, is S an "allocation strategy", or is it an actual "allocation" itself
<dirbaio[m]>
you need the latter to be able to use borrowed slice
<dirbaio[m]>
s/slice/slices/
<dirbaio[m]>
vs "allocation strategy" is nicer because you can create allocations without "collaboration" from the end user (inline or heap), so you can hide the type from the end user
<dirbaio[m]>
I've seen a few people request "Borrowed" for heapless, and noooone request heap support
<dirbaio[m]>
i've needed Borrowed myself a few times
<dirbaio[m]>
smoltcp has managed, which is "borrowed or owned" but at runtime (an enum)
<dirbaio[m]>
I guess none wants heaplessless heapless
<dirbaio[m]>
new crate name, to-heap-or-not-to-heap
<JamesMunns[m]>
yeah, it's more common for things like queues, imo.
<JamesMunns[m]>
like, bbqueue definitely needs it, heapless::MpScQueue could use it
<JamesMunns[m]>
mnemos' core messaging primitive is basically an async version of heapless::MpMcQueue
<JamesMunns[m]>
we treat it like a bounded, async, mpsc queue
phaseonx11[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
but the whole reason I'm doing this thing now is that I want to make mnemos' comms stack work on bare metal (basically embassy) targets, where you have fixed tasks so statically allocated channels are totally fine
<JamesMunns[m]>
but in mnemos we heap allocate all the channels. so whatever channel I use needs to work in both, OR you have to write two almost the same impls with different storage mechanisms.
<dirbaio[m]>
yea
<dirbaio[m]>
I do have a "heap or inline" use case too, sharing code between firmware and server
<JamesMunns[m]>
Maybe I'm the only person that tries to do shit like this :D
<JamesMunns[m]>
yeah, I'm not SURE this totally maps to like what managed is trying to do
<JamesMunns[m]>
I don't have a general solution to that problem, for like `Vec<u8>` or `heapless::Vec<u8; N>` from some pool
<dirbaio[m]>
the problem is I do want resizing on the server...
<dirbaio[m]>
server handles 1k-10k connections per instance
<dirbaio[m]>
so I'm currently setting N=big and wasting RAM
<JamesMunns[m]>
I plan to cheat in the comms stack by making the channels always typed (not frames/byte blobs), by serializing at the wire sender and deserializing at the wire receiver
<dirbaio[m]>
and if there's still too many conns it fails... i'd rather have it resize up
<dirbaio[m]>
memory on the server is essentially infinite, for code designed for embedded 🤪
ChristianHeussy[ has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
at least with postcard, it's guaranteed the `heapless::Vec<u8>`, `&[u8]`, and `alloc::Vec<u8>` have the same wire repr
<JamesMunns[m]>
I have uh, just made two versions of the wire structs before, or used features to swap them
<JamesMunns[m]>
I haven't found a NICE way to abstract over it tho.
<dirbaio[m]>
in my case it's not wire structs, it's the actual data structures implementing the protocol. like `Map<ConnId, Conn>`, lists of pending requests in each conn, etc
<JamesMunns[m]>
making it actually generic means you need all kinds of const N: usize and 'a and stuff that makes it really hard to use practically.
<JamesMunns[m]>
<dirbaio[m]> "in my case it's not wire structs..." <- ah. oof owie :(
<korken89[m]>
<mabez[m]> "I suppose that's up to japaric..." <- I'm all for it, I do not have the time to maintain heapless :/
exark has quit [Ping timeout: 245 seconds]
exark has joined #rust-embedded
NishanthMenon has quit [Ping timeout: 252 seconds]
NishanthMenon has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
FlyingSquirrelAr has joined #rust-embedded
FlyingSquirrelAr has quit [K-Lined]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
You're the heapless maintainer?
<firefrommoonligh>
Nice!
<firefrommoonligh>
It's a lovely lib. Should be part of core lib IMO
Guest7221 has left #rust-embedded [Error from remote client]
Farooq has joined #rust-embedded
<Farooq>
Ordered a cheap STM32 header board, rechargable AA batteries, their charger and some other components to build my robot
<dirbaio[m]>
Jonas[m]1: the way is RTC or TIMER, yes
<dirbaio[m]>
dirbaio[m]: nrf-hal is unmaintained though, check out embassy-nrf
<dirbaio[m]>
dirbaio[m]: there you can do `embassy_time::block_for(Duration::from_secs(1))`
<Jonas[m]1>
dirbaio[m]: I also see that the C SDK does have a `nrf_delay_ms()` that is probably what I was looking for, but probably does not exist in nrf-rs hal.
<Jonas[m]1>
<dirbaio[m]> "nrf-hal is unmaintained though..." <- embassy looks very interesting. But I am a very beginner and would like to do it without any framework at the moment, to more easyli understand the basics, and later move on to Embassy. Or can I use Embassy as a pure _hal_ instead of the _async-framework_-ish? I have not fully understood Embassy yet.
<dirbaio[m]>
Jonas[m]1: embassy-nrf is a hal, same as nrf-hal
<dirbaio[m]>
dirbaio[m]: you can use embassy-nrf only without the rest of embassy
<Jonas[m]1>
dirbaio[m]: I did not know that. I will have a look.
<Jonas[m]1>
<Jonas[m]1> "I did not know that. I will have..." <- dirbaio: Is there any beginner friendly documenation / tutorial for `embassy-nrf` ? I only see some examples, but they seem to use the embassy-executor thing that I would like to not use at the moment. Like https://github.com/embassy-rs/embassy/blob/main/examples/nrf52840/src/bin/blinky.rs
brazuca has joined #rust-embedded
<dirbaio[m]>
Jonas[m]1: most examples do assume you're using the executor
<dirbaio[m]>
dirbaio[m]: to not use it, just keep the standard cortex-m-rt `#[entry] fn main()` you have now
<dirbaio[m]>
dirbaio[m]: and put the code inside
<dirbaio[m]>
dirbaio[m]: and you'll have to replace the async sleep with `embassy_time::block_for(Duration::from_secs(1))`
sjm42[m] has joined #rust-embedded
<sjm42[m]>
<dirbaio[m]> "you can use embassy-nrf only..." <- ...minus any async fns, right? :o
<dirbaio[m]>
sjm42[m]: yes, but almost everything offers both an async and a blocking API
<Jonas[m]1>
<dirbaio[m]> "yes, but almost everything..." <- I get this error when I try to use embassy_nrf as a hal: ```note: `std` is required by `embassy_nrf` because it does not declare `#![no_std]`
<Jonas[m]1>
```
<Jonas[m]1>
Jonas[m]1: I import it as this in `cargo.toml` : `embassy-nrf = "0.0.0"`
<dirbaio[m]>
Jonas[m]1: the crate on crates.io is a placeholder
<dirbaio[m]>
dirbaio[m]: then do `cargo run --release`
<dirbaio[m]>
dirbaio[m]: well, assuming your board has an on-board probe. which board do you have?
<dirbaio[m]>
* well, that's assuming your
<dirbaio[m]>
* `cargo install, * --features cli`
brazuca has joined #rust-embedded
Guest7221 has joined #rust-embedded
<Jonas[m]1>
dirbaio[m]: I have the Adafruit Express, it has a bootloader for USB.... hmm. I think it should be a bit similar to RP2040 in that way. https://www.adafruit.com/product/4062
<Jonas[m]1>
Jonas[m]1: I have used probe-rs for rp2040, but I don't know how I should connect cables to use it on this nrf52 board, I think I need to deploy in a different way.
<Jonas[m]1>
Jonas[m]1: Perhaps I can use elf2uf2-rs - since that tool is working for rp2040 over usb. But no logging then.
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
Jonas[m]1: You can connect a probe to the little 10 pin connector in the middle of the board, but you will need some kind of adapter
<GrantM11235[m]>
GrantM11235[m]: The feather board also has a pre-installed uf2 bootloader, so you should be able to use uf2 (but not having logging really sucks imo)
<Jonas[m]1>
GrantM11235[m]: I have a RP Pico board, that I use for rp2040, but it is connect to two pins for SWD.
<GrantM11235[m]>
Jonas[m]1: Also, you might need to change some linker options to make your code work with the bootloader, I'm not sure
<Jonas[m]1>
GrantM11235[m]: Hmm, yeah, these are the difficult part when doing Rust embedded :(
<GrantM11235[m]>
Jonas[m]1: The 10 pin connector has SWD, you just need to find some way to connect the right pins
<Jonas[m]1>
GrantM11235[m]: shouldn't it be a pin for CLK as well?
<Jonas[m]1>
GrantM11235[m]: oh, this looks like some custom connector. I probably need to buy some hardware for that one? On rp2040 it is connected using two GPIO pins using jumper wires.
<GrantM11235[m]>
GrantM11235[m]: NOO! WRONG LINK AGAIN!! AHHHH
<GrantM11235[m]>
GrantM11235[m]: Wait, it was right that time
<GrantM11235[m]>
GrantM11235[m]: for some reason it showed me the wrong link preview image
<GrantM11235[m]>
<Jonas[m]1> "do you mean this cable? https..." <- Actually, this cable would NOT work, it uses the large size (2.54mm) connector not the small size (1.27mm)
<Jonas[m]1>
GrantM11235[m]: Thanks. But the bootloader / linker problem still remains. I probably need to read some docs to figure that out.
<GrantM11235[m]>
Progmem only exists because AVRs are a bit weird. If you are using arm/risc-v/whatever, you don't need to worry about it and everything just works
<dirbaio[m]>
Jonas[m]1: if you do have a debug probe you can simply ignore the bootloader
<dirbaio[m]>
dirbaio[m]: set your memory.x so flash starts at 0
<Jonas[m]1>
dirbaio[m]: oh, sounds good! Thanks!
<dirbaio[m]>
Jonas[m]1: flashing your firmware will overwrite the bootloader, but that's fine. you can restore it later if you want
<Jonas[m]1>
dirbaio[m]: I just need to buy some hardware then. So no blinking today or next week :(
<dirbaio[m]>
Jonas[m]1: (you probably won't want to, if you have a real debug probe there's little reason to use the bootloader. perhaps if you want to go back to using the Arduino IDE or CircuitPython etc)
<dirbaio[m]>
dirbaio[m]: it seems their bootloader is UF2, so elf2uf2-rs should work like in the rp2040, fi you want to try it out without waiting for the debug probe to arrive
<dirbaio[m]>
dirbaio[m]: flash is 0x26000 - 0xed000
<dirbaio[m]>
dirbaio[m]: and for RAM, you have to reserve 8 bytes for the softdevice
<dirbaio[m]>
dirbaio[m]: (yes, only 8 bytes. the docs there mention a bigger number, but that's only if you enable it to do bluetooth stuff)
<dirbaio[m]>
dirbaio[m]: so RAM would be 0x20000008 - 0x20040000
<dirbaio[m]>
dirbaio[m]: if you put that in your memory.x then convert with elf2uf2.rs it should hopefully work
<dirbaio[m]>
s/./-/
<Jonas[m]1>
dirbaio[m]: I will give it a try! Thanks for great help!
<GrantM11235[m]>
dirbaio[m]: That page is for the non-express version, are you sure it is the same?
<GrantM11235[m]>
GrantM11235[m]: nevermind, that is the page that is linked to in the express product page
<GrantM11235[m]>
GrantM11235[m]: I guess "express" just means it uses the 52840 instead of the 52832 in the older version
<Jonas[m]1>
GrantM11235[m]: yup, clicking on "Overview" of that guide, it is written for "Express".
<Jonas[m]1>
<dirbaio[m]> "so RAM would be 0x20000008 - 0x2..." <- I did not see these numbers in the linked guide. But this is maybe something documented for the nrf52840 elsewhere? Anyway, I will give it a try. Just trying to understand.
<dirbaio[m]>
Jonas[m]1: yeah they don't seem to document it because they assume you'll want bluetooth
<dirbaio[m]>
dirbaio[m]: ... or just wait for the probe lol
<Jonas[m]1>
<dirbaio[m]> "... or just wait for the probe..." <- I just ordered one now, with express shipping, so hopefully some day next week, it will blink. Thanks a lot!
<dirbaio[m]>
Jonas[m]1: damn bootloaders 🤣
<Jonas[m]1>
dirbaio[m]: I want the logging anyway, right after I got it blinking. :)
crabbedhaloablut has quit []
GenTooMan has quit [Ping timeout: 248 seconds]
GenTooMan has joined #rust-embedded
<M9names[m]>
<adamgreig[m]> "gmarull: I still use stm32ral on..." <- There's also raltool, which is a chiptool derivative used by the imx folks to generate an stm32ral-like interface