ConfigurableFirmata icon indicating copy to clipboard operation
ConfigurableFirmata copied to clipboard

add a NewPing wrapper as a contributed feature

Open soundanalogous opened this issue 9 years ago • 7 comments

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:

  • incompatible with Arduino Zero and Due (and I suspect other SAM-based boards)

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

soundanalogous avatar Jan 24 '16 21:01 soundanalogous

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?

EthraZa avatar Apr 08 '16 01:04 EthraZa

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.

soundanalogous avatar Apr 09 '16 06:04 soundanalogous

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?

shostakun avatar Mar 31 '17 04:03 shostakun

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 avatar Mar 31 '17 04:03 soundanalogous

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 avatar Mar 31 '17 04:03 soundanalogous

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).

soundanalogous avatar Mar 31 '17 04:03 soundanalogous

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.

shostakun avatar Mar 31 '17 05:03 shostakun