These are chat archives for nebrius/raspi-io

26th
May 2015
Derek Wheelden
@frxnz
May 26 2015 16:03
Anyone ever seen an error like this using I2C?
>> fs.js:615
    return binding.writeBuffer(fd, buffer, offset, length, position);
                   ^
Error: EIO, i/o error
    at Error (native)
    at Object.fs.writeSync (fs.js:615:20)
    at Bus.i2cWriteSync (/home/pi/git/photobooth/node_modules/raspi-io/node_modules/raspi-i2c/node_modules/i2c-bus/i2c-bus.js:332:13)
    at I2C.writeSync (/home/pi/git/photobooth/node_modules/raspi-io/node_modules/raspi-i2c/lib/index.js:338:36)
    at Raspi.i2cWrite (/home/pi/git/photobooth/node_modules/raspi-io/lib/index.js:508:21)
    at Strip.Controllers.I2CBACKPACK.show.value (/home/pi/git/photobooth/node_modules/node-pixel/lib/pixel.js:180:26)
    at null._onTimeout (/home/pi/git/photobooth/pixel.js:22:19)
    at Timer.listOnTimeout (timers.js:110:15)
Bryan Hughes
@nebrius
May 26 2015 16:05
@fivdi we ran into this before I think…hmmm…what was the issue
@frxnz are you calling anything that would set the pinMode of either of the I2C pins? (creating buttons, LEDs, etc)?
also, are you runing as root?
Derek Wheelden
@frxnz
May 26 2015 16:07
Yes to root
I stripped the code down to barebones, so I'm justing J5 and node-pixel
Here's my code:
var five = require('johnny-five');
var pixel = require('node-pixel');
var raspi = require('raspi-io');
var board = new five.Board({
    io: new raspi()
});

board.on('ready', function () {

    var strip = new pixel.Strip({
        length: 34,
        board: this,
        controller: 'I2CBACKPACK'
    });

    strip.on('ready', function() {
        strip.color("#f00");
        strip.show();

        setTimeout(function () {
            strip.color("#000");
            strip.show();
        }, 500)
    });

});
First call to strip.show() is fine, second call fails
Bryan Hughes
@nebrius
May 26 2015 16:10
oh interesting, that’s…unexpected
Derek Wheelden
@frxnz
May 26 2015 16:10
Isn't it? :)
No problems on Arduino
Bryan Hughes
@nebrius
May 26 2015 16:13
Can you do me a favor, go into node_modules/raspi-io/node_modules/raspi-i2c/lib/index.js and find the writeByteSync method at line 360?
There’s a block of code that looks like this:
        if (register === undefined) {
          this[getDevice](address).i2cWriteSync(address, 1, new Buffer([byte]));
        } else {
          this[getDevice](address).writeByteSync(address, register, byte);
        }
