Capability response does not report all pins for encoder

[jcvillegasfernandez]

Testing my Lazarus client for firmata I found missing informatión when firmata reports encoder pin capability.

It only shows pin2 and pin3 and from my reseach all pins are encoder capable so report capability should include that information, because I get all pin resolutions and capabilities from this report.

[soundanalogous]

It looks like there is an inconsistency in the current implementation between restricting pins to only those that support pin change interrupts vs allowing any digital pin on the board. I assume you're using an Arduino Uno or other ATMega328p-based board if you're only seeing the capability query reporting pins 2 and 3. This is due to this line.

[jcvillegasfernandez]

Yes, I am working with Arduino Uno.
A Lazarus client does not know with firmata hardware have, it only asks board for capabilities, that is the reason for geting all pin capabilities because this is the only way a Lazarus client knows what modules (I2C, Onewire, servo, etc) and pins working are in the board.

[jcvillegasfernandez]

I have just published my beta Lazarus client (Lazarus-client-for-Firmata-boards) if someone wants to try.

[jcvillegasfernandez]

Is there any body who could fix this issue? or can any body tell me how to do it?

[soundanalogous]

The first step is to determine if this is actually an issue or is WAI. An encoder will work best on pins 2 and 3 on an Arduino Uno because they use interrupts. Have you tested the encoder on other digital pins and do you feel its performance is acceptable in that case?

[jcvillegasfernandez]

I have not tested yet, I know (now after some research) arduino pin2 and 3 have interrupt capabilities but for most things you don't need that speed (a rotary encoder to adjust a level for example).
I think it is an issue, I am not talking about arduino I am talking about a protocol.
Imagine a Rasperry Pi, or an ESP8266 or whichever board you install the ConfigurableFirmata protocol on it, your ConfigurableFirmata client should know what capabilities the board has in order to work properly (even if you don't know if it is an arduino, etc.).
That is the reason a board has to inform about itself and a client only would use those reported capabilities.
In my case the client only could use 2 pins for encoders.

[jcvillegasfernandez]

I think I found another issue, I was working with an arduino nano , you know it has 2 more pins, but those pins are reported as analog pins only, so my client can't use them for other modes.

Can you see now, how important is report capabilities?

[soundanalogous]

The two extra analog pins on the Arduino Nano can only be used for analog input. It is a limitation of the ATmega328p, not Firmata.

[soundanalogous]

If I were to completely rearchitect the way report capabilities works, I would only report capabilities of the microcontroller. So there would be no such thing as a Servo Pin, an Encoder pin, a OneWire pin, Stepper pin, etc because they are not capabilities of the board. This issue that occured is pins types were assigned as identifiers of types of peripherals that could be wired to the board rather than just the core pin functions such as digital I/O, analog I/O, I2C, SPI, UART, and also identifying things like which pins support interrupts. The ideal way to handle Encoder would be just to report which pins are interrupt capable. The user can then determine wether or not to use the Encoder with interrupt pins only, or with digital pins that are not interrupt driven. However at this point I'm not sure when or if I'll ever get around to making such an overhaul. I'm really looking to people in the community to step forward to drive the effort and I can provide guidance along the way.

[jcvillegasfernandez]

I am a newbie to arduino, and I didn't kown the extra pins only work in analog mode.

Your point of view is right, but that involves a different approach solution and no firmata commands and a very very ... difficult task for me.
The real thing I want is made ConfigurableFirmata like a standard for everyone who wants to make a board for interfacing with a PC, router, etc.
So a client for ConfigurableFirmata will work on whatever ConfigurableFirmata board you have.

Now I have a new question related, is there a way an arduino knows it is an arduino board and what type Uno, Due, Mega, etc.?
If not, a new Firmata command could be implemented showing the board type, then you could prepare a database with boards capabilities this will solve a lot of problems.

[soundanalogous]

Now I have a new question related, is there a way an arduino knows it is an arduino board and what type Uno, Due, Mega, etc.?
If not, a new Firmata command could be implemented showing the board type, then you could prepare a database with boards capabilities this will solve a lot of problems.

This is not so simple. There is a way to identify the board architecture (e.g. __AVR_ATmega328P__) as well as the specific board (e.g. ARDUINO_SAMD_MKRZERO). That is how the capability query and response currently works (see Boards.h). The board architecture or specific board are identified at compile time and it's capabilities are defined there. Even if this section simplify defined a unique identifier for each board, a Firmata client would need to report back the pin layout to the board, effectively doing what the capability response does today in reverse. I think the current method is much simpler in the end.

[soundanalogous]

Correction from my above statement. The Firmata client would NOT need to report the pin layout back to the board. That's already handled correctly in the firmware. However, the Firmata client would need to understand the pin layout. That's what capability response give you today. A board Id would just be a round about way to get the data you already get from the capability response.