Nabto AppMyProduct using FreeRTOS Windows Simulator

Why choose FreeRTOS:

FreeRTOS is the market leading real time operating system and the de-facto standard solution for microcontrollers and small microprocessors. Few major Advantages of FreeRTOS are below

  • Provides methods for multiple threads or tasks, mutexes, semaphores and software
    timers. Thread priorities are supported.
  • Very small memory footprint, low overhead, and very fast execution.
  • A tick-less mode is provided for low power applications.

Nabto with FreeRTOS:

With Nabto AppMyProduct you can easily create a remote accessible device. You integrate a simple piece of software on the device firmware and now you are able to create an apps which can securely remote access and control your device even though the device resides behind your home firewall.

This blog demonstrates how Nabto application is built using the FreeRTOS Windows simulator. Windows simulator is used to evaluate the Nabto with FreeRTOS as proof of concept to ensure the software works as expected before porting to any particular hardware with Windows platform – however it should be noted that the simulator will not exhibit real time behaviour.

Nabto with FreeRTOS is a piece of C code, when integrated into an embedded networked
device, the device can be remotely accessed and controlled using a web based user interface or intelligent data acquisition system by using Nabto client APIs.

Every IoT (Internet of Things) device has a unique URL for automatic location over the Internet, and the technology allows secure, authenticated and extremely low bandwidth peer-to-peer connections to be established even when the device is deployed behind a NAT firewall. Nabto with FreeRTOS enabled IoT devices are even accessible over a local network in the absence of Internet connectivity.

The cloud infrastructure enables IoT devices to be accessed through a custom built user interface running in a smart phone app – the IoT device supplies the live data components of the interface (Example: Heatpump) by using a light weight UDP protocol.

 

RTOS-img1

About Nabto AppMyProduct:

AppMyProduct is an IoT application platform that helps you to
1. Quickly develop high-quality client side apps using the provided APIs
2. Customize the device side application using the provided demo application.
3. The uNabto framework and the client APIs can be downloaded using the below link.

https://www.nabto.com/downloads.html

uNabto Framework:

The drawing below gives a brief overview of how the Nabto platform actually work.
The Device represents the smart device and the uNabto server (uNabto SDK and Device specific Platform adapters) is running on the device. As soon as device connects to the Internet it identifies itself at the Nabto Basestation, using its unique ID which is already registered in AppMyProduct portal.

If a Client wants to connect to the device, a connect request with the device ID is sent to
the Basestation, and a direct connection to the device is established after verifying the identity of client. A client can be a native mobile app or an abstraction framework like our AMP Heat app used in this demo

nabto-platform-basics

Get more information on the AppMyProduct platform and the Client/Device SDKs
at appmyproduct.com.

The uNabto Platform Adapter:

The uNabto Platform Adapter is a small component that abstracts the Native Platforms
network and time functionality. The Platform Adapter is part of the uNabto server.
The uNabto server is divided into two layers:

  • The uNabto framework (uNabto SDK)
  • The uNabto Platform Adapter abstraction layer between the framework and the Native Platform

unabto-platform-adapter

The device specific uNabto server is readily available in AppMyProduct portal to port it to the FreeRTOS Windows module.

Implementation:

Nabto with FreeRTOS application securely connects your embedded device while handling networking, routing and encryption tasks. While using Nabto with FreeRTOS cloud hosting service, an embedded developer need to:

  1. Provide a network driver to interface FreeRTOS+UDP to their hardware platform.
  2. Add the Nabto with FreeRTOS source files to their project.
  3. Set ipconfigFREERTOS_PLUS_NABTO to 1 in FreeRTOSIPConfig.h (the
    FreeRTOS+UDP configuration file).
  4. Provide a single event handling C function to handle pre-formatted Nabto queries.

Nabto Queries:

Unique identifiers are used to distinguish between query types while data is sent to and
requested from a remote networked device in a simple UDP query packet.

A query can contain zero or more request parameters based on the operation triggered by the client application. Request parameters are used to send data to the remote networked device. Nabto with FreeRTOS automatically passes request parameters into the event handling C function.

RTOS-img2

Some query types require the remote networked device to respond with data. The application developer has to pass the response parameters using the event handling C function. Queries can be sent from a web based user interface (AMP Heat app).

FreeRTOS Windows Port for Heatpump Device Stub:

Download the port library from https://github.com/nabtodaemon/FreeRTOS-Nabto and follow the below installation instructions.

This demo uses the Microsoft Visual Studio (MSVC) version of the FreeRTOS Windows
simulator. The project can be build and debugged with the free Express edition of MSVC.