Before the if statement, add console.log('I2C write info: ', address, byte)
and then paste the output?
Derek Wheelden
@frxnz
May 26 2015 16:15
On it
Are you sure that's the right place? Not getting any console output
Bryan Hughes
@nebrius
May 26 2015 16:17
huh, that’s where the stack trace points (I think…there are source maps at play)
btw, are you sure you edited /raspi-io/lib/index.js, not raspi-io/index.js?
The latter is not actually used, it’s the original ES6 source
Derek Wheelden
@frxnz
May 26 2015 16:19
raspi-i2c/lib/index.js
I think writeSync is what is being called
Bryan Hughes
@nebrius
May 26 2015 16:21
quite possibly, those are the two methods that raspi-io calls
can you console.log address, register, buffer in the writeSync method? line 328
Derek Wheelden
@frxnz
May 26 2015 16:21
>> Red
I2C write info:  66 <Buffer 04 00 00 7c 07>
I2C write info:  66 <Buffer 02>
Blue
I2C write info:  66 <Buffer 04 7f 01 00 00>
I2C write info:  66 <Buffer 02>
Interestingly, it didn't fail that time
Bryan Hughes
@nebrius
May 26 2015 16:22
if you remove the console.log method, does it start erroring again?
Derek Wheelden
@frxnz
May 26 2015 16:24
Just ran it 5 more times, had 2 failures (that's with the console.log still present)
Bryan Hughes
@nebrius
May 26 2015 16:25
sounds like a race condition :-/
Derek Wheelden
@frxnz
May 26 2015 16:26
Seems that way. Just ran it 5 more times with console.log removed, all but 1 failed
Brian Cooke
@fivdi
May 26 2015 16:26
We had the EIO, i/o error when no device was connected to the Pi but that's not the case here.
Bryan Hughes
@nebrius
May 26 2015 16:26
can you do me a favor and edit /node_modules/raspi-io/lib/index.js and log the arguments to i2cConfig, i2cWrite, i2cWriteReg, i2cRead, and i2cReadOnce?
oh that’s right, I remember now
Derek Wheelden
@frxnz
May 26 2015 16:26
Sure
Brian Cooke
@fivdi
May 26 2015 16:27
@frxnz I've no experience with node-pixel, is there an AVR involved in the I2C communication?
Derek Wheelden
@frxnz
May 26 2015 16:28
Yes, this is communicating with an Arduino Nano
Probably should have mentioned that
Brian Cooke
@fivdi
May 26 2015 16:28
What baudrate is it I2C bus running at?
Derek Wheelden
@frxnz
May 26 2015 16:29
9600
Bryan Hughes
@nebrius
May 26 2015 16:29
technically it should haven’t a baud rate if the nano is in slave mode AFAIK
Brian Cooke
@fivdi
May 26 2015 16:29
You can find the baudrate in /boot/config.txt
Derek Wheelden
@frxnz
May 26 2015 16:30
Oh wait that's in debug
Brian Cooke
@fivdi
May 26 2015 16:30
I mean the I2C baudrate of the I2C bus on the Pi.
Derek Wheelden
@frxnz
May 26 2015 16:30
OH
Sorry
Brian Cooke
@fivdi
May 26 2015 16:31
The Pi is the I2C bus master and determines the I2C baudrate
Derek Wheelden
@frxnz
May 26 2015 16:31
Hm not seeing baudrate in config.txt
Bryan Hughes
@nebrius
May 26 2015 16:32
presumably there’s some default, but perhaps it’s too fast for the nano. Can you try setting the baudrate to 9600?
Derek Wheelden
@frxnz
May 26 2015 16:32
Sure, how do I do that?
Brian Cooke
@fivdi
May 26 2015 16:32
It should look something like this dtparam=i2c_arm_baudrate=100000
Is there nothing like this in /boot/config.txt?
Derek Wheelden
@frxnz
May 26 2015 16:34
This is all I have that isn't commented out:
# NOOBS Auto-generated Settings:
hdmi_force_hotplug=1
config_hdmi_boost=4
overscan_left=24
overscan_right=24
overscan_top=16
overscan_bottom=16
disable_overscan=0
dtparam=spi=on
dtparam=i2c_arm=on

dtparam=i2c=on
Brian Cooke
@fivdi
May 26 2015 16:35
Ok, add dtparam=i2c_arm_baudrate=10000
And dtparam=i2c_arm=on
Bryan Hughes
@nebrius
May 26 2015 16:35
perhaps I should add a default baud rate to the installation script (it already sets i2c=on)
Brian Cooke
@fivdi
May 26 2015 16:35
I think the default is 100000
But @frxnz set it to ten thousand, not 100 thousand
I think we're seeing the effects of a hardware but in the Pi
a hardware bug
Derek Wheelden
@frxnz
May 26 2015 16:40
Changed baudrate, rebooted, testing again
Brian Cooke
@fivdi
May 26 2015 16:40
:)
Derek Wheelden
@frxnz
May 26 2015 16:41
Just ran the script 6 times, no failures
Brian Cooke
@fivdi
May 26 2015 16:41
Th Pi is totally shit at supporting I2C clock stretching.
Bryan Hughes
@nebrius
May 26 2015 16:42
I wonder, can you do me a favor and explicitly set it to 100000 and test again? I’m curious if that value is also stable, and the default is something else
Derek Wheelden
@frxnz
May 26 2015 16:42
10/10. I think it's safe to say that was the issue
Sure, one minute
Brian Cooke
@fivdi
May 26 2015 16:43
Normal devices like a compass or whatever don't use clock stretching, so everything works fine, but microcontrollers always do.
Bryan Hughes
@nebrius
May 26 2015 16:44
I’m definitely documenting this in the README, and adding an explicit baud rate setting in the install script
Brian Cooke
@fivdi
May 26 2015 16:44
AVRs are too slow for I2C with the Pi at high speeds.
Derek Wheelden
@frxnz
May 26 2015 16:44
100000 = Failure on the first run
Derek Wheelden
@frxnz
May 26 2015 16:49
@bryan-m-hughes Are you going to use 10000 in the install script?
Bryan Hughes
@nebrius
May 26 2015 16:50
I’m thinking of still setting it to 100000. I’m worried that setting it to 10000 for everything will limit throughput on some sensors
but I’m also adding a section under I2C limitations that describes the issue and how to fix it
Derek Wheelden
@frxnz
May 26 2015 16:51
Ok, just wanted to know if we should document it in node-pixel.
Bryan Hughes
@nebrius
May 26 2015 16:51
That’s probably a good idea
Derek Wheelden
@frxnz
May 26 2015 16:51
Yep :)
Thanks for your help @fivdi & @bryan-m-hughes !
Bryan Hughes
@nebrius
May 26 2015 16:52
so I just published v1.0.3 of raspi-i2c. @frxnz can you do me another favor and go into node_modules/raspi-io and npm install raspi-i2c
oh wait, first edit /boot/config.txt and remove the two config lines
then npm install, then verify that both i2c_arm and i2c_arm_baudrate are set
I’m at 30,000ft and don’t have any hardware to test on ATM
Derek Wheelden
@frxnz
May 26 2015 16:54
Haha no problem
Bryan Hughes
@nebrius
May 26 2015 16:55
thx
Brian Cooke
@fivdi
May 26 2015 16:55
I think the default should be 100000, not 10000
Bryan Hughes
@nebrius
May 26 2015 16:56
:thumbsup:
Derek Wheelden
@frxnz
May 26 2015 17:01
The wifi in my office is probably worse than it is in your plane
Bryan Hughes
@nebrius
May 26 2015 17:02
haha, quite possibly. I should have thought to pack an RPi in laptop bag
Derek Wheelden
@frxnz
May 26 2015 17:05
Ok there we go
Looks good :+1:
dtparam=i2c=on
dtparam=i2c_arm_baudrate=100000
I'm off to lunch. Thanks again for your help
Bryan Hughes
@nebrius
May 26 2015 17:07
thanks a bunch for your help as well! I’ll get raspi-io updated with the new dep soon
Bryan Hughes
@nebrius
May 26 2015 17:12
ugh, I just realized that I probably should have bumped raspi-i2c to 1.1.0, since there is slightly different behavior now. Oh well.
Brian Cooke
@fivdi
May 26 2015 17:14
I think it's the same as before, the default is still 100000.
Bryan Hughes
@nebrius
May 26 2015 17:15
raspi-io 3.2.1 is out, with the raspi-i2c fix
I’m really liking that I hard lock the raspi-* dependency versions in raspi-io…means publishing a new version of raspi-i2c, etc doesn’t automatically get pulled in, and we can test it more easily first. And to think, this all started because there was some version of NPM that wasn’t properly updating dependencies of dependencies
Brian Cooke
@fivdi
May 26 2015 17:35
here's a description of the clock stretching bug on the Pi http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html
the same bug also exists on the Pi 2
Bryan Hughes
@nebrius
May 26 2015 17:40
ew
Brian Cooke
@fivdi
May 26 2015 19:12
@frxnz If you haven't done so already, you could increase the I2C baudrate in steps of 10000 to see what the max possible is. Or do a binary search for the max. It's somewhere between 10000 and 100000 :)
Or rewrite the I2C code on the AVR in assembler :worried:
Bryan Hughes
@nebrius
May 26 2015 19:46
Hmm...back off and wait is an interesting idea