Solved I2C bitrate crash and clockstreching.

[espruino-discuss]

Posted at 2016-05-23 by Frida

After more than 10 days; I have solved the crash problem. It was in jshardware.h.
When the program was to store the bitrate in the address, the address was not divisible by 4.

I hope it will run on a normal Espruino too. I haven't tested it yet.

I have also chaged a lot in i2c_master.c

//#define i2c_master_wait(x)    os_delay_us(x/4) // do{}while(0)

When x is under 4 then the result was 0. So the waiting in the program was not good.

Now I use this

#define i2c_master_wait(x)    os_delay_us(x*y)

and sat it up so it could wait between 1 and 4 us.

if(bitrate > 400000) {bitrate=400000;}
if(bitrate < 100000) {bitrate=100000;}
y = 400000/bitrate;

I don't know the bitrate, but I have it running with wii nunchuck and htu21d at the same time.

Se the attachment files.

Are there sombody, that have some equepment to test the bitrate, and to try it out?

And clockstreching on all places where the clocksignal goes from 0 to 1.

before any change:

 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v85.134 Copyright 2016 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 512KB:256/256, manuf 0xc8 chip 0x4013
>  I2C1.setup({scl:D0, sda:D2, bitrate:400000});
 ets Jan  8 2013,rst cause:1, boot mode:(3,7)
load 0x40100000, len 1396, room 16
tail 4
chksum 0x89
load 0x3ffe8000, len 776, room 4
tail 4
chksum 0xe8
load 0x3ffe8308, len 540, room 4
tail 8
chksum 0xc0
csum 0xc0
2nd boot version : 1.4(b1)
  SPI Speed      : 40MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 4Mbit(256KB+256KB)
jump to run user1 @ 1000

after change in:

Espruino/Espruino/src/jshardware.h

/// Settings passed to jshI2CSetup to set I2C up
typedef struct {
  int bitrate;
  Pin pinSCL;
  Pin pinSDA;
//  int bitrate;
  // timeout?
} PACKED_FLAGS JshI2CInfo;


 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v85.134 Copyright 2016 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 512KB:256/256, manuf 0xc8 chip 0x4013
>  I2C1.setup({scl:D0, sda:D2, bitrate:400000});
=undefined
>

after change in:

Espruino/Espruino/targets/esp8266/i2c_master.c

_____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v85.134 Copyright 2016 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 512KB:256/256, manuf 0xc8 chip 0x4013
>echo(0);
{
  "sdkVersion": "1.5.3(aec24ac9)",
  "cpuFrequency": 160, "freeHeap": 9528, "maxCon": 10,
  "flashMap": "512KB:256/256",
  "flashKB": 512,
  "flashChip": "0xc8 0x4013"
 }
23.66751708984
44.48982482910
10.90604566494
/
T   = 23.667 °C
RH  = 44.489  %
DEW = 10.906 °C
 
new Uint8Array([127, 127, 81, 130, 144, 167])   \
{
  "joy": { "x": 127, "y": 127 },
  "acc": { "x": 325, "y": 522, "z": 578 },
  "btn": { "z": false, "c": false }
 }
=undefined
23.66751708984
44.48982482910
10.90604566494
\
T   = 23.667 °C
RH  = 44.489  %
DEW = 10.906 °C
 
new Uint8Array([127, 127, 81, 130, 144, 167])   /
{
  "joy": { "x": 127, "y": 127 },
  "acc": { "x": 325, "y": 522, "z": 578 },
  "btn": { "z": false, "c": false }
 }

---

Attachments:

• i2c_master.c
• jshardware.h

[espruino-discuss]

Posted at 2016-05-23 by @MaBecker

wow - thanks a lot !

---

Posted at 2016-06-28 by @MaBecker

@frida now I found some time to test this nice modifications

step one build a version with your modification and run some simple tests

I2C1.setup({sda:D4, scl:D5, bitrate:100000});
=undefined

>I2C1._options
={ "sda": D4, "scl": D5, "bitrate": 100000 }
> 

read data from eeprom

>I2C1.readFrom(0x62,9);
=new Uint8Array([48, 50, 48, 49, 48, 48, 48, 50, 50])
>I2C1.readFrom(0x62,9);
=new Uint8Array([255, 255, 255, 255, 255, 255, 255, 255, 255])

hmm ?

>I2C1.readFrom(0x62,9);
=new Uint8Array([255, 255, 255, 255, 255, 255, 255, 255, 255])
>I2C1.writeTo(0x62,1);
=undefined
>I2C1.readFrom(0x62,9);
=new Uint8Array([48, 50, 48, 49, 48, 48, 48, 50, 50])
> 

can not read twice, have to send dumy writeTo to read again ?!

i2cget -y 2 0x62 0 has no problems ......

any comments or hints ?

---

Posted at 2016-06-29 by Frida

Not at the moment. What type of eeprom are you using?

---

Posted at 2016-06-29 by @MaBecker

this one PCA9501

---

Posted at 2016-06-29 by Wilberforce

@MaBecker

Does it work with the standard firmware? Then you can be sure that the change is related to the new code..

