Windows Remote Arduino - Part One

Introduction

 
With this short article with my initial experience, I would like to share a brief overview of the Windows Remote Arduino library, one of the technologies used in the World's Largest Arduino Maker Challenge.
 
Windows Remote Arduino
 
Windows Remote Arduino is an open-source library, which allows any Windows device, be it a Windows Phone, Surface, PC, or even Raspberry Pi 2 and other cards installed with Windows, to remotely control an Arduino board in different modes. The library allows developers to integrate with Arduino sensors in Windows projects, and manage tasks or applications of some complexity where only Arduino would be possible to achieve full implementation.
 
Find the library on Windows Remote Arduino dedicated GitHub page  in a repository called "remote-wiring." For those who are coming for the first time to the Windows world, Arduino, or the general Internet of Things, here you will find a good starting point. Below, we see in detail what library facilities in Windows remote Arduino you can control:
  • GPIO Pin I/O analog and digital.
     
    • The DigitalWrite() function.
    • DigitalRead function().
    • Analog inputs (PWM) by means analogRead() function.
    • Analog outputs (PWM) by analogWrite() function.
    • Setting the pin, and then declaring them as input or output.
    • Receiving events when the pin values undergo a change in logic state.
       
  • Send and receive data between devices using the I2C protocol.
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: