fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
richarde1 has joined #rust-embedded
richardeoin has quit [Ping timeout: 260 seconds]
<re_irc>
<@1c3t3a:matrix.org> Hey there! Does anyone know if there's a general purpose RiscV Allocator crate out there? Similar to alloc-cortex-m?
fabic has quit [Ping timeout: 258 seconds]
<re_irc>
<@9names:matrix.org> the cortex_m specific stuff is just a couple of calls to cortex_m::interrupt::free, which you could swap for riscv::interrupt::free
<re_irc>
<@9names:matrix.org> i wonder if it would be worth porting it to critical_section instead to make a truly generic allocator
<re_irc>
<@1c3t3a:matrix.org> Yep, that's what I just did. Maybe that might be a good idea, the cortex_m code is really only the critical section part!
<re_irc>
<@ryan-summers:matrix.org> Is it possible to have a no-std crate in the same workspace as a std-crate?
<re_irc>
<@ryan-summers:matrix.org> Context: I want to have a std-enabled host-side client for an embedded-firmware crate in the same repo
fabic has joined #rust-embedded
<re_irc>
<@1c3t3a:matrix.org> You could do this with a shared workspace (https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html). Just create the two crates in a folder, and then create a Cargo.toml file in the top level folder (where both of them live). Then you could define the workspace in the toplevel Cargo.toml:
<re_irc>
<@9names:matrix.org> we're talking about something different here Bastian
<re_irc>
<@9names:matrix.org> specifically that cargo tries to include std stuff in your no_std crate if it shares a workspace
<re_irc>
<@9names:matrix.org> i think it's still problematic, haven't seen any news that it's changed since someone brought it up last
<re_irc>
<@jordens:matrix.org> May have changed with the new cargo `resolver="2"`?
<re_irc>
<@9names:matrix.org> i haven't tested it since resolver="2" became a thing so that's definitely possible
fabic has quit [Ping timeout: 260 seconds]
<Lumpio->
I've had std and no_std crates in the same workspace and haven't had that problem
<Lumpio->
So it might be dependent on your deps or whatever, and the resolver
<re_irc>
<@dirbaio:matrix.org> if your std-using crate has a dep with `std` feature enabled, and your nostd crate wants the same dep but without `std` feature enabled, it breaks
<re_irc>
<@dirbaio:matrix.org> because cargo workspaces resolve deps' features for all workspace crates "together"
<re_irc>
<@dirbaio:matrix.org> so you end up with `std` enabled for the dep of the nostd crate
<re_irc>
<@dirbaio:matrix.org> and there's no way around that
<re_irc>
<@dirbaio:matrix.org> you simply can't put them in the same workspace
<re_irc>
<@jordens:matrix.org> the cargo docs seem to claim that you can condition e.g. std features on build target.
<re_irc>
<@dirbaio:matrix.org> resolver=2 doesn't fix it (that's only for dev-deps/build-deps. "main" deps still get features merged)
<re_irc>
<@dirbaio:matrix.org> hm
<re_irc>
<@dirbaio:matrix.org> maybe you can rig the std-using crate so it only requires `std` features on deps when building for std
<re_irc>
<@dirbaio:matrix.org> but that makes cargo.toml super ugly, for something you're not going to build for nostd anyway
<re_irc>
<@jordens:matrix.org> Maybe instead use one repo with three or more crates (`shared`, `no_std`, `std`) and no top level workspace.
<re_irc>
<@ryan-summers:matrix.org> Yeah, that's what I was leaning towards as well
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 258 seconds]
<re_irc>
<@halfbit:matrix.org> did anyone end up building a bootloader that's rust friendly? seems like that has been an ongoing thing
<re_irc>
<@halfbit:matrix.org> noticing some nice blog posts on PIC code for cortex-m and such, so maybe even can have multiple slots without moving them around like seems to be the usual strategy
<re_irc>
<@ruabmbua:matrix.org> Not sure, if I am asking in the best room here, but:
<re_irc>
<@ruabmbua:matrix.org> Is anyone aware of a crate, which provides a more advanced config system for cargo / rust? I currently have a custom xtask crate for my project, where I do all the stuff, that cargo can`t really do for me.
<re_irc>
<@ruabmbua:matrix.org> Now I want to implement a config system, where I am able to do more advanced configurations. Cargo is rather limited, there is for example no way, to pass e.g. a numeric cfg etc...
<re_irc>
<@ruabmbua:matrix.org> The obvious thing would be something generating a config.rs module.
<re_irc>
<@ruabmbua:matrix.org> I am currently thinking of adapting a python kconfig implementation, and modify it to spit out rust files. Something more rusty (pure rust) would be nicer :P
<re_irc>
<@ruabmbua:matrix.org> Yes, thats the way I want to do it. I am specifically asking for any crates, which help with config file parsing & code generation.
<re_irc>
<@ryan-summers:matrix.org> Perhaps look into `syn`, although that's more used for proc-macros and such
<re_irc>
<@ryan-summers:matrix.org> But it's a general programmatic approach to generating rust code
<re_irc>
<@ruabmbua:matrix.org> I will probably just use my own toml based cfg format, then generate a config.rs
<re_irc>
<@ruabmbua:matrix.org> Problem is, that the config can potentially get really complex, and I`d like to define the schema of the config (e.g. which cfg values etc... are available) also with toml.
<re_irc>
<@lachlansneff:matrix.org> How mature is the stm32l4 crate? It says work in progress, but does that mean unusable or almost ready for professional use?
richarde1 is now known as richardeoin
<re_irc>
<@newam:matrix.org> Generally for professional embedded you'll end up forking every dependency anyway.
<re_irc>
<@lachlansneff:matrix.org> adamgreig: You mentioned 0.8mm pitch BGA at one point—is there any way to determine if a chip has a bga pitch that big without looking all the way down at the datasheet?
<re_irc>
<@dirbaio:matrix.org> newam:matrix.org: That's a sad truth!
<re_irc>
<@dirbaio:matrix.org> why is that, in general? Experiences, thoughts? I'm curious if there's stuff we can do to make that less frequent
<re_irc>
<@dirbaio:matrix.org> faster PR reviews?
<re_irc>
<@adamgreig:matrix.org> lachlansneff:matrix.org: Sometimes it will say in the package name, distributor websites often have it as a data column, st website has it on their part finder etc, but the datasheet is the place eventually...
<re_irc>
<@newam:matrix.org> dirbaio:matrix.org: Not enough compile time configuration in the language yet. In C you can have headers for a user of a library to fill in, and those will const propagate in GCC. Rust has a long way to go for that level of configurability with `const`.
<re_irc>
<@newam:matrix.org> Faster PRs is another. Also more frequent releases when a PR is merged, switching to a git version for a bugfix is the gateway to forking.
<re_irc>
<@newam:matrix.org> That said, the forking situation is still a lot better in embedded rust than embedded C.
<re_irc>
<@ruabmbua:matrix.org> can anyone recommend a no_std deflate crate?
<re_irc>
<@firefrommoonlight:matrix.org> What's the best way to get random numbers in rust embedded? It seems like most of the relevant features don't work with the `rand` crate with default_features set. Eg generate a random number between 0 and 1
<re_irc>
<@firefrommoonlight:matrix.org> Maybe that's what the hardware periphs ar for?
<re_irc>
<@dirbaio:matrix.org> ruabmbua:matrix.org: for decompression-only I'm using [uzlib](https://github.com/pfalcon/uzlib) (C library, not crate). All the crates I tried had at the very least 4x code size. I didn't compare performance since uzlib was fast enough
<re_irc>
<@ruabmbua:matrix.org> firefrommoonlight: you want a pseudo random number generator.The rand crate can be used in no_std and it provides pseudo random number generators
<re_irc>
<@ruabmbua:matrix.org> you just need to seed it with *proper randomness* which might be hard depending on your HW
<re_irc>
<@dirbaio:matrix.org> use hwrng if it's fast enough for your use case, otherwise use it to seed a ChaCha12Rng :P
<re_irc>
<@ruabmbua:matrix.org> dirbaio: ok thanks. Was considering zlib already, have some experience with it in embedded. Will look into uzlib
<re_irc>
<@firefrommoonlight:matrix.org> Oh nice
<re_irc>
<@dirbaio:matrix.org> the impression I got is everyone optimizes for performance, uzlib is the only one optimizing for code size
<re_irc>
<@firefrommoonlight:matrix.org> Should I just use the STM32 (etc) RNG periph?
<re_irc>
<@firefrommoonlight:matrix.org> or would that be used in addition to rand with the seed?
<re_irc>
<@dirbaio:matrix.org> check datasheet for speed
<re_irc>
<@dirbaio:matrix.org> some HWRNGs are super slow
<re_irc>
<@dirbaio:matrix.org> stm32's (at least some) are fast though
<re_irc>
<@firefrommoonlight:matrix.org> sweet
<re_irc>
<@dirbaio:matrix.org> in that case chacha is probably not worth it
<re_irc>
<@adamgreig:matrix.org> though stm32 rng peripheral gives you a u32 that's distributed uniformly at random between 0 and 0xffff_ffff
<re_irc>
<@adamgreig:matrix.org> if you want a random float between 0 and 1 you have to take care of that yourself, for example
<re_irc>
<@adamgreig:matrix.org> while rand etc has algorithms for sampling various distributions of interest given some source of uniform randomness
<re_irc>
<@adamgreig:matrix.org> doing this yourself is an easy thing to mess up
<re_irc>
<@adamgreig:matrix.org> (depends on how much it matters of course...)
<re_irc>
<@ruabmbua:matrix.org> yeah, use something from rand and seed it with the HW for simplicity.
<re_irc>
<@adamgreig:matrix.org> yea. that also saves worrying about sharing access to the rng and so on
<re_irc>
<@dirbaio:matrix.org> is there something that can do "random float between 0 and 1", out of a RngCore?
<re_irc>
<@dirbaio:matrix.org> that'd be helpful since HALs implement (or should) RngCore
<re_irc>
<@adamgreig:matrix.org> `rand`?
<re_irc>
<@firefrommoonlight:matrix.org> I think the int would actually be what I want; that's perfect
<re_irc>
<@firefrommoonlight:matrix.org> Diving into RM now
<re_irc>
<@firefrommoonlight:matrix.org> I figure white noise is pretty easy if you use a finite number of steps with squaring
<re_irc>
<@ruabmbua:matrix.org> float is more complicated, since the values are not distributed uniformly (more distinct values closer to 0).
<re_irc>
<@adamgreig:matrix.org> you want to generate white noise?
<re_irc>
<@ruabmbua:matrix.org> So you can`t just rand.nextInt() as float
<re_irc>
<@firefrommoonlight:matrix.org> Yep!
<re_irc>
<@ruabmbua:matrix.org> or transmute::<_, float>(rand.nextInt())
<re_irc>
<@firefrommoonlight:matrix.org> I want to make headphones with a built in audiogram and then equalizer based on the results, and figure playing the test tones over white noise is a better gauge than the traditional silent environemtn
<re_irc>
<@dirbaio:matrix.org> oh `rand` can run on nostd? I thought it couldn't. I don't get what the `rand/rand_core` split is for then, lol
<re_irc>
<@firefrommoonlight:matrix.org> Since people with hearing loss might bge able to hear fine when its quiet
<re_irc>
<@ruabmbua:matrix.org> firefrommoonlight: Personally, I would just generate some random bytes, and put it into an array, then loop over it ^^
<re_irc>
<@adamgreig:matrix.org> you
<re_irc>
<@ruabmbua:matrix.org> For your usecase
<re_irc>
<@dirbaio:matrix.org> if you just want to generate noise you don't need it to be cryptographically-secure rand! :)
<re_irc>
<@dirbaio:matrix.org> some crap super-fast PRNG should work
<re_irc>
<@adamgreig:matrix.org> 44kHz 16-bit samples is 88kB of array just for a 1s period
<re_irc>
<@dirbaio:matrix.org> and it'll probably be faster than the HWRNG
<re_irc>
<@firefrommoonlight:matrix.org> for _ in 0..num_steps:
<re_irc>
<@firefrommoonlight:matrix.org> Only with ints
<re_irc>
<@firefrommoonlight:matrix.org> It's white noise when num_steps approaches oo
<re_irc>
<@firefrommoonlight:matrix.org> I just need the random() fn
<re_irc>
<@adamgreig:matrix.org> you might be making more work for yourself than necessary here
<re_irc>
<@adamgreig:matrix.org> though I don't know how that's "summing squares", you're not squaring?
<re_irc>
<@firefrommoonlight:matrix.org> Oops I mispoke
<re_irc>
<@adamgreig:matrix.org> dirbaio:matrix.org: I haven't tried this but I think so, rand's docs say "no_std compatibiliy (partial)"
<re_irc>
<@firefrommoonlight:matrix.org> Mainly, I want to make it so the tone is designed to stand out against the white noise background, instead of a very quiet tone in a silent background. This #1 demonstrates hearing in a noisy environment, and #2, avoids the need for a totally quiet room
<re_irc>
<@adamgreig:matrix.org> the point of the separate crate is to make it a small dependency for people implementing rng sources I think
<re_irc>
<@adamgreig:matrix.org> so, "white noise" is anything that's zero mean, finite variants, and each sample is independent
<re_irc>
<@adamgreig:matrix.org> people often talk about "gaussian white noise", which is where the distribution of samples is gaussian
<re_irc>
<@adamgreig:matrix.org> the "standard" random() sort of function is "uniform", meaning it returns all possible numbers in its range with equal probability
<re_irc>
<@adamgreig:matrix.org> but in a gaussian distribution, samples closer to the mean (0 for white noise) are more common, and more extreme values are less common
<re_irc>
<@adamgreig:matrix.org> if you add up a lot of uniform random numbers, the distribution of the sum tends towards a gaussian distribution, because on balance it's likely that positive and negative numbers cancel out, so the sum is closer to 0 (like a gaussian sample)
emerent has quit [Ping timeout: 252 seconds]
<re_irc>
<@adamgreig:matrix.org> so, if you're adding ten random numbers, maybe it's because you want gaussian white noise specifically? but in that case, you can probably be more efficient by generating gaussian samples to start with, instead of ten uniform samples
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
<re_irc>
<@firefrommoonlight:matrix.org> Correct!
<re_irc>
<@adamgreig:matrix.org> there's a few nice algorithms for this, like the box-muller transform which turns two uniform samples into two gaussian samples
<re_irc>
<@firefrommoonlight:matrix.org> Maybe CMSIS-DSP has something more efficient
<re_irc>
<@firefrommoonlight:matrix.org> Oh nice. What i posted is probably slower than it needs to be
<re_irc>
<@adamgreig:matrix.org> so instead of ten uniform samples per output sample (and the output distribution is _not_ gaussian, it's just a bit closer to it than you started), you get one gaussian sample per input sample, and the distribution is much better
<re_irc>
<@adamgreig:matrix.org> _but_, the box-muller transform is a bit of a pig to implement on embedded, because it needs sqrt, ln, cos, and sin
<re_irc>
<@firefrommoonlight:matrix.org> Luckily, CMSIS *does* have those!
<re_irc>
<@adamgreig:matrix.org> yea, but it won't be fast
<re_irc>
<@firefrommoonlight:matrix.org> (But perhaps since I don't need ti to be super precise, I could use the algo I posted with a low num of steps??)
<re_irc>
<@ruabmbua:matrix.org> easy way to get randomness fitted to a gaussian curve is a lookuptable with more samples close to 0.
<re_irc>
<@ruabmbua:matrix.org> Then generate one random number to select table index, and optionally as a second step add a small offset second random number.
<re_irc>
<@ruabmbua:matrix.org> That means 1/2 PSRNG calls per sample.
<re_irc>
<@firefrommoonlight:matrix.org> Oh nice!
<re_irc>
<@ruabmbua:matrix.org> If your cpu is slow
<re_irc>
<@adamgreig:matrix.org> if your current approach with summing ten samples sounds good enough, you can go ahead with it; maybe use an i32 as the accumulator and split each random u32 into two input i16s
<re_irc>
<@adamgreig:matrix.org> there's a slight catch which is that a uniform i16 is not zero mean because there are slightly more negative options than positive options
<re_irc>
<@adamgreig:matrix.org> but probably not important for audio noise
<re_irc>
<@firefrommoonlight:matrix.org> Yea - Can always convert on first/last step
<re_irc>
<@firefrommoonlight:matrix.org> Related question - I always wonder about the u32 buffers you send to DACs etc or accept from mics for audio. Is the DC offset significant for the way speakesr operate?
<re_irc>
<@adamgreig:matrix.org> but, you could also try just using each sample by itself instead of summing ten, and see how it sounds, it's still "white noise", just not "gaussian white noise"
<re_irc>
<@dirbaio:matrix.org> averaging 10 samples seems faster than the box-muller monster formulas lol
<re_irc>
<@adamgreig:matrix.org> yea for sure
<re_irc>
<@firefrommoonlight:matrix.org> Ie ideally you think of a signal like a sin wave oscillating around 0, but for these u32 arrays, it's probably osscilating with a DC offset of half a U32's max range
<re_irc>
<@adamgreig:matrix.org> much worse distribution quality though
<re_irc>
<@adamgreig:matrix.org> not many DACs take 32 bit inputs but in general they define some mapping from their control words to their output voltage
<re_irc>
<@firefrommoonlight:matrix.org> True, re maybe not needing gauassian. I'm still in the super early design phase for this
<re_irc>
<@firefrommoonlight:matrix.org> And it's going to be a somewhat ambitious project
<re_irc>
<@adamgreig:matrix.org> usually for an audio DAC you AC-couple the output, which removes any DC offset
<re_irc>
<@firefrommoonlight:matrix.org> I was using STM32's 12-bit DAC, where I'd manually reshape the signal to be about 500 - 3000 (range of 12 but unsigned is 0 - 4095)
<re_irc>
<@adamgreig:matrix.org> but yea, for a common DAC like on an stm32, where the output is 0v to 3.3v, and you control it with an input of 0 to 4095, your sine wave has a DC offset of like 1.65v
<re_irc>
<@firefrommoonlight:matrix.org> Switching to a 24-bit CODEC, but don't have it working yet
<re_irc>
<@adamgreig:matrix.org> but if you are using that for audio, you AC couple it (i.e., couple it through a capacitor or other high-pass filter), so the DC component is removed
<re_irc>
<@firefrommoonlight:matrix.org> But I send the I2S data to the codec using a u32 (Although without clipping the 24-bit limit)
<re_irc>
<@firefrommoonlight:matrix.org> Maybe some dacs output +/- voltage?
<re_irc>
<@adamgreig:matrix.org> if you were using it for some other analogue purpose, maybe you need a bipolar DAC (can go above and below zero), or maybe you use some extra circuitry to shift it or whatever
<re_irc>
<@firefrommoonlight:matrix.org> I guess the issue is how to speakesr work :/
<re_irc>
<@firefrommoonlight:matrix.org> Oh that makes sense re the AC couple!
<re_irc>
<@adamgreig:matrix.org> the speakers don't generally enjoy DC because it just heats their coils without moving them
<re_irc>
<@adamgreig:matrix.org> but you would AC couple speaker outputs
<re_irc>
<@firefrommoonlight:matrix.org> This is great info
<re_irc>
<@adamgreig:matrix.org> (depends on the speaker technology I guess. some technologies are inherently high-pass and don't care about DC)
<re_irc>
<@firefrommoonlight:matrix.org> It's possible this is handled by codecs
<re_irc>
<@firefrommoonlight:matrix.org> Since they tend to be pretty specialized for signal in, sound out
<re_irc>
<@adamgreig:matrix.org> yep, quite possible, but often it will be handled by an amplifier stage after the codec too, depending on how integrated your codec is
<re_irc>
<@firefrommoonlight:matrix.org> The one I have here has both speaker and headphones out, but I haven't read the fine prints or scoped them
<re_irc>
<@firefrommoonlight:matrix.org> I thoguht of this since I was surprised at how... high-level the whole thing is
<re_irc>
<@firefrommoonlight:matrix.org> Ie how it's *not* just a DAC, but I can't figure out exactly what it is!