Worst thing you are doing is handling the timer ticks. How do you think things are going to be synchronized with those ticks. I don't even what to discuss this logic which I don't understand; I just face a number of developers with such "timer thinking" which I would rather call "anti-thinking". You don't have to explain your rationale behind that, but if you can, it would be curious to hear. You don't really need to "time" or synchronize anything. You should just unconditionally send the data. More interestingly, the receiving side should do the same. But as the streams are generally lock each other, it would be important to do all the communications on both sides in separate threads, or, in some cases, some couple of threads dedicated to serial communications on each side.
You just need to use the class
System.IO.Ports.SerialPort
:
SerialPort Class (System.IO.Ports)[
^].
Now, the second aspect of it: you should not just send what you call "variables"; such approach would be totally non-structured, would take you anywhere. You should create some data structure which you can
serialize before you send it and
deserialize before you receive. This is a separate topic called
serialization:
Serialization — Wikipedia, the free encyclopedia[
^],
https://msdn.microsoft.com/en-us/library/ms233843.aspx[
^],
System.Runtime.Serialization Namespace[
^],
Binary Serialization[
^],
Using Data Contracts[
^],
DataContractSerializer Class (System.Runtime.Serialization)[
^],[
^],
DataContractJsonSerializer Class (System.Runtime.Serialization.Json)[
^].
—SA