therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
SbastiendHerbais has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
Yeah, Sophie in RTICv1, priorities work the way you think, BUT if you share resources between two tasks, the lower task is "escalated" to the priority of the higher task for the length of the lock. The intent is that you keep your locks as short as possible, usually just long enough to read or write some value.
<JamesMunns[m]>
It sounds like you have it sorted out now, but if you need the high prio task to not be inhibited, you can look at potentially using something like a channel between low and high to pass information without requiring a lock
<JamesMunns[m]>
(significantly more than Android and iOS, half as much as WASM and macOS!)
thejpster[m] has joined #rust-embedded
<thejpster[m]>
I’ve been told by a Big Company that there is no interest in Rust for IoT devices or microcontrollers and so they’re not putting any effort in to it. Some numbers to dispute that would be useful.
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Sounds like a great idea! Let's put that into motion.
<JamesMunns[m]>
Pinged the survey team about the question number limit, so we can figure out if we need to limit the number of questions
<Sophie[m]>
<JamesMunns[m]> "Yeah, Sophie in RTICv1, prioriti..." <- > <@jamesmunns:beeper.com> Yeah, Sophie in RTICv1, priorities work the way you think, BUT if you share resources between two tasks, the lower task is "escalated" to the priority of the higher task for the length of the lock. The intent is that you keep your... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/vpqZPRrCdCWyXKgeJiDjcmTH>)
<Sophie[m]>
Ty for clarifying!
ninjasource[m] has quit [Quit: Idle timeout reached: 172800s]
thalesfragoso[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Also, can anyone point me to examples of running a machine learning model on a microcontroller in Rust? Native or via FFI is fine.
t-moe[m] has quit [Quit: Idle timeout reached: 172800s]
GeorgesP[m] has joined #rust-embedded
<GeorgesP[m]>
Hi, I am writing a chip driver based on enbedded_io_async because protocol is over UART. I need to set the UART baudrate from within the driver (yes the chip change baudrate during init...), so I defined a Baud trait that the final implantation must provide. I am doing an example using embedded_io_adapter::FromTokio<tokio_serial::SerialStream>. SerialStream impl the crate tokio_serial::SerialPort which have a set_baud_rate()
<GeorgesP[m]>
function, but I am not able to go through the FromTokio wrapper. Can you help me plz ?
<dirbaio[m]>
I think you'll have to write your own adapter that impls both embedded-io-async and your baudrate trait
<dirbaio[m]>
Copy-paste from e-io-adapters and extend
<dirbaio[m]>
You could also write a wrapper that forwards embedded-io-async and adds your baudrate trait but I'm not sure if it'd be easier
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has joined #rust-embedded
<jannic[m]>
TIL that `-Cinline-threshold` is ignored by the rust compiler - and has been for a few years. Rust beta just started to print a warning about it.