<adamgreig[m]>
technically, it's because the flash wait state configuration needs to be set depending on the clock speed that rcc is sorting out: at high clock speeds you have to set higher wait states or the flash won't be ready when the cpu tries to read it
<adamgreig[m]>
and the HAL chooses to require you pass it in rather than directly accessing it as a design choice, because accessing it directly would require "unsafely" making up a new instance of the peripheral and using a critical section lock to update it, which wasn't a popular design decision at the time (but I think it's fair to say more HALs lean towards that for user convenience these days)
<KevinLy[m]>
adamgreig[m]: Thanks, that was super helpful! Is there any place I can read more about this? Is it in the data sheet of my respective STM32F3xx?
<adamgreig[m]>
yep, the reference manual for your chip will have a section all about the flash peripheral, which will explain what the wait states need to be
<adamgreig[m]>
it's possibly the actual numbers for the wait states vs clock speed will be in the datasheet instead
<adamgreig[m]>
s/possibly/possible/
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
<cr1901>
eldruin[m]: This is what I ended up doing. It is probably possible to make generic, but it's not my priority right now.
<cr1901>
Also, FWIW, I got sequential-storage working with 24x EEPROMs along with miniconf. Pretty cool!
IlPalazzo-ojiisa has joined #rust-embedded
badyjoke[m] has joined #rust-embedded
<badyjoke[m]>
Hello, I would like to use a Rust Hal for a C application. Do you know the way to do a FFI wrapper around some hal or pinpoint me to some resources ?
<diondokter[m]>
<cr1901> "Also, FWIW, I got sequential-..." <- 😁
<badyjoke[m]>
Thanks James Munns for the insight
<JamesMunns[m]>
Is there a specific chip your HAL is for? There might already be some Rust code for it.
<badyjoke[m]>
In fact, I wrote a basic Rust Hal to implement the SPI peripheral for the Atsam3x8e and use generic drivers. And I would like to use this into a C application if it's possible. It is mainly for learning purpose and see if it is doable to keep an already written C application.
<JamesMunns[m]>
AH! I totally misread your request, I'm sorry!
<badyjoke[m]>
Don't worry 😅
<JamesMunns[m]>
In reverse, MOST of what I said is still true, but you'll use https://github.com/mozilla/cbindgen instead, which takes a rust crate and makes a C header for it
<JamesMunns[m]>
you'll need to make your rust crate a static library, include the header file you generate, and compile it as part of your build process
<JamesMunns[m]>
In general, you'll need to write `extern "C"` public interfaces for your C code.
cesnel[m] has joined #rust-embedded
<cesnel[m]>
Hello there,
<cesnel[m]>
I wonder if when using Rust in an embedded target (understanding it as typical 32-bits MCU) does it really make sense at all to use the MPU?
<cesnel[m]>
I mean, does it the MPU have any use case, when the "memory-safety" is built-in in the language itself?
<JamesMunns[m]>
JamesMunns[m]: Also, if you ever run third party code (scripts, plugins, etc.), which isn't super common in embedded, but sometimes relevant, it can help isolate that as well.
<cesnel[m]>
Thanks a lot for the explanation James Munns
<JamesMunns[m]>
Yes, they use unsafe under the hood, in different ways. Either way tho, it's not nearly as "expensive" as you might think, tho it's definitely not ergonomic.
<JamesMunns[m]>
The general goal when writing low level Rust is to use `unsafe`, but "encapsulate" it or isolate it to as few places as possible: this makes it much easier to review, audit, and verify.
<JamesMunns[m]>
if you have 10000 lines of safe code, and 200 lines of unsafe code, that's much easier to manage (IMO) than having 10200 lines that could be safe or unsafe and it's impossible to tell which is which without reading very, very carefully.
<cesnel[m]>
Got it, fully agree, thanks :)
<JamesMunns[m]>
Every "introduce Rust to C programmers" will have A Guy that's like "well you have to use unsafe so what's the point" :D
<JamesMunns[m]>
so it's worth saying
<JamesMunns[m]>
We put the radioactive code in the radioactive code bunker and put on hazmat suits when we have to go touch it.
<JamesMunns[m]>
Instead of just storing it on the shelf with the sodas.
<cesnel[m]>
yeah, true, but i have a prepared answer. in "C" unsafe keyword actually exists: int main () {
<GuineaWheek[m]>
idk rtic makes a pretty strong argument in favor of rust just by itself alone
<cesnel[m]>
Agree, both embassy and RTIC are so great that I don't even have a clear answer to "which one to use". The controversial part for my presentation I presume its going to be: when using preemtive approach, at least for cortex-m, it forces user code to be executed at privileged level (ISRs), so there is full access to core internal bus. But in any case any critical action will then require unsafe block IINM.
<cesnel[m]>
I meant for RTIC, using higher than 0 prio soft tasks. For embassy, running executor in ISR to do preemtive approach
<cesnel[m]>
s/executor/executors/
<bomb>
cesnel[m] now now, no runtime!
<bomb>
is BBC Microbit 2 a good start for the embedded primer with Rust, or you recommend another development board?
<bomb>
Arduino is a safe choice, I guess?
<ryan-summers[m]>
I believe the rust embedded starter book is now based on the microbit 2. I would avoid arduinos on Rust because the support is not great because the CPU cores are quite dated and not well supported by LLVM
<ryan-summers[m]>
Atleast for the older atmel-based Arduinos
<diondokter[m]>
Or does anybody know a good way of diffing two binaries? Sadly they're kinda large at 400kb of flash usage.
<diondokter[m]>
Doing a objdump and comparing in vscode doesn't go well because the files are too big. But using a simpler diff tool also doesn't quite work since locations and hashes are different which trips it up
AtleoS has quit [Ping timeout: 255 seconds]
AtleoS has joined #rust-embedded
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
<diondokter[m]> "Or does anybody know a good..." <- > <@diondokter:matrix.org> Or does anybody know a good way of diffing two binaries? Sadly they're kinda large at 400kb of flash usage.
<JamesMunns[m]>
> Doing a objdump and comparing in vscode doesn't go well because the files are too big. But using a simpler diff tool also doesn't quite work since locations and hashes are different which trips it up
<JamesMunns[m]>
beyond compare is usually a champ. Paid tool but should have a free trial
<JamesMunns[m]>
JamesMunns[m]: supports diffing binary files (with changed addrs I don't think that will be very helpful tho), but it can also power through hundreds-of-MB files.
<diondokter[m]>
Cool, thanks for the recommendation!
<JamesMunns[m]>
JamesMunns[m]: also allows you to manually "re-align" the two files however you need to.
<JamesMunns[m]>
IIRC it should, I've known someone else who used the same trick. Any particular reason you're considering it?
<RobertJrdens[m]>
I was doing a deep (at least for me) dive into reflection in rust on no-std+no-alloc. TL;DR: you can get a lot of things done just fine.
<RobertJrdens[m]>
Using linkme would make this a bit nicer.
<JamesMunns[m]>
Yeah, I haven't directly TRIED linkme before, but "array of function pointers in a linker array" is something that will definitely work.
<JamesMunns[m]>
(dunno how happy it'd make ralfj, but conceptually is reasonable IMO)
<RobertJrdens[m]>
why would he be unhappy?
<JamesMunns[m]>
hmmm, I thought there used to be a discussion of soundness concerns on linkme, but maybe they all got addressed or I misremembered.
<RobertJrdens[m]>
It's certainly not life-before-main.
<JamesMunns[m]>
only thing I can think about is "what if different compilation units do different things with struct layout and the compiler doesn't realize it can't do that"
<JamesMunns[m]>
but, idk if the compiler does that (now or ever in the future), or what.
<RobertJrdens[m]>
Doesn't struct layout need to globally consistent always? Can't imagine how that could not be the case.
<JamesMunns[m]>
if you don't pass a struct from one unit to another, and it doesn't hit FFI or other escaping, I don't see why they couldn't be laid out different locally.
<JamesMunns[m]>
idk if a compiler would ever WANT to do that, or if they even could leverage that.
<JamesMunns[m]>
(to be clear, I'm inventing a hypothetical issue, not something I am practically aware of. Just noting that for repr(Rust) and other similar things that are not fully stable, the compiler is allowed to do seeming weird things, and if the compiler doesn't understand the things you are doing, it might do incorrect things).
<RobertJrdens[m]>
Oh cool! Their list of supported platforms kept me from actually looking 😉
<therealprof[m]>
<diondokter[m]> "Or does anybody know a good..." <- > <@diondokter:matrix.org> Or does anybody know a good way of diffing two binaries? Sadly they're kinda large at 400kb of flash usage.
<therealprof[m]>
> Doing a objdump and comparing in vscode doesn't go well because the files are too big. But using a simpler diff tool also doesn't quite work since locations and hashes are different which trips it up
<therealprof[m]>
cargo-bloat to locate the bulk of the change. cargo-asm to analyze the differences.
<diondokter[m]>
<therealprof[m]> "> <@diondokter:matrix.org> Or..." <- Hmmm yeah, the total diff is too different. Symbols are in different order now. Beyond Compare does work well though!
<therealprof[m]>
<diondokter[m]> "Hmmm yeah, the total diff is too..." <- > <@diondokter:matrix.org> Hmmm yeah, the total diff is too different. Symbols are in different order now. Beyond Compare does work well though!
<therealprof[m]>
> I can try your suggestion too
<therealprof[m]>
Yeah, forget about the full diff; the compiler will completely shuffle the binaries around and nothing stays the same, including addresses.
<diondokter[m]>
Oh that diff in the picture is the diff of the compiler between the versions
<therealprof[m]>
Cargo bloat sorts by size and allows to easily see if functions jump in size.
<diondokter[m]>
Yeah, there are some changes
<therealprof[m]>
(function names usually don't change between compilers)
<therealprof[m]>
cargo-asm yields annotated assembly per function, that makes a side-by-side comparison much easier.
<therealprof[m]>
I've used cargo-bloat for some time to track binary size changes between compiler versions...
<diondokter[m]>
There are some functions that have 2 bytes difference. Looking at what instruction was added now
<therealprof[m]>
If you're looking for 400kB size differences, looking for 2B is probably not too fruitful.
<diondokter[m]>
No, the size of both is roughly 400kB
<therealprof[m]>
Oh.
<diondokter[m]>
I was saying because the firmware is this big it's hard to see what meaningful differences there are
<therealprof[m]>
I see. Just from experience I can tell you that such small changes occur every few days on the nightly builds.
<diondokter[m]>
Yeah I know. But one of these changes is loadbearing :P
<therealprof[m]>
It's really hard to tell exactly what caused the change, sometimes small changes create a large ripple effect.
<diondokter[m]>
I'm kinda tempted to write a script that compiles all the different compiler commits and then tests the project so I can hopefully get to the exact compiler commit where the relevant thing changed
<therealprof[m]>
But I do find the combination of cargo-bloat/cargo-asm super useful both to track changes in the compiler but also when optimising code for size...
<diondokter[m]>
Very likely there's UB in this project
<JamesMunns[m]>
diondokter[m]: isn't that what the rustc bisecting tool is for?
<diondokter[m]>
If I knew what the compiler changed, maybe I'd know what the UB would be
<therealprof[m]>
diondokter[m]: I would bet that is a waste of time.
<diondokter[m]>
Haha me too
<therealprof[m]>
I don't see the relation between size and UB really...
<diondokter[m]>
JamesMunns[m]: Ah that was the name! I knew some tool existed for it
<JamesMunns[m]>
therealprof[m]: he's just looking for where the miscompilation/UB manifests
<diondokter[m]>
therealprof[m]: It's not a size thing
<diondokter[m]>
One version gives me no runtime error and one does. The error is wrong, but the assembly of that particular part is the same between the versions
<JamesMunns[m]>
but if it is UB, then yeah, it's just as likely to show up anywhere, not necessarily anything meaningful in the compiler.
<JamesMunns[m]>
like, the actual bisected diff might be an entire red herring, if it's actually UB.
<diondokter[m]>
Yeah
<diondokter[m]>
Idk
<diondokter[m]>
Maybe it'd be more fruitful to review all of the unsafe code
<JamesMunns[m]>
probably depends on the volume of unsafe code, and how much effort it takes to set up cargo-bisect-rustc
AtleoS has quit [Remote host closed the connection]
AtleoS has joined #rust-embedded
<AdamHott[m]>
The PR for the tooling.md of the rust embedded book got merged. But it needs to be updated on the website, how do we get that updated?
<JamesMunns[m]>
it probably needs to be added to a
<ryan-summers[m]>
bomb: Rust's targets reference specific processor cores for the microcontroller, for example, ARMv6 architectures and ARMv7/v8 are often seen in STM32 chips
<bomb>
oh, right, thumb. thank you
<bomb>
that, too. yes
K900 has joined #rust-embedded
<K900>
It's probably better to search for "none"
<K900>
Which is to say "no OS"
<bomb>
K900 ha, I was wondering what were they about!
<JamesMunns[m]>
AdamHott[m]: I can't remember if they update automatically or if we have to PR them
<ryan-summers[m]>
Ah well thats a bad link...
<diondokter[m]>
ryan-summers[m]: Just ignore that some of the triples have four words :P
<diondokter[m]>
s/words/sections/
<bomb>
I should join you on Matrix
Ecco has quit [Ping timeout: 252 seconds]
Ecco has joined #rust-embedded
Ecco has quit [Ping timeout: 268 seconds]
Ecco has joined #rust-embedded
ragarnoy[m] has quit [Quit: Idle timeout reached: 172800s]
kenny has quit [Ping timeout: 255 seconds]
avery71[m] has quit [Quit: Idle timeout reached: 172800s]
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]
kenny has joined #rust-embedded
jr-oss has quit [Ping timeout: 260 seconds]
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
AtleoS has quit [Ping timeout: 245 seconds]
bomb has quit [Quit: 💣]
esden[cis] has joined #rust-embedded
<esden[cis]>
and that worked without a hitch.
<esden[cis]>
<dirbaio[m]> "yea the BMP is so odd. does it..." <- I am biased... but I actively use BMP for embassy/rust, it works great for me! :) (to be clear the project uses STM32L4) (I still have to document how to use BMP in a Rust embedded project... thanks for the reminder.) Mostly for loading the firmware and for getting the defmt log output over serial. But I did use it to do some GDB stepping through the Rust code when that was needed,
<esden[cis]>
I do plan eventually to provide a way to use probe-rs with BMP by providing a rust crate for the BMP remote protocol. I think someone made a wrapper crate for the C library, but I want to have something native rust instead to bring it up stream.
<esden[cis]>
That said, probe-rs uses RTT as the main mode to operate (not sure if it can use serial instead), and I found that to be laggy and lossy, so I rather use uart->socat->defmt-print instead.
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
> I found that to be laggy and lossy
<JamesMunns[m]>
with BMP specifically? It typically works pretty robustly, I've had hours-days of logs stay solid before.
<esden[cis]>
No not with BMP with ST link. I can’t use bmp with probe-rs
<esden[cis]>
Ok I guess I have to be much more elaborate here...
<JamesMunns[m]>
huh! yeah, sorry, also just dropping by :D
<JamesMunns[m]>
using probe-rs with an st-link, or j-link, or daplink, or picoprobe have all been fairly reliable for me! (j-link has the worst throughput tho)
<esden[cis]>
Lossy because it has to initiate the connection before you get log output. With socat I can just have it nonstop running while I develop, so when firmware is loaded it immediately gets output.
<JamesMunns[m]>
ahhhhh.
<JamesMunns[m]>
yeah, the old probe-run tool would halt before attach, and the probe-rs CLI didn't adopt that behavior
<esden[cis]>
And yes with stlink it is laggy, about 500ms or more before an action takes place and the output comes out over RTT onto the console
<JamesMunns[m]>
(probe-run would set a breakpoint at main, halt until RTT attached, then run once it was attached)
<esden[cis]>
Or even more than that, I never measured it but it is annoying to have this disconnect.
<esden[cis]>
Additionally I can use dumb loggers in the field that ingest serial data too. And so on. RTT is nice to get started quickly. But for longer term and production I find UART better as long as one has the available hardware pins. :D
<JamesMunns[m]>
fair! would definitely be worth reporting if it's that reliable tho, as that's definitely not my experience wrt reliability or throughput.
<esden[cis]>
It was reliable when running. It is just the way I was hoping the turn around to happen and how I wanted to use it.
<JamesMunns[m]>
Definitely not trying to get you to change ways that work for you - mostly just hoping to capture that for a probe-rs improvement if it was possible. I appreciate you taking the time to explain!
<esden[cis]>
James Munns: yeah I totally understand! It was not a probe-rs problem it was a me problem. :D This is why I want to put effort into allowing probe-rs to use BMP directly. It will be good to have. :D
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
mars has joined #rust-embedded
mars has quit [Read error: Connection reset by peer]