- Sat Aug 22, 2015 5:06 pm
#26821
Personally, I've been using I2C on Arduino for months, controlling an MCP23017 GPIO Expander, and it is working fine.
Moderator: Mmiscool
- Sun Aug 23, 2015 2:47 am
#26849
One of the problems with the "basic" i2c implementation is the following (realistic) scenario:
- communication with a slave fails due to a bit error or due to a software error
- slave remains in active state (not idle, waiting for start condition) because the conditions for the state machine haven't been met
- at some random point in the communication later on, either with this slave or another, the confused client thinks it's being talked to and starts operating the SDA line (and maybe even the SCL line if it features clock stretching). This is quite an "interesting" scenario to debug.
So this is the proper procedure (which is also explained in the NXP documentation):
- always monitor the SDA and SCL lines; the master can release them and they should go up then, but some client may still be pulling them down because it's confused
- the esp8266 allows monitoring outputs even though they're... outputs
- this makes sense in an open drain setup, where the actual state of the line may not correspond to the state to the state of the output (output = released = up, another devices pulls it down = down, wins).
- when line state doesn't match output state, assume confused client and reset bus (or report to end user)
- but reset procedure according to NXP: toggle the SCL line eight times, which would clear the state of a simple i2c slave, that doesn't monitor start/stop conditions within a data byte, then send a stop condition (IIRC).
- please note that i2c (as apposed to smb) does not have a "timeout" condition, so a simple slave could be hogging the bus for eternity.
On the other hand, timing is quite easy for i2c, because it's completely asychronous, just make sure two single SCL toggle never exceed the maximum bus speed. The simplest slaves can handle up to 100 kHz, but most of them can do fast mode or fast mode plus (400 kHz or more). Higher than fast mode you won't be able to attain on an esp8266 due to the software bit-banging nature.
- communication with a slave fails due to a bit error or due to a software error
- slave remains in active state (not idle, waiting for start condition) because the conditions for the state machine haven't been met
- at some random point in the communication later on, either with this slave or another, the confused client thinks it's being talked to and starts operating the SDA line (and maybe even the SCL line if it features clock stretching). This is quite an "interesting" scenario to debug.
So this is the proper procedure (which is also explained in the NXP documentation):
- always monitor the SDA and SCL lines; the master can release them and they should go up then, but some client may still be pulling them down because it's confused
- the esp8266 allows monitoring outputs even though they're... outputs
- this makes sense in an open drain setup, where the actual state of the line may not correspond to the state to the state of the output (output = released = up, another devices pulls it down = down, wins).
- when line state doesn't match output state, assume confused client and reset bus (or report to end user)
- but reset procedure according to NXP: toggle the SCL line eight times, which would clear the state of a simple i2c slave, that doesn't monitor start/stop conditions within a data byte, then send a stop condition (IIRC).
- please note that i2c (as apposed to smb) does not have a "timeout" condition, so a simple slave could be hogging the bus for eternity.
On the other hand, timing is quite easy for i2c, because it's completely asychronous, just make sure two single SCL toggle never exceed the maximum bus speed. The simplest slaves can handle up to 100 kHz, but most of them can do fast mode or fast mode plus (400 kHz or more). Higher than fast mode you won't be able to attain on an esp8266 due to the software bit-banging nature.
- Sun Aug 23, 2015 10:51 am
#26879
@eriksl
what would you suggest then as the command set for basic.
I am trying to keep it as simple as possible.
what would you suggest then as the command set for basic.
I am trying to keep it as simple as possible.
Serial terminal in the chrome browser see https://serialTerminal.com
http://esp8266basic.com
A BASIC interpreter for your ESP
Working now on Autodrop3d. A 3d printer with automatic part ejection system. https://autodrop3d.com
http://esp8266basic.com
A BASIC interpreter for your ESP
Working now on Autodrop3d. A 3d printer with automatic part ejection system. https://autodrop3d.com
- Sun Aug 23, 2015 11:37 am
#26887
I don't understand what you mean? When I said "basic" I meant "no thrills", I wasn't talking about the programming language.
You could always have a look at my i2c implementation, but iirc you're using the arduino one anyway.
You could always have a look at my i2c implementation, but iirc you're using the arduino one anyway.
