<re_irc>
< (@firefrommoonlight:matrix.org)> Thanks for the info!
dc740 has quit [Remote host closed the connection]
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
hifi has quit [Ping timeout: 260 seconds]
hifi has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@chrysn:matrix.org)> seeing that async function in trait is approaching quickly and there's a request for user feedback: is this something we better experiment with in embedded-nal or in embedded-hal?
<re_irc>
< (@ryan-summers:matrix.org)> There's already an embedded-nal-async that experiments can happen in :)
<re_irc>
< (@chrysn:matrix.org)> embedded-nal-async currently just uses GAT and explicit future types (where implementers practically need to resort to TAITIT). As I understand, we'd need to alter the embedded-nal-async (and implementers) from the GAT phrasing to full async-function-in-trait to gather the relevant data. Question is, do we better do that in embedded-nal-async or embedded-hal-async?
<re_irc>
< (@lulf_:matrix.org)> e-n-a first maybe, less impact. I think there is a pr for e-h-a already though
<re_irc>
< (@ryan-summers:matrix.org)> Yeah, e-n-a has a much smaller user base and less impact on a ton of users IMO
<re_irc>
< (@ryan-summers:matrix.org)> Downside is less data
<re_irc>
< (@chrysn:matrix.org)> : Good with me (it's also my preference); may I invite you to review my responses at https://github.com/rust-embedded-community/embedded-nal/pull/73 then? Doing async-fn-in-trait and the UDP PR in parallel would be a merging nightmare.
vancz has quit []
vancz has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@alex:matrix.sempto.net)> So I'm trying to update my old stm32f100 RTIC project to newer dependencies, and now I'm getting errors that look like this everywhere I specify clocks:
<re_irc>
--> src/main.rs:168:23
<re_irc>
error[E0599]: no method named `mhz` found for type `{integer}` in the current scope
<re_irc>
error[E0034]: multiple applicable items in scope
<re_irc>
|
<re_irc>
--> src/main.rs:436:42
IlPalazzo-ojiisa has quit [Quit: Leaving.]
conplan has quit [Remote host closed the connection]
<re_irc>
<Ralph> : i'm using the stm32f4xx-hal and i had to add "fugit" to the project and use "MHz" (instead of "mhz"). though as you're using another microcontroller with another HAL YMMV
<re_irc>
<Ralph> : and for "millis" & co. i had to add "fugit" as a dependency. again, YMMV depending on your setup (and i'm no expert in any of this, anyway)
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
<re_irc>
< (@alex:matrix.sempto.net)> Ralph: Yep, this worked, thanks! I had to write it like this ".use_hse(8u32.MHz())" but at least it compiles again
dequbed has joined #rust-embedded
<re_irc>
<Milo Moisson> Hi, I would like to exchange small payloads between a STM32F103 (BluePill) and my computer. What is the best way and also the most supported within the Rust current crate ecosystem. I think about Bluetooth, but I think that it may be better ways
<re_irc>
< (@k900:0upti.me)> Serial to USB?
<re_irc>
< (@k900:0upti.me)> That's usually the simple way
<re_irc>
< (@k900:0upti.me)> If you have a USB/serial converter
<re_irc>
<Milo Moisson> I need something wireless
<re_irc>
<Milo Moisson> It is actually a little car
<re_irc>
< (@alex:matrix.sempto.net)> Not sure how well mantained the crates for it are.
<re_irc>
<Milo Moisson> I have a question for nRF products. Do I need to connect it to my STM32 board or do I flash my program directly on it ?
<re_irc>
< (@grantm11235:matrix.org)> If you use an nrf24l01 you will need another one with another microcontroller to plug in to your pc
<re_irc>
<Milo Moisson> : Why? I cannot just connect Bluetooth to my computer ?
<re_irc>
< (@alex:matrix.sempto.net)> nrf24l01 is not bluetooth,
<re_irc>
< (@grantm11235:matrix.org)> Then nrf24l01 is just a radio module, you need an mcu like an stm32 to control it. There are other nrf chips that have a built in mcu
<re_irc>
< (@grantm11235:matrix.org)> * The
<re_irc>
< (@grantm11235:matrix.org)> There are nrf chips that have a built in mcu and support bluetooth, that would probably be the easiest
<re_irc>
< (@grantm11235:matrix.org)> There are plenty of nrf based dev boards, for example the microbit
<re_irc>
<Milo Moisson> Maybe I don't understand what is an SoC
<re_irc>
< (@grantm11235:matrix.org)> An SoC (System on Chip) is pretty much the same thing as a microcontroller
<re_irc>
<Milo Moisson> I'll search more but thanks for your answerss
<re_irc>
<Milo Moisson> * answers.
<re_irc>
< (@k900:0upti.me)> It is probably going to be easier to use a SoC with onboard wireless like that one
<re_irc>
< (@k900:0upti.me)> Simply because they're better integrated
<re_irc>
< (@thejpster:matrix.org)> A system on chip is exactly that: a processor, boot ROM, RAM, GPIO controller, UART controller … all on one chip. It used to take up a whole PCB with one chip for each function - like in a Commodore 64.
<re_irc>
Basically any modern microcontroller is a system-on-chip.