scott_ has joined #rust-embedded
scott_ is now known as astatine-mat
astatine-mat is now known as astatine-matt
astatine-matt has quit [Quit: Konversation terminated!]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
smach has joined #rust-embedded
smach has quit [Ping timeout: 256 seconds]
rardiol has quit [Ping timeout: 256 seconds]
<re_irc> <> I submitted this pull request and get approved: :)
<re_irc> <> Now we may develop RISC-V kernels (supervisor) and hypervisor using Rust standard library. In some situations we furtherly need `riscv` crate to control more registers than what the standard library supports.
Rahix has quit [Quit: ZNC -]
Rahix has joined #rust-embedded
<re_irc> <> Yes. `itm-decode` and the new `itm` library its using replaces the `itm-tools` repo.
<re_irc> <> (But it depends on some unreleased features of `cortex-m` at the moment)
<re_irc> <> anyone playing with linear algebra crates for bare metal without std lib?
richardeoin has quit [Ping timeout: 256 seconds]
richardeoin has joined #rust-embedded
rardiol has joined #rust-embedded
<re_irc> <> I'm working on a driver for a humidity and temperature sensor (sht40). It contains a heater element which could be activated with different power settings and for different time periods. My current attept is to specify enums for the valid power levels and periods like:
<re_irc> <> ```rust
<re_irc> <> Does anyone know about a common/better naming schemes for these type of enums? Abbreviating the unit in upper camel case makes them ambiguous (mW vs. MW).
<re_irc> <> pub enum HeatingPower { Milliwatts200, Milliwatts110, Milliwatts20 }
<re_irc> <> I've sometimes specified it as Power0p200 (SI 0.200, or zero-point-twohundred) or similar
<re_irc> <> I've come across this often. Maybe there should be a crate with SI types/type aliases? Or is there already?
<re_irc> <> Or you can just simplify it and say:
<re_irc> <> pub enum HeaterPower {
<re_irc> <> /// Configure the heater to operate at 200mW.
<re_irc> <> ```rust
<re_irc> <> Also, ask me how my result was off by a power of 9 when ordering resistors from Digikey
<re_irc> <> I've seen some for time-related units like microseconds as new type structs in [embedded-time]( but this is for "continuous" values an not for "discrete" ones like the three power settings.
<re_irc> <> Wait wait
<re_irc> <> Just use ΜWatts
<re_irc> <> If there's not a specific reason why the user needs to know the exact power level of the heater in code, I'd just use high/medium/low
<re_irc> <> And let docs be there for detailed info on tech specs
<re_irc> <> That's an uppercase μ, of course
<re_irc> <> This looks pretty darn good. :)
<re_irc> <> Oh wait wrong OOM
<re_irc> <> This will let the sensor take off to another world ... :-D
<re_irc> <> No no no, I was off in the wrong direction
<re_irc> <> Just kidding. You mean `uwatts`, right? ryan-summers' proposal removes a lot of ambiguity and the user has to deal with converting an actual power value to an enum item anyway.
<re_irc> <> Agree. Well-documented enums are a stable
<re_irc> <> Unicode brings special code points for units to bother the users with: u+33bd for mW - so `㎽200` should be a valid enum item. ;-)
<re_irc> <> I would personally hate using non-ascii in an enum....
<re_irc> <> Yea just use mW200 and tell clippy to shut up about camel case
<re_irc> <> (but I like low/medium/high even more)
<re_irc> <> Actually that
<re_irc> <> I try to adhere to language naming conventions, but make excpetions for things like this
<re_irc> <> Specifically, I agree on using scientific or domain-specific conventions over language conventions, and silencing the warning
<re_irc> <> `#![allow(non_snake_case)]` etc
<re_irc> <> See also:
<re_irc> <> ```rust
<re_irc> <> const τ: f32 = 2. * core::f32::consts::PI;
<re_irc> <> better known as `core::f32::consts::TAU`?
<re_irc> <> OH FUCK
<re_irc> <> honestly I'm surprised it doesn't lint that, if you try `const PI: f64 = 3.14159...;` then clippy will say "error: approximate value of `f64::consts::PI` found" and suggest you refer to consts::PI instead
<re_irc> <> I guess it's not quite smart enough to see through the multiplication :P
<re_irc> <> Or I haven't actually tried that in Rust
<re_irc> <> Not sure!
rardiol has quit [*.net *.split]
Rahix has quit [*.net *.split]
Amadiro has quit [*.net *.split]
Socke has quit [*.net *.split]
richardeoin has quit [*.net *.split]
Shell has quit [*.net *.split]
inara has quit [*.net *.split]
cr1901 has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
edm has quit [*.net *.split]
fooker has quit [*.net *.split]
jackneillll has quit [*.net *.split]
emerent has quit [*.net *.split]
ni has quit [*.net *.split]
bpye has quit [*.net *.split]
kehvo has quit [*.net *.split]
re_irc has quit [*.net *.split]
dreamcat4 has quit [*.net *.split]
sauce has quit [*.net *.split]
Ekho has quit [*.net *.split]
cyrozap has quit [*.net *.split]
hifi has quit [*.net *.split]
creich has quit [*.net *.split]
mightypork_ has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
wose has quit [*.net *.split]
Amanieu has quit [*.net *.split]
tafa has quit [*.net *.split]
jasperw has quit [*.net *.split]
Darius has quit [*.net *.split]
rektide has quit [*.net *.split]
eigenform has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
vancz has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
xnor has quit [*.net *.split]
darknighte has quit [*.net *.split]
dne has quit [*.net *.split]
Rondom has quit [*.net *.split]
mrkajetanp has quit [*.net *.split]
x56 has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
Ekho has joined #rust-embedded
GenTooMan has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
cyrozap has joined #rust-embedded
dreamcat4 has joined #rust-embedded
xnor has joined #rust-embedded
kehvo has joined #rust-embedded
sauce has joined #rust-embedded
fooker has joined #rust-embedded
edm has joined #rust-embedded
bpye has joined #rust-embedded
Rahix has joined #rust-embedded
re_irc has joined #rust-embedded
Amadiro has joined #rust-embedded
Socke has joined #rust-embedded
rardiol has joined #rust-embedded
emerent has joined #rust-embedded
ni has joined #rust-embedded
richardeoin has joined #rust-embedded
Shell has joined #rust-embedded
jackneillll has joined #rust-embedded
inara has joined #rust-embedded
cr1901 has joined #rust-embedded
darknighte has joined #rust-embedded
dne has joined #rust-embedded
Rondom has joined #rust-embedded
jasperw has joined #rust-embedded
rektide has joined #rust-embedded
Darius has joined #rust-embedded
eigenform has joined #rust-embedded
tafa has joined #rust-embedded
Lumpio- has joined #rust-embedded
vancz has joined #rust-embedded
hifi has joined #rust-embedded
creich has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
Foxyloxy has joined #rust-embedded
wose has joined #rust-embedded
Amanieu has joined #rust-embedded
x56 has joined #rust-embedded
mrkajetanp has joined #rust-embedded
mightypork_ has joined #rust-embedded
<re_irc> <> I have an English problem. Should I use 'unreference' or 'dereference'?
<re_irc> <> Thank you very much for your input on the enums! It's making progress and I've got the next question related to style. Does anyone consider the following awkward:
<re_irc> <> * Just having a `measurement` method in the driver interface returning `RawSensorData`
<re_irc> <> * Providing the conversion to physical values in separate structs like `FixedSensorData`, `FloatSensorData`, ... all impementing `From<RawSensorData>`
<re_irc> <> This keeps the driver interface small while allowing to convert the raw sensor data in a variety of tastes. See [here]( for the complete wip).
<re_irc> <> I always use dereference, also there is trait `Deref`, but what's the context?
<re_irc> <> Generally, I'd say "dereferenced", as in "I want to dereference this pointer to get the underlying object"
<re_irc> <> If you are referring to dealing with a reference to something, its _dereference_ like in the `Deref` trait.
<re_irc> <> I'd personally think about why anyone would want the raw data. If you have a real use case (not hypothetical), I'd provide a `read_raw()` that gets called internally in `measure()` and have `measure()` return SI measurements
<re_irc> <> Thank you all :) Should be dereference to be consistent.
<re_irc> <> "dereference" is like follow the pointer to the thing.
<re_irc> <> "unreference" is more like make the pointer to the thing go away, so there is no longer a pointer (a reference) to the thing.
<re_irc> <> You could say a leaked heap object could be "unrefernced".
<re_irc> <> Thank you! I see your point. When just returning a single type of measurement, my gut instinct directs me toward a binary fixed-point value (`I16F16`) which can be handled decently even on MCUs without FPU. They can be converted trivially into floating point. Even a decimal fixed-point representation like _milli degree celsius_ could be done with some thoughts or i still provide a...
<re_irc> ... suitable conversion as sugar topping. What do you think?
<re_irc> <> It seriously depends on your intended use case. Even on lower end processors, moving it into a float for a short period of time isn't a huge processor cost, although it can bloat code
<re_irc> <> I still use floats on an MSP430 (16 bit, 12MHz) without too much issue (although I do not do floating math, I internally convert to fixed, Q format before doing that)
<re_irc> <> I'd personally leave conversion to fixed point for easy manipulation up to the application users. I don't think actually converting a number from fixed -> float is costly, as long as you avoid the float math internally
<re_irc> <> Although I could be wrong on that front. Like I said, it all depends on intended audience. Nowadays, floating point units are pretty common even on pretty low end processors
<re_irc> <> I'd just design it how you need it and omit raw fixed point unless you have to have it. Someone can PR/open an issue if they need something else
<re_irc> <> I'm actually targetting an esp32c3 and i have a m0+ in mind and i want to play nice with them with regard to code bloat. These targets were triggering me to check for fixed-point options which i've seen for example for the nrf52's internal temperature sensor.
<re_irc> <> For not exposing raw fixed point numbers, the `fixed` crate looks good at a first glance and i don't expect noticeable overhad from using its types.
<re_irc> <> Ah the M0 doesnt have an FPU - I had forgotten that
<re_irc> <> Thanks for this insight! I did not dare them to perform well in this scenario. :)
<re_irc> <> This is a pretty good point! I think i will go for `I16F16` and leave introducing the _milli degree celsius_ which is commonly used in sensirions c drivers to future prs.
<re_irc> <> 🙏
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <> Hey everyone! Long time no see! Happy New Year!! Haven't been online for a while but with the start of the year I just wanted to drop by and say thanks for all the work done by the WG and the great community around embedded Rust :D
starblue has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc> <> yay, it's extremely basic but i got an LED blinking from a risc-v softcore running rust on an fpga 🚀
<re_irc> <> i miss `cortex_m::asm::delay()` though 😢
<re_irc> <> 924 bytes of firmware just fits in my 1kB PROM
<re_irc> <> this was on my "christmas projects list" so it's ticked off at the eleventh hour :D
<re_irc> <> adamgreig: nice! did you build the softcore yourself or did you "only" (in big quotes) have to get the toolchains to behave well enough to flash an existing project?
<re_irc> <> I am using the minerva softcore for ease of integration
<re_irc> <> whole thing took about 1h from "mkdir rv" to blinking so ntb i think
<re_irc> <> oh that's quite alright
<re_irc> <> the whole gateware is about 50 lines of python:
<re_irc> <> and 20 awkward lines of rust
<re_irc> <> I don't think my wishbone to bram interface is, uh, "compliant"
<re_irc> <> but it's enough that it successfully reads code on the ibus and reads and writes memory on the dbus, so...
<re_irc> <> haha, null pointer reads as a delay unit
<re_irc> <> toolchain pain is essentially zero, amaranth handles all the yosys+nextpnr wrangling, and rust of course makes the rust side insanely easy
<re_irc> <> I don't even have a riscv gcc/binutils installed
<re_irc> <> I've never actually used amaranth, but standalone ghdl+yosys+nextpnr can be quite an experience
<re_irc> <> yea, and all the cool risc-v cores are in weird HDLs now, right? vexriscv looks like an experience to build yourself
<re_irc> <> picorv32 probably easier and it's not too hard to add some verilog files to the amaranth build, but minerva already being in amaranth was the easiest possible
<re_irc> <> is there a better "nop"? I was looking for an equivalent to cortex_m::asm::nop (or delay) but didn't find anything in the `riscv` crate
<re_irc> <> maybe it's in core::arch instead...
<re_irc> <> riscv does have a canonical "nop", I think it's `add r0, r0, r0` or something like that?
<re_irc> <> didn't want to break out the nightly compiler for inline asm if i could help it
<re_irc> <> but yea apparently `nop` is a pseudoinstruction that expands to `addi x0 x0 0`, I have just read
<re_irc> <> ah yes, that
<re_irc> <> > > <> haha, null pointer reads as a delay unit
<re_irc> <> > is there a better "nop"? I was looking for an equivalent to cortex_m::asm::nop (or delay) but didn't find anything in the `riscv` crate
<re_irc> <> I can look into adding `asm::nop` and `asm::delay` to the `riscv` crate.
<re_irc> <> I don't know if there's some good reason it's not there or it's actually present elsewhere or something
<re_irc> <> but would be handy to have for this very basic getting-started stuff!
<re_irc> <> I agree, I will look into it 🙂
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc> <> any tips trying to make sense of generated asm code vs. my rust source? the `--release` version seems to inline many things, which makes it hard to troubleshoot
<re_irc> <> trying to debug a problem that only occurs in release builds?
<re_irc> <> xiretza: yeah, basically
<re_irc> <> that's never fun - one thing you can try is to change the cargo release profile to be the same as the debug profile step-by-step
<re_irc> <> yeah, i tried that, but wasn't that successful
<re_irc> <> Can you add `#[inline(never)]` in certain spots to help narrow it down?
<re_irc> <> Ohh. I didn't know about that one. Thanks!
<re_irc> <> adamgreig: This got me thinking... what if Rust became the de-facto standard for setting up openfpga projects with riscv softcores? Haha jk...unless ????? 👀👀👀
<re_irc> <> Wow. The compiler translates the address of the DMA peripheral into two instructions that basically do 5 << 28. Neat.
starblue has quit [Ping timeout: 256 seconds]
jringstad__ has joined #rust-embedded
Amadiro has quit [Remote host closed the connection]
smach has joined #rust-embedded