UNIT 3

API DEVELOPMENT AND EMBEDDED PROGRAMMING

TOPIC 1 : GETTING STARTED WITH API
TOPIC 2 : WRITING A NEW API
TOPIC 3 : REAL TIME REACTIONS
TOPIC 4 : OTHER PROTOCOLS
TOPIC 5 : TECHNIQUES FOR EMBEDDED CODE : MEMORY MANAGEMENT
TOPIC 6 : PERFORMANCE AND BATTERY LIFE
TOPIC 7 : LIBRARIES
TOPIC 8 : DEBUGGING
TOPIC 9 : DEVELOPING IOT AND IOT DESIGN METHODOLOGY
TOPIC 10 : CASE STUDY ON IOT SYSTEM FOR WEATHER MONITORING

TOPIC 1 : GETTING STARTED WITH API

API is an Application Programming Interface that is a collection of communication protocols
used by various programs to communicate between them. A programmer can make use of various API
tools to make their program easier and simpler. Also, an API facilitates programmers with an efficient
way to develop their software programs.
So an API helps two programs or applications to communicate with each other by providing them
with the necessary tools and functions. It takes the request from the user and sends it to the service
provider and then again sends the result generated from the service provider to the desired user.
A developer uses APIs in his software to implement various features by using an API call without
writing complex codes. We can create an API for an operating system , database system , hardware
system, JavaScript file , or similar object-oriented files. Also, an API is similar to a GUI(Graphical User
Interface) with one major difference. Application program interface helps software developers to access
web tools while a GUI helps to make a program easier to understand for users.

WORKING OF AN API :
Think of a client-server architecture where the client sends the request via a medium to the server
and receives the response through the same medium. An API acts as a communication medium between
two programs or systems for functioning. The client is the user/customer (who sends the request), the
medium is the API , and the server is the backend (where the request is accepted and a response is
provided).
Steps followed in the working of APIs are :
1.​ The client initiates the requests via the APIs URI (Uniform Resource Identifier).
2.​ The API makes a call to the server after receiving the request.
3.​ Then the server sends the response back to the API with the information.
4.​ Finally, the API transfers the data to the client

TYPES OF APIs :
1. WEB APIs : A Web API also called Web Services is an extensively used API over the web and can be
easily accessed using the HTTP protocols. A Web application programming interface is an open-source
interface and can be used by a large number of clients through their phones, tablets, or PCs.
2. LOCAL APIs : In this type of API, the programmers get the local middleware services. TAPI
(Telephony Application Programming Interface), and .NET are common examples of Local APIs.
3. PROGRAM APIs : It makes a remote program appear to be local by making use of RPCs (Remote
Procedure Calls). SOAP is a well-known example of this type of API.
MASHING UP APIS: An API mashup is a technique that combines data and functionality from multiple
APIs into a single, unified service. It acts as a central hub, to different APIs and aggregating their
responses into a user-friendly format. The idea of “mashing up” multiple APIs to get a result has taken off
and can be used to powerful effect.
Example: Using a mapping API to plot properties to rent or buy- for example, Google Maps to visualise
properties to rent via Craigslist, or Foxtons in London showing its properties using Mapumental.
Its uses are :
1.​ Enhanced functionality: Mashups allow you to create new services that’s not possible with a
single API. Imagine combining weather data with a mapping API to recommend the perfect
outdoor activity based on your location and current conditions.
2.​ Improved user experience: By presenting data from different sources in a single interface,
mashups simplify the user experience and eliminate the need to switch between multiple
applications.
3.​ Reduced development time: Instead of building everything from scratch, developers can leverage
existing APIs and focus on the unique logic of their mashup.

TOPIC 2 : WRITING A NEW API

A brief overview of creating and implementing a simple API is given below :

Step 1: Design your API:

1.​ Understand the API’s use case: Define what your API will do and identify the resources it will
handle.
2.​ Sketch out the structure: Create a diagram showing how resources relate to each other and decide
on the data formats.

Step 2: Implement the API:

1.​ Framework: Use a simple framework like Ruby on Rails, especially when building REST APIs.
2.​ Language: Select a language you’re comfortable with (e.g., Python, Node.js).
3.​ Create models and migrations: Define your data models and create database tables.
4.​ Define routes: Set up routes to map URLs to controller actions.
5.​ Build controllers: Implement logic to handle requests and interact with your models.

Step 3: Test the API:

1.​ Run tests: Use tools like Postman to test your API endpoints.
2.​ Check functionality: Ensure that CRUD operations (Create, Read, Update, Delete) work as
expected.

Step 4: Deploy and maintain:

