Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
Kert[m] has joined #rust-embedded
<Kert[m]>
<bozgi[m]> hi! i am new to embedded, i've for a long time wanted to make a keyboard. I managed to design it and get it manufactured. As a chip I chose Seeed Studio XIAO nRF52840. I can't manage to get it to register a keypress, and even to get a timer working. This is the code that makes the device be...
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
_whitelogger has joined #rust-embedded
<fard[m]>
Speaking of wasm, thank you all for your responses, it was very informative. I'm going to follow Dirbaio's advice, the Data-Driven option, which seems more appropriate for my level at the moment. The thread was very interesting, thanks again!
crabbedhaloablut has quit [Quit: bye]
crabbedhaloablut has joined #rust-embedded
<thejpster[m]>
<adamgreig[m]> thejpster: you reckon this way is easier than keeping master branch's cortex-m and reverting the breaking changes? there's a bunch of things we definitely want to keep like the inline-asm changes that are quite big iirc
<thejpster[m]>
But what if there are things on 0.7.x that master doesn’t have? We have to reconcile these histories somehow.
<bozgi[m]>
even when i set it as periodic it still hung up
<bozgi[m]>
<KevinPFleming[m]> The loop calls `start` on each timer after `wait` returns `Ok()`, which would make them sort-of periodic.
<bozgi[m]>
the reason i made it like that is because the periodic timer didn't help so i thought i would "simulate" it
<bozgi[m]>
bozgi[m]: but it still runs once
<bozgi[m]>
bozgi[m]: and it doesn't panic
<bozgi[m]>
bozgi[m]: just halts
<KevinPFleming[m]>
bozgi[m]: have you tried commenting out the `usb_dev.poll()` to see if it might be hanging there?
<bozgi[m]>
KevinPFleming[m]: i haven't - will do it now
<bozgi[m]>
bozgi[m]: one second
<bozgi[m]>
bozgi[m]: it does
<bozgi[m]>
bozgi[m]: the poll hangs it
<bozgi[m]>
bozgi[m]: but without the poll it doesnt register as a usb device
<KevinPFleming[m]>
bozgi[m]: that makes sense, the USB stack isn't getting any CPU time
<bozgi[m]>
KevinPFleming[m]: thank you for Your help
Foxyloxy has quit [Ping timeout: 272 seconds]
Foxyloxy has joined #rust-embedded
<KevinPFleming[m]>
<bozgi[m]> thank you for Your help
<KevinPFleming[m]>
good luck tracking it down!
<ksvr[m]>
I am making a library that should work with no_std, however I would still like to offer some of the stuff with containers like Vec, when running on a platform that can target std. Is there a way to do that?
<bozgi[m]>
maybe a feature that has std stuff?
<ksvr[m]>
Wouldn't that cause issue with the macro no_std?
<Ralph[m]>
<ksvr[m]> I am making a library that should work with no_std, however I would still like to offer some of the stuff with containers like Vec, when running on a platform that can target std. Is there a way to do that?...
<Ralph[m]>
note that you can feature-gate this to `alloc` rather than `std`, then consumers of your library on embedded devices which opt to use a memory allocator can still use `Vec` & co.
<bozgi[m]>
bozgi[m]: the first `if` is used for me to easily flash my board
<ksvr[m]>
mameluc[m]: Well I have variable length returns, right now I did a fixed array allocation, one with heapless as well and would like to add std::vec, but its mostly to be fancy I guess
<ksvr[m]>
Ralph[m]: This is a great example, thanks
<thejpster[m]>
Any thoughts on how to fix this last clippy issue? The emotional toll from this PR is high.
<Ralph[m]>
maybe unpopular, but: bump MSRV to something newer?
<JamesMunns[m]>
I thought out MSRV was pretty permissive like "current stable" or "current stable - 3" or something
<JamesMunns[m]>
I don't think we autobump it, but yeah, afaik there's not much keeping us
<dirbaio[m]>
lint was added on 1.77.0 (2024-03-21)
<dirbaio[m]>
* that lint was
<dirbaio[m]>
cortex-m msrv is stricter
<dirbaio[m]>
> This crate is guaranteed to compile on stable Rust 1.38 and up. It might compile with older versions but that may change in any new patch release.
<JamesMunns[m]>
huh!
<dirbaio[m]>
you could argue the "that may change in any new patch release" applies just to "It might compile with older versions" so bumping the msrv is breaking
<JamesMunns[m]>
We do allow teams to decide to set a stricter msrv, so yeah, sounds like a "put it up to a vote to the arm team" if we want to change it.
<dirbaio[m]>
but honestly i'd just change that and bump the msrv in a minor version anyway
<dirbaio[m]>
1.38 is ancient
<Ralph[m]>
dirbaio[m]: "may change in any new patch release" to me clearly states that it's allowed to be bumped even in a new 0.7.x release
<JamesMunns[m]>
yeah I assume dirbaio meant 0.7.x with "minor", since we're pre-1.0
<dirbaio[m]>
"that" in "that might change" refers to "It might compile with older versions", not "This crate is guaranteed to compile on stable Rust 1.38 and up"
<dirbaio[m]>
it's the way my brain parses that sentence at least 😅
<Ralph[m]>
dirbaio[m]: argh, you're right. i misread it (the way i wanted to interpret it 😅)
<Ralph[m]>
just change the statement at the same time and consider it a bugfix to the README 😜
<dirbaio[m]>
hehehe
apirkle has quit [Ping timeout: 272 seconds]
<thejpster[m]>
MSRV is 1.38 on master, but 1.59 on 0.7.x branch because it uses inline asm
<thejpster[m]>
I think the answer to the warning about the new clippy lint is to allow unknown lints.
<thejpster[m]>
Please do not bump MSRVs beyond 1.76.0, because we have a Ferrocene release based off that, with 12 months support left to go (or longer)
<dirbaio[m]>
if Ferrous is promising X months of support, shouldn't Ferrous provide that support?
<thejpster[m]>
we provide support for the compiler. If customers pay us, we can provide support for upstream Rust crates too.
<thejpster[m]>
The WG is free to set the MSRV to whatever it feels like. It can set it to latest nightly if it so chooses. But some choices have a negative effect on the adoption of the crates, and Rust in general.
<thejpster[m]>
I'm just asking nicely, please try not to go beyond the current Ferrocene stable releases. If you have good reasons to go beyond them anyway, that's fine. I will support my customers in spite of that change.
<thejpster[m]>
Equally, I have no desire for you to keep the MSRV at 1.61. The latest compiler I support is 1.76. So I'm also saying "hey, bump the MSRV to 1.76!"
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
AshconMohseninia has joined #rust-embedded
<AshconMohseninia>
question, has anyone seen this before with probe-rs attach? Im in a project that is inside a workspace, probe-rs cannot resolve line or file information, and says Insufficient DWARF info; compile your program with debug = 2 to enable location info. All that i changed is that this project is now part of a workspace rather than a standalone project
<JamesMunns[m]>
you need to set profiles in the workspace, not the project
<AshconMohseninia>
JamesMunns[m]: perfect! That worked, thanks!
<AshconMohseninia>
also i wonder if anyone here knows, is there a way on a cortex-m device to load the code into RAM, such that (For instance updating a bootloader), it allows the flash to be overwritten whilst the bootloader is running?
sroemer has quit [Quit: WeeChat 4.5.2]
<thejpster[m]>
yes. You just need a linker script that puts .text and .rodata in RAM, and some mechanism of getting the code to where you told the linker it was going to be.
<thejpster[m]>
Neotron OS loads ELF applications into RAM from SD Card and executes them.
<thejpster[m]>
you could do it with a single function in your bootloader marked `#[link_section = ".data"]` but Rust might insert a jump to a function in flash, which will spoil your data. A standalone binary is safer.
<thejpster[m]>
Also, this is how probe-rs works. It drops a block of code into RAM and jumps to the various routines to erase a block write a sector, etc.
jason-kairos[m] has quit [Quit: Idle timeout reached: 172800s]
jason-kairos[m] has joined #rust-embedded
<jason-kairos[m]>
Does cortex M3/M4 etc. have better code density than M0/M0+? (ie. how many bytes of flash needed for the same program between the two)
<jason-kairos[m]>
they have more 32 bit instructions, conditionals, etc.
<jason-kairos[m]>
* Does cortex M3/M4 etc. have better code density than M0/M0+? (ie. how many bytes of flash needed for the same program between the two, assuming no floating point or anything fancy)
<jason-kairos[m]>
they have more 32 bit instructions, conditionals, etc.
<JamesMunns[m]>
based on no data, I do think thumbv6 produces more code than thumbv7 for stuff like function preludes and some other boilerplate-y things
<JamesMunns[m]>
you could a/b test it pretty easily by compiling the same code base for thumbv6m-none-eabi and thumbv7em-none-eabi
<JamesMunns[m]>
it's not a *lot*, but maybe couple percent?
<jason-kairos[m]>
I've used 490kb of 512kb on my MCU. It's wild how quickly it adds up when you've got the facilities that Rust provides. There is no way I'd make anything so big if I was working in C.
<JamesMunns[m]>
That's a lot of code. You're using hubris, right?
<jason-kairos[m]>
Yeah, 10 threads and an external C library (~200kb) for a protocol. It adds up. An idle thread might only be 64 bytes of flash and 32 bytes of ram, but once you start having IPC servers it gets big.
<dirbaio[m]>
Hubris compiles each task as a separate binary
<dirbaio[m]>
So if you use the same lib from N tasks you end up with N copies of that lib in flash.
<TomB[m]>
I wonder if an elf loader is possible with rust, or if the lack of any sort of ABI would make this hell
<TomB[m]>
C makes it pretty easy to link between ELFs, the symbols are consistently named and such...
<thejpster[m]>
you can easily parse an ELF and copy the segments out, but if you want a dynamic loader you need a dynamic linker to relocate the PIC library to where you're loading it, and then patch up the binary to link to the library in the place you just put it.
<thejpster[m]>
Neotron just has static non-relocable binaries.
<jason-kairos[m]>
<dirbaio[m]> So if you use the same lib from N tasks you end up with N copies of that lib in flash.
<jason-kairos[m]>
Bingo, string formatting and arithmetic seem to be major ones. But honestly I often find it quite difficult even with map files to ascertain what causes a binary to jump from 60kb to 100kb. Mostly just state machines, parsing, and zerocopy type conversions.
<dirbaio[m]>
if oyu're flash-constrained maybe hubris isn't the best choice
<jason-kairos[m]>
512kb should be enough for anyone, it's on me to write better IPC servers
<jason-kairos[m]>
or at least, it's one me to figure out the tooling to figure out how much flash is occupied by each crate/module
<jason-kairos[m]>
s/one/on/
<jason-kairos[m]>
* IPC servers / parsers / etc.
<jason-kairos[m]>
* IPC servers / protocol parsers / etc.
<JamesMunns[m]>
It's maybe a little experimental still, but I'm working towards it
<JamesMunns[m]>
It gives you typed sockets basically, you can use it to "localhost", but also with remote embedded/desktop systems
<JamesMunns[m]>
The "local only" examples are only like 11-20KiB with panic immediate abort
<JamesMunns[m]>
* like 11-20KiB .text with panic
<jason-kairos[m]>
hubris comes with its own particular flavor of an IPC system complete with a IPC description language and server/client generator. When I look at the generated client/servers, they look about as simple as I could imagine them being. (zerocopy'ing to/from a struct)
<jason-kairos[m]>
It often seems like panic!() and string formatters pertaining to it are big contributors
<JamesMunns[m]>
Sure! Mine takes any serde type that impls the postcard-schema trait
<jason-kairos[m]>
If there was a no-panic IPC library, I'd be eager to investigate
<JamesMunns[m]>
For local comms, it doesn't even serialize, it just sends like a channel.
<JamesMunns[m]>
It definitely doesn't get you the isolation hubris does, but if you Just want message passing, with the option for remote comms, that's what I'm aiming for.