ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
bomb has quit [Quit: πŸ’£]
inara has quit [Quit: Leaving]
inara has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<KevinLy[m]> Any tips on how to get a .wav file onto my microcontroller's flash memory? I'm planning on using it to play a tune from DAC or PWM
<ryan-summers[m]> <KevinLy[m]> "Any tips on how to get a .wav..." <-
<ryan-summers[m]> That will encode the file into a u8 slice in your binary
trinhtuan[m] has joined #rust-embedded
<trinhtuan[m]> Did anyone meet the same issue as mine while working in a container? If i run "espflash boad-info --port /dev/ttyUSB0" it said port not found, but if i run "espflash board-infor --list-all-ports" then it worked. For further details pls see attached screenshot. Thanks.
jr-oss has joined #rust-embedded
barafael[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> New docs, who dis?
Ekho has quit [Quit: CORE ERROR, SYSTEM HALTED.]
Ekho has joined #rust-embedded
bomb has joined #rust-embedded
rom4ik7 has joined #rust-embedded
rom4ik has quit [Ping timeout: 255 seconds]
rom4ik7 is now known as rom4ik
<RobertJrdens[m]> branch removed
<RobertJrdens[m]> branch removed
IlPalazzo-ojiisa has joined #rust-embedded
<thejpster[m]> Note this also officially makes Cortex-M team official target maintainers
M9names[m] has joined #rust-embedded
<M9names[m]> <thejpster[m]> "Note this also officially..." <- condolences
<M9names[m]> are there any other targets for whom teams are responsible?
<thejpster[m]> It’s fine. I’m leaving.
<M9names[m]> i hope you all look out for yourselves (and each other)
<bomb> Rust is so darn nice for embedded project, I wish the Rust Foundation wasn't so ideologically charged :\
<K900> ...what
bomb has quit [Remote host closed the connection]
bomb has joined #rust-embedded
sourcebox[m] has joined #rust-embedded
<sourcebox[m]> diondokter: I'm just trying to play around with the `
<sourcebox[m]> w25q32jv` crate. Problem is that the `WP` and `HOLD` pins are not optional.
<diondokter[m]> Ah tight
<diondokter[m]> * Ah right
<diondokter[m]> Feel free to PR!
<diondokter[m]> I can review and release today
<sourcebox[m]> Another question: is there anything in the code that refers to that specific chip? Because usually, they only differ in page count as long as you don't use the commands for dual and quad mode. For testing, I use a W25Q64JV, which is double the size. The final design uses a smaller W25X40CLSNIG one.
<diondokter[m]> sourcebox[m]: I don't remember tbh. It might work for the entire family, but this is the chip we had and we just made a driver for it.
<sourcebox[m]> If you don't do any calculations or checks that depends on the page count, then it should work.
<sourcebox[m]> Seems like you do out-of-bounds checks, so they will fail with larger chips.
<diondokter[m]> Seems like an easy change
<diondokter[m]> Though feature flags would limit the usage to exactly one type
<diondokter[m]> * one type across the entire program
<sourcebox[m]> Yep, but the question is more if it makes sense to make this crate generic because the name implies a specific chip.
<diondokter[m]> Yeah, it'd have to change name
<JamesMunns[m]> wxxQxxyy is catchy
<JamesMunns[m]> (/s πŸ˜„)
<sourcebox[m]> I think there's a need for such a crate that can also do async. Don't know if that already exists, but if not, this is a good start for it.
<diondokter[m]> Yeah that'd be nice! (Though I have no time to do it)
<diondokter[m]> So feel free to fork too. I think the license is MIT/Apache
<sourcebox[m]> The alternative would be to look into one of the crates that were mentioned yesterday on the Embassy room:... (full message at <>)
<sourcebox[m]> They seem to be older and not async.
<sourcebox[m]> Since you can't change the crate name, there has to be a new one anyway. So we maybe can have a closer look what to change.
bomb has quit [Quit: πŸ’£]
eldruin[m] has quit [Quit: Idle timeout reached: 172800s]
<sourcebox[m]> diondokter: There is already a fork by someone who did what we were talking about. Maybe it can be merged.
<diondokter[m]> Oh lol
<sourcebox[m]> But please have a closer look if the changes are in your sense.
<diondokter[m]> That code does look like how I would do it
<sourcebox[m]> He removed WP and HOLD completely. Maybe because the code does not make any use of them.
<diondokter[m]> Ah well. Kinda fair. All our code did was setting them high I think.
<diondokter[m]> In theory you could do some nice things with them... But it's kinda hard to do it on a driver level
<sourcebox[m]> The pins are needed for the dual/quad commands though.
<diondokter[m]> Ah
<sourcebox[m]> So if you like to add that later, it's maybe better to keep them.
<diondokter[m]> Idk. A general driver for this chip should probably also work for people who want to tie those pins to vcc instead of to the mcu
<sourcebox[m]> I'm not sure if they use internal pullups. Did not find any info on that.
<diondokter[m]> I don't think so, but I might not remember correctly
<sourcebox[m]> I tie them to VCC via pullups on my board.
<sourcebox[m]> If you want to use quad mode later, you maybe should just consume the pins so that they can't be accidently used for something else. But you don't need to store them unless there's a free() function that gives them back. So they don't have to be generic parameters.
AtleoS has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
caligari[m] has joined #rust-embedded
<caligari[m]> is it possible to use defmt logging with a raw string output format to be read by a human in a standard terminal?
<JamesMunns[m]> do you want it to be defmt over the debugger wires (e.g. encoded, and you have to decode it with the elf file), or just "all text all the time"?
<JamesMunns[m]> if the latter, probably check out the `rtt_println` crate, it's basically "text over RTT" with no fancy encoding and decoding like defmt.
IlPalazzo-ojiisa has joined #rust-embedded
<caligari[m]> I'm really thinking in the UART tx channel on MCU and a common tty-usb on a PC to receive the log lines
<JamesMunns[m]> Yeah, check out rtt_println
<caligari[m]> but RTT needs a probe with RTT capability, doesn't it?
<slabity[m]> So a few days ago I was able to switch to using a proper debugger/programmer for my RP2040 using probe-rs. However, it looks like it doesn't work well when trying to flash the board while a multicore program is running. I get the following:... (full message at <>)
<slabity[m]> I need to upload a program that does not execute anything on CORE1, power it off, and then flash my full program onto it in order for any output to occur
<slabity[m]> When I stop the debugger I get the following:... (full message at <>)
<slabity[m]> Is there something I'm missing?
<JamesMunns[m]> <caligari[m]> "but RTT needs a probe with RTT..." <- Sorry, do you want to log over USB, like with a USB serial connection? embassy has that for most supported HALs. Then you could use the log crate or your own console code.
<JamesMunns[m]> I had thought that you wanted to use a debugger, most debuggers can do RTT as it's just over swd
IlPalazzo-ojiisa has quit [Quit: Leaving.]
GenTooMan has quit [Read error: Connection reset by peer]
cybernaut has joined #rust-embedded
cybernaut has quit [Read error: Connection reset by peer]
GenTooMan has joined #rust-embedded
therustybits[m] has quit [Quit: Idle timeout reached: 172800s]
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
dygear[m] has quit [Quit: Idle timeout reached: 172800s]
corecode[m] has quit [Quit: Idle timeout reached: 172800s]