---

Posted at 2016-06-29 by Frida

According to the datasheet:

The PCA9501 contains an internal address counter that increments after each read or
write access and as a result, if the last word accessed was at address ‘n’ then the address
counter contains the address ‘n + 1’.

So if you make two readings after each other, the address counter are moving further.

So you have to reset the adress counter to the beginning of your data, to get the same out again.

---

Posted at 2016-06-29 by @MaBecker

Yep - rtfm - thanks !

---

Posted at 2016-07-13 by ExperimentalZeros

Hi all,

I am having the same issue with the I2C as described on the first post. I am currently using firmware 1v85 and 1v86 (from @tve github) and found that the fixes on both the ".h" and ".c" files seemed not implemented.

I would appreciated just direction on what to do to get me going, as I would like to implement I2C to the Wemos R1 D2 board.

---

Posted at 2016-07-13 by Frida

If there isn't somebody that have made a pull request, it isn't in the original version.
I don't have the knowledge, to do a pull request.

---

Posted at 2016-07-13 by @MaBecker

ups - missed that, will create a pull by tomorrow

---

Posted at 2016-07-13 by ExperimentalZeros

@frida and @MaBecker,

Thank you both for such quick response! I will sure wait for the update!

---

Posted at 2016-07-14 by @MaBecker

@ExperimentalZeros for futher I2C please check

http://forum.espruino.com/comments/12682035/

and

http://forum.espruino.com/conversations/286554/

---

Posted at 2016-07-14 by ExperimentalZeros

@MaBecker

Thank you, very relevant I2C information. Also, I will update the I2C Implementation table.

---

Posted at 2016-07-15 by @MaBecker

@frida please double check i2c_master.c and jshardware.h

@tve please also take a detailed look, if possible.

---

Posted at 2016-07-15 by Frida

jshardware.h seems to be ok.
You've moved some things around for jshardware_common.c.
My concern is if the order of

/// Settings passed to jshI2CSetup to set I2C up
typedef struct {
  int bitrate;
  Pin pinSCL;
  Pin pinSDA;
//  int bitrate;
  // timeout?
} PACKED_FLAGS JshI2CInfo;

will influence on the other micro's, that have I not tryed.

I will check the other later on.

---

Posted at 2016-07-15 by @MaBecker

@frida hmm, thought that this was something you had changed in jshardware.h and mentioned in #1 to stop I2C1.setup({scl:D0, sda:D2, bitrate:400000}); from reseting.

maybe @tve or @gfwilliams can advise

---

Posted at 2016-07-15 by Frida

Yes I have changed it, but I never tested it on Espruino or Pico, to see if there were any problems there.

---

Posted at 2016-07-16 by @MaBecker

Ok - no problem - I can check on Pico

---

Posted at 2016-07-16 by Frida

Well, I downloaded Gordon's latest sources.
I made some changes, and from your files.
Special from i2c_master.c I have comentet some more lines out.
I compiled it, downloaded it to ESP8266-01, and it ran.
//i2c_master_wait(1); // sda 0, scl 1 //*********************
These lines are not needed anymore.

Try it out.

---

Attachments:

• jshardware.h
• i2c_master.c

---

Posted at 2016-07-16 by tve

Looks like the way the checking for clock stretching is coded it'll make everything quite a bit slower. At what clock rate does it operate with the clock stretching code?

---

Posted at 2016-07-16 by Frida

As I said in post #1:

Are there somebody, that have some equipment to test the bitrate, and to try it out?

Because, I don't have.

I have it running with htu21d and wi-nunchuck or 2 htu21d with sda and scl crossed
while they only have 1 address.

---

Posted at 2016-07-16 by @MaBecker

at the moment I am testing my i2c devices with 100KHz

---

Posted at 2016-07-16 by @MaBecker

@frida - ok - all your changes are now updated to this fork

---

Posted at 2016-08-29 by user67316

I'm interested in the I2c master software - can you confirm which is the latest file, is it compatible with ESPRESSIF's I2c master - and if so am I right in saying that clock stretching is implemented but there is no timeout - ie if the slave pulls the clock low and keeps it there the ESP will eventually watchdog reboot (if that is the case I'll endeavour to add a timeout)..

Any help appreciated - I'm doing great with the Espressif code but the lack of clock stretching is an issue for me. Just programming in C.

---

Posted at 2016-08-29 by user67316

I AM able to speed test and compare - see my other query - once I'm sure which code to grab I'll try it and report speed back - it is quite easy to speed up the ESPRESSIF code but this of course has additional checks for clock stretching.

---

Posted at 2016-08-30 by @MaBecker

Hi Pete (user67316),

these two files contain Frida's changes:

i2c_master.c
i2c_master.h

---

Posted at 2016-08-30 by tve

The current code operates at a little over 300khz, which is quite close to the 400khz max of many devices. It was significantly optimized from the espressif code and all the inner loops were pretty much rewritten. IIRC I tried to make it as fast as I could without exceeding 400khz and still leaving some dials in there to easily turn the speed down to 100khz.