Windows Remote Arduino - Part One

A closer look Now that we have seen a bit of what Windows Remote Arduino can do before you write code or begin to explain something, we explore how it all works. In this section we will see the process behind the design of the library, having a close look at the structure and as mentioned, sharing the practical part in future articles with code examples. We will see whether the hardware is the software side. For those who wish to pursue the path of development right now, complete installation instructions and code samples can be found at this link.

Decisions which are the basis of design

We will discuss the design of the Windows Remote API Arduino. For example, starting from pinMode and digital Write, there are familiar functions to Arduino developers that rather than reinvent them, were unchanged in order to leave what is already familiar without changing the syntax, thus facilitating the development phase. APIs have been designed to reflect as much as possible those who are familiar with the Arduino concepts. There are of course changes, as the WinRT is fundamentally different from basic Wiring used in the Arduino sketch. However, with a little reorganization, you can use much of the logic and control of one Arduino sketch in an application using the library UWP Windows Remote Arduino. After designing the API, you need a protocol to facilitate communication between Windows and a familiar Arduino board, the protocol used, Firmata, in my opinion, was the most sensible choice. Even in this case, it is an open-source project that has been implemented in many other languages, including Arduino Wiring, moreover included by default in Arduino projects.

Architecture

As I read and understood, Windows Remote Arduino is divided into three layers. In the first, named Stream, communication is the physical communication, the initial layer, necessary for the exchange of data and information between Windows and the Arduino device. Above the initial level of communication, we have the Firmata protocol we discussed previously, which is responsible for decoding the raw data coming in and making them understandable messages. Finally, the last layer, called RemoteWiring, which abstracts all protocol messages, enables remote control of Arduino boards from Windows. Initial concepts for the development with the library

For all cases of use, the class RemoteDevice included on RemoteWiring in the layer is the starting point that the developer has to use for the interaction between the two devices. To interact, we have available the following IStream implementations that we must necessarily use when we create an object RemoteDevice: usbserial, BluetoothSerial, NetworkSerial or DfRobotBleSerial, contained in the Stream communication layer mentioned above. After invoking the begin() method on Stream, all subsequent API calls are made via the RemoteDevice instance created. So we can set the modes or states of the pin, read the digital pin values and/or analog, start I2C communication to other devices that support this protocol, and servo drive even as stepper motors or other hardware just using this single class. Expand Windows Remote Arduino functionality

For most experts, Windows Remote Arduino also allows you to customize the commands and features, this means Signed SysEx -- more information can be found at this link. For example, the management of SPI communication is possible via SysEx commands. SysEx commands enable developers to write complex or custom code that can run under Windows Remote Arduino. The addition of the SPI support

Usually, there are two communication methods -- (I2C and SPI) -- which microcontrollers typically use to communicate with other devices. This is commonly required for many sensors, and other equipments have their own MCU. Each of these two methods has its pros and cons, but both are widely supported by Arduino. Now, the library depends on the Windows Remote Arduino Signed Protocol to function. One of the disadvantages of using Signed is that there is no existing SPI support -- now with Windows Remote Arduino SPI operations are possible by using advanced commands, SysEx, as mentioned before. Fortunately, the three-layer architecture will allow the Signed layer to be in a relatively simple exchange with another implementation of the protocol. From there, the class RemoteDevice could be modified to accept the new protocol, or a new implementation of RemoteDevice could be written to use the new protocol level.

Conclusion

In this first article, I tried on the basis of my initial experience with Windows Remote Arduino, to give initial hints on what we can do, how it works, what are the pros and cons that everything has, unfortunately. I am confident that gradually this will become an excellent choice for managing Windows sensors of the Arduino family, to drive something more complex such as servo motors, stepper motors, and other equipment at this time requires a more careful development. In future articles, we will start the practical part, starting from the creation of a UWP project, and install the library using Windows Remote Arduino Nuget. Additional resources Below I leave links to deepen further in detail how the Windows Remote Arduino library.

Read more articles on Arduino:

• Arduino Due and Mobile Service
• Police Strobe Light Using Arduino