<ilpalazzo-ojiis4>
That was my first thought too, admittedly.
<ilpalazzo-ojiis4>
But --release compiles with opt-level = 3 and --debug compiles with opt-level = "s",
<ilpalazzo-ojiis4>
so unless --release somehow manages to produce a smaller binary than --debug then I can't see how that could be it.
<ilpalazzo-ojiis4>
That said, I changed --release to compile with opt-level = "s" too and nothing changed.
<ilpalazzo-ojiis4>
Setting strip to false changed nothing either.
<ilpalazzo-ojiis4>
lto is true in both changes… so the only explanation is that setting debug to true causes this.
<ilpalazzo-ojiis4>
I admit, I'm inclined to just ignore --debug.
<ilpalazzo-ojiis4>
(Side-note: OSHI— it just turned 04:00 AM.)
<M9names[m]>
Opt-level 3 does sometimes produce smaller binaries, that's not super surprising.
<M9names[m]>
Debug does range checks unless you turned that off, maybe those are typing you over the edge?
<ilpalazzo-ojiis4>
Could be.
<ilpalazzo-ojiis4>
BTW, is the error indeed “out of space”? I couldn't make heads or tails of it, in this case; that said, all the previous times I'd hit linker errors were indeed related to program size.
<cr1901>
ilpalazzo-ojiis4: This looks like a "you ran out of RAM for global variables" error.
<ilpalazzo-ojiis4>
wat
<ilpalazzo-ojiis4>
Hmmmmmmmmmmmmm
<cr1901>
The linker tried putting a bunch of global variables (not necessarily from _your_ application crate) into AVR data memory, ran out of room, and gave up.
<cr1901>
I see the ROM version of this error a lot on MSP430.
<ilpalazzo-ojiis4>
Could be, judging by what code caused this.
<cr1901>
debug w/ opt-level="s" is sometimes bigger than release w/ opt-level="s" too, at least in MSP430 land
starblue has quit [Ping timeout: 248 seconds]
<ilpalazzo-ojiis4>
Yes, that much is not surprising.
<ilpalazzo-ojiis4>
I, for one, am supremely hyped about it.
<ilpalazzo-ojiis4>
Are you part of Ferrous Systems as well?
<thejpster[m]>
yes
<ilpalazzo-ojiis4>
So, uh… are you guys hiring? I sent an e-mail to ask as much but no response has come as of yet.
<thejpster[m]>
where to?
<thejpster[m]>
* where did you send it to?
<ilpalazzo-ojiis4>
sales@ferrous-systems.com. Not exactly the ideal destination, but I wasn't able to find any other more relevant addresses in the web-site.
<thejpster[m]>
There's a button at the top that says "Get in Touch". You can then tick "Other inquiries"
<ilpalazzo-ojiis4>
I might as well.
<ilpalazzo-ojiis4>
Should I attach a CV, or wait until an affirmative response?
<thejpster[m]>
Either will work. Our hiring manager will reach out in due course but. I'm not aware of any open positions but it doesn't hurt to make yourself known.
<ilpalazzo-ojiis4>
Oh! Now that I had no idea about.
K900 has joined #rust-embedded
<K900>
Aren't you like five people
<K900>
Ferrous that is
<thejpster[m]>
19 and 3 pets last I checked
<K900>
Whoa
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
Rahix has quit [Server closed connection]
cr1901_ is now known as cr1901
Rahix has joined #rust-embedded
<cr1901>
and 3 pets last I checked <-- how many cats?
<ilpalazzo-ojiis4>
Asking the real questions here.
zagura has quit [Server closed connection]
zagura has joined #rust-embedded
hyphened[m] has joined #rust-embedded
<hyphened[m]>
Quick question
<hyphened[m]>
Is there any crate that encompasses all HAL traits?
<hyphened[m]>
Or at least the async ones?
<hyphened[m]>
Because right now I'm trying to implement a driver and I found myself tracking down the traits around in like 5 different crates
<hyphened[m]>
embassy-embedded-hal, embedded-hal-1, embedded-hal-async, embedded-hal-02 and embedded-hal-nb
<hyphened[m]>
And there is also the embassy-hal-internal
<hyphened[m]>
BTW this is not a rant
<ryan-summers[m]>
The only "official" HAL traits are the rust-embedded embedded-hal traits (02). The 1.0 are currently in beta testing (release candidate)
<ryan-summers[m]>
Embassy traits are for embassy-only, so any non-embassy HAL won't implement them generally
<ryan-summers[m]>
* them generally, unless they were made for embassy
<dirbaio[m]>
these embassy crates don't define traits, they implement the embedded-hal ones
<ryan-summers[m]>
So I think the crate you're looking for is just embedded-hal and embedded-hal-async
<ryan-summers[m]>
* So I think the crate you're looking for is just embedded-hal and embedded-hal-async respectively
<dirbaio[m]>
(and you're not supposed to use embassy-internal, it's internal-use-only :) )
<dirbaio[m]>
what driver are you writing?
<dirbaio[m]>
typically you need to depend on either embedded-hal 1.0 if you want to make it blocking, or embedded-hal-async 1.0 if you want to make it async
<hyphened[m]>
dirbaio[m]: I'm looking for SpiDevice but the RP2040 embassy crate does not expose it, should I use the structs in those crates
<dirbaio[m]>
are you writing a driver for an SPI chip?
<dirbaio[m]>
or using an existing driver?
<hyphened[m]>
dirbaio[m]: I know, but I was getting a bit puzzled at this point 🥴
<hyphened[m]>
I'm creating an async driver for the NRF24L01
<hyphened[m]>
With independent data streams for reception, to use them from different tasks
<dirbaio[m]>
okya
<hyphened[m]>
dirbaio[m]: Did not find any for async, all blocking
<dirbaio[m]>
then on the driver side you need just embedded-hal-async
<dirbaio[m]>
use embedded_hal_async::SpiDevice;
<dirbaio[m]>
struct MyDriver<S: SpiDevice> { ...}
<dirbaio[m]>
on the user side (the crate that uses the driver, not the driver crate itself) you need to supply an SpiDevice implementation
<hyphened[m]>
dirbaio[m]: Okay, that's the step in which I should use the `embedded-hal-async` trait with the `embassy-embedded-hal` SPI device struct
<dirbaio[m]>
there's 2 crates that provide this currently: