ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
sarath08071994[m has joined #rust-embedded
<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.
<M9names[m]> Then you need to set linker flags as appropriate for your SDK inside your .cargo/config.toml.
<M9names[m]> You'll need to find those out yourself, they are likely to be environment variables that will be set when you activate that environment.
<sarath08071994[m> Ok, thank you I will check that.
AtleoS has joined #rust-embedded
pilipbeta[m] has quit [Quit: Idle timeout reached: 172800s]
<sarath08071994[m> There are no target "arm-oe-linux-gnueabi" on the rust supported targets. So which target I have use instead of this.
<JamesMunns[m]> what does the oe part stand for?
<JamesMunns[m]> `armv7-unknown-linux-gnueabi` is for "basically any flavor of linux"
<sarath08071994[m> openEmbedded
<sarath08071994[m> JamesMunns[m]: Ok๐Ÿ‘
<JamesMunns[m]> You might want if you end up needing to link in dynamic libraries. You also mentioned OpenEmbedded, so the meta-rust layer might also help you:
<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]
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 260 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
timonsku[m] has joined #rust-embedded
<timonsku[m]> starting in 30min there is a talk on the state of Rust in Zephyr at EOSS:
<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
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]> (insert obligatory "embassy fixes this" here)
<dirbaio[m]> lol
<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 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]: > <> Another thing that came up today in a meeting was the issue of dependencies and 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 <>)
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]> Yeah we're having a Zephyr Vs Embassy Vs PlatformIO fight at work atm
<juliand[m]> JamesMunns[m]: > <> yeah, the options are:... (full message at <>)
<GrantM11235[m]> JamesMunns[m]: speaking of which, I saw this announcement on twitter, but I don't know if it has been mentioned here. Congrats to dirbaio !
<thejpster[m]> juliand: it's on the 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/