1.​ Monitor and update: Constantly monitor the performance of your API and make necessary
updates to ensure it continues to meet user needs.

IMPLEMENTING THE API: An API defines the messages that are sent from client to server and from
server to client. The most common standards are :
1.​ Representational State Transfer (REST): REST API is popular and simple to interact with for a
limited microcontroller. For example, some of the HTTP methods aren’t well supported by every
client or, indeed, server. In particular, web browsers only support GET and POST, which can
complicate things when interacting with REST from a web page. In REST, you attach each
resource to a URL. If we want to GET a resource, POST it onto the server in the first place, PUT
an update to it, or DELETE it from the server. Access a set of web URLs like
http://timer.roomofthings.com/timers/ or http:://timer.roomofthings.com/timers/1234 using HTTP
 methods such as GET and POST, but also PUT and DELETE. The result is often XML or JSON
but can often depend on the HTTP content-type negotiation mechanisms.
2.​ JSON-RPC: Access a single web URL like http://timer.roomofthings.com/api/, passing a JSON
string such as {‘method’:’update’, ‘params’: [{‘timer-id’:1234, ‘description’:’Writing API
chapter for book’}], ‘id’:12}. The return value would also be in JSON, like {‘result’:’OK’,
‘error’:null, ‘id’:12}.
3.​ XML-RPC: This standard is just like JSON-RPC but uses XML instead of JSON.
4.​ Simple Object Access Protocol (SOAP): This standard uses XML for transport like XML-RPC
but provides additional layers of functionality, which may be useful for very complicated systems.
5.​ cURL: Client for URLs(or cURL) is a software project comprising two development
efforts-cURL and libcurl. Libcurl is a free, client -side URL transfer library with support for a
wide range of protocols. cURL is a command-line tool for getting or sending files using URL
syntax.

TOPIC 3 : REAL TIME REACTIONS :

A traditional sort of API, where you make an HTTP request to the server and receive a response.
To establish an HTTP request requires several round-trips to the server. There is the TCP “three-step
handshake” consisting of a SYN (synchronise) request from the client, a SYN-ACK from the server to
“acknowledge” the request, and finally an ACK from the client.
To perform an action the instant that something happens on your board, you may have to factor in
the connection time. If the server has to perform an action immediately, that “immediately” could be
nearly a minute later, depending on the connection time. Two options here: polling and “Comet”
technologies.

POLLING: The traditional way of handling this situation using HTTP API requests was to make
requests at regular intervals. This is called polling. Make a call every minute to check whether new data
is available for you.
1.​ The WhereDial should start to turn to “Work” the moment that the user has checked into his
office.
2.​ The moment that the task timer starts, the client on the user’s computer should respond, offering
the opportunity to type a description of the task.
You could make this quicker, polling every 10 seconds, But this would put load on the following:
The server: If the device takes off, and there are thousands of devices, each of them polling regularly, you
will have to scale up to that load.
The client: This is especially important if, as per the earlier Arduino example, the microcontroller blocks
during each connection.

COMET: Comet is an umbrella name for a set of technologies developed to get around the inefficiencies
of polling.
Long Polling (Unidirectional): The first important development was “long polling”, which starts with the
client making a polling request as usual. Even if that answer is “nothing to report”, the long poll waits
until there is something to say. Long polling would be ideal for the case of WhereDial: the dial requests to
know when the next change of a user’s location will be. As soon as WhereDial receives the request, it
moves the dial and issues a new long poll request. Of course, if the connection drops, the client can also
make a new request.
Multipart XMLHttpRequest (MXHR) (Unidirectional): When building web applications, it is common to
use a JavaScript API called XML. HttpRequest to communicate with the web server without requiring a
full new page load. From the web server’s view, these requests are no different from any other HTTP
request. It is perfectly possible to simply long poll and create a new request on breaking the old one, but
this means that you might miss a message while you’re establishing the connection.
HTML5 WebSockets (Bidirectional): The HTTP protocol used in web services sits atop the TCP protocol.
Traditionally, the API used to talk directly to the TCP layer is known as the sockets API. When the web
community was looking to provide similar capabilities at the HTTP layer, they called the solution
WebSockets.

TOPIC 4 : OTHER PROTOCOLS

