If, for some reason, the connection to the Arduino is lost, it may be nice to have some form of automatic reconnect mechanism.
Maybe also automatically do a new discovery of the Arduino device.
i.e.:
reconnect to last known serial port.
if that fails, find the first serial port that supports firmata.
Because IStringProtocol has nothing to do with Firmata and you should not combine 2 communication protocols on the same connection. Firmata already has the ability to send strings.
Currently this library mainly does Firmata connections on an Arduino.
But it also has the ability to open a normal serial connection to an Arduino.
In my opinion that is something this library doesn't need.
It should solely focus on Firmata connections, because a normal serial connection to an Arduino can be created via the System.IO.Ports.SerialPort class.
The only reason to keep the current basic serialport functionality is for the EnhancedSerialPort fixes for Mono. I don't know if these are still necessary, I find it very strange if Mono wouldn't have fixed this in the previous years.
I also propose to rename this package to a name that has Firmata in it.
And as Firmata is only a protocol and doesn't depend on an Arduino, Arduino may even be dropped from the package name.
Some methods in ArduinoSession throw exceptions in a worker thread while handling responses or waiting for a response (e.g. EnqueueReceivedString throws TimeoutException).
These exceptions aren't caught and cause the program to quit.
In most cases the error is recoverable, but by throwing exceptions in a worker thread, we have less control over the exception handling.
Don't throw exceptions here, we control the flow of the program, so can also generate an error event or something else.
hi thanks for amazing project , am working stepper motors , so can i control stepper motors with it ? if not how can we add stepper motor support to it
The Debug.WriteLine statements have a negative impact on the performance. They cause messages to be handled seconds after arrival if you have serious load on the arduino. I noticed this when with an arduino that sent 20 sysex messages per second.
TODO: find out if this method still works correctly when waiting for a reply on a message, while the arduino is also constantly sending other (sysex) messages.
I'm in trouble to compile netrcore3 brach ... i tried with Framework 4.6.1 - Net Standard 2.0 because can't compile it in 4.7.2/4.8 or standard 2.1 but there is an error in IFirmataProtocol to use C#8.
It can't use "default interface" in c# 7.3 to implement:
SendSysExWithReply(SysEx message, Func<SysEx, bool> replyCheck, int? timeoutMs)
Old firmata versions encoded the sysex payload as 2 7-bit bytes per byte.
That has changed somewhere in newer versions.
This may affect string encoding as well, so check that as well.
The SerialConnectionFinder returns ArduinoSessions instead of a serial connection.
The (serial) connection is no longer part of the interface, it is demoted to be an internal aspect of the ArduinoSession.
The rationale is that the serial connection typically only lives as long as the ArduinoSession. If you dispose of the ArduinoSession, the serial connection is also closed. Might as well dispose it then.
Also, SerialConnectionFinder should be renamed to FirmataFinder to emphasize the change in its interface of returning ArduinoSessions instead of serial connections.
For example, ObservableArduinoSessionTester contains a test that does nothing.
Why are there even Observables in ArduinoSession, while there are also event for the same things?
I.e. CreateAnalogStateMonitor() vs event AnalogStateReceived ?