<sarath08071994[m>
I am trying to compile rust std code for Quectel evk board. I am facing an issue with choosing the right target and linker while cross compiling on the Linux host system. Can any one please help regarding this.
<sarath08071994[m>
Board architecture is armv7l
M9names[m] has joined #rust-embedded
<M9names[m]>
Can you provide more details than that? Like, model number of the evk board, link to the Linux SDK, etc?
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<sarath08071994[m>
Quectel AG35 series (R12)
<sarath08071994[m>
* Board: Quectel AG35 series (R12),
<sarath08071994[m>
The Linux SDK is a proprietary one
<sarath08071994[m>
* Board: Quectel AG35 series (R12),
<sarath08071994[m>
The Linux SDK is a proprietary one,
<sarath08071994[m>
It has armv7l
<M9names[m]>
Based on screenshots of the SDK I'm going to assume armv7a, glibc and softfloat. So your target name will be armv7-unknown-linux-gnueabi
<sarath08071994[m>
How to choose the linker
<sarath08071994[m>
<M9names[m]> "Based on screenshots of the..." <- How to choose the linker
<sarath08071994[m>
* the linker ?
<sarath08071994[m>
* How to choose the linker ?
<sarath08071994[m>
And the armv7l architecture
<M9names[m]>
Use the linker from your SDK
<M9names[m]>
You can instruct cargo to use it by setting it in your project's Cargo.toml.
<JamesMunns[m]>
(I haven't used meta-rust, just know it exists)
GregBodnar[m] has joined #rust-embedded
<GregBodnar[m]>
<JamesMunns[m]> "what does the oe part stand..." <- `oe` is OpenEmbedded. You'll see it referenced along with Yocto builds for embedded Linux.
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<M9names[m]>
I don't think meta-rust helps here, they're dealing with a distro built by open-embedded, not o-e itself.
<M9names[m]>
Still, if they get so desperate they decide it's easier to learn o-e than to use the SDK they have it's nice to have that option
qzl[m] has quit [Quit: Idle timeout reached: 172800s]
marmrt[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
A bit like an nRF53 - you get a Cortex-M33 for application code and a Cortex-M3 for the radio.
<thejpster[m]>
I wonder if it's made out of iMX IP, or if we'd need a new HAL
<thejpster[m]>
"Someone's going to have to fix rust embedded, because the GPIO's are strongly typed, but we'd actually like it to be useful...." - ouch
<dirbaio[m]>
lol where's that from?
<thejpster[m]>
<timonsku[m]> "starting in 30min there is a..." <- here
<thejpster[m]>
his specific complaint was that you have to re-write main to run your application on a different PCB, whilst zephyr hides all this for you and you just give west build a board argument
<thejpster[m]>
I don't think embassy fixes that
<JamesMunns[m]>
or we need better docs of "it's not actually useful to abstract over the 10% of main, if it means your build tooling becomes 1000x more complex"
<JamesMunns[m]>
I had this argument with someone recently, maybe from RIOT-OS?
<JamesMunns[m]>
at least, we've de-prioed "you can write a main file that works on 10 chips", like arduino or zephr
<JamesMunns[m]>
s/zephr/zephyr/
<JamesMunns[m]>
but instead "you can write a driver crate that can be used on 10 chips with no changes"
<JamesMunns[m]>
but, we didn't show up to give a talk on that! so maybe a note for next time :)
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
General embedded question if anyone knows - im trying to hook a fatfs implementation to the ST SD driver, and it works but its *painfully* slow. If i set up the working areas to span more than one sd card sector, the multi block writes become unreliable.
<FreeKill[m]>
I've not had to integrate either fatfs or SD cards into a system before - am I missing any obvious footguns? Cos this is getting irritating
<dirbaio[m]>
there's 2 separate issues
<dirbaio[m]>
- Generics infecting everything, so if you want to e.g. change one pin you have to change it in 50 places (or use type aliases)
<dirbaio[m]>
- No equivalent of devicetree in Rust
<dirbaio[m]>
IMO devicetree exists to workaround the C type system -- it lets you centralize your pin definitions in one place and have that checked at compile time etc
<dirbaio[m]>
but we can alreayd do that in Rust with the Rust type system. eg check whether pin X can do SPI MOSI or whatever at compile time
<dirbaio[m]>
so I don't think we need a devicetree in Rusrt
<dirbaio[m]>
s/Rusrt/Rust/
<JamesMunns[m]>
I have to do something else, but before we get too deep in the hole:
<JamesMunns[m]>
I think we do need to talk about "messaging" and "communicating outside of the group of enthusiasts"
<dirbaio[m]>
because (as long as you fix the generics spam), if you want to change the pin of something, you change it in 1 place (in Rust code in main, where you construct the thing. vs also in 1 place in devicetree. it's the same in the end)
<JamesMunns[m]>
like, not "convincing other people to use Rust", but more "talking about embedded rust, how it works today, benefits, etc.", out in public, because if WE don't, we're going to keep seeing all these "is Rust embedded good?!?!" blog posts and videos from people who are or aren't familiar with Rust, really, or just tried it out for a bit, instead of people who have been using it full time for ~years
<dirbaio[m]>
(and yes Embassy fixes most the generics spam, and fixing the rest of it is in the roadmap)
<JamesMunns[m]>
I think we DO need to take criticism for things people say they are struggling with! Even if we think they're struggling because they are trying to "write C in Rust".
<diondokter[m]>
JamesMunns[m]: Yeah, just had a meeting today with a hardcore C dev and he claimed Rust is always slower and always produces bigger binaries than C or even Cpp
<juliand[m]>
diondokter[m]: And C produces larger binaries than pure assembly, so let's use assembly?! Even if that were the case, I think there are enough advantages over C that would even justify it
<JamesMunns[m]>
yeah, if we don't have active comms, people will just invent shit on the internet.
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
I'm just having a deja-vu on that ;-)
<diondokter[m]>
juliand[m]: He does write assembly in some cases for max performance in some hot loops and stuff... So yeah 😂
<thejpster[m]>
this is weird - the subtitles are running ahead of the live stream
<sourcebox[m]>
I would really like to see panic-immediate-abort stabilzed.
<sourcebox[m]>
Because telling those people to have to use the nightly toolchain puts even more scary arguments on the table.
<sourcebox[m]>
Btw. I had to retranslate some asm to C a while ago and the result was often faster.
<JamesMunns[m]>
anyway, as always, I think we should have more comms, and I think anyone who is using Rust and can help write about it will do a lot more than any one person yelling loudly about it
<GrantM11235[m]>
<JamesMunns[m]> "I think we DO need to take..." <- I think a large portion of those struggles are the result of generic-spam-filled HALs, so I don't know how to fix that other than saying "embassy fixes this" over and over lol
<sourcebox[m]>
Optimization has come a long way.
<JamesMunns[m]>
GrantM11235[m]: yeah, I think we should talk about this at rustnl
<juliand[m]>
Another thing that came up today in a meeting was the issue of dependencies and crates.io in general. Not only regarding licenses (mostly MIT and Apache anyway afaik) but also regarding safety/security. Are there any plans to have more quality-controlled or reviewed crates at some point?
<juliand[m]>
I think this actually is an attack surface where someone could offer a useful crate, people use it and then inject malicious code. Didn't really have an answer to that one except for reviewing every dependency :/
<thejpster[m]>
juliand: you can just pay to make that problem go away
<JamesMunns[m]>
I really need to write a retraction of "type states are always good" I wrote previously, I much prefer Embassy's current take: check generics at construction time, then ditch the generics.
<diondokter[m]>
We do have an active blog on the Tweede golf website, but it's only so many times you can write about the same high level pros and cons of rust :P
<JamesMunns[m]>
juliand[m]: > <@juliand:fehler-in-der-matrix.de> Another thing that came up today in a meeting was the issue of dependencies and crates.io in general. Not only regarding licenses (mostly MIT and Apache anyway afaik) but also regarding safety/security. Are there any plans to have more quality-controlled or... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZzNhJltROkBjxZcQnlSlTqSY>)
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]>
Yeah we're having a Zephyr Vs Embassy Vs PlatformIO fight at work atm
<thejpster[m]>
juliand: it's on the ferrocene.dev roadmap, because all our customers are asking for it
<thejpster[m]>
other vendors are available
lulf[m] has joined #rust-embedded
<lulf[m]>
In my experience a good way to get the 'C believers' into Rust is to have them participate in some workshop.
<lulf[m]>
It's hard to convince anyone from slides
<dirbaio[m]>
(from the stream): "If you get a device_t* from devicetree for an uart and you call an i2c method on it you will probably segfault" 💀
<dirbaio[m]>
<3 C
<thejpster[m]>
he's not selling me on device tree, ngl
<diondokter[m]>
Oh no! :P
<juliand[m]>
Also: is there any page to refer to when people ask about Rust Embedded for Linux? There is the linux embedded-hal, but other than that using Rust on Embedded Linux seems mostly like using it on Desktop, except for accessing peripherals like SPI etc. So I couldn't find anything specific on that topic.
<sourcebox[m]>
To me, the binary size issue has to be improved. This one major thing that comes up very quickly every time I'm talking to some C developer.
<thejpster[m]>
sourcebox: I'm sure the code size working group would love some help
<juliand[m]>
lulf[m]: Especially the quick and easy toolchain setup should easily convince people before they even start coding
<diondokter[m]>
sourcebox[m]: Tbh, with defmt and panic abort I've not found this to be a major issue myself.
<diondokter[m]>
But if you really need fmt, then yeah...
<thejpster[m]>
sadly code size and code performance are often (not always, but often) in tension]
<thejpster[m]>
s/]/\/
<thejpster[m]>
* sadly code size and code performance are often (not always, but often) in tension
<sourcebox[m]>
thejpster[m]: AFAIK this mainly to panic handling.
<diondokter[m]>
We need the std/core to be size optimization aware so we can do e.g. #[cfg(size-opts)]
<dirbaio[m]>
a lot of the bloat is the compiler being stupid. like it not optimizing out panic formatting stuff.
<diondokter[m]>
* We need the std/core to be size optimization aware so we can do e.g. #[cfg(size-opts)] in std
<dirbaio[m]>
im' sure there's lots of low-hanging fruit there
<dirbaio[m]>
but someone with compiler knowledge would need to go and fix it
<sourcebox[m]>
I personally don't have that much of a problem with the binary sizes. Mainly because I use larger chips anyway.
<dirbaio[m]>
and most of the rust devs don't do embedded
<dirbaio[m]>
for example the wg-binary-size has focused on stuff that doesn't affect embedded, such as size of dwarf info...
<sourcebox[m]>
Ok, what is e.g. really the blocker for panic-immediate-abort becoming stable? build-std I guess?
<JamesSizeland[m]>
Is Embassy on the agenda at EOSS at all?
<dirbaio[m]>
sourcebox[m]: that's sort of a workaround, I think the "preferred" fix would be to fix whatever's preventing the compiler from optimizing out the panic fmt sutff
<dirbaio[m]>
s/sutff/stuff/
<dirbaio[m]>
if you set a panic handler that doesn't print the panic message, the compiler should optimize all the fmt stuff out
<dirbaio[m]>
but it doesnt for some reason
<dirbaio[m]>
s/doesnt/doesn't/
<dirbaio[m]>
if that was fixed, we'd get the same code size gains as panic_immediate_abort
<sourcebox[m]>
dirbaio[m]: That's true.
<thejpster[m]>
good talk, would recommend
<thejpster[m]>
nice to hear an "outsider's" view
<thejpster[m]>
you don't just want to hear me and james banging on about the same stuff all the time
<JamesMunns[m]>
Yeah - I haven't listened to this talk, so I'm less salty about this one, than the last "is rust embedded good" blog articles that keep dropping across my feeds
<timonsku[m]>
<dirbaio[m]> "IMO devicetree exists to..." <- devicetree is a whole lot more than pin definitions. Its a description of the hardware as a whole and includes hardware configuration. You need something like it in any language if you want a full abstraction that doesn't require code changes and isn't tied to the language of choice.
<dirbaio[m]>
timonsku[m]: yeah but why is "doesn't require code changes" an advantage?
<dirbaio[m]>
the devicetree is also "code"
<dirbaio[m]>
why is it better to have to change N lines of devicetree code instead of N lines of Rust code?
<timonsku[m]>
oh thats a very long discussion :D
<dirbaio[m]>
hehe :D
<JamesMunns[m]>
(I'd love to have you both on a recorded chat to podcast about it :D)
<timonsku[m]>
that goes beyond of devicetree and is more about why are abstractions relevant at this level.
<timonsku[m]>
For embedded it goes beyond code and ties heavily into the hardware side of things which is affected by supply chains and other unrational factors
<timonsku[m]>
but yea happy to talk about that, I think chat room is probably not the best setting
<dirbaio[m]>
you can build the same abstractions with just Rust. the BSPs
<timonsku[m]>
but I think the tldr is that its not about changing but supporting 15 different variants at the same time for the same firmware
<dirbaio[m]>
at my company we have a single codebase for the firmware of 6 products, each with 4-5 revisions average
<dirbaio[m]>
the product/board/revision-specific code is concentrated in one corner of the codebase, the "BSPs"
<dirbaio[m]>
it contains all pin definitions, it instantiates all the drivers, and passes them to the "main" code
<dirbaio[m]>
main code can do stuff like #[cfg(has_nfc)] or #[cfg(has_buzzer)] to adapt to the different products' features
<timonsku[m]>
<dirbaio[m]> "the devicetree is also "code"" <- its more like a weird markup language really, if done today it would probably be json or something like that
<dirbaio[m]>
adding a new revision touches only the BSP, adding a new product touches mostly only the BSP unless the product has somthing really new that others didn't have
<dirbaio[m]>
that's sort of the "equivalent" of devicetree in my codebase
<dirbaio[m]>
and it's all Rust
<dirbaio[m]>
it works quite well
<timonsku[m]>
sure yea, I'd say thats how you would do it in C land too without something like devicetree
<sourcebox[m]>
dirbaio[m]: This is exactly what I'm doing. The difficulties start e.g. with generics that contain internals are passed to the business code.
<dirbaio[m]>
sourcebox[m]: you can use a HAL with less generics (like embassy 🙈), and/or type aliases
<dirbaio[m]>
even in the face of supply chain issues etc. different revisions have different chips that do the same thing, the BSPs abstract it so main code doesn't need to care
<sourcebox[m]>
In my concrete case, it's usb-device where the bus includes the ESP32 pins.
<sourcebox[m]>
And yes, a type alias can probably solve it.
<dirbaio[m]>
the HAL should choose to not include the pins in generics yep
<sourcebox[m]>
The long types don't matter that much as long as inference works, but as soon as you have to pass it to a function or store it in a struct...
<dirbaio[m]>
timonsku[m]: C can't do stuff like "check PA5 is not used twice" or "check PA5 is usable for SPI MISO" at compile time, so using devicetree *does* add a lot of value in the C case
<dirbaio[m]>
my argument is this is not the case with Rust
<dirbaio[m]>
so IMO the advantages don't outweigh the downsides of devicetree in Rust
<dirbaio[m]>
not as much, at least
<sourcebox[m]>
And most example don't run into that situation, because they just use the simple case of having just a main function.
<GrantM11235[m]>
I did some tinkering with an ESP32 board a while ago. Let's just say that it made me miss the generics-lite embassy HALs 😭
<sourcebox[m]>
But I have to say that the ESP team already eliminated a lot of generics.
<dirbaio[m]>
out with all generics 🔥
<sourcebox[m]>
There once was the situation that a GPIO pin used 5 or 6.
<GrantM11235[m]>
That's good to hear, I'll have to give it another look one of these days
<sourcebox[m]>
I think it was mostly danielb that worked on it initially.
<GrantM11235[m]>
My other annoyance was the PAC/HAL split, where you need to take the PAC, then pass parts of it to the HAL, then initialize it. The embassy way is much simpler where you just configure/initialize the HAL and then you are done
danielb[m] has joined #rust-embedded
<danielb[m]>
<GrantM11235[m]> "I did some tinkering with an ESP..." <- remember the times when gpios had like 7 generic parameters?
<dirbaio[m]>
7? 😱
<danielb[m]>
around that number
<sourcebox[m]>
That's what I remember, maybe 5 or 6.
Foxyloxy has joined #rust-embedded
mabez[m] has joined #rust-embedded
<mabez[m]>
And still much to improve
<mabez[m]>
Dark times those were 😅, glad they're gone
Foxyloxy_ has quit [Ping timeout: 260 seconds]
<sourcebox[m]>
But esp-hal is already quite usable. If the ADC stuff gets fixed, I'm mostly happy.
<JamesMunns[m]>
I think it's gone *if you use embassy*, but a lot of people don't end up there first. Either old tutorials, or "I don't want async yet" (and don't know it's not mandatory)
<mabez[m]>
<sourcebox[m]> "In my concrete case, it's usb-..." <- Just looked, there's no reason to include those types on the usb structure we can just use them in the constructor only. I'll take a look at that later
<JamesMunns[m]>
(again, we gotta be louder if we want misconceptions to go away!)
<sourcebox[m]>
A bit OT: maybe a traditional RTOS that plays nicely with embassy could be something that people used to FreeRTOS would like.
<timonsku[m]>
<dirbaio[m]> "so IMO the advantages don't..." <- oh sure but I wouldn't say thats what devicetree is about, if the language maps better to it I would say thats a better reason to use it, not worse :)
<timonsku[m]>
Thats one thing that made me interested in the talk, the proposition that you could map devicetree into native language structures without binary size overhead is very appealing over C.
<timonsku[m]>
You can totally invent a devicetree esque thing that is plain rust.
<timonsku[m]>
Personally I prefer supporting existing efforts if they do the job but thats a preference thing.
<GrantM11235[m]>
<GrantM11235[m]> "My other annoyance was the PAC/..." <- Is there any interest in moving the esp hals in this direction? The main downside is that you basically have to give up on mixing HALs "safely"
<dirbaio[m]>
> mixing HALs "safely"
<dirbaio[m]>
this has never worked. you need both hals to use the exact same PAC and version, and usually different HALs insist on e.g. managing clocks entirely themselves, causing conflicts.
<dirbaio[m]>
and people very rarely do that...?
<dirbaio[m]>
what is more common is mixing HAL and PAC
<dirbaio[m]>
PAC singletons ensure you as a user don't step on the HAL's toes
<dirbaio[m]>
but often you do want to step on HAL's toes to set some random bit the HAL doesn't yet have a config setting for...
<dirbaio[m]>
and still fails with e.g. using PA8 with the HAL and PA9 with the PAC. both are in GPIOA so you have to steal it anyway
<dirbaio[m]>
PAC singletons don't work
<mabez[m]>
<GrantM11235[m]> "Is there any interest in..." <- I'm not quite sure I follow, but in esp-hal we don't use PAC singletons, we use generated ones inside esp-hal itself. Am I missing something?
<GrantM11235[m]>
In embassy that would be a single line: let p = embassy_stm32::init(config);
<GrantM11235[m]>
As someone who hasn't read the full esp32c3 datasheet, most of those lines are meaningless to me. I imagine a newbie would be even more confused and scared 😱
<mabez[m]>
Ah okay I see, thanks! I think optimizing the "default config" is something we can improve. Of course if you want to do anything in your example like, maxing clocks you then need to delve into stm RCC specifics right?
<mabez[m]>
Well actually I know because I did it on an f2 for a project 😅
<barnabyw[m]>
similarly, when I got started with stm32f1xx_hal, it took me a long time to figure out what all the setup boilerplate did
<dirbaio[m]>
stm32 rcc is a giant pain
<diondokter[m]>
dirbaio[m]: Yeah, I made sure I got at least one U0 example that had the RCC configured to run at max speed. So annoying to figure out
<dirbaio[m]>
now that the code for it in the HALis okay-ish, I wanted to eventually change the defaults to do "as fast as possible on the chip, from HSI"
<dirbaio[m]>
which should always Just Work
<GrantM11235[m]>
All the clock configs are stored in the config struct that is passed to init. My example was a little unfair because I didn't show the monstrosity that created the config struct. embassy-stm32 doesn't have a way to just ask for the best/fastest config (yet)
<dirbaio[m]>
but that sitll won't be enough because in many cases you want to run from HSE and that varies board-to-board 😭
<mabez[m]>
That's good feedback though, thank you. On a side note we'll also be removing all the split extension traits soon, I hate them with a passion haha, so that will be one less line of boiler plate
<GrantM11235[m]>
btw that embassy-stm32 config would be a little bit cleaner if you could do ..Default::default() struct update syntax on non-exhaustive structs. I still don't understand why that's not allowed
<dirbaio[m]>
GrantM11235[m]: yeah right???
<dirbaio[m]>
there's some issues and IRLO threads about it... afaict there's no good reason to disallow it
<dirbaio[m]>
perhaps we should just remove non_exhaustives?
<dirbaio[m]>
so far every release is breaking anyway
<diondokter[m]>
Or add builder functions
<dirbaio[m]>
I despies builders 😬
<dirbaio[m]>
* I despise builders... 😬
<diondokter[m]>
haha
<dirbaio[m]>
dirbaio[m]: but in the future if things settle down it might be valuable to be able to add new config settings in minor releases
<dirbaio[m]>
feels wasteful to have to do a major release just for adding some random bit to some config :(
<GrantM11235[m]>
Yeah, other than this one issue, normal non-exhaustive structs Just Work and do everything that I would want a builder to do
<diondokter[m]>
Yeah, I'd keep it as is. Non-exhaustive is made for stuff like this
<dirbaio[m]>
yeah... like nonexhaustive is supposed to be "builders, but integrated into the language"
<GrantM11235[m]>
I really like the fact that it is just structs, not functions. It makes it clear that building the config doesn't actually do anything on it's own
<diondokter[m]>
Wait... going back to bsps... How would one config the `config.toml` so you can do `cargo run --feature my-board-rev2` and have it pick the correct target triple and probe-rs runner?
<diondokter[m]>
I don't think that's possible, right? Maybe cargo aliases (which I hate)?
<dirbaio[m]>
not possible, no (:
<dirbaio[m]>
* not possible, no :(
<diondokter[m]>
Hmmm
<GrantM11235[m]>
I have another minor ~~complaint~~ piece of feedback about the esp hals: in the beginning I forgot to call hal::embassy::init and it took me a while to figure out why my delays never returned. I think this would be solved if there was a unified hal::init that also initialized the embassy stuff if that feature is enabled
<GrantM11235[m]>
I'm also looking at the gpio types again. I have `GpioPin<Input<PullUp>, 9>`, which isn't *that* bad, but it's still not as clean as embassy's `Input<'a>`
<GrantM11235[m]>
Well anyway, keep up the good work and thanks for listening to my feedback!
AtleoS has quit [Ping timeout: 272 seconds]
netguru[m] has quit [Quit: Idle timeout reached: 172800s]
MiloMoisson[m] has quit [Quit: Idle timeout reached: 172800s]
<mabez[m]>
<GrantM11235[m]> "I have another minor ~~complaint..." <- Yeah I've run into that before hand too 😅
<diondokter[m]>
Yes, I agree with James Munns that we should have more embedded rust coms out there. So ehhh... oops :)