<dirbaio[m]>
are you running the unmodified example from the embassy repo?
<holo[m]>
yes
<holo[m]>
i didnt change for now anything
<dirbaio[m]>
that example is using one very particular i2c chip, are you using exactly that one?
<dirbaio[m]>
if you have another i2c chip you want to use, you'll most likely have to change the address and the data sent to it
<dirbaio[m]>
if the address is wrong you should get a "NACK" error instead of it simply hanging though
<holo[m]>
i have RP Pico W
<holo[m]>
exactly
<holo[m]>
what i read this should be exactly example for this board
<holo[m]>
other examples bliking led, wifi with server ware working
<dirbaio[m]>
i2c is a protocol for talking to other chips
<dirbaio[m]>
that you've connected to the GPIO pins on the board
<dirbaio[m]>
that example is assuming you've connected a mcp23017 (an I/O expander) to pins 14 and 15
<dirbaio[m]>
it's not built into the pico w board itself
<dirbaio[m]>
if you don't have that, it'll do nothing
<holo[m]>
i connected there SDC41 im not expecting ther willl be CO2 leve OOB but i thought at least some data will be recived
<holo[m]>
ahh
<dirbaio[m]>
then you'll have to read the SDC41 datasheet to see how to talk to it to i2c
<dirbaio[m]>
you'll have to change the i2c address
<holo[m]>
so it wont be showing anything else except that sensor?
<dirbaio[m]>
i2c chips have an "address" so you can talk to many different chips using the same pins, if you have the wrong address the chip won't reply even if it's connected on the same pins
<holo[m]>
from where i can take this address?
<dirbaio[m]>
the SDC41 datasheet
<holo[m]>
ahh so it will be hardcoded?
<holo[m]>
what if i have few same chips?
<dirbaio[m]>
it's hardcoded by the manufacturer yes
<dirbaio[m]>
sometimes the chip manufacturer adds some "address select" pins to the chip so you can customize it
<barnabyw[m]>
many chips give you some way to choose or program different addresses. otherwise, you need to connect them to separate I2C peripherals on your MCU, or via an I2C multiplexer
<dirbaio[m]>
but if not, all SDC41 chips will have the same address, so you can only talk to one of it on a single bus
<barnabyw[m]>
the SCD-41 isn’t on adafruit’s I2C address list (surprisingly, seeing as they sell boards with it on) so you’ll need to check the datasheet https://learn.adafruit.com/i2c-addresses/the-list
<holo[m]>
i have somwhere greate book which i read 10 years ago which explaining topic really well but its in C
<holo[m]>
s/read/red/
<barnabyw[m]>
once you know how the protocol works, you can pick up the rest by looking at some rust i2c examples. the programming language doesn’t make a big difference in this case, especially for blocking transactions
<barnabyw[m]>
the challenge is usually figuring out how to communicate with a specific device, which you do by reading the datasheet (unless you get lucky and someone wrote a library for it already)
<barnabyw[m]>
* it already, which is less likely with rust than C)
<holo[m]>
im more afraid if my rust skills will be enough to implement what i read or copy from other libraries to learn how to implement it with embassy-rs but i figure out GPIO so i hope will figure out it too
Guest6516 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
haobogu[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
samkent has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
cr1901_ is now known as cr1901
lehmrob has joined #rust-embedded
JamesSizeland[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has joined #rust-embedded
samkent has quit [Remote host closed the connection]
samkent has joined #rust-embedded
HumanG33k has joined #rust-embedded
lehmrob has quit [Ping timeout: 252 seconds]
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<holo[m]>
Hello i read yesterday [SCD41 datasheet ](https://sensirion.com/media/documents/48C4B7FB/6426E14D/CD_DS_SCD40_SCD41_Datasheet_D1_052023.pdf)and i have question about ACKs. Do embassy function write_read is implmenting them or i need to send them manually. If its implemented how its working, how to just send 1 bit? Is it just by setting up HI level on pin for some time or there is some possibility just to send 1 bit (i thought minimum
<holo[m]>
1 byte is possible)
<holo[m]>
* Hello i read yesterday [SCD41 datasheet ](https://sensirion.com/media/documents/48C4B7FB/6426E14D/CD_DS_SCD40_SCD41_Datasheet_D1_052023.pdf)and i have question about ACKs. Do embassy function write\_read is implmenting them or i need to send them manually in my code. If its implemented how its working, how to just send 1 bit? Is it just by setting up HI level on pin for some time or there is some possibility just to send 1 bit (i
<holo[m]>
thought minimum 1 byte is possible)
<JamesMunns[m]>
write_read handles the acks for you
<JamesMunns[m]>
on receiving, it writes the acks automatically, on sending it returns an error if a byte was not acked
<holo[m]>
JamesMunns[m]: so on writes i should check them before sending more?
<holo[m]>
ahh ok understand error there, how it is implemented? how it is sending one bit?
<holo[m]>
* ahh ok understand just error there to handle. how it is implemented? how it is sending one bit?
<JamesMunns[m]>
the write read handles the whole thing for you, and res is a Result, where it was Ok if everything went well, or Err if something bad happened
<JamesMunns[m]>
you don't need to handle things "manually", it's automatic.
<holo[m]>
if res is my answare what is that in for?
<holo[m]>
JamesMunns[m]: yes understand just curious how its implemented sending just 1 bit if minimal type have 8 bits
<barnabyw[m]>
`write_read` returns a `Result<(), Error>` which tells you if the operation was successful or not. if it was successful, the data which was read gets put in `in`, which is why you need to pass a mutable reference to it
<JamesMunns[m]>
holo[m]: to answer your question: the hardware usually does this automatically for you
<JamesMunns[m]>
so usually you give the hardware the array of bytes, and it "automatically" does the 8 data bits + one ack bit handling (for send or receive) automatically
<barnabyw[m]>
* or not (and what kind of error occurred, if there was one). if
<JamesMunns[m]>
if there's some kind of error in the ack bit, the hardware will set an "error" flag, or trigger an "error" interrupt. Embassy's driver will listen for that
<JamesMunns[m]>
if the hardware doesn't report an error, embassy's driver knows it succeeded without error.
<holo[m]>
Is it possible to implement i2c programatically? how in that case 1 bit is sent?
<Lumpio->
If you programmatically you mean without using the hardware I2C peripheral, then you would use bit banging and then you can do anything with the GPIO lines
<barnabyw[m]>
holo[m]: yes, it’s called “bit-banging”, and you’d send one bit by toggling the relevant pin with the correct timings
<Lumpio->
Bit banging means manually writing ones and zeros onto the lines, so you're free to do any amount of bits you want.
Guest7282 has left #rust-embedded [Error from remote client]
<holo[m]>
ahh so just setting HI level on pin for some time?
<Lumpio->
yep
<Lumpio->
Quite manually.
<barnabyw[m]>
but bit-banging uses a lot of CPU time to do something which hardware peripherals can handle for you, so it’s generally a last resort which you only use if you aren’t able to use a hardware peripheral. it can be a good learning exercise if you want to get a low-level understanding of how these protocols work, though
<Lumpio->
yep
<vollbrecht[m]>
and bitbanging is also quite subsceptible to timing problems/ timing glitches, so you need to design them often carefully so the end result works.
<holo[m]>
thanks for explaining i wont be implmeneting my own i2c for now i was just couriou when i saw that ACK as 1 bit in datasheet how it can be done
<barnabyw[m]>
afaik that’s an example of how embassy could be used in a web assembly environment, i.e. in a web browser
<K900>
No, it's for running it in your browser
<barnabyw[m]>
btw, for embassy-specific questions there’s a dedicated embassy matrix room: #embassy-rs:matrix.org
<vollbrecht[m]>
s/de/en/
<dav1d>
I wish there was a bridge for the esp and embassy channels as well :(
<barnabyw[m]>
do many people use this room via IRC? I tried briefly but found the way the bridge handles replies and reactions extremely noisy
<dav1d>
I prefer it over joining the matrix channel, mainly because I am also in a bunch of other IRC only channels. The bridge itself can be a bit annoying but it isn't too bad and it's nice that the channel is alive.
<dav1d>
e.g. the neovim channel does no longer have a bridge and it's pretty much dead now
Guest41 has joined #rust-embedded
Guest7282 has joined #rust-embedded
notgull has quit [Ping timeout: 276 seconds]
notgull has joined #rust-embedded
<holo[m]>
<K900> "No, it's for running it in..." <- Whats the case to start embassy-rs program in webbrowser on in wasm kubernetes/containerd? Isnt there better frameworks dedicated for wuch cases?
<holo[m]>
* In reply to @k900:0upti.me
<holo[m]>
Whats the case to start embassy-rs program in webbrowser on in wasm kubernetes/containerd? Isnt there better frameworks dedicated for such cases?
<holo[m]>
No, it's for running it in your browser
<barnabyw[m]>
I think it was more of a proof-of-concept, I’m not aware of anyone actually using embassy like that
<K900>
It's just proof that you can do something like that if you wanted to
<barnabyw[m]>
(but knowing dirbaio, he probably already wrote some big complex website completely in embassy 😉 without telling anyone)
<vollbrecht[m]>
its also a possible way to running embassy code not on an mcu rather on the "host" system albeit not nativ, but in a wasm runtime
<vollbrecht[m]>
so can be used for testing code directly etc
<vollbrecht[m]>
so if you write your application with a mcu specific part and an embassy no mcu specfic part you could run that code in wasm
<barnabyw[m]>
* (but knowing dirbaio, he probably already wrote some big complex website completely in embassy without telling anyone 😉)
<vollbrecht[m]>
* run that 2nd code in
<barnabyw[m]>
I wonder who’ll be the first to write a full-full-stack embassy application, with shared code between the embedded hardware, native application and web UI…
AdamHorden has quit [Ping timeout: 245 seconds]
<vollbrecht[m]>
there is a rust async project out there that does that to an extend exactly that - minus the embassy part. but you could easily adapt it to do that. check [this](https://github.com/ivmarkov/ruwm) out .
danielb[m] has joined #rust-embedded
<danielb[m]>
barnabyw[m]: my EKG runs a webserver on top of embassy, does that count?
<barnabyw[m]>
vollbrecht[m]: woah, very cool!
<barnabyw[m]>
danielb[m]: if the EKG webserver also serves a site running embassy via WASM? embaception!
<danielb[m]>
barnabyw[m]: no 🙈
<JamesMunns[m]>
<dav1d> "I wish there was a bridge for..." <- Catherine runs the bridge now, and might be able to add those channels?
Guest7282 has left #rust-embedded [Error from remote client]
kenny has joined #rust-embedded
<holo[m]>
What im thinking if there will be some solution like kubeedge but for mcu which can connect to k8s cluster such small devices and then start wasm on them as on normal wasm nodes right now in kubernetes clusters
AdamHorden has joined #rust-embedded
samkent has quit [Remote host closed the connection]
Guest41 has quit [Quit: Client closed]
Ekho has quit [Quit: CORE ERROR, SYSTEM HALTED.]
Ekho has joined #rust-embedded
whitequark[cis] has joined #rust-embedded
<whitequark[cis]>
<JamesMunns[m]> "Catherine runs the bridge now..." <- I can do that
<whitequark[cis]>
please DM me to discuss
jessebraham[m] has joined #rust-embedded
<jessebraham[m]>
The bridge seems to create a lot of noise, I already struggle enough to keep up with messages in the `esp-rs` room :/ Not sure I want more to deal with haha
notgull has quit [Ping timeout: 264 seconds]
<JamesMunns[m]>
<jessebraham[m]> "The bridge seems to create a lot..." <- Do you mean the join/leave messages?
<JamesMunns[m]>
I actually have those disabled in my client, so maybe I just don't notice it :p
<jessebraham[m]>
Yeah there are huge blocks of them in here every day haha
<jessebraham[m]>
Didn't know you could disable those
<barnabyw[m]>
Element does a pretty good job of collapsing the join/leave messages. I’ve never noticed any noise from IC
<barnabyw[m]>
s/IC/IRC in element, only the other way around/
<jessebraham[m]>
I gave up on Element long ago haha
<JamesMunns[m]>
Yeah, in element it's All Settings > Preferences > Timeline
<JamesMunns[m]>
in beeper they're off by default. Other clients no idea
<barnabyw[m]>
and wouldn’t be necessary at all if you add a _u8 to one of the literal numbers, then it’ll get inferred
<barnabyw[m]>
oh actually not for consts
<barnabyw[m]>
they need explicit types for some reason I can never remember
<Lumpio->
I think all "items" require an explicit type, it makes sense for anything "pub" at least because you don't want a public interface changing by accident because type inference decided it's something differnt
<Lumpio->
But yes sometimes it's a bit annoying, especially if the type is some ridiculous nested generic
<barnabyw[m]>
with consts it’s true even if they‘re not pub
<barnabyw[m]>
s/true/required/, s//`/, s//`/
<Lumpio->
As I said all items require a type
<Lumpio->
I wouldn't mind if they relaxed it a bit for private items
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
There is an RFC about allowing some type inference in statics and consts right now, but I'm not sure if it is a good idea. It's kinda like allowing `fn foo() -> _ {42_u8}`