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
<henrik_alser[m]> Which one is line 57?
<henrik_alser[m]> Ok so it never gets past the first i2c write?
<holo[m]> first iw waekup
<holo[m]> so second
<holo[m]> if i remove wake up then on read_write
<holo[m]> always on second command
<henrik_alser[m]> I guess it could be because the sensor doesnt know the mcu has been reset
<holo[m]> yep when i will turn off whole its working
<henrik_alser[m]> And it doesnt like to get a ”wake up” when already running?
<holo[m]> i will try to remove it
<holo[m]> it not necessary i think
<holo[m]> like i said
<holo[m]> i removed wake up
<holo[m]> and same but right now its stoping on 63 line so write_read
<holo[m]> its looks like doesnt metter what commands are before always on second
<holo[m]> and its happening only when flashing, maybe some probe-rs issue?
<holo[m]> basically if you personally not curious what is happening here i can leave with it i need it to work separately without debugger connected. I can proceed with this "get_ready_Status" command to remove this "timings" from code and will proceed
<holo[m]> s/get_ready_Status/get\_ready\_Status/
<holo[m]> s/leave/live/, s/get_ready_Status/get\_ready\_Status/
<holo[m]> * basically if you personally not curious what is happening here i can live with it, i need it to work separately without debugger connected. I can proceed with this "get\_ready\_Status" command to remove this "timings" from code
<holo[m]> so if its working after restart like it should its fine for me πŸ™‚
Guest7282 has joined #rust-embedded
<henrik_alser[m]> Still strange that it hangs though, it should just return a Nack Err
<holo[m]> if you want me to check something more here let me know
<holo[m]> it wont return nack becasue im not seeing it on osciloscope even
<holo[m]> its just hanging in middle of data sending
<holo[m]> and ack is presented (according to osciloscope)
<henrik_alser[m]> And then the sensor is clock stretching forever?
<holo[m]> this is how its looks like
<holo[m]> so its not NACK
<henrik_alser[m]> Gotcha
<barnabyw[m]> probe-rs
<henrik_alser[m]> I would guess it has something to do with the sequence of commands when it’s already running
<holo[m]> but probe-rs not reseting device after flash?
<henrik_alser[m]> Maybe try sending a stop command first thing before entering the loop
<holo[m]> i will move it from end to begining
<henrik_alser[m]> And make sure to wait > 500ms after that
<holo[m]> hmm
<holo[m]> looks good
<holo[m]> and even showing "reses"
<holo[m]> πŸ™‚
<henrik_alser[m]> Yay!
<holo[m]> πŸ˜„
<holo[m]> yep controller is reseted but sensor is not
<holo[m]> so its in reading state
<henrik_alser[m]> Yes and i guess it doesnt like seeing other commands when in reading state
<holo[m]> yep exactly:
<holo[m]> Will continue tommorow this ready check and finally decoding of values. Next will need to create module, structs and implement methods.. will have bussy weekend. thank you very much again for help!
<holo[m]> good night πŸ™‚
<henrik_alser[m]> Cheers! Sleep tight ✨
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 252 seconds]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 260 seconds]
crabbedhaloablut has joined #rust-embedded
<JamesMunns[m]> <holo[m]> "Will continue tommorow this..." <- Just a check, is there a reason you AREN'T using the existing SCD4x driver?
yourarj[m] has joined #rust-embedded
<yourarj[m]> Namaste and hello everyone. New to Rust embedded.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/lxRgSdxwSfykcYmPYfKfoUDv>)
<AdamHott[m]> <yourarj[m]> "Namaste and hello everyone..." <- > <@yourarj:matrix.org> Namaste and hello everyone. New to Rust embedded.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/bXhHwjgJwVMQRNjNQzXQdRjE>)
<JamesSizeland[m]> <vaknin[m]> "thanks a lot, everyone" <- https://www.theembeddedrustacean.com/p/embedded-rust-learning-guide I just discovered this resource too, could be useful
<holo[m]> <JamesMunns[m]> "Just a check, is there a..." <- Hey, mainly for learning purpose. Second i didnt found one based on embassy-rs and i will need embassy for wifi too
<holo[m]> I know there is posibility to mix HALs but sure if its good idea, and as noob wanted to learn just one framwork for beggining
<holo[m]> * HALs but im no sure if
<JamesMunns[m]> Gotcha, I won't argue with #1, re: #2 it might be worth using/adapting the existing crate. Most of the time turning a non-async crate into an async crate just means:
<JamesMunns[m]> * adding `.await` to all the driver calls
<JamesMunns[m]> * swapping `embedded-hal` to `embedded-hal-async`
<JamesMunns[m]> that way you don't have to re-invent anything, but if you WANT to re-invent everything, I won't stop you!
<holo[m]> ahh so same driver should work without any changes for embassy-rs too?
<holo[m]> s/too/just need to add await and include embassy await/
<JamesMunns[m]> yeah, actually, if you're using blocking, the driver should Just Work
<JamesMunns[m]> tho the driver might be on embedded-hal v0.2 instead of 1.0.0-rc.3
<holo[m]> JamesMunns[m]: ohh didnt know it
<JamesMunns[m]> `embedded-hal` traits are like the "common adapter", embassy's HAL(s) implement those traits, so all drivers are portable.
<JamesMunns[m]> that way you can use the SCD4x crate on RP2040, STM32, Nordic, etc. etc. with no changes.
<holo[m]> thats good news, and probably will switch to it. For now just for learning purpose will try to create my own driver
<holo[m]> im begginer in Rust too so that will be good thing on which i can learn it
<holo[m]> eg decoding function implementations or CRCs
<JamesMunns[m]> Up to you! That being said: when learning, I typically suggest:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/QgXfVPPQqlrkMZGTzkVIChZi>)
<JamesMunns[m]> and there for sure is a difference between:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MiibNFIPTstrsNsckUIvjVml>)
<holo[m]> I already used DHT22 driver for RP5 to read data from it but it was not so fun :). If i use ready to use driver prbably my Osciloscope would still stay on shelf. During that 2 - 3 days i didnt learn only how to create code to read it but too how to read and use datasheet and how use osciloscop, so avreage 1 day per one thing its not bad i think πŸ™‚
<holo[m]> * its not so bad i
<holo[m]> * James Munns: I already, * its not so bad i
<holo[m]> BTW according to osciloscope i figure out why i didnt saw anythihg what was behind screen on it. Dont know why decoding function on my osciloscope for I2C is only 4K mem depth, others have full support (4M). Why it is like that, I2C is so "havy" protocol?
<holo[m]> withou decoding function enabled i can see whole frames/commands with reply and scrol graph
<holo[m]> * withou decoding function enabled i can see whole frames/commands with reply and can scroll whole graph
<holo[m]> * depth, others decoders have full
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has joined #rust-embedded
<holo[m]> I thought from now it will be easier but i was wrong. Noob question, how to convert right now array of `[u8; 9]` data which i received to Struct which i created to store this data? And/or how to use 2 first array cells and connect to one value? Destination struct is simple:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HIaiIfFIRTYcvWJMDBEELmwe>)
<K900> That's not 9 bytes?
<holo[m]> array which im getting from sensor have 9 bytes (CO2 leve, temperature, humidity] each 2 first bytes have data 3rd have CRC and x3
<K900> Then you want `u16::from_be_bytes` or `u16::from_le_bytes`
<K900> Depending on endianness
<K900> And you probably want to verify the checksum first, and then convert the values
<holo[m]> K900 ⚑️: thanks its working. Is there some better way to put there those values?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VxOhBlQyPJCNMbYBctRidLVe>)
<K900> I don't know what the checksum is
<holo[m]> * K900 ⚑️: thanks, its working. Is there some better way to put there those values?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/luKJvzTJcNtgtKHQdBdEHxXU>)
<K900> So uh, it depends?
<K900> But yes this is what you want
<K900> No, this looks like it's operating on bytes
<K900> The uint16_t is the number of bytes to process, because C doesn't have fat pointers
<holo[m]> i was wondering right now why there are 2 parameters in this function πŸ™‚
notgull has quit [Ping timeout: 256 seconds]
starblue has quit [Ping timeout: 252 seconds]
AdamHorden has quit [Quit: Adam Horden | adam.horden.me]
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
link445645[m] has joined #rust-embedded
<link445645[m]> Hi all, I'm new to embedded, looking forward to join this community <3
<holo[m]> i did it πŸ™‚
<AdamHott[m]> holo[m]: Yayy!
<holo[m]> only what is not satisfying me still is that they are not looking acurate
<holo[m]> i know there are offset functions with which i should setup it to make it closer to real values?
<holo[m]> temperature is around 5*C and hmidity around 8% more than it is showing
<AdamHott[m]> Is your sensor placed near any heat or humidity source?
<holo[m]> second thing co2 level is doubled (im not sure becasue i have seond cheap china sensor which is showing 472 but i dont beleve it
<holo[m]> AdamHott[m]: right now not
<holo[m]> just putted on table
<AdamHott[m]> If you hold your hand around the sensor, does the temperature reading go up?
<holo[m]> ok humidity right now showing ok compared to second which i had before in other part of room but temperature is still 5 degree lower
<holo[m]> AdamHott[m]: yes
<holo[m]> can it be this one is showing proper values of co2 and that china one to low values, this data depends on temperature accuracy?
<holo[m]> s/to/too/
<holo[m]> * can it be this one is showing proper values of co2 and that china one too low values, or maybe is this data depends on temperature accuracy?
<AdamHott[m]> I read that accuracy will decrease when the frequency of readings increases, how often are you reading values?
<dav1d> Still looking for a 1-wire embassy compatible implementation for my temp sensor :(
<holo[m]> every 5 - 7 seconds
<AdamHott[m]> I'd look more into that
<AdamHott[m]> I'm not for sure
<holo[m]> huidity is +/- ok right now taking in to account it have 5% margin
<holo[m]> temperature is to low, but i think that offset is to adjust it?
<holo[m]> * adjust it, am i right?
<holo[m]> only what i do not understand if i really have 1k of CO2 in room πŸ˜„
<barnabyw[m]> 1000ppm CO2 is quite easily possible with a small or badly ventilated room, especially if there are multiple people there
<holo[m]> i made tests and i think right now this one is proper not that one from alie, i put it outside and it imdediatelly showed standard air values 350 - 550
<holo[m]> so yep its working πŸ˜„
<holo[m]> only that temperature will need that offset
<AdamHott[m]> congrats!
<holo[m]> thanks. Tommorow will try to use this library which you mention and will try to configure it with embassy and will compare values
starblue has joined #rust-embedded
crabbedhaloablut has quit []
PhilMarkgraf[m] has quit [Quit: Idle timeout reached: 172800s]