Closed nkolban closed 8 years ago
I'll have my hands on a CHIP later today or tomorrow, so I can try to repro.
Thanks Rick. Be sure and hit me up if you have any questions or can't reproduce.
Howdy Rick, how did your testing go?
Hi @nkolban,
Unfortunately I don't have access to the PCF8574A
to try this out. Sounds like the issue is timing related for sure.
One note since I don't have many I2C devices, the I2C functionality has only really been tested with the built-in PCF8574A
and AXP290
on the CHIP board.
I could take a look at any debug logs: sudo DEBUG=chip-io node <file>.js
to see if there are any hints.
@rwaldron thanks for helping out!
@ugate do you have an ideas on this?
@sandeepmistry I have an HD44780 and I'll have to look around to find my PCF8574A modules so I can test this configuration.
@nkolban Are you using a PCF8574A
module/breakout board or have you home brewed the components (images etc. may help)? Are you using any of the XIO
during your tests? I'm just wondering if there could be an issue between the PCF8574A
that your using and the built-in PCF8574A
that's also running on i2c-2
. Judging by the address you're using that may not be an issue, but that leads me to ask how you configured the address? Do you get the same results on i2c-1
? If you need help enabling it run this script and follow the prompts.
Have a look at the results of this google search:
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=lcd%201602%20pcf8574
The keywords are "lcd 1602 pcf8574". What you will find is that there is now a popular and cheap "module" that is based on the "PCF8574" that basically solders into a HD44780 module. Since the PC8574 exposes 8 pins of GPIO that are exposed by I2C, it makes "physical" wiring easier. Johnny-Five provides drivers that can drive the PCF8574 IC through I2C. As for a conflict, I found that the CHIP supplied PCF8574A is at address 0x38 while the unmodified HD44780 PCF8574A module is at 0x3F. Because I am running the 4.4 Kernel on CHIP, the bus on which the I2C peripherals are visible is "#2".
@nkolban Ah, I see. So, you basically have the PCF8574A
backpack module soldered to a LCD1602A
. Thanks for clarifying. I wanted to make sure that we are in fact talking about PCF8574A
vs PCF8574
and there isn't any wiring issues. Are you willing to enable i2c-1
on your CHIP as I previously suggested? The script will update your CHIP's DTB to enable i2c-1
when you reboot (or you can run it manually using fdtput
). As you've indicated, it was disabled in 4.4 to conform with DT NTC is using for DIPs. But if you're not using any DIPs we can enable it. I'd like to see if we get the same results on a clean bus as I feel this would be the simplest diagnostic step we could initially take.
Also, you may want to review johnny-five issue #326. There looks to be similarities to what you're experiencing and what others have reported.
Unfortunately I'm not able to make dramatic changes to the I2C bus of my CHIP. I only have two and I have a deadline for a book release based on CHIP that is only a week away. I was planning on having an illustration of driving the LCD1602 through Johnny-Five but have tested with this alternate node module:
https://www.npmjs.com/package/lcd-pcf8574
which works. I'd still like to get to the bottom of the Johnny-Five/CHIP LCD1602 interaction but can't, at this time, change the BUS. If there are other non-intrusive tests I can execute, I'll be delighted to do so.
Well... It didn't :X I had time allotted to work on it, but that time was eaten up getting the thing set up. I plan to come back to it as soon as I can
I tried your code, nothing display in my lcd, my ic is PCF8574T. $ node -v v4.5.0
@sumarouno thanks for trying it out, can you please try again node-chip-io v2.0.1?
I've noticed I2C is completely broken (was trying opening /dev/i2c-undefined
) in v2.0.0, and have pushed a fix.
@sandeepmistry , I upgraded to node-chip-io v2.0.1 as your request. I can confirm that no more problem to my lcd i2c backpack. This code is work like a charm:
"use strict";
var five = require('johnny-five');
var chipio = require('chip-io');
var board = new five.Board({
io: new chipio()
});
board.on('ready', function() {
let lcd = new five.LCD({controller: "PCF8574T", address: 0x27, bus: 2});
lcd.cursor(0,0);
lcd.print("1234567890");
console.log("We should now see text!");
});
Thanks for your great work
Oh no, wait @sandeepmistry . When i stop that code. and then run the code once again, the lcd show me unknown char. I don't know why. Thanks
the lcd show me unknown char. I don't know why. Thanks
What happens when you run the following:
"use strict";
var five = require('johnny-five');
var chipio = require('chip-io');
var board = new five.Board({
io: new chipio()
});
board.on('ready', function() {
let lcd = new five.LCD({controller: "PCF8574T", address: 0x27, bus: 2});
console.log("We should now see text!");
});
What happens when you run the following:
Hi @rwaldron , tried that, my lcd is showing nothing when run your code.
Thanks
Perfect! That's what we want :)
Now, let's try this...
"use strict";
var five = require('johnny-five');
var chipio = require('chip-io');
var board = new five.Board({
io: new chipio()
});
board.on('ready', function() {
let lcd = new five.LCD({ controller: "PCF8574T", address: 0x27, bus: 2 });
lcd.clear().cursor(0, 0);
lcd.print("1234567890");
console.log("We should now see text!");
});
Run this, let it print and then close the program and run it again. Please report back :)
Thanks!
Hi @rwaldron , tried your code, run, stop, and run again. Still show me the garbage text, III #3CScs
.
Thanks
Ok, thanks. I'll need hardware to test further and I'm not home until late tomorrow, so probably won't be able to try this until Friday. Thanks for your patience
Thanks @rwaldron.
Let me know if I can help by faking the PCF8574T
on an Arduino or something.
Also, the i2c code is based on node-ffi
and fs
and is all async, not sure if this is the root cause of the issue. I'm open to using the i2c-bus module that's been discussed in the J5 Gittter channel.
I would say thank you to @rwaldron and @sandeepmistry . I really appreciate your work.
@sumarouno What happens when you execute:
sudo i2cset -y 2 0x27 0x01 0x42 0x2e 0x48 0x2e 0x49 0x2e 0x50 0x2e i
Replace 0x27
with 0x3F
if your using a PCF8574A or PCF8574AT rather than a PCF8574
Hi @ugate , i tried
sudo i2cset -y 2 0x27 0x01 0x42 0x2e 0x48 0x2e 0x49 0x2e 0x50 0x2e i
and nothing happen.
Thanks
Garbage text is solved by using npm install sandeepmistry/node-chip-io#sync-io
from #19
@sandeepmistry I don't think that the issue was caused by the use of async (as described in #19), but rather the issue seems to stem from the fact that some operations were being performed synchronously while others were being performed asynchronously causing race conditions. An example of which is i2cConfig
which is synchronous while i2cWrite
is asynchronous. I have been working on a fork recently where I've added quite a few new features to chip-io
and have converted all of the operations to async. I ran some tests on that version and I never once got any garbage text, but when I run the current chip-io
code from master on the same example, I too periodically get garbage text that @sumarouno and @nkolban received.
That make a sense. May I try your fork?
Sure. I'll send the pull request to this repo soon.
Thank you
@ugate any updates on your PR? I'm looking at merging #19 otherwise.
@sandeepmistry You can go ahead and merge #19 if you'd like. The changes that I've made are pretty significant. So, I'd like to take some time to thoroughly test things out before I submit the PR. I've basically updated I2C to exclusively use ioctl
messaging versus using fs
for r/w (plus a lot of other unrelated features).
Closing this for now as #19 has been merged and it resolved the issue for @sumarouno.
I've opened #22 to track an alternative I2C layer implementation. @ugate please go ahead and submit a PR for your ioctl
when you think it's stable.
I'm writing a book on CHIP and want to include sections on using Johnny-Five to drive I/O. I am testing with an LCD 16x2 display with an I2C adapter. The Node.js script I am running is:
My node version is 4.4.7.
When I run the script, 1 time in 10 (approx) it shows the desired output, otherwise it is garbage text ... sometimes the garbage changes from run to run. I have validated that my LCD is working properly. Based on the fact that the output is non-deterministic, my thinking is that I am facing a timing issue of some description. Have you heard of anything similar?
If there are additional diagnostics I can provide, don't hesitate to post back. If I can assist live with real-time tests, screen shares or anything else, I can be reached on skype at "neil.kolban".