Steps:

  1. Download the source code (Freertos-Nabto.zip) and extract it.
  2. Ensure Microsoft Visual Studio (MSVC) is installed.
  3. Open the MSVC solution called FreeRTOS_Plus_UDP_with_CLI.sln, which is
    located in the \FreeRTOS-Plus\
    Demo\FreeRTOS_Plus_UDP_and_CLI_Windows_Simulator directory.
  4. The demo uses WinPCap to create a virtual network connection by accessing raw Ethernet data on a real network connection

Introducing the unabto_config.h configuration file:

The Nabto source files contain several constants that affect its behavior. Default values for each constant are set in unabto_config_defaults.h. To modify a value from its default setting,re-define the value in unabto_config.h (do not edit unabto_config_defaults.h).

Network configuration:

This demo project is supplied with ipconfigUSE_DHCP set to 1 in FreeRTOSIPconfig.h. If
DHCP is not used a static IP address must be configured and ipconfigUSE_DHCP must be
set to 0.

Steps:

  1. The static IP address is set by the constants configIP_ADDR0 to configIP_ADDR3.
    Edit these constants to appropriate values for your network. The chosen address must be compatible with the network, and unique on the network (the IP address will be compatible if its first three octets match the first three octets of other IP addresses on the same network).  This step shall be skipped if DHCP is used.
  2. Most Windows computers have more than one physical network interface, so it is
    necessary to define which interface the stub will use. A mapping of interfaces to
    interface numbers is displayed when the tutorial application is executed (see Figure
    below). Set configNETWORK_INTERFACE_TO_USE to the number of the interface to
    use.

Network-Config

Device URL:

Every Nabto with FreeRTOS device on a network must have a unique URL. The URL is
obtained by calling an application defined callback function pcApplicationNabtoDeviceURL().Applications that use Nabto with FreeRTOS must provide an pcApplicationNabtoDeviceURL() implementation. pcApplicationNabtoDeviceURL() can be found in main.c.

const char *pcApplicationNabtoDeviceURL(void)
{ 
    /* Enter your device id here */ 
    static const char * pcURL = "abc.xyz.appmyproduct.com";

    /* Return the URL that will be used by the device.  The URL must be in 
    persistent memory (not declared on the stack of this function), and 
    unique on the network.
    A unique URL can be created by prefixing the main URL with the serial 
    number or MAC address of the device (or any other unique identifier).
    It is ok in this case to use a simple constant string, provided only one 
    instance of this project is connected to the network at any one time, and 
    that the default project configuration is not changed to allow remote 
    access. */ 

    return pcURL;
}

Device Key:

Every Nabto with FreeRTOS device on a network has got a key associated with it. The device key is encoded in the function xStartNabtoTask() found in nabto_task.c (folder: FreeRTOS+/Source/FreeRTOS+Nabto/platforms/freertos_net/nabto_task.c)

/* Set device key */ 
if (!unabto_read_psk_from_hex("<device-key>", nms->presharedKey, PRE_SHARED_KEY_SIZE)) 
{ 
    vOutputString("Invalid cryptographic key specified"); 
    return false; 
}

Local Vs Remote access:

Nabto with FreeRTOS can be configured to accept connections from local (non-internet)
addresses or accept connections from remote (internet) addresses, or accept connections
from both local and remote addresses simultaneously.

The unabto_config.h file supplied with this demo is configured to accept both local and remote connections.

Running the Heatpump stub:

Start the Heatpump demo by selecting “Start without Debugging” from the Visual Studio’s
Debug menu. A Windows console will open displaying the available network adapters and the network configuration.

RTOS-HP-stub1

The device will try to register with the Nabto Basestation. Once the device gets registered
with Basestation, you will see the message “State change from WAIT_GSP to ATTACHED”
as in the below figure.

RTOS-HP-stub2

Now, using the AMP Heat app (available on Google play store and Apple app store) connect your device and verify whether it works. When the AMP Heat app is started for the first time, you need to pair your client with the device. Then on, the paired device will be automatically discovered if it is online.

AMP-stub1

AMP-stub2

FAQ:

Why I am unable to connect to the device?

The windows simulator creates a virtual network interface by reading and writing raw Ethernet data through a real network interface. Any connection issues encountered are likely to be related to the operation of the virtual interface, not the operation of the Nabto with FreeRTOS code.

Things to try if you are not able to connect to the device when it is running.

Ping
Try pinging the configured IP address. If ping replies are received then it is likely the problem is not related to the network configuration.

Wired Vs Wireless network interfaces
Using a wired network is preferred rather than a wireless network. If that is not possible try connecting to (or pinging) the project from a different computer on the same network.

Firewall
Often in corporate environments, they enforces a policy on windows machines that prevents a uni cast response to a broadcast request. The following URL provides information on how to check if uni cast responses are allowed on your machine: http://technet.microsoft.com/enus/library/cc742429.aspx

Try temporarily disabling any firewall or other network filtering software during your testing.

