Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
@Diactoros sooo clock stretching is when a slave device holds the clock line load while is “thinks” about what it’s gonna send you.
So in normal i2c or spi communication the host micro starts the communication, and typically directly gets registers from the slave device. And it’s almost instant like talking to a spi flash chip
In newer devices the damn people abstract it so that it’s not register controlled the slave micro processes the request, handles other things then decides to respond when it’s ready... the issue with this is it holds the clock line low, while it thinks.. sure this wouldn’t be an issue using interrupts, but when you have 1 i2c perf, but 2 separate pairs of pins that can use i2c, and one pair is for switched power slaves vs non switched power slaves. I must mux the lines and switch the muxing of the pins to use the perf depending on who I’m talking to. Works perfectly if there wasn’t clock stretching, you can’t mux in the middle of a clock stretch, or everything gets fucked up... you almost have to wait for the fucker to be done thinking and respond before moving on, thus it can be interrupt driven, but blocking as in I can’t interrupt time scheduling to another slave on another channel if the current slave is clock stretching me for 3ms + ....
3ms doesn’t seem like a long time but in embedded milliseconds are like seconds in the real world... soooo much stuff can be done in a millisecond.. and wasting 3+ milliseconds clock stretching me means I am forced to wait... I like it keep my tasks 2 milliseconds or less. -
@Diactoros so a device responds in i2c as well as other protocols and ways with a NACK Or Ack... if shit is wrong with a normal slave it will NACk me and I will move on/try again later.. with these asic i2c devices they will accept the command, and ack me, so me, I think everything is fine and working. But when I ask for the read response they clock stretch.. in stead of just NACk as in not ready... no they clock stretch till they ready.. then respond in the message they send with a NACk or ack... so I could wait that long and still get a “simulated” NACk... rather than just letting go of the the lines and nacking me they falsely ack me....
Confusing right???
Lol drunk right now and pissed but the logic is correct -
@QuanticoCEO could you connect the line to an interrupt pin, enable the interrupt after you get the ACK, and then let the interrupt trigger when you need to handle the incoming data and meanwhile go do other stuff?
-
@RememberMe the chip has interrupt capabilities on the i2c perf no need for an extra line, the interrupt isn’t the issue, the issue is due to the clock stretching I can’t remux the lines to the other pair of i2c lines to talk to other devices while I wait. I can do other things while I wait for them, but I just can’t do any other i2c things.
-
@RememberMe yeah it’s like hell... if you are not ready to respond to my message when I send it, fucken NACk me.. don’t ack and then hold the line for 3x eternity (retrospec)
-
@QuanticoCEO
Hi I’d like to order a pepperoni pizza.
Hold please
20 minutes later
We made your pizza. Cash or Card?
Fucken clock stretching.... seriously ... if you’re gonna clock stretch me for any more than 3ms (which is still pushing it) just fucken NACK me so I know your not ready god damn.... it’s fucken i2c .... stop with the application i2c bullshit... I just want to read the fucken registers stop abstracting it put it on a god damn DMA..
clock stretching is why we can’t have nice things lol
rant