And it randomly stops working - I did have some sample code that used the wiring from the 01.Basics\DigitalReadSerial, plus an LED on pin 10, and last night I had it working with Firmata reading digital pin 2 and turning on/off the LED to show state, but now it will not work properly
I seem to also have to set pin 0 to digital input in order to fire the callback when I push the button connected to pin 2, but the callback eventargs say that pin0 changed state, when it didn't, pin 2 did
By default StandardFirmata initializes all digital pins to output. Digital pin changes are reported on each iteration of the main loop in StandardFirmata. Pin changes are reported only if reporting is enabled for the port that pin belongs to. So to read a digital pin, you need to perform the following steps:
- Set the pin mode to INPUT
- Enable reporting for the port that contains the pin
- Subscribe to digital messages (0x9N where N is the port the pin belongs to)
In firmata port #s start from 0 and pins are allocated to ports in order, so D0-D7 = port 0, D8-15 = port 1, etc.
Regarding which Firmata/midi commands to send and receive, refer to the documentation here: https://github.com/firmata/protocol/blob/master/protocol.md. Specifically see set pin mode (0xF4), report digital port (0xDN where N is the port number) and digital I/O message (0x9N where N is the port number).
I see that was never updated in the old examples. I'll update the links now to avoid confusion in the future.
oh I see
so to read pin 2 I need to enable port 0
ahh, so I guess that was my misconception, I thought "port" was just another word for pin
So I doubt protocol docs or whatever will help me
Maybe you need to make that info a little more front and center? Even now knowing about ports, the only reference I can find to it is a comment in some code on the arduino site
sendDigitalPort(byte portNumber, int portData); //send an 8-bit port in a single digital message
And I have to store the old state to know what changed?
I don't see why that part is shifted to software, it would be way more efficient to do it in hardware surely?
session = new ArduinoSession(connection);
session.SetDigitalPinMode(2, PinMode.InputPullup);
session.SetDigitalReportMode(0, true);
session.DigitalStateReceived += Session_OnDigitalStateReceived;
...
private void Session_OnDigitalStateReceived(object sender, FirmataEventArgs<DigitalPortState> eventArgs)
{
var isSet = eventArgs.Value.IsSet(2);
Console.WriteLine($"Message is for port {eventArgs.Value.Port}. Pin2 value= {isSet}");
session.SetDigitalPin(10, isSet);
}
Do all the client libs work like this? You get zero delta information, just new state and you need to work out what changed yourself?
Some firmata client libraries sort that out for you, it really depends on the particular library. The reason we use ports instead of individual pins is throughput. When updating on every iteration of the main loop, it's far more efficient to report 8 pins at a time rather than individually. However a buffering mechanism would solve the same issue, but it was not initially part of the architecture. It is something I'm considering however for Firmata v3.
you could send more efficiently - in the above use case you only need to send two values to tell me that pin 56 changed to 1
for a port you are sending 8
but I spose what, you must always send a byte or something?
still, by switching to PIN/STATE you lose 50% bandwidth at most, but you could gain a bunch of CPU cycles at the host
maxing out the CPU of the arduino is no big deal
firmata/protocol#68
A new feature would be added that enables reporting individual pins in addition to ports
A firmware implementation would use one method or the other
1 bit per pin
but in binary of course
so all I am saying is maybe allow a mode like 00110