MQ TELEMETRY TRANSPORT : MQTT is a lightweight messaging protocol, designed specifically for
scenarios where network bandwidth is limited is desired.The client/server model of HTTP, MQTT uses a
publish/subscribe mechanism for exchanging messages via a message broker. Rather than send messages
to a predefined set of recipients, senders publish messages to a specific topic on the message broker.
Recipients subscribe to whichever topics interest them, and whenever a new message is published on that
topic, the message broker delivers it to all interested recipients. It was developed initially by IBM but has
since been published both open and closed source, and are available, together with libraries for many
different languages. This makes it much easier to do one-to-many messaging, and also breaks the tight
coupling between the client and server that exists in HTTP.
EXTENSIBLE MESSAGING AND PRESENCE PROTOCOL : Extensible Messaging and Presence
Protocol, or XMPP. XMPP grew from the Jabber instant messaging system and so has broad support as a
general protocol on the Internet. Because it wasn’t designed explicitly for use in embedded applications, it
uses XML to format the messages.
CONSTRAINED APPLICATION PROTOCOL : CoAP draws many of its design features from HTTP
and has a defined mechanism to proxies to allow mapping from one protocol to the other.

TOPIC 5 : TECHNIQUES FOR EMBEDDED CODE : MEMORY

MANAGEMENT
TYPES OF MEMORY :
1. ROM : Read-only memory refers to memory where the information stored in the chips is hard-coded at
the chips’ creation and can only be read afterwards.
Flash : Flash is a semi-permanent type of memory which provides all the advantages of ROM - namely,
that it can store information without requiring any power. It stores the information that you want to hold
on to, such as the program executable itself or important data that has been gathered.

RAM : Random-access memory requires power to retain its contents, but the speed of update is
comparable with the time taken to read from it. The working memory for the system is the place where
things are stored while being processed. For certain processor architectures , the data (RAM) and program
(flash/ROM) memory spaces are separated, which means that they aren’t interchangeable. As a result, you
may have to do a little additional work to copy the data from flash into RAM when you want to use it.
The Arduino platform provides an additional macro to let you specify that certain strings should be stored
in flash memory rather than RAM.

MAKING THE MOST OF YOUR RAM :

Yet you may want to use as much of the memory as possible to provide more features. This
consideration is important, and it’s easier to make the best trade-off between maximising RAM usage and
reliability if your memory usage is deterministic. The way to achieve this result is to not allocate any
memory dynamically, that is, while the program is running.
Rather than allocate space for the entire page, you set aside space to store the important
information that you’re going to extract and also a buffer of memory that you can use as a working area
while you download and process the page. Rather than download the entire page into memory at once,
you download it in chunks—filling the buffer each time and then working through that chunk of data
before moving on to the next one.
Example: The count of new tweets can discard a lot of the data as it goes. All it needs to track is whether
or not each tweet is newer and the timestamp for the newest tweet it has seen.

TOPIC 6 : PERFORMANCE AND BATTERY LIFE

For items which run from a battery or which are powered by a solar cell, and those which need to
react instantaneously when the user pushes a button, it makes sense to pay some attention to performance
or power consumption. A lot of the biggest power-consumption gains come from the hardware design.
One of the easiest ways to make your code more efficient is to move to an event-driven model
rather than polling for changes. The reason for this is to allow your device to sit in a low power state for
longer and leap into action when required, instead of having to regularly do busywork to check whether
things have changed and it has real work to do.
This optimization works only if the API that you’re connecting to offers that sort of feature. For
many operations, restricting things is not an option. If it would make sense to restrict the data, but the
existing API doesn’t provide that possibility, you always have the option of writing a service of your own
between the device and the proper API (known as a shim service). The shim service has all the processing
power and storage available to a web server and so can do most of the heavy lifting. After this, it just
sends the minimum amount of data across to be processed in your embedded system.