Hubs and Switches
Intelligent hubs and switches can shield network nodes from traffic. Try connecting through a dumb hub.

 

Remote control your Arduino MEGA and Wiznet Ethernet with AppMyProduct

Summary:

With this article you will learn how to create a firmware and an app to securely Internet remote control (from inside AND outside your home network) an Arduino MEGA board with a Ethernet Shield. The IoT communication infrastructure used for this is AppMyProduct.com a Software as a Service, Pay as you Go (with free demo licenses) version of the Nabto.com Enterprise platform which makes it easy to create remote control IoT systems for all types of microcontrollers and remote control clients (apps, tablets, pc’s etc.). The app and firmware is a simple Heating control demonstration which easily can be altered to your own need.

What you need:

  • Arduino MEGA2560 board
  • Wiznet W5100 Ethernet Shield version 1

Arduino MEGA:

(If you know all about Arduino, please scroll down to “About uNabto AppMyProduct” section)

The Arduino Mega 2560 is a microcontroller board based on the ATmega2560. It has 54 digital input/output pins (of which 14 can be used as PWM outputs), 16 analog inputs, 4 UARTs (hardware serial ports), a 16 MHz crystal oscillator, a USB connection, a power jack, an ICSP header, and a reset button. It contains everything needed to support the microcontroller; simply connect it to a computer with a USB cable or power it with an AC-to-DC adapter or battery to get started.

The Arduino Mega is the addition to the Arduino family. This board is physically larger than all the other Arduino boards and offers significantly more digital and analog pins. The MEGA uses a different processor allowing greater program size and more. The Mega2560 differs from all preceding boards in that it does not use the FTDI USB-to-serial driver chip. Instead, it features the ATmega16U2 programmed as a USB-to-serial converter. The Mega has four hardware serial ports, which means maximum speed if you need a second or third (or fourth) port.

ArduinoMega

Technical Specifications:

1. Microcontroller: ATmega1280 or 2560

2. Operating Voltage: 5V

3. Input Voltage(recommended): 7-12V

4. Input Voltage(limits): 6-20V

5. Digital I/O Pins: 54 (of which 14 provide PWM output)

6. Analog Input Pins: 16

7. DC Current per I/O Pin: 40 mA

8. DC Current for 3.3V Pin: 50 mA

9. Flash Memory: 128KB or 256KB

10. SRAM: 8 KB

11. EEPROM: 4 KB

12. Clock Speed: 16 MHz

Wiznet W5100 Ethernet Shield:

The Arduino Ethernet Shield connects your Arduino device to the internet. Just plug this module onto your Arduino board, connect it to your network with an RJ45 cable. As always with Arduino, every element of the platform – hardware, software and documentation – is freely available and open-source.

Specifications:

  •  Operating voltage 5V (supplied from the Arduino Board)
  •  Ethernet Controller: W5100 with internal 16K buffer
  •  Connection speed: 10/100Mb
  •  Connection with Arduino on SPI port

Description:

The Arduino Ethernet Shield allows an Arduino board to connect to the internet. It is based on the Wiznet W5100 Ethernet chip (datasheet). The Wiznet W5100 provides a network (IP) stack capable of both TCP and UDP.

The Ethernet Shield has a standard RJ-45 connection, with an integrated line transformer and Power over Ethernet enabled.

The shield also includes a reset controller, to ensure that the W5100 Ethernet module is properly reset on power-up. Previous revisions of the shield were not compatible with the Mega and need to be manually reset after power-up.
The current shield has a Power over Ethernet (PoE) module designed to extract power from a conventional twisted pair Category 5 Ethernet cable.

W5100-EthernetShield

Technical Specification:

  • IEEE802.3af compliant
  •  Low output ripple and noise (100mVpp)
  •  Input voltage range 36V to 57V
  •  Overload and short-circuit protection
  •  9V Output
  •  High efficiency DC/DC converter: type 75% @ 50% load
  •  1500V isolation (input to output)

Interfacing Arduino MEGA with Ethernet Shield:

Ethernet Shield Arduino board connects to a LAN or the Internet. Installation is very simple. Plug the Ethernet shield connectors in the expansion card connectors of Arduino and then connect the Ethernet cable to the RJ45 connector slot. In the image below you can see the Arduino Mega with an installed expansion board Ethernet Shield.

ArduinoMega-EthernetShield

About uNabto AppMyProduct:

AppMyProduct is an IoT application platform that helps you to
1. Quickly develop high-quality client side apps using SDKs and/or template apps
2. Customize the device side application using the provided demo application.
3. The uNabto framework and the client APIs can be downloaded using the below link.
https://www.nabto.com/downloads.html

uNabto Framework:

