-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
writeQuick #34
Comments
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.
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 '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();
}
});
}); |
Thanks a lot for the detailed answer and the quick fix! The writeQuick works. |
Your welcome and thank you for reporting the issue.
If you call If you call Internally The
Thats good news 😄 |
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?" 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 promise if it's clear to me I'll stop. |
I'm not familiar with an I2C STO signal. There are START and STOP conditions, however the
This isn't entirely correct. The i2c-bus.scan() method opens an new
If I understand things correctly, I'd say 1 and 2 are incorrect and 3 and 4 are correct. If a |
The scan method works perfectly, and it perfectly does what I need. |
No problem. You're welcome. |
Hi, I'm trying to make all my I2C communication async in my code and I bumped into the following. Please take a look at it, but it could happen that I'm doing something flat-out wrong.
It's about calling writeQuick, I include the test code:
wqtest.txt
and the output of the program:
output.txt
And the result is:
Also this little piece of code is supposed to check the I2C device's presence. It works fine - I used the sync version so far - but I want to make sure I understand it properly what I'm doing.
Could you please validate if this pseudo code is the way?
handle one device starts:
open i2cBus - nicely async and pass the instance on
...
device check: writeQuick/Sync a single bit -> then evaluate the the program's condition
and set true or false accordingly.
...
since the device check went through I can start communicating using the device.
... do some I2c comm ...
...
i2cBus.close()
handle one device ends
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.
The text was updated successfully, but these errors were encountered: