<re_irc>
<@luojia65:matrix.org> 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.
<re_irc>
<@tmplt:matrix.org> monacoprinsen:matrix.org: Yes. `itm-decode` and the new `itm` library its using replaces the `itm-tools` repo. https://github.com/rtic-scope/itm
<re_irc>
<@tmplt:matrix.org> (But it depends on some unreleased features of `cortex-m` at the moment)
<re_irc>
<@fragadaleta:matrix.org> 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>
<@sirhcel:matrix.org> 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>
<@sirhcel:matrix.org> ```rust
<re_irc>
<@sirhcel:matrix.org> 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>
<@firefrommoonlight:matrix.org> Just use ΜWatts
<re_irc>
<@ryan-summers:matrix.org> 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>
<@ryan-summers:matrix.org> And let docs be there for detailed info on tech specs
<re_irc>
<@firefrommoonlight:matrix.org> That's an uppercase μ, of course
<re_irc>
<@sirhcel:matrix.org> ryan-summers:matrix.org: This looks pretty darn good. :)
<re_irc>
<@sirhcel:matrix.org> firefrommoonlight:matrix.org: This will let the sensor take off to another world ... :-D
<re_irc>
<@firefrommoonlight:matrix.org> No no no, I was off in the wrong direction
<re_irc>
<@sirhcel:matrix.org> 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>
<@firefrommoonlight:matrix.org> Agree. Well-documented enums are a stable
<re_irc>
<@sirhcel:matrix.org> 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>
<@ryan-summers:matrix.org> I would personally hate using non-ascii in an enum....
<re_irc>
<@adamgreig:matrix.org> Yea just use mW200 and tell clippy to shut up about camel case
<re_irc>
<@adamgreig:matrix.org> (but I like low/medium/high even more)
<re_irc>
<@firefrommoonlight:matrix.org> Actually that
<re_irc>
<@firefrommoonlight:matrix.org> I try to adhere to language naming conventions, but make excpetions for things like this
<re_irc>
<@firefrommoonlight:matrix.org> Specifically, I agree on using scientific or domain-specific conventions over language conventions, and silencing the warning
<re_irc>
<@adamgreig:matrix.org> better known as `core::f32::consts::TAU`?
<re_irc>
<@firefrommoonlight:matrix.org> OH FUCK
<re_irc>
<@adamgreig:matrix.org> 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>
<@adamgreig:matrix.org> I guess it's not quite smart enough to see through the multiplication :P
<re_irc>
<@firefrommoonlight:matrix.org> Or I haven't actually tried that in Rust
<re_irc>
<@firefrommoonlight:matrix.org> 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>
<@luojia65:matrix.org> I have an English problem. Should I use 'unreference' or 'dereference'?
<re_irc>
<@sirhcel:matrix.org> 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>
<@sirhcel:matrix.org> * Just having a `measurement` method in the driver interface returning `RawSensorData`
<re_irc>
<@sirhcel:matrix.org> * Providing the conversion to physical values in separate structs like `FixedSensorData`, `FloatSensorData`, ... all impementing `From<RawSensorData>`
<re_irc>
<@barafael:matrix.org> I always use dereference, also there is trait `Deref`, but what's the context?
<re_irc>
<@ryan-summers:matrix.org> luojia65:matrix.org: Generally, I'd say "dereferenced", as in "I want to dereference this pointer to get the underlying object"
<re_irc>
<@sirhcel:matrix.org> luojia65:matrix.org: If you are referring to dealing with a reference to something, its _dereference_ like in the `Deref` trait.
<re_irc>
<@ryan-summers:matrix.org> sirhcel:matrix.org: 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>
<@luojia65:matrix.org> Thank you all :) Should be dereference to be consistent.
<re_irc>
<@dalepsmith:matrix.org> "dereference" is like follow the pointer to the thing.
<re_irc>
<@dalepsmith:matrix.org> "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>
<@dalepsmith:matrix.org> You could say a leaked heap object could be "unrefernced".
<re_irc>
<@sirhcel:matrix.org> ryan-summers:matrix.org: 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>
<@ryan-summers:matrix.org> 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>
<@ryan-summers:matrix.org> 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>
<@ryan-summers:matrix.org> 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>
<@ryan-summers:matrix.org> 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>
<@ryan-summers:matrix.org> 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>
<@sirhcel:matrix.org> 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>
<@sirhcel:matrix.org> 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>
<@ryan-summers:matrix.org> Ah the M0 doesnt have an FPU - I had forgotten that
<re_irc>
<@sirhcel:matrix.org> ryan-summers:matrix.org: Thanks for this insight! I did not dare them to perform well in this scenario. :)
<re_irc>
<@sirhcel:matrix.org> ryan-summers:matrix.org: 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>
<@sirhcel:matrix.org> 🙏
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@jorgeig:matrix.org> 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>
<@adamgreig:matrix.org> yay, it's extremely basic but i got an LED blinking from a risc-v softcore running rust on an fpga 🚀
<re_irc>
<@adamgreig:matrix.org> i miss `cortex_m::asm::delay()` though 😢
<re_irc>
<@adamgreig:matrix.org> 924 bytes of firmware just fits in my 1kB PROM
<re_irc>
<@adamgreig:matrix.org> this was on my "christmas projects list" so it's ticked off at the eleventh hour :D
<re_irc>
<@xiretza:xiretza.xyz> 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>
<@adamgreig:matrix.org> I am using the minerva softcore for ease of integration
<re_irc>
<@adamgreig:matrix.org> whole thing took about 1h from "mkdir rv" to blinking so ntb i think
<re_irc>
<@adamgreig:matrix.org> I don't think my wishbone to bram interface is, uh, "compliant"
<re_irc>
<@adamgreig:matrix.org> but it's enough that it successfully reads code on the ibus and reads and writes memory on the dbus, so...
<re_irc>
<@xiretza:xiretza.xyz> haha, null pointer reads as a delay unit
<re_irc>
<@adamgreig:matrix.org> toolchain pain is essentially zero, amaranth handles all the yosys+nextpnr wrangling, and rust of course makes the rust side insanely easy
<re_irc>
<@adamgreig:matrix.org> I don't even have a riscv gcc/binutils installed
<re_irc>
<@xiretza:xiretza.xyz> I've never actually used amaranth, but standalone ghdl+yosys+nextpnr can be quite an experience
<re_irc>
<@adamgreig:matrix.org> yea, and all the cool risc-v cores are in weird HDLs now, right? vexriscv looks like an experience to build yourself
<re_irc>
<@adamgreig:matrix.org> 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>
<@adamgreig:matrix.org> xiretza:xiretza.xyz: 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>
<@adamgreig:matrix.org> maybe it's in core::arch instead...
<re_irc>
<@xiretza:xiretza.xyz> riscv does have a canonical "nop", I think it's `add r0, r0, r0` or something like that?
<re_irc>
<@adamgreig:matrix.org> didn't want to break out the nightly compiler for inline asm if i could help it
<re_irc>
<@adamgreig:matrix.org> but yea apparently `nop` is a pseudoinstruction that expands to `addi x0 x0 0`, I have just read
<re_irc>
<@xiretza:xiretza.xyz> ah yes, that
<re_irc>
<@dkhayes117:matrix.org> > > <xiretza:xiretza.xyz> haha, null pointer reads as a delay unit
<re_irc>
<@dkhayes117:matrix.org> > 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>
<@dkhayes117:matrix.org> I can look into adding `asm::nop` and `asm::delay` to the `riscv` crate.
<re_irc>
<@adamgreig:matrix.org> I don't know if there's some good reason it's not there or it's actually present elsewhere or something
<re_irc>
<@adamgreig:matrix.org> but would be handy to have for this very basic getting-started stuff!
<re_irc>
<@dkhayes117:matrix.org> I agree, I will look into it 🙂
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc>
<@ubik:matrix.org> 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>
<@xiretza:xiretza.xyz> ubik:matrix.org: trying to debug a problem that only occurs in release builds?
<re_irc>
<@xiretza:xiretza.xyz> 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>
<@ubik:matrix.org> yeah, i tried that, but wasn't that successful
<re_irc>
<@dkhayes117:matrix.org> Can you add `#[inline(never)]` in certain spots to help narrow it down?
<re_irc>
<@ubik:matrix.org> dkhayes117:matrix.org: Ohh. I didn't know about that one. Thanks!
<re_irc>
<@josfemova:matrix.org> 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>
<@ubik:matrix.org> 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]