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
<holo[m]> it helped thank you, now left problem with response variable:
<barnabyw[m]> (not that it’s important, but in this case pub const NAME = [0x21_u8, 0xb1] would have a fixed type, it wouldn’t be possible for type inferrence to decide that it’s something different)
<holo[m]> | ^^^^^^^^^ help: a local variable with a similar name exists: `response`
<Lumpio-> respoSnse
<holo[m]> i2c.write_read(ADDR, &READ_MEASUREMENT, &mut resposnse).unwrap();
<holo[m]> | ^^^^^^^^^ help: a local variable with a similar name exists: `response`
<holo[m]> ahh
<holo[m]> typo thanks
notgull has quit [Ping timeout: 260 seconds]
<holo[m]> its compiling now but im getting runtime errror:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/aSGlzwRCCBIbvTcrrbxhnLCp>)
M9names[m] has joined #rust-embedded
<M9names[m]> Abort(NoAcknowledge) means the target device did not respond, which means it could be the wrong address, wrong wiring, bad power or missing/insufficient pull-up resistors
<M9names[m]> and maybe not "wrong wiring" but "bad wiring"
<holo[m]> so guessing all resistors will be on that board already
Amanieu has quit [Ping timeout: 256 seconds]
<holo[m]> will check with metter if all wires are conntinous
<holo[m]> and if there is voltage on sensor itself
<Lumpio-> What is "ADDR"?
<barnabyw[m]> it’s unlikely the pull-up resistors will be on the sensor board
<M9names[m]> barnabyw[m]: why do you say that?
<barnabyw[m]> you’ll probably have to provide them yourself, unless the MCU board you’re using includes them
<holo[m]> ok wirering and power is ok
<barnabyw[m]> M9names[m]: I’ve never seen an I2C sub device breakout board which provides its own bus pull-up resistors?
<Lumpio-> I can literally see them on the board though
<holo[m]> im noob thoght with such board will be all included
<holo[m]> ok lets check what is needed i have some
<barnabyw[m]> because otherwise you’d end up with loads of pull-up resistors in parallel
<barnabyw[m]> yeah maybe, I’m not familiar with that specific board
<holo[m]> is it possible to setup that pull up from rp pico?
<Lumpio-> https://dfimg.dfrobot.com/nobody/wiki/4482c60dae7dfada6884e717e83894da.pdf this is the schematic from the link above
<Lumpio-> It has pull-ups
<JamesMunns[m]> barnabyw[m]: it's decently common
<JamesMunns[m]> (as seen here)
<barnabyw[m]> weird
<holo[m]> ok so what i can check more?
<Lumpio-> I agree it's not the best design but not the first board I've seen with those
<holo[m]> connections are ok, power is ok
<Lumpio-> holo[m] what is your ADDR
<JamesMunns[m]> holo which power pin did you use
<holo[m]> pulup is in place 🙂
<JamesMunns[m]> 5v or 3v3?
<holo[m]> 3v3
<M9names[m]> just to be clear: you should always check the schematics when available, rather than guessing what will be there or assuming what purpose components on the board will have
Amanieu has joined #rust-embedded
<Lumpio-> Is like the entirety of your code visible somewhere instead of just snippets
<holo[m]> M9names[m]: its sensor for microbit so i woudnt expect there will be missing something but thanks for advice will be checking it
<holo[m]> its just remade example from embassy-rs for blockin i2c
<holo[m]> * blockin i2c for rp pico w
<JamesMunns[m]> your pins are wrong I think
<Lumpio-> Check for reversed SCL/SDA?
<JamesMunns[m]> Should be I2C0, using pins PIN12 (SDA) and PIN13 (SCL)
<JamesMunns[m]> at least from what your bread board looks like
<Lumpio-> But they're using I2C1
<Lumpio-> And that supports pins 14 and 15
<holo[m]> ahh so i took wrong value form picture?
<JamesMunns[m]> oh, I lied?
<JamesMunns[m]> hold on let me re-count
<Lumpio-> Now for my favorite question - is the I2C address correct or does it need to be shifted in some direction by one
<JamesMunns[m]> ah, I2C1, pins 10 (SDA) and 11 (SCL)
<JamesMunns[m]> Lumpio-: its right
<JamesMunns[m]> the pins are wrong
<Lumpio-> what
<holo[m]> i have conncted SDA to 15 and SCL to 14
<Lumpio-> Which pinout are you looking at JamesMunns[m]
<holo[m]> i took this grey numbers
<Lumpio-> The peripheral supports multiple pin mappings doesn't it
<JamesMunns[m]> you want the green numbers
<holo[m]> ahh here will be problem
<Lumpio-> oh
<holo[m]> so 10 and 11
<holo[m]> changing in code
<JamesMunns[m]> yes
<Lumpio-> This HAL doesn't validate pins by type?
<JamesMunns[m]> they both happen to be i2c1 pins
<JamesMunns[m]> lol
<Lumpio-> Oooh they were right by accident
<Lumpio-> Or well wrong, but compiled, by accident
<holo[m]> still same
<Lumpio-> right right
<holo[m]> with that pin_10 and pin_11 still same error
<holo[m]> hmm or after second compile
<barnabyw[m]> confusingly, both pins 14 and 15 and GP14 and GP15 (pins 19+20) seem to be valid for I2C1 SDA and SCL
<holo[m]> not error but no ifnromations
<Lumpio-> Well that's progress though
<holo[m]> im not expecting values i know i need to decode them but at least anything should appear?
<barnabyw[m]> maybe put info~() calls between each I2C operation and see how far you’re getting before it hangs?
<barnabyw[m]> s//`/, s/~/!/, s//`/
<barnabyw[m]> and if you have a scope or logic analyzer, now’d the be the time to plug it in and take a look at what’s actually happening on the pins
<barnabyw[m]> s/the//
<M9names[m]> also, maybe follow the exact read procedure the provided example does. and read the datasheet to ensure that is sensible.
<holo[m]> writing_Reading hangs
<JamesMunns[m]> yeah, the SCD3x at least required a pretty decent amount of time for it to "boot up" after starting before you could talk to it
<JamesMunns[m]> not sure about the scd4x
<holo[m]> so before i will make first try of reading i should wait at least fiew seconds?
<barnabyw[m]> worth trying at least
<JamesMunns[m]> I mean in the example 9names posted they wait 5 seconds: https://github.com/hauju/scd4x-rs/blob/main/examples/linux.rs#L19-L24
<JamesMunns[m]> also iirc the scd30 required a CRC on every message?
<barnabyw[m]> but you could also read the datasheet and see if it mentions any timing characteristics
<holo[m]> 30ms max
<holo[m]> so will give him even 1 sec before i will start reading
<holo[m]> same
<holo[m]> thats how its looks now
<M9names[m]> have you read the example? sends a "wake up" command to the module to bring it out of sleep mode.
<JamesMunns[m]> Also sensirion parts require a certain message format: https://docs.rs/sensirion-i2c/latest/sensirion_i2c/
<JamesMunns[m]> it need to contain an 8-bit CRC at the end of every command or the sensor will ignore it
<holo[m]> in that 3.5 for this commands which im sending nothing mentioned about this CRC
<JamesMunns[m]> @holo look at section 3.3
<holo[m]> ahh yes there is CRC at the end
<holo[m]> hmm or not
<holo[m]> hmm those cmmands do not need CRC
<JamesMunns[m]> Either way, I would 1000% agree with 9names and that you should try to use or follow the behavior in https://github.com/hauju/scd4x-rs
<JamesMunns[m]> the fact you are not getting a NAK means the sensor is doing SOMETHING
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<holo[m]> according to my understanding there is in 3.5 lack of CRC
<JamesMunns[m]> youre also sending in little endian order
<holo[m]> will try to add this wake_up too
<JamesMunns[m]> pub const START_PERIODIC_MESUREMENT: [u8; 2] = [0x21, 0xb1];
<JamesMunns[m]> that will send
<JamesMunns[m]> * 0x21
<JamesMunns[m]> * then 0xb1
<holo[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> ```... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/rPJJtoVbkuCHkijjTqlVigWk>)
<JamesMunns[m]> oh no
<JamesMunns[m]> just kidding
<JamesMunns[m]> its late and I can't read
<JamesMunns[m]> that's fine
<holo[m]> 🙂
<JamesMunns[m]> and yes, you're correct, the "start periodic measurement" command doesn't require a CRC
<JamesMunns[m]> I would recommend waiting 5s after "start" before your first "read measurement", like the example does
<holo[m]> still same
<JamesMunns[m]> you're not waiting 5 seconds AFTER START_PERIODIC_MEASUREMENT like I said
<holo[m]> ahh i though
<holo[m]> on starupt
<JamesMunns[m]> sleep for 5 seconds where it says `info!("writing")`
<barnabyw[m]> waiting 100ms or so before you do anything isn’t a bad idea though, to make sure you’ve given the device time to start up
<JamesMunns[m]> i dunno if rust-analyzer is confused or it really is making that an i32
<barnabyw[m]> or 30ms if you trust the 30ms max start up time
<JamesMunns[m]> yeah, +1 to "100ms on startup, 5000ms after START_PERIODIC_MEASUREMENT".
<holo[m]> still same
<holo[m]> ok but its hang on START_PERIODIC
<holo[m]> so its even not going to this 5 seconds
<JamesMunns[m]> 🙃
<holo[m]> whn i removed wakeup it goes further
<JamesMunns[m]> Seems like it always hangs on the second command
<JamesMunns[m]> could be an embassy bug? Hard to tell without a logic analyzer
<JamesMunns[m]> Anyone else in the room with an SCD4x and an RP2040 handy?
<JamesMunns[m]> (and ideally a logic analyzer or oscilloscope?)
<holo[m]> you mean this?
<JamesMunns[m]> WELL WHY DIDN'T YOU SAY SO
<JamesMunns[m]> heel yeah wire that bad boy up to SDA and SCL
<holo[m]> i never used it before 😄
<holo[m]> ok give me some time 🙂
<JamesMunns[m]> s/heel/hell/
<JamesMunns[m]> I'm gunna go to bed (it's europe, late here), but basically you should have two probes, CH1 and CH2. they have a ground clip and a hook for what they are measuring. connect one of the ground clips (doesn't matter which one) to the GND of the breadboard, and CH1 to SDA and CH2 to SCL
<JamesMunns[m]> Maybe someone else here can help you set a trigger on falling edge of the SCL line with a capture window of "a while"
<holo[m]> im from europe too 2am here, no worry i think i will leave it for tommorow too
<barnabyw[m]> maybe the sensor board just needs a good night’s sleep and it’ll work perfectly in the morning
<holo[m]> i will check tommorow some tutorials how to use this thing and if something will back to you
<JamesMunns[m]> tho, learning how to do the basics with an oscilloscope or logic analyzer (and really, just having one) is seriously one of the best skills you can learn as an embedded developer
<JamesMunns[m]> to start, maybe just forget the i2c stuff, and set a pin low and high every 100ms
<JamesMunns[m]> then make sure you can read the square wave, then make sure you can set triggers on the falling edge
<JamesMunns[m]> once you can do those two things, and see the square wave clearly, then capturing the I2C pulses should be a good step forward
<holo[m]> for now i need to learn how to wire this thing and check if ist working i ordered it few years ago from alie when i wanted to learn risc-v board but it was to hard then for me for begining so its waited for now 🙂
<JamesMunns[m]> You're making progress, and are fairly close!
<holo[m]> thanks for helping i will try to read something how to use it tommorow and will back to you
IlPalazzo-ojiisa has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
Amanieu has quit [Ping timeout: 268 seconds]
stgl has quit [Quit: ZNC 1.8.2 - https://znc.in]
Amanieu has joined #rust-embedded
AdamHorden has quit [Quit: Adam Horden | adam.horden.me]
AdamHorden has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
tafa has quit [Quit: ZNC - https://znc.in]
tafa has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 252 seconds]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Client Quit]
crabbedhaloablut has joined #rust-embedded
m3vict[m] has quit [Quit: Idle timeout reached: 172800s]
agg has quit [Remote host closed the connection]
agg has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
pbsds has quit [Quit: The Lounge - https://thelounge.chat]
pbsds has joined #rust-embedded
stgl has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
markov_twain has joined #rust-embedded
Guest7282 has joined #rust-embedded
ruan[m] has quit [Quit: Idle timeout reached: 172800s]
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
tr09[m] has quit [Quit: Idle timeout reached: 172800s]
<AdamHott[m]> Question to the group: for designing PCB, I found that flux.ai has some AI features to help build schematics. But for actually preparing for a quote for PCB prototype manufacturing, I know I have to upload the gerber file. But there are a lot of other fields I don't understand in the quoting process. Is there a reference that would be good for me to learn these materials?
<AdamHott[m]> And I've found some additional software to analyze Gerber files, like AutoDesk Eagle, KiCAD, Altium Designer, Gerbv, and ViewMate. Wonder if anyone has opinions on these?
Lakier15[m] has quit [Quit: Idle timeout reached: 172800s]
<barnabyw[m]> AdamHott[m]: you could ask an ai about them :P
<JamesMunns[m]> idk, I'm of the opinion "things are twice as complex to debug as they are to design", so if the AI helps you design something more complex than you understand, you're probably out of luck if it doesn't work perfectly.
<barnabyw[m]> what other fields are you referring to, and what PCB manufacturing service are you looking at?
<JamesMunns[m]> KiCAD is pretty widely used for hobbyists, as well as for decently complex commercial usage as well. There are also a fair number of "design your first board and get it manufactured" tutorials on youtube for KiCAD
<JamesMunns[m]> Many of the other tools you mentioned are paid tools, for better or worse: If you DO pay for them there are like training materials for them (possibly also paid).
<barnabyw[m]> e.g. this one which covers making a basic MCU breakout board and getting it manufactured https://www.youtube.com/watch?v=aVUqaB0IMh4
<barnabyw[m]> IIRC fritzing has a simplified PCB manufacturing flow, if you’re okay with its limitations and the price likely being much higher than what you’d pay at JLC, PCBWay etc. I’d second the recommendation for KiCAD though, it’s very good and constantly improving
<AdamHott[m]> <barnabyw[m]> "what other fields are you..." <- So far I've looked at PCBWay and a number of low quantity prototyping PCB shops in the US like Pentalogix, Sierra Circuits, and OSH Park:
firefrommoonligh has joined #rust-embedded
<AdamHott[m]> <barnabyw[m]> "e.g. this one which covers..." <- This would be great to go through, thank you!
<firefrommoonligh> Confirming KiCad is nice
<firefrommoonligh> So the prob with OSHpark is it doesn't do assembly
<barnabyw[m]> soldering it yourself is more fun anyway 🤓
<AdamHott[m]> barnabyw[m]: yes this is what I want to do, to learn soldering well
<AdamHott[m]> barnabyw[m]: So I could just get the boards manufactured, order the parts, and solder away, right?
<firefrommoonligh> Yes
<firefrommoonligh> Might be a good learning exercise for a small board'
<barnabyw[m]> that’s how I’ve always done custom boards, yes. once you reach a certain density of components (or want more than one board) paying for assembly is definitely worth it though
<firefrommoonligh> Maybe use large passives
<firefrommoonligh> It will be tedius and error-prone
<firefrommoonligh> But maybe not a bad exercise
<firefrommoonligh> Yea try 0603 or greater
<firefrommoonligh> 0402 is the sweet spot for voltage dividers, bypass caps etc or really anything that doesn't need a high capacitance value, but will be trickier to hand solder
<barnabyw[m]> 0805s with handsoldering footprints are pretty much perfect for comfortable hobbyist handsoldering IMO
<barnabyw[m]> manageable without any particularly special equipment
<firefrommoonligh> I will say this: Almost all the faults on my own boards are from dorking up the hand-soldering of a part that is out of stock at JLC or w/e
<firefrommoonligh> It's never because the manufacturer fucked it up
<firefrommoonligh> (*Or for design faults on my part)
<JamesMunns[m]> AdamHott[m]: Adam Hott have you soldered before? Or done surface mount soldering before?
<JamesMunns[m]> if y'all are suggesting 0603 for a first soldering experience, on a board you actually expect to work, you are setting him up for failure :p
<JamesMunns[m]> like, after you burn the first dozen passives and scorch the first boards, yep, I'm sure he can get the swing of it, but like, maybe start with through hole if he's never held an iron before :D
<firefrommoonligh> Obligatory safety message: Both lead and flux fumes are bad for you!
<firefrommoonligh> In the not-immediately-obvious, but will damage your body over time way
<AdamHott[m]> JamesMunns[m]: I've done soldering before, did a lot of it when I was a kid in my grandpa's workshop. And I have painted in oils before which gives me that fine grain detail needed for smaller components. That being said I've never done surface mount soldering!
<barnabyw[m]> once I learned SMD soldering I’d never want to go back to through-hole (sooo many leads to clip and reflow, ugh) but yes, some small through-hole project is a good starting place if you’ve never held an iron before
<firefrommoonligh> * 0402 is the sweet spot for voltage dividers, bypass caps etc or really anything that doesn't need a high capacitance/inductance/voltage or current-handling, but will be trickier to hand solder
<barnabyw[m]> maybe buy a lil kit rather than jumping straight into designing your own PCB, if you’ve not soldered anything before
<firefrommoonligh> Yea IMO THT is not practical outside of larger ports
<firefrommoonligh> But still important because you will end up with those ports most likely
<firefrommoonligh> So you have to learn both
<AdamHott[m]> If I start with Through-Hole, what size components would I use?
<firefrommoonligh> Whatever the connectors spec you need is
<barnabyw[m]> might be worth backing up a step: do you have a specific goal at the moment? i.e. a particular project you want to make?
<firefrommoonligh> This is a 2023 board demoing that THT is still a thing. Mostly larger ports that need high current handling and structural stability
<AdamHott[m]> barnabyw[m]: I need some ideas for a pretty complicated project. I want to do something that stands out. I'm wanting to get a job in embedding and need some complex examples.
<barnabyw[m]> might I recommend several smaller projects in slowly increasing scope and complexity, each of which builds on the skills you developed in the previous one?
<AdamHott[m]> That sounds good
<firefrommoonligh> Ok how about this
<firefrommoonligh> Make a dev board for your favorite MCU
<firefrommoonligh> Or do something relevant to a hobby
<AdamHott[m]> firefrommoonligh: This sounds great
<ijager[m]> A LED cube is fun too, starts with basic GPIO, and to make it more advanced keep adding interfaces to control it from your computer. Control it via hardware timers instead etc.
Foxyloxy_ has quit [Quit: Textual IRC Client: www.textualapp.com]
<ijager[m]> * adding interfaces (UART, USB, WIFI, BT) to control
<AdamHott[m]> What about a micro:bit V2 dev board similar to this but way toned down? Is this too complicated?
<AdamHott[m]> -5nFnJFJ8NravdRJUYl7wMkaVcFvlpnxYRoCehMQAvD_BwE
<AdamHott[m]> Or is this even a Dev board?
Foxyloxy has joined #rust-embedded
Foxyloxy has quit [Client Quit]
<ijager[m]> I would advise to have a more clear goal for. your project, a dev board is too generic in my opinion. Like when is it finished? What software are you going to write for it?
Foxyloxy has joined #rust-embedded
<ijager[m]> Unless it is only about the PCB design
<AdamHott[m]> ijager[m]: I basically want an example where 1) I successfully get a board printed 2) I solder simple components to learn board soldering and 3) get some type of components attached like a USB hub for a keyboard and an LCD for keyboard output
<AdamHott[m]> And then write the software to glue it all together
<AdamHott[m]> It just needs to be somewhat impressive for an example to discuss in interviews
<ijager[m]> With a microcontroller or a rpi?
<AdamHott[m]> whichever works better for the example. The Raspberry Pi Pico W is affordable so that would be ideal.
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #rust-embedded
<AdamHott[m]> Hey all, I chatted with ijager and decided on project for this, thanks!
<AdamHott[m]> :)
<dirbaio[m]> 📣 we're looking for help testing a new version of `probe-rs` using the `nusb` crate (pure Rust replacement for libusb, fixes lots of pains for example around cross-compilation). If you use probe-rs (either the CLI or lib) we'd appreciate if you can give it a test and report whether it works or not!... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/YumOCIppcTEkUXvsiETeTTOH>)
kpcyrd[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<cr1901> JamesMunns[m]: I love postcard-rpc, but I can't use it for my use case b/c I need a UDP or TCP connection, not serial. So uhhh... is there a quick porting guide? :D
<cr1901> Additionally, I don't want to use tokio executor for this app, b/c the compile times are horrific on ARM SBCs (So I don't think "new_manual" applies)
<dirbaio[m]> you can crosscompile from your main PC
<dirbaio[m]> cross makes it relatively easy
<cr1901> I don't want to cross-compile. I like my current workflow and don't feel like changing it. :)
<dirbaio[m]> ¯\_(ツ)_/¯
<cr1901> That said, tokio might not be the problem, but rather the RPC crates I'm using/want to get rid of. So we'll see
<cr1901> (How do you make executor-independent async functions? Aren't a bunch of the embassy helper crates executor-independent?)
<dirbaio[m]> on Linux, you need a "reactor" to drive async io.
<dirbaio[m]> Tokio folks decided to integrate the reactor into the executor, probably for speed. so tokio io futures only work on tokio executor
<dirbaio[m]> but tokio is the exception really
<dirbaio[m]> most other async io crates are executor-independent
<dirbaio[m]> for example async-io
<dirbaio[m]> async-io launches its own reactor in a background thread, independent from the executor, so it works on any executor
sourcebox[m] has joined #rust-embedded
<sourcebox[m]> The whole idea behind Rust async is that the functions should be independent of the runtime.
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]> and all crates that build on top of async-io are also executor-independent, like async-net.
<dirbaio[m]> yeah
<cr1901> The leaf futures either launch a reactor or communicate with an already existing one?
<dirbaio[m]> it's actually Tokio who "screwed it up" by integrating the reactor into the executor. Since it's the most popular async runtime, people think "stuff is not executor-independent" is a rust async problem, while it's not, it's a tokio problem
<dirbaio[m]> I imagine first one creates it and then it gets reused for the whole lifetime of the program
<dirbaio[m]> haven't checked tho
<cr1901> (Actual question I want to ask: How do you do a single-threaded runtime?)
<dirbaio[m]> just use any single-threaded executor
<dirbaio[m]> though if you use async-io with a single-threaded executor you'd actually have 2 threads I think? one for the reactor from async-io, and another for the executor
<cr1901> You have to pass "here's how you communicate with the reactor" down to leaf futures, but I can't visualize it
<dirbaio[m]> but that shouldn't "matter", your futures can stll be !Send etc
<cr1901> yea I meant "only a single thread period", but noted
<dirbaio[m]> I think tokio's single-threaded runtime is actually a single thread (for executor+reactor)
<dirbaio[m]> I imagine leaf futures "find" the reactor through a thread local?
<dirbaio[m]> * thread local variable?
<cr1901> what does embassy executor/reactor do?
<dirbaio[m]> embassy is different, there's no "reactor"
<dirbaio[m]> the "reactor" is just interrupts
<dirbaio[m]> HAL code stores wakers in a global, interrupts wake the wakers
<dirbaio[m]> leaf futures from the HAL store wakers in globals*
<dirbaio[m]> so I guess it's kinda the hardware equivalent as async-io, but instead of a background thread you have interrupts triggered by the hardware
<dirbaio[m]> so it's also executor-independent
<dirbaio[m]> like, you can use embassy-stm32 HAL on top of RTICv2 executor instead of embassy-executor and it all works fine
<cr1901> Hmmm, I think I'll have to take a look to understand why leaf futures that store to wakers in globals are executor independent (b/c wouldn't embassy define the waker types? Does the RTICv2 executor also use embassy waker types?)
<dirbaio[m]> Waker is from core, so all executors use the same type https://doc.rust-lang.org/core/task/struct.Waker.html
<cr1901> ahhhh
<dirbaio[m]> it contains a vtable, so each executor can make it do a different thing when woken. (typically push the task into its run queue)
<JamesMunns[m]> cr1901 there's not a porting guide, but there's an "escape hatch" where you can make your own connection logic, basically exchanging frames (UDP would be a decent match).
<JamesMunns[m]> THAT BEING SAID, tbh, you might be better off with just using REST, or gRPC, or other existing concepts
<cr1901> (I'm trying to get rid of the HTTP server, so REST is out)
<JamesMunns[m]> yeah, fair.
<JamesMunns[m]> you COULD establish a UDP connection, then use https://docs.rs/postcard-rpc/latest/postcard_rpc/host_client/struct.HostClient.html#method.new_manual
<JamesMunns[m]> https://github.com/jamesmunns/postcard-rpc/blob/main/source/postcard-rpc/src/host_client.rs#L60 is an example of taking that WireContext and being in charge of sending/receiving frames
<cr1901> That is indeed something to play with, thanks!
<JamesMunns[m]> so you'd do something like take the UDP frames back and forth
<cr1901> A lot of the postcard stuff (pretty-hal-machine, postcard-rpc) is for serial ports, which fair, it's your library. But, in general I've not found the serial stuff very useful for my own work :(.
<JamesMunns[m]> I'm actually currently getting away from that a bit, for USB at least
<JamesMunns[m]> in a private project, I've switched to using nusb with bulk transfers, which means I end up with frames, sort of like UDP
<JamesMunns[m]> that one is fun because it also has multiple devices, which means I've had to add a routing layer on top of it (one USB device acts as a bridge for multiple devices, and you can have multiple USB bridges)
<cr1901> Nothing wrong with serial ports, I just don't find them ergonomic and/or "brings joy" when I have to provide my own USB CDC device or "RX/TX/GND cable"
<cr1901> (God all I do is bitch at your work, I swear I think it's awesome)
<JamesMunns[m]> :)
<JamesMunns[m]> I don't feel complained at!
<cr1901> :)
<cr1901> dirbaio[m]: So a waker has a vtable, one entry for "each possible executors the waker could ever be accessed by"? Why is this info needed at runtime (why would you ever modify a waker from two runtimes simultaneously?)?
<dirbaio[m]> a waker has a vtable with methods for "wake, clone, drop"
<dirbaio[m]> so embassy-executor will create a waker where "wake" points to embassy-executor code
<dirbaio[m]> RTIC will create a waker where "wake" points to RTIC code
<dirbaio[m]> so
<cr1901> (I think I'm used to a narrow definition of vtable for "dynamic dispatch to multiple possible implementations, and you can't know which one until runtime". Which I guess is technically true for Wakers too...)
<cr1901> But you'd only have one executor typically in your application, so the vtable could be set at compile time? Idk... :P
<dirbaio[m]> if you're running a task on embassy-executor, it goes roughly like this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/JdDVzzBcYruyPolXixUJEtzE>)
<dirbaio[m]> it's set up this way so you don't have to configure anything at compile time
<dirbaio[m]> and you can even mix executors. for example you could use embassy-executor and rticv2 on the same app. So some wakers go to one, some go to the other
<dirbaio[m]> would be silly to do, but async is designed to support that
<cr1901> Ahhh, I didn't realize you could compose runtimes
<cr1901> actually, scratch that
<dirbaio[m]> or on std, you might be using tokio but call a lib that's using smol underneath
<cr1901> Yea, this is nested event loops, correct?
<dirbaio[m]> could be nested, could be on separate threads
<dirbaio[m]> the dynamic dispatch does add a slight overhead
<cr1901> I remember a while ago (2018) a convo w/ Graydon on hellsite saying that "composing runtimes wasn't really possible/practical". Interesting that changed
<dirbaio[m]> embassy has an opt-in feature that does it https://github.com/embassy-rs/embassy/pull/1263
<dirbaio[m]> it makes wakers 1 word (task pointer) instead of 2 (task pointer, vtable pointer)
<cr1901> dynamic dispatch might actually matter for 10mill conns a sec :P
<dirbaio[m]> and removes the dynamic dispatch
<dirbaio[m]> if you opt-in to using that then the HALs are not executor-independent anymore, of course
<cr1901> Anyways, let's stop here, and let me chew on what you've said for a while. Thanks for the discussion
<dirbaio[m]> it's not something i'd recommend
<dirbaio[m]> but it's there in case you need to squeeze out the last % of performance or code-size:D
<cr1901> heh
vaknin[m] has joined #rust-embedded
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]> vaknin[m]: Welcome! https://esp-rs.github.io/no_std-training/ esp and ferrous systems have some training material that might be a good jumping in point for you?
<barnabyw[m]> <JamesSizeland[m]> "Welcome! https://esp-rs.github...." <- I’d start by getting a basic blinky example working on each board so you know you have a working dev environment and can build+flash firmware
<jessebraham[m]> We have a bit more of a general introduction for the ESP32 stuff as well:
<jessebraham[m]> Ahh, I guess the training links to that, doesn't it 😅
henrik_alser[m] has joined #rust-embedded
<henrik_alser[m]> <barnabyw[m]> "I’d start by getting a basic..." <- Teaching university courses in embedded systems, my experience is that Rust by far is the preferred path for getting into this stuff (EE and CS students with no prior Rust nor embedded experience)
eZioPan[m] has quit [Quit: Idle timeout reached: 172800s]
<henrik_alser[m]> <henrik_alser[m]> "Teaching university courses in..." <- (Thanks to the superior tooling, disregarding the obvious language benefits)
<vaknin[m]> <henrik_alser[m]> "Teaching university courses in..." <- ha, that's interesting, thanks for sharing!
<vaknin[m]> What 'framework' would you suggest to start with? I've seen 'embassy', 'RTIC', and so many other libraries, I'm quite confused
<holo[m]> hey, like i told yesterday i played with my osciloscope with trial and errors i get some outputs from I2C communication
<holo[m]> it looks like only half of command is sent with write_read finction
<holo[m]> and thats how its stucking
<holo[m]> any idea ehat could be wrong? here is my code for remind:
<JamesMunns[m]> Yup, looks like either:
<JamesMunns[m]> * embassy-rp bug
<JamesMunns[m]> * the scd device is getting very confused and is locked up or clock stretching
<JamesMunns[m]> could you try using the not-blocking methods?
<JamesMunns[m]> also, please stop pasting big blocks of code in chat, it'll be much easier to help you if you make a github repo
<holo[m]> ok sorry will do that
<holo[m]> And i have one more question about osciloscope what if coumication will be longer than my displacy? i mention its only showing this what fits on my screen
<holo[m]> how to make it non blocking?
<holo[m]> s/displacy/display/
<henrik_alser[m]> <vaknin[m]> "ha, that's interesting, thanks..." <- > <@vaknin:matrix.org> ha, that's interesting, thanks for sharing!
<henrik_alser[m]> > What 'framework' would you suggest to start with? I've seen 'embassy', 'RTIC', and so many other libraries, I'm quite confused
<henrik_alser[m]> Those two are both great options, for general work i tend to go with embassy these days as a first resort
<holo[m]> * how to make it non blocking i thought im using non blocking functions 🙂?
<holo[m]> And i have one more question about osciloscope what if coumication will be longer than my display? i mention its only showing this what fits on my screen
<barnabyw[m]> henrik_alser[m]: even if you don‘t end up using embassy, the embassy docs have a nice walkthrough showing how you’d implement the same application at several layers of abstraction https://embassy.dev/book/dev/layer_by_layer.html
<holo[m]> And i have one more question about osciloscope what if coumication will be longer than my display? i mention its only showing this what fits on my screen
<holo[m]> * how to make it non blocking i thought im using non blocking functions because im using non blocking example 🙂?
<JamesMunns[m]> holo[m]: > <@holo:matrix.org> how to make it non blocking i thought im using non blocking functions because im using non blocking example 🙂?
<JamesMunns[m]> > And i have one more question about osciloscope what if coumication will be longer than my display? i mention its only showing this what fits on my screen
<JamesMunns[m]> I mean to use the `async` version
<holo[m]> ahh
<holo[m]> ok will try
<JamesMunns[m]> I think the async hal bits are more commonly used, so its possible the blocking one has a bug
<JamesMunns[m]> if it "just works" with the async version, then it's probably an embassy bug
<JamesMunns[m]> (or rather, a "blocking hal method bug")
<holo[m]> thanks trying this second example in that case
<henrik_alser[m]> barnabyw[m]: If you’re familiar with async programming from other fields it should be a smooth onboarding to embedded programming
<holo[m]> and what with osciloscope? what if communication wont fit screen? is it some rewind option or something? when i was using horizotal positioning, graph was cutted on edge of screen
<JamesMunns[m]> Usually scopes will have some "sample depth", where the sample depth / sample rate is how long of a "snapshot" you can record
<JamesMunns[m]> > Thanks to a sample rate of 1 GSa/s and a memory depth of 8 Mpts you can easily work with this oscilloscope
<JamesMunns[m]> so, if you are sampling at 8msps, you can record one second
<JamesMunns[m]> for I2C at 100khz, you probably want to be recording at 200ksps+, 1msps wouldn't be bad. at 1msps you'd get 8s of recording time
<holo[m]> looking for this setting i remember i it somwher but not remember whenre
<JamesMunns[m]> It does show the value at the top center, where it says "5.00 MSa/s"
<vaknin[m]> henrik_alser[m]: thanks a lot, everyone
<holo[m]> thats it
<holo[m]> ?
<holo[m]> i can not set more than 4k
<holo[m]> and when i move right now with horizontal positioning its cutted
<JamesMunns[m]> you want "mem depth" to be 8M, and "sample rate" to be 1MSa/s
<JamesMunns[m]> usually the arrow means "use one of the dials to change the setting"
<JamesMunns[m]> Usually there's a menu knob
<JamesMunns[m]> lemme pull up a pic
<JamesMunns[m]> Oh, to the right of the `F0` button, there's a knob that says "MENU"
<JamesMunns[m]> try pressing Mem Depth and twisting that knob?
kenny has joined #rust-embedded
<JamesMunns[m]> If that doesn't do it: might be time to look up the user manual :D
<holo[m]> in menu i have 6 options
<holo[m]> at least right now i know what to search
<holo[m]> i thing that acquire wont be what i need
<holo[m]> * that acquire setting wont be
<holo[m]> ok got it this acquire menu is for it, for 2 channels i can maximum 4M
<henrik_alser[m]> <JamesMunns[m]> "Yup, looks like either:..." <- > <@jamesmunns:beeper.com> Yup, looks like either:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/tJNGLGYbmqkQMgROmuiQSAEm>)
<henrik_alser[m]> holo: Are you using external pullup resistors?
<holo[m]> its included on board
<holo[m]> James Munns: setting up this 4M depth didnt change anything, only this what is placed on one screen, i do not see too optoin to change sample rate. Its changing based on depth setting i choose
<holo[m]> i rewrite it for async function like adviced and now getting such runtime error:
<holo[m]> on osciloscope i see only first fuction sent
<JamesMunns[m]> whats the Err?
<JamesMunns[m]> you covered up the most important part :p
<holo[m]> ahh sorry
<JamesMunns[m]> src/bin/i2c_blocking.rs
<JamesMunns[m]> that doesnt look async :p
<JamesMunns[m]> not sure what that error is
<holo[m]> its in same file but like you see on log its executing async_fn
<JamesMunns[m]> main is an async fn
<holo[m]> i copied async configuration from ascync example to blocking exampe where i made my change
<barnabyw[m]> did you change let mut i2c = i2c::I2c… to make a new async I2C rather than calling new_blocking?
<holo[m]> s/change/changes/
<JamesMunns[m]> ahhhh you did async in the blocking example file
<JamesMunns[m]> got it
<JamesMunns[m]> abort reason 8: no ack
<JamesMunns[m]> so the SCD didn't ACK your bits
<holo[m]> it did in blocking 🙂
<holo[m]> but second was not send
<JamesMunns[m]> is the scope still showing the clock "stuck low" like in the other picture?
<JamesMunns[m]> <holo[m]> "1000000712.jpg" <- like does it look like this still?
<holo[m]> its showing only first part/command exactly like it was before with blocking
<holo[m]> right now i do not see even try of sending second command
<JamesMunns[m]> is it panicking on the second command? or the first one?
<JamesMunns[m]> the first one seems to complete successfully?
<holo[m]> according to log info on first its not going to "Wait 5 second"
<JamesMunns[m]> (gotta run for a bit)
<holo[m]> "writing" information not showint at al
<holo[m]> wheni reverted to previous blocking its like it was, strange Same logic is failing on other commands
crabbedhaloablut has quit []
notgull has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
<holo[m]> i made few additional tests, i added additional command (wake up) on beggining and im getting same error. So its not problem just with read_write. I tried same on blocking example, and first writing command is working and second writing command is breaking same way like read_write before, s on second byte. Looks like its always hanging on second command (no matter which it is) and on first command with await even its sending it
<holo[m]> properly. Can it be broken sensor?
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiisa has joined #rust-embedded
<barnabyw[m]> if you have a dev board lying around with arduino support, maybe try making an arduino sketch which communicates with it using the official library from sensiron? then you at least know a) whether or not the sensor works, and b) what successful i2c communication with it looks like https://github.com/Sensirion/arduino-i2c-scd4x
<holo[m]> i have rp5 too
<holo[m]> on other i2c pins same, ok will try your advice and will try to find something for rp
<holo[m]> to check if that sensor working at all
<holo[m]> 😆
<holo[m]> working
<barnabyw[m]> that was quick!
<holo[m]> i turned pico w off and on
<holo[m]> and started work 😄
<barnabyw[m]> huh
crabbedhaloablut has quit []
<GrantM11235[m]> Maybe it was the spinlock reset bug? I don't remember the exact details, hopefully someone else does
<holo[m]> After few next flashes happened same and i needed to take out usb power from pico to reset make it usable again. Ok now i need to decode what get back but after i will walk and thake some fresh air. Thank you all for helping
<henrik_alser[m]> holo: are you using the ”critical-section-impl” feature of embassy-rp?
<henrik_alser[m]> If you do, make sure you unlock spinlock 31 as suggeated above
<henrik_alser[m]> embassy_rp::pac::SIO.spinlock(31).write_value(1);
<henrik_alser[m]> First thing in main
<henrik_alser[m]> (rp2040 has a bug in it, where a reset won’t also reset the spinlocks)
<henrik_alser[m]> (one of which are used for the multicore safe critical section implementation)
<henrik_alser[m]> If you’re only using a single core, you can remove this feature and use the ”critical-section-single-core” feature on the cortex-m dependency instead
Noah[m]1 has quit [Quit: Idle timeout reached: 172800s]
notgull has quit [Ping timeout: 260 seconds]
<henrik_alser[m]> * a reset,, * as triggered by probe-rs, won’t also
Guest7282 has left #rust-embedded [Error from remote client]
vancz_ has quit []
vancz has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<holo[m]> <henrik_alser[m]> "holo: are you using the ”..." <- thanks for info, i will add it to my code What i mention it is crashing each second or third flash by a row
<henrik_alser[m]> holo[m]: Sounds very much like a spinlock issue
<barnabyw[m]> is there a no_std equivalent of anyhow which can work without an allocator?
<holo[m]> and looks like i added this line before i2c config and now 5th time in row flash working
<holo[m]> henrik_alser[m]: and looks like, i added this line before i2c config and now 5th time in row flash working
<holo[m]> nope
<holo[m]> i was celebrating to fast
<holo[m]> but, what i mention too this problem appear too when i remove sleep between commands
<henrik_alser[m]> Do you have it at the first line in main?
<holo[m]> ahh no
<holo[m]> will try
<holo[m]> same
<holo[m]> i think is something with sleep times between commands it looks itw working when i have 5 sec between each of them
<holo[m]> but with 1 sec it stoping working again
<holo[m]> exactly.. hmm maybe im missed something from datasheet
<holo[m]> such is crashing when i change it to 5 seconds its working
<holo[m]> this is locking pico or sensor and need to be restarted
<henrik_alser[m]> <holo[m]> "exactly.. hmm maybe im missed..." <- The datasheet says you can only read it every 5 seconds or it will return Nack
<henrik_alser[m]> You can check the get_data_ready_status 0xE4B8
<holo[m]> sumarizing those 1 seconds it is more than 5 sec
<holo[m]> with 5 sec after wake_up and rest with 1 the same
<M9names[m]> no, it's 5 seconds after you start measurement
<M9names[m]> but you're only waiting 1
<M9names[m]> and then it returns nack, which when you unwrap causes your program to panic
<henrik_alser[m]> And the reason it’s crashing for you is because you get a panic on unwrapping the Err
<henrik_alser[m]> (9names beat me to it)
<holo[m]> with this still same:
<holo[m]> and with such flash is breaking but after restart its working (i see on osciloscope)
<holo[m]> BTW is there posibility to reconnect without flashing to debug output?
<henrik_alser[m]> If you remove the unwraps and print the errors instead it will be easier to see where it fails
<henrik_alser[m]> holo[m]: probe-rs attach
<holo[m]> <henrik_alser[m]> "And the reason it’s crashing for..." <- i should handle it by match?
<holo[m]> * by match instead?
<holo[m]> * i should handle it with match instead?
<henrik_alser[m]> holo[m]: The i2c Error implements defmt Format so you can print it directly
<holo[m]> and what with that get_data_ready_status i should check this in loop if there is error before i start reading?
<henrik_alser[m]> holo[m]: Yeah or just retry if you get an Err when attempting to read measurement would do aswell i guess (maybe with a little delay)
<holo[m]> ok i added thos e reses and info but still same and not showing anything:
<holo[m]> still just hanging
<henrik_alser[m]> And removed the unwraps?
<holo[m]> sorry yes
<henrik_alser[m]> At what line does it stop?
<holo[m]> └─ i2c_blocking::____embassy_main_task::{async_fn#0} @ src/bin/i2c_blocking.rs:57
<holo[m]> what is strange when i reset it its working with same code
<holo[m]> 🙂