<Farooq>
<okhsunrog[m]> "have you considered using..." <- nope I want to stay bare metal for now
<Farooq>
<RobWells[m]> "Would the timer interrupt..." <- So in general the right way to do something periodically are timers?
<JamesMunns[m]>
Farooq: embassy and rtic are still bare metal 🙂
<JamesMunns[m]>
Farooq: Yes
<Farooq>
JamesMunns[m]: they manage many things for me. Don't day?
<Farooq>
s/day/they/
<JamesMunns[m]>
They're really just libraries. They're like any library: they do things in a reasonable way. There's no "magic" to them.
<JamesMunns[m]>
you certainly don't *have* to use them!
<JamesMunns[m]>
But IMO it's easier to learn how to use them than re-invent them from scratch, which is actually a much more challenging thing to do for someone who is learning.
<rafael[m]>
Plenty of stuff to learn still with Embassy and hal being used in my experience 🙃 More rewarding though because things work and then one can dig deeper into stuff in whatever pace fits best.
<JamesMunns[m]>
yes, the library/libraries are handling things for you! But honestly in about the way you would want them to do so!
<JamesMunns[m]>
The same way using `heapless::Vec` handles logic for pushing/popping data for you - you COULD write it yourself if you wanted to! But you don't *have* to.
<Farooq>
hmm thanks
<Farooq>
I think I will use RTIC
<okhsunrog[m]>
are you worried about binary size or something else?
<okhsunrog[m]>
rtic and embassy take almost the same amount of flash, without using them you might save about a couple of KB, I don't think it will help you much, it will make your life miserable. using RTIC or embassy is nicer. if you're a beginner I'd recommend embassy, it has more examples, larger community and the HAL is better supported. although you can use embassy-stm32 hal with RTIC if you want to
andwass[m] has joined #rust-embedded
<andwass[m]>
I would just add that it isn't wrong per say to learn about the low-level stuff (peripherals, interrupts etc.), and at some point you will probably have to learn about it, but if you are new to embedded altogether there are so many other things to learn that the lowest-level gory details shouldn't be your priority if you can't help it.
<andwass[m]>
s/'t//
rainingmessages has quit [Quit: bye]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
I don't think pushing RTIC or embassy for this concept is appropriate
<firefrommoonligh>
Put the LED on a timer/interrupt
<firefrommoonligh>
* I don't think pushing RTIC or embassy (Suggesting a framework switch) for this question is appropriate.
<thejpster[m]>
> This means you can now use Rust on Arm Cortex-M4, Cortex-M4F, Cortex-M7, and Cortex-M7F processors in safety-critical contexts. These processors can be found as the primary compute element in a wide variety of industrial- and automotive-grade microcontrollers, but also as additional processing elements focused on safety or low-power efficiency within a larger System-on-Chip.
<thejpster[m]>
Which implies that we have found a way to run the Rust compiler test suite on those targets.
<JamesMunns[m]>
> Work is ongoing with partners on library certification, particularly of libcore. If you need libcore certified for your use case, and want to be one of the first users, please let us know!
<JamesMunns[m]>
Does anyone *not* need libcore for their use cases? :p
M9names[m] has joined #rust-embedded
<M9names[m]>
on hardware, or through the cursed qemu stuff you've been talking about?
diondokter[m] has joined #rust-embedded
<diondokter[m]>
thejpster[m]: Oh that's great! People have been asking about this and I always just say they should talk to you guys. Now I can just say it's supported :D
<diondokter[m]>
* supported :D (And still should talk to you guys :P)
<thejpster[m]>
JamesMunns[m]: You do not require a *certified* libcore - you can instead certify your application as a whole, containing the parts of libcore you require.
<JamesMunns[m]>
That makes sense!
<thejpster[m]>
but obviously having a pre-certified libcore makes that easier. Work in progress.
<JamesMunns[m]>
Same as any other crate you pull in, you ship it, you own it
<thejpster[m]>
M9names[m]: Well people generally don't like to talk about how they test and qualify their proprietary compilers.
<M9names[m]>
doesn
<JamesMunns[m]>
That's the Secret Sauce Recipe, I assume :D
<dirbaio[m]>
> In order to test this target, the build process will acquire a copy of our secret sauce from AWS. Ensure you’re authenticated, following the section in Setting up a local development environment if your environment is not yet set up.
<thejpster[m]>
if you haven't met userspace QEMU, it executes linux binaries compiled for an alien architecture, but running the userspace code in QEMU's emulation and then dispatches syscalls to your actual kernel
<thejpster[m]>
the kernel is clearly Linux - we've giving you Linux commands to install qemu. The alien CPU is Cortex-M4 - you can see that.
<thejpster[m]>
so look at the dependencies for libstd on Linux and you tell me which ones need changing to run on Cortex-M4.
<thejpster[m]>
In nightly releases (so, post 25.05) I will even ship you the pre-compiled thumbv7em-ferrocenecoretest-eabi libstd. So you can cargo run --target=thumbv7em-ferrocenecoretest-eabi and it just executes the binary and gives you standard out and everything. Or, you know, cargo test --target=thumbv7em-ferrocenecoretest-eabi.
whitequark[cis] has joined #rust-embedded
<whitequark[cis]>
thejpster[m]: (all of them?)
<Farooq>
@andwass:matrix.org @okhsunrogm:matrix.org the flash size is only 16KB. So yeah binary size is important. But the reason I'm trying an MCU is learning about low level hardware details. Not just do a project. STM32F0 is simple. So it won't be very hard to learn about low level stuff. I am also interested in coding directly in Assembly to directly talk to the hardware.
<diondokter[m]>
If you're 'just' learning and don't need to be productive, then just do what interests you the most!
<diondokter[m]>
But using embassy and/or rtic is what professional people do too
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
extrafofo has quit [Remote host closed the connection]
<Farooq>
Alright new nerd hole found: Run Evolutionary Machine Learning on STM32F0. As in directly train on the MCU
<Farooq>
or maybe F1
jfsimon has quit [Remote host closed the connection]
rom4ik has quit [Quit: bye]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.5.2]
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 252 seconds]
cr1901_ has quit [Ping timeout: 245 seconds]
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
<dirbaio[m]>
this is a bit offtopic but
<dirbaio[m]>
has anyone ever seen cargo install failing to replace a binary when running in CI?
<dirbaio[m]>
HAHAHA it's due to setting CARGO_TARGET_DIR when running cargo-install
<dirbaio[m]>
* HAHAHA it's due to setting CARGO_TARGET_DIR when running cargo install
<diondokter[m]>
Surely this is a cargo bug then, right?
<dirbaio[m]>
actully no, wtf
<dirbaio[m]>
yeah doing this fixed it CARGO_TARGET_DIR=/tmp/cargo-install-target cargo install --git https://github.com/Dirbaio/java-spaghetti --locked --rev 469dc3570ad76753b61e8c9760eaaada5a16f16d
<dirbaio[m]>
* yeah doing this fixed it CARGO_TARGET_DIR=/tmp/cargo-install-target cargo install --git https://github.com/Dirbaio/java-spaghetti --locked --rev 469dc3570ad76753b61e8c9760eaaada5a16f16d no it didn't
d34db33f has joined #rust-embedded
<dirbaio[m]>
* yeah doing this fixed it CARGO_TARGET_DIR=/tmp/cargo-install-target cargo install --git https://github.com/Dirbaio/java-spaghetti --locked --rev 469dc3570ad76753b61e8c9760eaaada5a16f16d no it didn't yes it did, just turns out there was another issue aside from this one
norineko has quit [Remote host closed the connection]
norineko has joined #rust-embedded
norineko has quit [Remote host closed the connection]
norineko has joined #rust-embedded
<dngrs[m]>
have you tried cargo binstall? (not sure if that helps but I usually default to using that)
<dngrs[m]>
oh wait nvm you're installing your own binary
Foxyloxy_ has quit [Read error: Connection reset by peer]