TOPIC 7 : LIBRARIES
1.​ LwIP: lwIP, or LightWeight IP, is a full TCP/IP stack which runs in low-resource conditions. It
requires only tens of kilobytes of RAM and around 40KB of ROM/flash. The official Arduino
WiFi shield uses a version of this library.
2.​ uIP: uIP, or micro IP, is a TCP/IP stack targeted at the smallest possible systems. It can even run
on systems with only a couple of kilobytes of RAM. Arduino systems which don’t use the
standard Ethernet shield and library, use the Ethercard port for AVR.
3.​ uClibc: uClibc (http://www.uclibc.org/) is a version of the standard GNU C library (glibc) for
embedded Linux systems. Changing code to use it normally just involves recompiling the source
code.
4.​ Atomthreads: Atomthreads (http://atomthreads.com/) is a lightweight real-time scheduler for
embedded systems. You can use it when your code gets complicated enough that you need to
have more than one thing happening at the same time. The scheduler switches between the tasks
quickly enough that it looks that way, just like the multitasking on your PC.
5.​ BusyBox: BusyBox (http://www. busybox.net/) is a collection of a host of useful UNIX utilities
into a single, small executable and a common and useful package to provide a simple shell
environment and commands on your system.

TOPIC 8 : DEBUGGING
One of the most frustrating parts of writing software is knowing your code has a bug, but we can’t
understand where the bug is. Modern desktop integrated development environments (IDEs) have excellent
support for digging into programs, while your code is running. You can set breakpoints which stop
execution when a predefined set of conditions is met, at which point you can check memory to see what it
contains, evaluate expressions to see whether they are correct, and then step through the code line by line
to watch what happens. You can even modify the contents of memory or variables for the rest of the code
execution and in the more advanced systems we can rewrite the code while the program is stopped. The
debugging environment for embedded systems is usually more basic. If your embedded platform is
running on a fully featured operating system such as Linux, you are better placed than if you’re
developing on a tiny microcontroller.
Emulation is a good approach if the software is complex because that’s the scenario in which you
need the most development and debugging time. The target hardware from a desktop PC , particularly
when it has specialised sensors or actuators, the harder it is to write software subsystems for the emulator.
You should be aware of hidden complexities, but in many cases you won’t encounter them. The first , is
obviously the amount of space needed for any logging information: all the strings and code to do the
logging have to fit into the embedded system along with your code. The second , typically a small buffer
is used to store the outgoing data while it is being transmitted.

TOPIC 9 : DEVELOPING IOT AND IOT DESIGN METHODOLOGY

​ Designing IoT systems can be a complex and challenging task as they involve interactions between various
components. A wide range of choices are available for each component. We will look at a generic design
methodology which is independent of specific product, service or programming language. IoT systems designed
with this methodology will have reduced design time, testing time, maintenance time, complexity and better
interoperability. The steps involved in the designing of an IoT system or applications is shown below :

1.​ PURPOSE AND REQUIREMENTS SPECIFICATION : In this step, the system purpose, behavior and
requirements are captured. Requirements can be: Data collection requirements, Data analysis requirements,
System management requirements, Security requirements, User interface requirements.
A. Purpose : A home automation system that allows controlling the lights remotely using a web application
B. Behavior : Home automation system should support two modes: auto and manual
Auto: System measures the light level in the room and switches on the light when it is dark
Manual: Allows remotely switching lights on and off
C. System Management : System should provide remote monitoring and control functions
D. Data Analysis : System should perform local analysis of the data
E. Application Deployment : Application should be deployed locally, but should be accessible remotely
F. Security : Should provide basic security like user authentication

2.​ PROCESS SPECIFICATION : The use cases of the IoT system are formally described based on or
derived from the purpose and requirements specifications. The process specification for home automation
system is as shown below.

​ ​

3.​ DOMAIN MODEL SPECIFICATION : The domain model describes the entities and objects in the
domain of the IoT system to be designed. Using domain model, system designers can get an understanding
of the IoT domain for which the system is to be designed. It defines the attributes of the objects and
relationships between objects. The domain model is independent of any specific technology or platform.
The entities, objects and concepts defined in the domain model of home automation system
include the following:
1.​ Physical Entity : The physical identifiable objects in the environment. IoT system provides
information about the physical entity (using sensors) or performs actuation upon the physical
entity.
 2.​ Virtual Entity : Virtual entity is a representation of the physical entity in the digital world. For
every physical entity there is a virtual entity.
3.​ Device : Devices provide a medium for interaction between physical and virtual entities. Devices
are used to gather information from or perform actuation on physical entities.
4.​ Resource : Resources are software components which can be either on-device or
network-resources. On-device resources are hosted on the device and provide sensing or actuation
(eg: operating system). Network-resources include software components that are available on the
network (eg: database).
5.​ Service : Services provide an interface for interacting with the physical entity. Services access
resources to perform operations on physical entities

The domain model specification diagram for home automation system is shown below:

4.​ INFORMATION MODEL SPECIFICATION : Information model defines the structure of all the
information in the IoT system. Does not describe how the information is stored and represented. To define
the information model, we first list the virtual entities. Later details like attributes and relationships are
added. The information model specification for home automation system is as shown below:
 5.​ SERVICE SPECIFICATION : The service specification defines the following:
●​ Services in the system
●​ Service types
●​ Service inputs/output
●​ Service endpoints
●​ Service schedules
●​ Service preconditions
●​ Service effects
For each state and attribute in the process specification and information model, we define a service. Services either
change the state of attributes or retrieve their current values. The service specification for each state in home
automation systems are as shown below:

6.​ IOT LEVEL SPECIFICATION : Based on the requirements we will choose the IoT application
deployment level. The deployment level for home automation system is shown in the below figure.
 7.​ FUNCTIONAL VIEW SPECIFICATION : The functional view defines the functions of the IoT systems
grouped into various functional groups. Each functional group provides functionalities for interacting with
concepts in the domain model and information related to the concepts. The functional groups in a
functional view include: Device, Communication, Services, Management, Security, and Application.
The functional view specification for home automation system is shown in the below figure:
Device : It is for monitoring and control. In Home automation, the device contains a single board mini
computer, a light weight sensor and mini switch.
Communication : The communication FG handles the communication for the IOT system. It includes the
communication protocols that are the backbone of IOT systems and helps in connectivity. It also includes
the communication APIs like REST that are used in exchanging data over the network.
Services : It includes various service such as services for device monitoring, device control services , data
publishing services and device discovery.
Management : It includes all functionalities that are needed to manage and configure the IOT systems.
Security : It Includes security mechanisms like authentication , authorization and data security etc.

8.​ OPERATIONAL VIEW SPECIFICATION : IoT system deployment and operation are defined, such as
service hosting options, storage options, device options, application hosting options, etc.
Devices:The computing device (Raspberry Pi), light-dependent resistor (sensor), relay switch (actuator).
Communication APIS: REST APIs
Services: Controller Service - Hosted on the device, implemented in Python, and run as a native service.
Mode service - REST-ful web service, hosted on a device, implemented with Django-REST Framework.
State service - REST-ful web service, hosted on a device, implemented with Django-REST Framework.
Application:Web Application - Django Web Application, Application Server - Django App Server,
Database Server - MySQL.

9.​ DEVICE AND COMPONENT INTEGRATION : The devices like sensors, computing devices and
other components are integrated together. Devices like minicomputer, LDR sensor, and relay switch
actuator.

10.​ APPLICATION DEVELOPMENT : Using all the information from previous steps, we will develop the
application (code) for the IoT system. The final step in the IoT design methodology.
It is to develop the IoT application. The application has controls for the mode (auto-on or auto-off) and the
light (on or off).

TOPIC 10 : CASE STUDY ON IOT SYSTEM FOR WEATHER MONITORING

Describe your use case:
1.​ The system proposed is an advanced solution for monitoring the weather conditions at a particular place
and make the information visible anywhere in the world.
2.​ The technology behind this is Internet of Things (IoT), which is an advanced and efficient solution for
connecting the things to the internet and to connect the entire world of things in a network.
 3.​ The system deals with monitoring and controlling the environmental conditions like temperature, relative
humidity, light intensity and CO level with sensors and sends the information to the web page and then
plots the sensor data as graphical statistics.
4.​ The data updated from the implemented system can be accessible in the internet from anywhere in the
world

Below diagram shows the process specification for weather monitoring system. It shows that the sensors are read
after fixed intervals and the sensor measurements are stored.

Understanding Environment Parameters and Changes Parameters like Rainfalls, Temperature, Cyclones,
Humidity, Pollution.
Concerns: Rising Temperatures and Global Warming, Rising Pollution Levels , Sudden Changes in Seasons Cycle ,
Vegetation Covers and Man Made Activities , The need to deliver accurate data to people.
Data Will be Used by: Governments, NGOs, People

USE CASE FEATURES : Embedded device is for monitoring Temperature,Humidity, Pressure,light

intensity,sound intensity levels and CO levels in theAtmosphere to make the environment intelligent or interactive
with the objects through wireless communication.

Architecture is discussed in a 4-tier model with the functions of each individual module developed for noise
and air pollution monitoring.

1. TIER 1 : Tier 1 is the environment, Tier 1 provides information about the parameters under the region which is to
be monitored for noise and air pollution control.
2. TIER 2: Sensor devices in tier 2, sensor data acquisition, Tier 2 deals with the sensor devices with suitable
characteristics, features and each of these sensor devices are operated and controlled based on their sensitivity as
well as the range of sensing. In between tier 2 and tier 3 necessary sensing and controlling actions will be taken
depending upon the conditions, like fixing the threshold value, periodicity of sensing, messages (alarm or buzzer or
LED) etc. Based on the data analysis performed in between tier 2 and tier 3 and also from previous experiences ,
normal working conditions are determined. 3. TIER 3 : Decision making in tier 3. Tier 3 describes the data
acquisition from sensor devices and also includes the decision making. Which specify the condition the data is
representing which parameter.
4. TIER 4 : Tier 4 deals with the intelligent environment. Which means it will identify the variations in the sensor
data and fix the threshold value depending on the identified level of CO or noise levels. In this tier sensed data will
be processed, stored in the cloud i.e.in to the Google spread sheets and also it will show a trend of the sensed
parameters with respect to the specified values. The end users can browse data using mobile phones, PCs