Does J5 support 74HC4067 and 74HC4051 yet?

[aabm00]

Hello

Some days ago I send you a message asking if Mux Shield II was supported by J5 and you kindly are working in a controller for it. thanks !!!

I'm working in a project that an arduino Yun has to control machines (UTAS) (pressures, temperature and humidity) at this stage. Depending of the model they can be between 10 to 30 analog sensors.

So the Mux shield II would an option in some cases but in other probably with the 74HC4067 or 74HC4051 muxs would be enough and cheaper.

It would be nice if I could help in the implementation. I have taken a look at the firmata protocol to try to understand how it works (it isn't trivial). And some questions arise.

Is there some guide o similar, to how implement (code) new hardware in J5 firmata client?

It could be possible to have to edit the Firmata in the arduino side to add functionality for a new hardware or it's only needed in client side (J5)?

I am looking for a pressure sensors (not atmospherical) with range between -2000 and 2000 pascal. It would be necessary to add a new controller for them in J5?

Thanks

Links to the hardware:
74HC4067 https://www.sparkfun.com/products/299
74HC4051 http://www2.mouser.com/Search/Refine.aspx?Keyword=74HC4051

PD: It would nice if someone know where I can find this kind of pressure sensors (low pressure) -2000 to 2000 Pa. It's difficult to find them

[rwaldron]

https://github.com/rwaldron/johnny-five/tree/muxshield2

The problem with multiplexer ICs is that they generally require synchronous IO to function correctly. For example, with the muxshield2 uses a single pin for a single pin over 16 input I was forced to write a mechanism with these semantics:

1. add device pin to list of pins to report values for
2. create an async loop that will:
   1. look up the next device pin to read
   2. send the "select" instruction telling the IC to report for that device pin.
   3. send the request to read the common (1 per row) analog input pin. (The firmata protocol is best at sending a one-time-for-all-time request that says "I want this pin to be read and reported back, once every cycle"; those responses are handled by firmata.js and result in an event handler being called with the reported value).
   4. once the value is reported for the device pin in this iteration, the event handler on the common analog input pin must be unregistered to prevent any more deliveries.
   5. repeat step 2

This is all counter to the strength of using JS to write control programs, which is: send a single instruction indicating a request for continuous readings and async delivery. Now there are 5 digital writes, 1 pin mode change and 1 pin read request, very every single value reported by every single input that's initialized for input—vs. 1 pin mode change and 1 pin read request, for all time.

It could be possible to have to edit the Firmata in the arduino side to add functionality for a new hardware or it's only needed in client side (J5)?

Only on the JS side.

I am looking for a pressure sensors (not atmospherical) with range between -2000 and 2000 pascal. It would be necessary to add a new controller for them in J5?

That depends—is it a basic analog sensor? If yes, then no new code needs to be added, just use the Sensor class. If it's an I2C sensor, then a new controller would need to be written.

[aabm00]

I'm very sorry for the delay to answer
The last week and this one, I can't dedicate time at this project. I want to have time to understand how firmata works, and how you has implemented it, in a way to understand how to create controllers like "mux shield II" and others.
I hope the next week I can take a look at your comments about mux shield II.

Sorry again, and thanks

[ajfisher]

@rwaldron - we can probably support this using pin group - this and keypads was sort of the use case Jeff and I had in mind if we think it's a useful one?

[rwaldron]

How do pin groups help when pin reads need to be handled between pin writes?

[unsalted]

Sorry to dig this one up for y'all is there any movement on multiplexers? I'm about to integrate them in a project that requires a lot of potentiometers and was just looking to see if I could develop with j5, looks like this may be asking a lot considering what I read above.

[alexcroox]

+1

[rwaldron]

I think the only way to make this work is to create an I2C "backpack" component. We use this approach for other similarly complex or timing/speed-sensitive components. Basically it will work like this:

• Johnny-Five will communicate with an I2C peripheral that's running a firmware that we will write (that's pretty straight forward)
• The I2C peripheral will actually be another microcontroller (this is easy)
• The 74HC4067D will be connected to the I2C peripheral

Here are a few examples of backpacks that we've done in the past:

• https://github.com/rwaldron/j5-ds-touch#backpack-controller
• https://github.com/ajfisher/nodebots-hcsr04#i2c-backpack
• https://github.com/ajfisher/node-pixel/blob/master/docs/johnnyfive-i2c.md

I just ordered a pack of 5 74HC4067D ICs, should be here on friday. I will keep you posted :)

[alexcroox]

Just re-read the original post. Does it mean that the Mux Shield ll is supported already? I'm just looking to extend digital in/out with it.

[rwaldron]

Yes, Muxshield 2 is already supported, this example should be helpful to get you started: http://johnny-five.io/examples/expander-MUXSHIELD2-mixed

I'll try to write up a simpler guide for us in expanders and virtual boards

[alexcroox]

I think I love you

[rwaldron]

hahaha ❤️

[rwaldron]

Working on the 74HC4067 and hit something that I needed advice on: firmata/arduino#276

74HC4051 is still in transit.

[dtex]

Hi @aabm00,

Johnny-Five contributors and maintainers are loathe to close issues where someone has a need. We don't want anyone to ever feel that we don't care, but we just haven't gotten to this feature yet. Rather than leave it languishing as an open issue we have created a Requested Features page and added your request for these two expanders there.