ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<JamesMunns[m]> it's barely tested but seems to work
<JamesMunns[m]> and postcard-rpc could take this further and automatically determine the largest buffer needed for ANY type in or out, but you'd have to either ignore or handle cases where you want to be able to send `&str` or `&[u8]`, which is harder in the general case
<JamesMunns[m]> (postcard-rpc prepares an array of all data types on the wire, so you could make a version of my const fn that works on `&[&NamedType]` instead of just `&NamedType`
<JamesMunns[m]> * just `&NamedType`)
<JamesMunns[m]> * (postcard-rpc prepares a const array of all data types on the wire, so you could make a version of my const fn that works on `&[&NamedType]` instead of just `&NamedType`)
Jubilee[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
jr-oss_ has joined #rust-embedded
jr-oss has quit [Ping timeout: 260 seconds]
sroemer has quit [Ping timeout: 255 seconds]
emerent_ has joined #rust-embedded
emerent has quit [Killed (erbium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 276 seconds]
haobogu[m] has quit [Quit: Idle timeout reached: 172800s]
flippette[m] has joined #rust-embedded
<flippette[m]> hi, i have a pimoroni pico plus 2w and i'm trying to modify the embassy-rp memory.x file to use the full 16mb flash + 8mb psram, how exactly can i do that?
<flippette[m]> from what i understand the address ranges for the xip subsystem starts at 0x10000000
<flippette[m]> but does the external flash come first in the address space or does the psram?
<flippette[m]> this section in the datasheet looks relevant but i'm still unsure how to proceed https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf#xipaddressmap
chrysn[m] has joined #rust-embedded
<chrysn[m]> Is there any slimmer interface than serde that could be offered for crates like minicbor and heapless to meet at, so that that interface describes "we're building a string" or "we're building an array"? serde certainly comes to mind (and minicbor supports it), but serde is of bigger scope, and also opinionated enough to not quite be a first choice. (For example, it only works with string keys, which is why minicbor mainly uses own
<chrysn[m]> Looks like it won't be trival to convince [minicbor to support heapless](https://github.com/twittner/minicbor/pull/4), and that's not even getting started on other types that are string-ish or vec-ish (smallvec comes to mind).
<chrysn[m]> derives).
<chrysn[m]> (I've briefly considered proposing PR'ing this to heapless (just as it supports serde), but minicbor changes quite frequently, so that wouldn't be practical – apart from heapless being the more widely used crate)
starblue[m] has joined #rust-embedded
<starblue[m]> <flippette[m]> "but does the external flash come..." <- That depends on the chip selects. I think normally the flash comes first, and from the schematics at https://shop.pimoroni.com/products/pimoroni-pico-plus-2-w that is indeed the case.
starblue has joined #rust-embedded
sroemer has joined #rust-embedded
sroemer has joined #rust-embedded
<thejpster[m]> flippette: be warned, you must not use core::sync::atomic::* values within the PSRAM address space (or the flash address space, but the flash is read-only so you wouldn't put an atomic there anyway).
<thejpster[m]> And I have a Pico 2 Plus and I can confirm the flash is at 0x1000_0000 where you would expect it to be. The SRAM is on the second bank (although I haven't used it yet).
<thejpster[m]> Does embassy-rp have a driver for the PSRAM? I never got around to writing one for rp2350-hal.
<flippette[m]> > Does embassy-rp have a driver for the PSRAM?
<flippette[m]> doesn't seem so to me
<flippette[m]> * > Does embassy-rp have a driver for the PSRAM?
<flippette[m]> doesn't seem so to me
<flippette[m]> also does anyone know if the RM2 wifi chip on the pico plus 2w can use the same firmware as the one in cyw43-firmware?
<dirbaio[m]> it has the same cyw43439 chip, so it should work
<flippette[m]> i can't seem to get the embassy wifi-blinky example to work on it
<dirbaio[m]> from looking at the schematic the pinout is the exact same lol
<dirbaio[m]> so it really should work
<dirbaio[m]> can you post DEFMT_LOG=trace output?
<flippette[m]> <dirbaio[m]> "can you post DEFMT_LOG=trace..." <- oh my god i have to get defmt over serial over usb 🫠
<flippette[m]> i'll do that later tonight then
<dirbaio[m]> ah you don't have any logs at all 🫠
<dirbaio[m]> yeah it's hard to debug things without logs
<flippette[m]> this is a blinky example 🫠
<dirbaio[m]> it's a blinky example that goes through a super complex wifi chip on a relatively new mcu and a just-released board
<dirbaio[m]> you're probably one of the first people on earth using rust+rp235x+cyw43439 :D
<dirbaio[m]> it's normal that things don't work first try
<dirbaio[m]> yeah you'll have to try either defmt-over-usb
<dirbaio[m]> or log-over-usb with embassy-usb-logger
<dirbaio[m]> are you sure you're not hitting a panic though? you will not see panic messages over usb
<dirbaio[m]> which is why I recommend getting a real debug probe set up
<flippette[m]> dirbaio[m]: i do have a debugger but not the jst cable that fits this board :melting_face:
<flippette[m]> s/:melting_face:/🫠/
<flippette[m]> dirbaio[m]: ...no actually
<flippette[m]> okay i might be able to wire up an led and light that up on panic
<flippette[m]> let's see
<flippette[m]> seems to be getting hung on this line
<flippette[m]> let (_, mut ctrl, runner) =
<flippette[m]> cyw43::new(CYW43_STATE.init(cyw43::State::new()), pwr, spi, CYW43_FW)
<flippette[m]> .await;
<dirbaio[m]> we will need trace logs to debug this
hampycalc[m] has joined #rust-embedded
<hampycalc[m]> Hi all - I have a crate that might be of us to others: https://github.com/gold-standard-phantoms/max1726x-rs
<hampycalc[m]> Perhaps suitable for: https://github.com/rust-embedded/awesome-embedded-rust
<hampycalc[m]> actually never mind - I'll wait until we have the device in production, as we'll have gone through some thorough versioning and a "release"
nhogan06[m] has joined #rust-embedded
nhogan06[m] has left #rust-embedded [#rust-embedded]
<JamesMunns[m]> fwiw: tchncs-de is having a very bad spam day, the bots are working overtime
<JamesMunns[m]> feel free to @ me anywhere if you see a random from that homeserver posting an imgur link, it's a weird AI conspiracy message that looks like someone is either trolling or had a serious mental break :p
<JamesMunns[m]> (the mods and bots have banned like 20-30 accounts in the last 15-20 minutes)
scorpion2185[m] has joined #rust-embedded
<scorpion2185[m]> are they bots?
<JamesMunns[m]> it looks very bot-ish. They join, post the imgur link, then don't do anything else
<scorpion2185[m]> i am seiing them in many rooms
<scorpion2185[m]> s/seiing/seeing/
<JamesMunns[m]> yeah, it's pretty rough. The bots are banning 1-2 accounts every minute
077AAT1JQ has quit [Quit: quit]
exark has joined #rust-embedded
sroemer has quit [Ping timeout: 260 seconds]
<flippette[m]> <dirbaio[m]> "we will need trace logs to debug..." <- so i found out about `defmt-serial` and that it'll log through my uart reader thingamajig
<flippette[m]> well it should
<JamesMunns[m]> it won't if you panic.
<flippette[m]> this works
<flippette[m]> but this doesn't
<flippette[m]> JamesMunns[m]: well `defmt_serial` looks like this
<flippette[m]> and i did put features = ["critical-section-impl"] for embassy-rp
<flippette[m]> so i'm at a total loss here
<flippette[m]> <flippette[m]> "image.png" <- i made an led get toggled between these 2 parts and the defmt macros are either hanging or panicking?
<JamesMunns[m]> defmt serial requires you to pass in a `&'static mut Serial`
<JamesMunns[m]> I'm not sure why your example compiles if you pass it in by value.
<flippette[m]> oh `SERIAL` is a `StaticCell<BufferedUart<...>>`
<JamesMunns[m]> ah its a staticcell, got it
<dirbaio[m]> "doesn't work" means it compiles but doesn't write anything?
<dirbaio[m]> Try setting the DEFMT_LOG envvar
<flippette[m]> yea the defmt version doesn't log anything
<flippette[m]> i've already set DEFMT_LOG=trace in config.toml
<dirbaio[m]> DEFMT_LOG=trace cargo run blahblah
<dirbaio[m]> Hmmm
<JamesMunns[m]> also how are you trying to "hear" the data?
<flippette[m]> JamesMunns[m]: `socat -u /dev/ttyACM0,rawer,b115200`
<flippette[m]> and for defmt i pipe that into defmt-print -e target/release/thumbv8m.main-none-eabihf
<JamesMunns[m]> does rawer disable buffering?
<JamesMunns[m]> by default ttyACM0 line buffers
<flippette[m]> <flippette[m]> "image.png" <- i've never used socat before but it seems to work for this one
<flippette[m]> picocom also works
<JamesMunns[m]> yeah, you print a newline :)
gauteh[m] has joined #rust-embedded
<gauteh[m]> flippette[m]: socat works pretty well on linux, but not on mac os. better to use stty and cat, or something else
<flippette[m]> i tried stdbuf -o0 socat -u /dev/ttyACM0,rawer,b115200 STDOUT, still no dice
<flippette[m]> gauteh[m]: picocom also doesn't work, and i don't know how to set the baud rate with cat
<gauteh[m]> ok :/ there may be a bug in defmt-serial as well. you could try to do defmt::flush(), does the example-std work in defmt-serial?
cbjamo[m] has joined #rust-embedded
<cbjamo[m]> <thejpster[m]> "And I have a Pico 2 Plus and I..." <- > <@thejpster:matrix.org> And I have a Pico 2 Plus and I can confirm the flash is at 0x1000_0000 where you would expect it to be. The SRAM is on the second bank (although I haven't... (full message at
<flippette[m]> gauteh[m]: the log macros never terminate, i don't think i can even call that 😅
<flippette[m]> (or they immediately terminate everything but yk)
<JamesMunns[m]> oh
<JamesMunns[m]> you almost definitely don't want to use buffered uart
<JamesMunns[m]> it requires interrupts to send data
<JamesMunns[m]> and defmt uses a critical section
<JamesMunns[m]> which disables interrupts
<flippette[m]> regular uart doesn't implement embedded_io::Write it says
<flippette[m]> JamesMunns[m]: huh, makes sense
<dirbaio[m]> JamesMunns[m]: Lolllll
omani[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
<flippette[m]> absolute cinema
<flippette[m]> Lo⅃
Artea has quit [Quit: ZNC 1.9.1 - https://znc.in]
M8alpreet[m] has joined #rust-embedded
<M8alpreet[m]> Hi,
<M8alpreet[m]> I created a PR to add some MacOS related instructions for the discovery book. There is a check failing, but it's not clear what's causing the issue.
<flippette[m]> <JamesMunns[m]> "which disables interrupts" <- yea you were correct
<flippette[m]> i implemented `embedded_io::{Read, Write}` for `Uart<'d, T: Instance, Blocking>` and it works now
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
<flippette[m]> https://github.com/embassy-rs/embassy/pull/3483 pls review thanks
<JamesMunns[m]> it might be rejected for Read at least, because IIRC it should be buffered, otherwise you will not receive data
<JamesMunns[m]> Write might be okay, not sure.
<JamesMunns[m]> ah, probably don't listen to me, there's at least some impls for this
<thejpster[m]> <JamesMunns[m]> "it looks very bot-ish. They join..." <- I got a DM that did that. Very annoying.
AdinAck[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> By the way, for anyone who was waiting - I've cut a 0.10 release of postcard-rpc, and at this point I *think* I am done making breaking changes, and it's at a point where I'd be comfortable recommending it again. If someone finds a problem, please let me know!
<flippette[m]> <dirbaio[m]> "we will need trace logs to debug..." <- now that i have defmt working
<flippette[m]> ❯ socat -u /dev/ttyACM0,rawer,b115200 STDOUT | defmt-print -e target/thumbv8m.main-none-eabihf/release/rp2350-
<flippette[m]> playground
<flippette[m]> 0.038050 INFO defmt init!
<flippette[m]> the logs are not very helpful
<JamesMunns[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> By the way, for anyone who was waiting - I've cut a 0.10 release of postcard-rpc, and at this point I *think* I am done making breaking changes, and it's at a... (full message at <https://catircservices.org/_irc/v1/media/download/AX1heYd7wJskMikbnxetqHOcHHXR20RTsabK2__ULUrLYdIeobDn2R-9PXjeHi6-R1Vckr-2R9K_UCx5waLOkx1CeS5EmAHQAGNhdGlyY3NlcnZpY2VzLm9yZy9keVNDWU95eFZPSHNwdGdBdXplT2pKbHc>)
<JamesMunns[m]> JamesMunns[m]: I plan to improve the docs, but like I said, I think the code should be good to go - at least for breaking changes!
<JamesMunns[m]> JamesMunns[m]: And if you are ever confused or the docs look wrong, please do ping me here and/or open an issue, I'll prioritize updating things that people complain about :)
PhilMarkgraf[m] has joined #rust-embedded
<PhilMarkgraf[m]> Hey everyone, I wanted to share my recent visit with the Agile Embedded Podcast, speaking about my experiences using Embedded Rust. I hope this honors the work this community has put into making Embedded Rust practical, pragmatic, and awesome.
<flippette[m]> <flippette[m]> "the logs are not very helpful" <- oh sorry i forgot to enable `feature = ["defmt"]` for `cyw43{-pio}`
<flippette[m]> here's the logs when i do
<dirbaio[m]> hm seems it's failing very early
<dirbaio[m]> it's reading a dummy test register that should always return 0xFEEDBEAD https://github.com/embassy-rs/embassy/blob/main/cyw43/src/bus.rs#L59-L65
<dirbaio[m]> and it's returning zero intead
<dirbaio[m]> s/intead/isntead/
<dirbaio[m]> probably something's wrong with the spi or the pio
<dirbaio[m]> wrong pinout maybe?
<dirbaio[m]> is the cyw43 in that board wired the exact same way as in the original Pico W?
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
<flippette[m]> this is pico w
<flippette[m]> this is pp2w
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
romancardenas[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]> it seems equivalent yeah..
<dirbaio[m]> i'd suggest looking at the WL_CLK, WL_CS, WL_D lines with an oscilloscope
<flippette[m]> i don't have one though 😅
<flippette[m]> i can maybe use my uni's scope tomorrow and report back
<dirbaio[m]> with that you'll be able to see whether cyw43-pio is outputting the right signals or not, and whether the cyw43 is responding or not
<dirbaio[m]> I wonder if this has something to do with it https://github.com/embassy-rs/embassy/issues/3476
<dirbaio[m]> though other people are using pio on rp235x just fine
<flippette[m]> dirbaio[m]: regarding the function mentioned here
<flippette[m]> ...why is it like that?
<flippette[m]> ohhh okay it's 2 different functions
<flippette[m]> i can't read
notafbihoneypot[ has joined #rust-embedded
<notafbihoneypot[> Is it a good idea to learn rust as a first language (embedded )
<flippette[m]> <dirbaio[m]> "I wonder if this has something..." <- doing what they say gives these logs now
<flippette[m]> and it repeats this forever
<JamesMunns[m]> notafbihoneypot[: I would suggest learning it on the desktop first, then switch to embedded when you are comfortable!
<dirbaio[m]> welp it changed from all zeros to all ones. still wrong :D
<dirbaio[m]> I wonder why set_ie is needed in rp235x but not in rp2040?
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> Is this errata E9?
<JamesMunns[m]> (I saw a pull down in one of the snippets)
<thejpster[m]> Pads are all isolated in PoR on 2350
<thejpster[m]> Cost me a week that did
<thejpster[m]> s/in/at/, s/PoR/reset/
<dirbaio[m]> that's set_iso(false), right? it's done here https://github.com/embassy-rs/embassy/blob/main/embassy-rp/src/pio/mod.rs#L1057-L1060
<thejpster[m]> Ah yeah that’s right
<dirbaio[m]> ohhh, aside from that IE defaults to 1 in rp2040, and to 0 in rp235x
<dirbaio[m]> lol
<thejpster[m]> And E9 recommends you leave IE disabled until you want to read a pin
<dirbaio[m]> hmm okay so it's a bug we never set IE=1 in PIO
<flippette[m]> <JamesMunns[m]> "Is this errata E9?" <- oh joy
<dirbaio[m]> rp235x datasheet says this in "differences in pio from 2040"
<dirbaio[m]> > • Improved GPIO input/output delay and skew.
<dirbaio[m]> 🤔🤔🤔
<dirbaio[m]> wtf does that mean
<dirbaio[m]> cyw43-pio was super finicky to get right because it tries to go to the max of 62.5mhz, which requires timing down to the clock cycle
<dirbaio[m]> if they changed timings it could break things
<dirbaio[m]> flippette: can you test with https://github.com/embassy-rs/embassy/pull/3484 ?
Icy-Thought[m] has joined #rust-embedded
<Icy-Thought[m]> Somewhat offtopic but do we have a rust space with more rust rooms?
<Icy-Thought[m]> * Somewhat offtopic, but
<dirbaio[m]> same
<dirbaio[m]> Icy-Thought[m]: https://matrix.to/#/#rust-space:matrix.org
<dirbaio[m]> also do you have the overclock feature enabled?
<Icy-Thought[m]> Icy-Thought[m]: Much appreciated! :)
<dirbaio[m]> try flippng it
<dirbaio[m]> * try flipping it
<dirbaio[m]> s//`/, s//`/, s/?/ in `cyw43-pio`?/
<flippette[m]> with overclock it reads something else
<dirbaio[m]> set a higher divider, like 0x0300 or 0x04000
<dirbaio[m]> s/0x04000/0x0400/
<dirbaio[m]> the rp235x goes faster, maybe it makes sense that we have to slow it down more...
jistr has quit [Remote host closed the connection]
<flippette[m]> 0x0400 too
<dirbaio[m]> ugh
<dirbaio[m]> well it's clearly doing something now
<dirbaio[m]> feels like the cyw43 is trying to reply but the data gets corrupted
<dirbaio[m]> the spi wiring is cursed lol
<dirbaio[m]> i'm afraid i'm out of ideas
<dirbaio[m]> other than "change shit randomly and see if it improves" :D
<dirbaio[m]> or look at it with an oscilloscope...
danielb[m] has joined #rust-embedded
<danielb[m]> dirbaio[m]: that's basically AI
<dirbaio[m]> the current cyw43-pio code was made with a lot of "change shit randomly and see if it improves" as well...
<flippette[m]> can't spell dirbaio without ai 😔
<danielb[m]> "was developed using an extremely mature form of genetic algorithm"
<danielb[m]> genetic algorithm is called biology
<danielb[m]> to be fair it's often more compelling to blindly fiddle bits than to think, thinking is hard 😣
<vollbrecht[m]> my old electronics prof coined this nice term for how we should call this working method: "monkey circuits analysis". And i today still often use this advanced technique :D
jistr has joined #rust-embedded
Danilo[m] has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has joined #rust-embedded