<re_irc>
<Yashwanth SINGH M> Hi, im currently using stm32f411 board and nrf52840 board in my project. So i have added both crates in corgo.toml file , during compilation i get linking error when i use both crate .If i individually use any of those it will work fine.I have attached the screen shot, In line 29 and 31 nrf52840 & stm32f411 dependency are added respectively.
<re_irc>
<GrantM11235> This is the main part that I changed
<re_irc>
for met in vector_metrics.iter_mut() {
<re_irc>
col_vector.push(met.as_mut() as &mut dyn Metric)
<re_irc>
}
jasperw has quit [Ping timeout: 256 seconds]
jasperw has joined #rust-embedded
Guest2 has joined #rust-embedded
<re_irc>
<gauteh> Yashwanth SINGH M: This typically happens when you dont use the PAC or HAL crate in your program, can usually be fixed by adding "use nrf52849_hal as hal"
<re_irc>
<barafael> any no_std builder derive crates out there which do not require nightly? I know derive_builder but that one requires nightly according to the documentation, and that's not good for a library or is it ok?
<re_irc>
<gauteh> It's not the end of the world :) Depends on your goal, or whether the nightly features it requires are going to get stable in the near future
<re_irc>
<barafael> typed_builder is pretty good
<re_irc>
<justacec> Gang. Was looking at playing with the LoRa-E5 (Based on STM32WLE5JC). Was going to base on RTIC and the stm32wlxx-hal create. But then I noticed that, inside the stm32wlxx-hal crate is a board support crate (lora-e5-bsp). You can see it at https://github.com/stm32-rs/stm32wlxx-hal/tree/main/lora-e5-bsp. As this is not in Crates.io, what is the most correct way to use that crate?
<re_irc>
<justacec> By use, I mean include in the cargo.toml file. Would it be download the crate locally and then manually configure the crate in the cargo.toml, like a crate from GIT?
<re_irc>
<yruama_lairba> hi, i there a way to use "rprintln!()" without causing issues with interrupt ?
<re_irc>
<yruama_lairba> * is
<re_irc>
<yruama_lairba> i have trouble with i2s because of that
<re_irc>
<ryan-summers> You need to use "rtt_target::set_print_channel_cs()" to specify a special type of critical section. If you don't care if messages may be dropped (e.g. if you log in your ISR, those logs would get dropped if you interrupt a different RTT print), you can look at https://github.com/quartiq/stabilizer/blob/master/src/hardware/setup.rs#L204-L244 as a reference
<re_irc>
<ryan-summers> But essentially, you have to give RTT a special critical section function so it knows how to handle pre-emption
<re_irc>
<ryan-summers> Otherwise, rprintln!() establishes a critical section (disables interrupts) for the whole format of the printed message, which can be prohibitive if formatting takes a while and you need low-latency response
<re_irc>
<yruama_lairba> ryan-summers: can i avoid this by directly using rtt_channel ?
<re_irc>
<ryan-summers> That doesn't fix your problem - it puts a cirtical section that disables interrupts as your cs function. You said you want to enable interrupts during rprintln, which means you need to figure out what kind of critical section fits your needs
<re_irc>
<ryan-summers> If you truly don't want rprintln not to stop your ISRs, you need to tell it how to safely handle the shared RTT channels between interrupt priorities or you're creating a race condition on the resource
<re_irc>
<ryan-summers> * want rprintln to not block
<re_irc>
<ryan-summers> * channels. Otherwise, your ISR could use the RTT channel while your lower priority task is using it, giving garbage output.
<re_irc>
<yruama_lairba> i mean can i use write!(channel, ....) instead ?
<re_irc>
<yruama_lairba> since a channel is a owned value, it deosn't need to implement a critical section ? ins't it ?
<re_irc>
<ryan-summers> I don't know - check the "rtt_target" code to see if it invokes the critical section in that case. It seems sound to me if "channel" doesn't implement "Copy" or "Clone" (i.e. if it's a singleton)
<re_irc>
<ryan-summers> But if "channel" is just a simple index (usize), you'd still need to lock to prevent concurrent access of the underlying channel buffer
<re_irc>
<ryan-summers> * (usize) or enum,
<re_irc>
<ryan-summers> Looks like it might work though
Guest2 has quit [Ping timeout: 256 seconds]
<re_irc>
<barafael> Having made a couple embedded-hal drivers, I am observing a few recurring themes: * type-state design pattern * proptest + proptest-derive for bytes to/from struct conversion * smart_default::SmartDefault super useful * embedded-hal-mock is good. What are yours?
<re_irc>
I've been working on a project with and ESP32 microcontroller, and I figured out a lot of stuff, but there's one thing I've gotten stuck on.
<re_irc>
<elidupree> Hi there!
<re_irc>
The controller has a simple job – continuously read from four analog pins and report the results over the air (currently using Wi-Fi because it was easy to set up, probably ideally using BLE later). And I've got it working, using esp-idf-hal, but I would like it to be more real-time than it is. Right now everything is synchronous, and although it maintains a throughput of 1000 readings per second, sometimes there's a latency of...
<re_irc>
... around 10ms for the readings. I don't mind a latency of 10ms to communicate the readings across the network, but I do want the readings to be _taken_ on an exact schedule (and just catch up with relaying them as-needed).
<re_irc>
<adamgreig> elidupree: you might find good esp-specific advice in #esp-rs:matrix.org (https://matrix.to/#/#esp-rs:matrix.org)
<re_irc>
<adamgreig> in general it does sound like an interrupt to read the adc sample into a queue is a good architecture for you, but I don't know about interrupts in esp-idf-hal... maybe you can even use std::thread?
<re_irc>
<elidupree> oh, thanks for the link!
<re_irc>
<elidupree> use std::thread how?
<re_irc>
<adamgreig> I believe esp-idf-hal supports std? i don't know if it has threads but if so you could have one thread read the ADC on a regular schedule and a second thread post batches of readings over wifi
<re_irc>
<adamgreig> but yea, probably best ask people who know about esp-idf-hal!
<re_irc>
<elidupree> yeah it does support std, and you can make threads, but I don't think they'll do the job
<re_irc>
<elidupree> because it wasn't just that sending the data blocks
<re_irc>
<elidupree> I measured what appears to be occasional 5ms-ish delays just in the adc reading itself, which I'm assuming means my thread got interrupted for 5ms by something else
<re_irc>
<adamgreig> the thread should be able to take samples, then sleep until the next sampling instant, then take samples again, and repeat, and in principle that should mean you get no jitter or gaps in samples
<re_irc>
<adamgreig> hmm, i would have hoped there weren't 5ms interruptions by something else but... i don't know
<re_irc>
<elidupree> I wouldn't even be averse to getting a different control board, just for my own convenience, if there's another microcontroller that does Wi-Fi/BLE and 4+ channels of ADC reading, and has good Rust support, that someone can suggest
<re_irc>
<firefrommoonlight> Rust appreciate time. I've been doing more C translation to Rust. The Rust syntax is much clearer and explicit in its descriptions and behavior
<re_irc>
<firefrommoonlight> Comparisons often focus on memory safety, but the biggest appear to me is language design
<re_irc>
<firefrommoonlight> Things like DRY violations in header files, ambiguity over what goes in header vs C files, not explicitly declaring your type as an array etc
<re_irc>
<firefrommoonlight> The preproceessor sub-language
<re_irc>
<firefrommoonlight> And idioms, like defaulting to global mutable variables instead of more carefully managing state
<re_irc>
<firefrommoonlight> And the prefixes on everything!
<re_irc>
<firefrommoonlight> And Enum items being called directly without their parent