IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
<@lambdafriend:matrix.org> Turns out _someone_ has to zero out the memory in the buffers. I was expecting the audio library I'm using to do it, but it turns out I'm the one writing the audio library and I wasn't doing it 🤣
<re_irc>
<@lambdafriend:matrix.org> +also
<re_irc>
<@jamesmunns:beeper.com> You got some surprise bonus data!
<re_irc>
<@lambdafriend:matrix.org> TIL bonus data cast to f32s are NaNs 😂
exark has joined #rust-embedded
exark has quit [Changing host]
exark has joined #rust-embedded
starblue3 has quit [Ping timeout: 246 seconds]
starblue3 has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc>
<@monacoprinsen:matrix.org> What type of MCU is best suited if you want to make an HMI based solution, touch/ display?
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@k900:conduit.0upti.me> If you're using something like Slint it really doesn't matter
<re_irc>
<@monacoprinsen:matrix.org> K900: Interesting, I think I met these guys at embedded world last year now that you mentioned it.
<re_irc>
<@bluesky404:matrix.org> Hi guys,
<re_irc>
having a few questions here, hope someone could help.
<re_irc>
1. For the nRF9160 DK I have a simple RTIC Firmware just performing defmt::println!("hello world"); inside #[init].
<re_irc>
I want to specify the link section of this mod app to 0x00060000, but the Compiler does not allow me to place #[link_section = ".firmware_a"] above mod app { ... }. How do I do this properly?
<re_irc>
2. In the project, I want a simple "Bootloader" in the SECURE_FLASH region which just jumps to 0x00060000 so the RTIC app gets executed. But I guess I need to specify for the vector table the reset_vector to point at my bootloader. Also I guess it should replace the zephyr.bin?
<re_irc>
<@diondokter:matrix.org> Best to modify the memory.x file so that the flash region starts at 0x60000
mrtazz has quit [Quit: Leaving.]
emerent has quit [Ping timeout: 264 seconds]
emerent has joined #rust-embedded
<re_irc>
<@ruabmbua:matrix.org> I got a bit of a configuration problem with my personal project: I need a non trivial amount of compile time configuration values, where simple cargo features are not enough. E.g. for configuration dependent constants etc... I`d really like something similar to KConfig (linux kernel configuration system), but instead of generating a header, generate a rust module.
<re_irc>
Is anyone aware of such a tool? Bonus would be if its written in rust.
<re_irc>
As a last resort I could ofc do my own thing, but it would probably be very basic as I do not want to spend much time on it.
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
<re_irc>
<@diondokter:matrix.org> : Couple of things you can do:
<re_irc>
1. Make a build script or proc-macro that takes a config file and builds a rust module based on the values. has made something like that before: https://github.com/jamesmunns/toml-cfg
<re_irc>
2. Make all configs use compile-time environment variables. You'll get everything in string form, but with https://github.com/rodrimati1992/konst/ you can parse a lot of it at compile-time too
<re_irc>
<@rursprung:matrix.org> now that embedded-hal 1.0.0-alpha.10 also contains "SetDutyCycle" which allows replacing the v0.2 "PwmPin" i was trying to update my code (https://github.com/rursprung/tb6612fng-rs/tree/master) to support both at the same time. is there a way to do this _without_ duplicating everything?
<re_irc>
in the perfect case i could just implement both without any feature flag. but i didn't see an option for that. so i thought that i'll just do it with a feature flag, but even then it doesn't work :(
<re_irc>
i was sort-of hoping to do something like this:
<re_irc>
#[cfg(feature = "hal_v02")]
<re_irc>
#[cfg(feature = "hal_v02")]
<re_irc>
use embedded_hal::digital::v2::OutputPin;
<re_irc>
type PwmPin = embedded_hal::PwmPin<Duty = u16>;
<re_irc>
#[cfg(feature = "hal_v1")]
<re_irc>
use embedded_hal_one::digital::OutputPin;
<re_irc>
#[cfg(feature = "hal_v1")]
<re_irc>
use embedded_hal_one::pwm::SetDutyCycle as PwmPin;
<re_irc>
and then use it:
<re_irc>
impl<IN1, IN2, PWM> Motor<IN1, IN2, PWM>
<re_irc>
where
<re_irc>
IN1: OutputPin,
<re_irc>
IN2: OutputPin,
<re_irc>
PWM: PwmPin,
<re_irc>
{
<re_irc>
but that doesn't seem to work because i'm not allowed to use a "type" for this (for v0.2) but i need to pass along the parameter ("<Duty = u16>") somehow. i also can't use "#cfg(...)" directly in the "where" either (this isn't C/C++ with the preprocessor, after all... here it'd have made my life a lot easier :D).
<re_irc>
does anyone have a recommendation on how to do this properly?
<re_irc>
<@ruabmbua:matrix.org> You can create a "trait alias" by creating a custom trait and a blanket impl
<re_irc>
i have a crate which supports no-alloc (thus using heapless) and i'd also like to add support for "alloc". in the best case most of the code dealing with the "Vec" has nothing to do with allocation (just adding/removing elements; the APIs for those actions are the same in alloc & heapless).
<re_irc>
from what i've seen no such abstraction exists, which is IMHO a bit of a shame. is there a specific reason for this? i think it'd be great if e.g. "core" (or a new "alloc-api" or similar) could offer such an abstraction and the various implementations could then implement it to make it easier to write portable code.
<Shell>
I assume the heapless::Vec is exposed in the API, and isn't just an internal implementation detail?