The drawing below gives a brief overview of how the Nabto platform actually work. The Device represents the Arduino Mega and the uNabto server (uNabto SDK and Device specific Platform adapters) is running on the device. As soon as device connects to the internet it identifies itself at the Nabto Basestation, using its unique ID which is already registered in AppMyProduct portal. If a Client wants to connect to the device, a connect request with the device ID is sent to the Basestation, and a direct connection to the device is established after verifying the identity of client. A client can be a native mobile app or an abstraction framework like our Heat Control Ionic starter app used in this demo

nabto-platform-basics

Get more information on the AppMyProduct platform and the Client/Device SDKs at appmyproduct.com.

The uNabto Platform Adapter:

The uNabto Platform Adapter is a small component that abstracts the Native Platforms network and time functionality. The Platform Adapter is part of the uNabto server.

The uNabto server is divided into two layers:

  •  The uNabto framework (uNabto SDK)
  • The uNabto Platform Adapter abstraction layer between the framework and the Native Platform

unabto-platform-adapter

The device specific uNabto server is readily available in AppMyProduct portal to port it to the Arduino module.

Implementing the Platform Adapter:

The Platform Adapter acts as link between the generic uNabto framework and the Arduino platform. The adapter is divided into single files, as suggested in the Nabto documentation (TEN023 Nabto device SDK guide, section 12):

  • unabto_config.h: Basic uNabto configuration
  •  unabto_platform_types.h: Define all necessary uNabto types
  •  unabto_platform.h: Platform specific ad-hoc functions
  •  time_adapter.cpp: Time functions
  •  random_adapter.cpp: Random generator functions
  •  dns_adapter.cpp: DNS resolver functions
  •  network_adapter.cpp: Communication functions
  •  log.cpp: Logging

Heat Pump Demo:

The Heat Pump demo showcases how to use the Nabto request response model on the Atmel AVR platform. This demo uses the Arduino MEGA board and Wiznet W5100 Ethernet shield (Ethernet module version 2) to perform the actions.

Heat Pump Library – Arduino Mega:

Get the Nabto Arduino Mega2560 library from [https://github.com/nabtodaemon/heatcontrol-arduinomega#heatcontrol-arduinomega] and follow the below installation instructions.

  • Add the library to the Arduino IDE via

Sketch -> Include Library -> Add .ZIP Library

Browse to the folder containing the downloaded library file and add the unabto-arduinomega-sdk-2.1.1.zip (downloaded zip file)

  • Open the HeatPump.ino example via

File -> Examples -> Nabto-Mega2560 -> HeatPump

The sample sketch includes the Nabto class, which encapsulates the Nabto setup. For the sketch to work, the below settings are to be changed. The setting should specify the board’s MAC address (found on the Ethernet board) followed by the unique Device ID and pre-shared key of the device obtained from portal.appmyproduct.com

// Enter device id and pre-shared key from portal.appmyproduct.com
const char* DEVICE_ID = "abc.xyz.appmyproduct.com";
const char* PRE_SHARED_KEY = "4f2a03f29f509035c03bc229ae870849";

(i.e. Sign-up for an AppMyProduct account, Create a product, Create licenses, copy a license Id and License Key into the DEVICE_ID and PRE_SHARED_KEY in the code section mentioned above)

The loop function inside the sketch is used to call the tick() method of the Nabto class that triggers the framework to check for new UDP packets and send responses. The time between ticks should be around 10 milliseconds. This is achieved by a hard delay, but you can also use the time to do application related tasks. For example, the demo uses it to update the brightness of the LED and to simulate the room temperature in the demo application tick function.

Test your device:

After compiling and uploading your HeatPump sketch to the Arduino Mega, it establishes a connection to your Ethernet network and starts the uNabto server. In your serial monitor you should see the following printout:

ArduinoMega-log

Now, using the Heat Control Ionic starter app (also available on google play store) connect your device and verify that the inbuilt LED changes its brightness according to the target heat.

Read more about obtaining the the Heat Control app or how to compile, possible adjust, your own version here https://www.appmyproduct.com/tutorial.html

ArduinoMega-HeatPumpOverview

ArduinoMega-Heatpump

When the Heat Control Ionic app is started for the first time, you need to pair your client app with the device. Then on, the paired device will be automatically discovered if available online.

FAQ:

1. Why is the device not able to communicate with Basestation?

Check the firewall settings on your network.

Ensure your data packets are been transmitted to Basestation and not blocked by your firewall, it must allow outgoing UDP traffic.

2. Device is online, why it is not discovered by my client app?

Ensure the device and the client are connected on the same network.

Search for your device, once discovered pair your client app with the device for the first time use.

Later, the paired device will be listed when the app is started.

3. Device can be accessed locally (on same network), why it cannot be accessed from outside network?

Your device might not be attached to the Basestation. Check the device application logs to locate the below message:

“State change from WAIT_GSP to ATTACHED”

If found, then should be able to connect from outside network. Note, your client must be paired with the device before accessing it.