Comments (7)
Hi, thank you for reporting this issue. You are right. There is a bug in the argument checking in the writeQuick method in i2c-bus v1.2.1. This has now been fixed in v1.2.2 which was published on npm this morning. If you update to i2c-bus v1.2.2 the writeQuick method should function as expected.
The real question is that do I have to do anything else after the writeQuick? Somekind of stop communication is needed there to make the target device abort the comm, and ignore the bit we sent as a probe. --- well, if I'm right.
Whether or not it's a good idea to use writeQuick to check for the presence of a device is a different question. It will depend on the device and what the device does when writeQuick is called to write a bit to the device. To be honest, I wouldn't use a method that writes to the device to check for it's presence as write commands will generally tell the device to do something which may not be wanted.
i2c-bus has a scan method and that's what I'd used to check for the presence of a device. The scan method will detect the same device as the command i2cdetect -y -r
. The implementation of the scan method calls receiveByte which only reads data from the device. I'd do something like this:
'use strict';
var i2cBus = require('i2c-bus'),
i2c1;
function closeBus() {
i2c1.close(function(err) {
if (err) {
throw err;
}
console.log('finished');
});
}
function communicateWithDevice() {
console.log('communicate with device...');
closeBus();
}
i2c1 = i2cBus.open(1, function(err) {
if (err) {
throw err;
}
i2c1.scan(function(err, devices) {
if (err) {
throw err;
}
if (devices.indexOf(0x73) !== -1) {
console.log('found device');
communicateWithDevice();
} else {
console.log('device not found');
closeBus();
}
});
});
from i2c-bus.
Thanks a lot for the detailed answer and the quick fix!
Well, I fully agree what you are saying about the write. Actually it was a result of my desperate attempts. The case was that one device got always the bus jammed when I tried to do the traditional scan with receiveByte. (i might messed it up) But when I found the writeQuick version of the scan I was jumping in joy. :D "aaaah, the insiders do it this way"
The writeQuick works.
from i2c-bus.
Thanks a lot for the detailed answer and the quick fix!
Your welcome and thank you for reporting the issue.
The case was that one device got always the bus jammed when I tried to do the traditional scan with receiveByte. (i might messed it up)
If you call i2cdetect -y -r 1
from the command line, does the bus also get jammed? (If you haven't got i2cdetect installed the command sudo apt-get install i2c-tools
should install it.)
If you call i2cdetect -y -q 1
does it function correctly and detect the device at address 0x73 without jamming the bus?
Internally i2cdetect -y -r 1
uses receiveByte
and internally i2cdetect -y -q 1
uses writeQuick
.
The i2c-bus
scan
method uses receiveByte
because not all platforms support writeQuick
. For example, the Raspberry Pi supports both receiveByte
and writeQuick
, but the BeagleBone only supports receiveByte
.
The writeQuick works.
Thats good news 😄
from i2c-bus.
I did some tests with the async receiveByte and when I call it second time the bus gets stuck. This was the symptom at the first time.
"If you call i2cdetect -y -r 1 from the command line, does the bus also get jammed?"
No, the i2cdetec -y 1 didn't jam the device, and that made me suspicious. That's why I started researching. I must have done something wrong back then. The only thing that wasn't clear to me how to kinda "roll back" the probing operation. I read something about a STO signal (instead of STOP) which makes the targeted device abort the communication whatever was started. (i haven't got time to find the article again)
By the way in your example code when you are finished with the async scan you go on and do the i2c communication. Though within the i2c-bus.scan() you close the bus.
I have few options:
1 - you either thought re-opening it in the beginning of the I2C communications.
2 - that simple close within scan() is the STO i was looking for.
3 - it is just there because the scan() opens it, so it's has to be closed inside scan() as well
4 - i'm lucid dreaming, and next time I should take only the half of it. => That sto/stop is not needed 'coz receiveByte is "harmless" I can continue normal operation, nothing special is needed.
I promise if it's clear to me I'll stop.
from i2c-bus.
The only thing that wasn't clear to me how to kinda "roll back" the probing operation. I read something about a STO signal (instead of STOP) which makes the targeted device abort the communication whatever was started.
I'm not familiar with an I2C STO signal. There are START and STOP conditions, however the i2c-bus
API does not provide direct access to these conditions and allows the operating system to handle them.
By the way in your example code when you are finished with the async scan you go on and do the i2c communication. Though within the i2c-bus.scan() you close the bus.
This isn't entirely correct. The i2c-bus.scan() method opens an new Bus
object for the scan and stores it in a local variable called scanBus here. After it has finished its work, the scan
method closes the Bus
object that it stored in the local variable scanBus
here. The Bus
object that the user opens in order to call scan isn't closed.
1 - you either thought re-opening it in the beginning of the I2C communications.
2 - that simple close within scan() is the STO i was looking for.
3 - it is just there because the scan() opens it, so it's has to be closed inside scan() as well
4 - i'm lucid dreaming, and next time I should take only the half of it. => That sto/stop is not needed 'coz receiveByte is "harmless" I can continue normal operation, nothing special is needed.
If I understand things correctly, I'd say 1 and 2 are incorrect and 3 and 4 are correct.
If a Bus
object is created with open
or openSync
, that Bus
object can be used to talk to any number of devices on the I2C bus for as long as you choose. Any Bus
method, including scan
can be called as often as required. In addition, and if needed, it's possible to create more than one Bus
object for the same bus.
from i2c-bus.
The scan method works perfectly, and it perfectly does what I need.
Many thanks for your help!
from i2c-bus.
No problem. You're welcome.
from i2c-bus.
Related Issues (20)
- Aborting with `malloc(): invalid size (unsorted)` HOT 3
- Support for 16 bit command/index HOT 3
- Does this library support different speeds? HOT 3
- installation fails with docker on ARM64 (raspberry PI 4B) HOT 2
- .openSync() works async way HOT 8
- index.d.ts HOT 4
- Crashing when declared and run HOT 2
- cannot detect i2c device of shtc3
- HC-SR04 Ultrasonic Sensor example on i2c-bus HOT 3
- writeI2cBlockSync returns a PromisifiedBus rather than the suggested number of bytes written HOT 5
- Can't it be used on orange pi 3 LTS? HOT 1
- Failing to install on Raspberry Pi Zero 2 W HOT 8
- Slave mode support? HOT 1
- Asistance with reading a register HOT 3
- Approach for device abstraction layer HOT 5
- Error: EIO, Input/output error HOT 2
- Question - Thread Safety/Mutexing - Are the methods on an I2CBus thread safe on a RaspberryPi in Node.JS? HOT 2
- How to list available adapters? HOT 6
- Error HOT 3
- Install fails on macOS Big Sur (11.1) HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from i2c-bus.