Closed MaBecker closed 1 year ago
>try {
: print(Date.now());
: I2C1.readFrom(0,1);
:} catch(err){
: print(Date.now());
: print(err);
:}
946687016930.89868164062
946687018927.22033691406
InternalError: InternalError: Timeout on I2C Read Receive Mode
=undefined
Well, these could maybe be lowered a bit (to 1 sec?), but what about using software I2C? does that work?
But potentially if we lower it too much we stop real hardware which does delay its response from functioning correctly.
I feel like i2cdetect is very much a developer tool, it's nothing you'd use in production. I'm not sure it's worth a whole bunch of effort just so the 2 times a year someone uses it, they have to wait 1 minute instead of 13 minutes it takes.
Also, i2cdetect could trivially implement the small bit of i2c needed for a scan, and could just bit-bash it itself - that way it could complete everything very quickly.
I just added a WAIT_UNTIL_SHORT
for testing
>try {
: s=Date.now();
: I2C1.readFrom(0,1);
:} catch(err){
: print(Date.now()-s);
: print(err);
:}
2.23254394531
InternalError: InternalError: Timeout on I2C Read Receive Mode
Having a I2C1.detect({start:0,end:0x77}) returning a array of available id's would be great.
Any hints would be helpful ;-)
Just try copying the code needed from https://github.com/espruino/Espruino/blob/master/src/jsi2c.c#L66-L164 to do a read, but as JavaScript. Then you have complete control over the delay
Running on a Pico with 2v16.199.
Which is fine but it takes several seconds until this message is displayed and this is a nogo for a scanner like i2cdect.
Looks like there are some fiexd defs
https://github.com/espruino/Espruino/blob/f2fb0451c25d7ad0afe3bde0f97cf0994a87fbca/src/jshardware.h#L466-L482
https://github.com/espruino/Espruino/blob/f2fb0451c25d7ad0afe3bde0f97cf0994a87fbca/targets/stm32/jshardware.c#L2479
Any hints how to speed this up?