search

firmata / ConfigurableFirmata

A plugin-based version of Firmata
GNU Lesser General Public License v2.1
149 stars 71 forks source link

add a NewPing wrapper as a contributed feature #43

Open soundanalogous opened 8 years ago

soundanalogous commented 8 years ago

Since the Arduino pulseIn function is blocking it would be useful to have a non-blocking way to read ping sensors. One solution is to create a contributed feature (in the same fashion as FirmataEncoder) that wraps the NewPing library.

An initial pass at a protocol was submitted a while back: https://github.com/firmata/protocol/pull/6

There are some limitations of the NewPing library:

I also need to look into how much RAM and Flash memory the library consumes per instance.

EthraZa commented 8 years ago

Today I got my first Arduino (uno) kit with a hc-sr04 ultrasonic range finder and a stepper motor just to find out that I can not use it together with Node.js. :(

There is some news on this NewPing feature request?

soundanalogous commented 8 years ago

There has been no progress on the NewPing wrapper, however there are ways to use the hc-sr04 with Node.js if you use johnny-five. Here is one example: http://johnny-five.io/examples/proximity-hcsr04/ However, if you want to use the sonar sensor and a stepper motor simultaneously, then you'll have to create an i2c backpack for the HC-SR04. See this example: http://johnny-five.io/examples/proximity-hcsr04-i2c/. This is the best way to use this sensor with Firmata.

shostakun commented 7 years ago

I've just done a quick-and-dirty rearrangement of this PING_READ implementation using pulseIn for ConfigurableFirmata. The implementation is compatible with Johnny-Five's HCSR04 controller, but it seems that the command used, 0x75, has already been assigned to shift registers in ConfigurableFirmata.h. I'm hoping to eventually do a non-blocking implementation using NewPing, but I'd still like to keep it compatible with Johnny-Five. Any thoughts on how to resolve this conflict going forward?

soundanalogous commented 7 years ago

ConfigurableFirmata features that wrap libraries should use the extended ID (3 bytes) as described here: https://github.com/firmata/protocol/blob/master/feature-registry.md#optional-feature-set. Sorry this new process is not documented anywhere in detail yet.

Johnny-Five will need to support the extended ID. 0x75 should be deprecated.

soundanalogous commented 7 years ago

The NewPin Firmata wrapper should also be hosted as a module. See the FirmataEncoder module as an example. The module name should start with "Firmata...", so "FirmataPing" or "FirmataNewPing". The main difference is to use the 3 byte extended ID rather than the single byte ID like you see used in FirmataEncoder.

soundanalogous commented 7 years ago

Also don't create a new pin mode. I'm deprecating the use of pin modes for non microcontroller-specific pin functionality (but keeping for modes like: UART, Analog I/O, Digital I/O, I2C, SPI, DAC).

shostakun commented 7 years ago

I guess this will be more involved than I was hoping. I'll move this discussion over to: firmata/protocol#6.

I had already made a module called FirmataNewPing and used the standard INPUT, OUTPUT, and IS_PIN_DIGITAL rather than making new types, so no problems there.