Saravana Pandian Annamalai
27. August 2015 · Write a comment · Categories: ARM, Embedded Software, Technology · Tags: ,

Continuing our series on interrupts, this blog will capture the ARM interrupt architecture along with the evolution of the same from the early ARMv4 to the latest ARMv8 models. A fair outline of overall flow, including the exception/ registers model, is given to aid the reader understand the principles behind the ARM interrupt architecture design.

ARM Instruction Set

ARM architecture has continuously evolved since its introduction. Beginning with ARMv4, architecture evolution is labeled with incremental values like ARMv5, ARMv6 till the latest ARMv8. There are additions and extensions that are labeled with a suffix like ARMv5TE or ARMv6K.

As with any RISC core, ARM supports very few instructions and is capable of executing them fast at a rate of 1 instruction per clock using techniques such as pipelining, branch prediction, caching etc.

Many RISC architectures define a set of instructions and encoding that will be executed by the processor. But ARM Architecture is an advanced design that supports different instruction sets that can be changed dynamically. Each of these instruction execution modes offer unique advantage like higher code density, support for Java execution etc. Few of the instruction sets supported are

ARM: The default mode that operates with fixed width (32-bit) instructions. Automatically changed to this mode when an interrupt/exception occurs.

Thumb: It is a 16-bit instruction set that can be used for higher code density. It is has limited set of instructions and registers compared to ARM mode, but can be advantageous if limited register manipulations are done.

Thumb2: Introduced in ARMv6T2, this brings the best of both worlds, by supporting mixed 16 bit and 32 bit instructions able to achieve very higher code density and performance. This has become popular that modern OS like Windows Embedded Compact has made this the default execution mode. Even Linux kernel supports compilation to Thumb2 mode.

Jazelle: Optimized for Java code execution.

SIMD: Single Instruction Multiple Data instruction set for better data manipulation.

There are other sets like VFP, Security extension etc that are not explained in this blog. It is interesting to note that these instructions sets can be interchangeably used as switching from one to another is as simple as setting one or more bits is a register, that can be accomplished by a single instruction.

With ARMv8, two higher level Execution States are introduced – AArch32 and AArch64. While the AArch32 is mostly similar to the instructions sets in the earlier architectures, AArch64 supports a single 64 bit instructions set and registers. It is possible to transition between these during exceptions by a process called Interprocessing.

ARM Processor Modes and Exception Levels

While the instruction sets define the type of instructions supported, ARM core supports multiple modes that defines how the access privilege, current exception taken etc. The processor modes supported are

Mode Description
User Mode with minimal access privilege. It is not possible to change to other modes from this mode. In an OS, generally the applications are executed in this mode
FIQ Entered up on an Fast Interrupt being received
IRQ Entered up on an Interrupt being received
Supervisor Same set of register visibility as in User mode but with higher privileges
Monitor Part of security extension that can be used during transition from a Secure Mode to Non-secure mode.
Abort Entered when there is an error accessing data memory(Data Abort) or instruction area (Prefetch abort)
Undefined Entered when a wrong instructions is executed
System Mode that has full privileges that can be used to configure the system. Usually the kernel operates in this mode in an OS.

Of these modes, except User mode, all others are said to be privileged modes. Usually the transition between these modes is done primarily with exceptions and in limited case, with instructions.

AArch64, introduces four Exception levels, represented by ELn, that is used to determine the level of privilege. EL0 is the least privileged while EL3 is the most. The recommended usage model for the same are:

ARMv8 Exception Model

Recommended usage of ARMv8 Exception Levels

It is key to remember that the AArch32 mode processor states are still usable when executing in that.

ARM Register Model

It is generally known that there are 16 general purpose registers (R0 through R12, R13 (Stack Pointer), LR (Link Register) and PC) and two Program Status Registers (CPSR and SPSR). But few of these registers are actually banked and different registers are available for different processor modes. The register bank in AArch32 state as given in ARMv8 TRM is given below:

Registers in ARM

Arm Register Banking

Based on the current processor mode, the registers are visible to software access. i.e. if the processor is in Supervisor mode, reading R13 will return SP_svc where as access to R13 will return SP_irq in IRQ mode. For FIQ mode, lot more registers are banked enabling fewer stack push/pops for faster interrupt processing. Also, since the FIQ vector is at the end of the vector table, the handler (ISR) can be directly placed at the FIQ vector address rather than having a branch to ISR instruction as in case of other exceptions.

In AArch64 mode, there are 31 64-bit general purpose registers labeled XL0 to XL30. XL30 is generally used as Procedure Link Register. None of these are banked. But there are few registers that are banked for each Execution level – Stack Pointer (SP), the Exception Link Register (ELR) and the Saved Process State Register (SPSR). To enable access of AArch32 registers from AArch64 state, the AArch32 registers are mapped to lease significant 32-bits of the AArch64 registers. The mapping of the same as given by ARM is as follows

  X0-X7 X8-X15 X16-X23 X24-X30
0 R0 R8_usr R14_irq R8_fiq
1 R1 R9_usr R13_irq R9_fiq
2 R2 R10_usr R14_svc R10_fiq
3 R3 R11_usr R13_svc R11_fiq
4 R4 R12_usr R14_abt R12_fiq
5 R5 R13_usr R13_abt R13_fiq
6 R6 R14_usr R14_und R14_fiq
7 R7 R13_hyp R13_und No Register

ARM Exceptions Model

In ARM architecture, anything that affects sequential flow of instructions is called an exception. For example, it could be an occurrence of an interrupt, access of wrong memory or even power-cycling the system. These exceptions are clearly defined along with the specific steps taken on an exception – typically involving change in processor mode and jumping to a vector address. Some of the defined exceptions are

Exception Description Entered Mode Vector Offset
Reset Entered on power on reset Supervisor mode 0x00
Undefined Instruction Invalid/Unimplemented instruction Undefined 0x04
Supervisor Call Usually by SWI/SVC instruction. Used for system call implementation Supervisor 0x08
Secure Monitor Call Usually by SMC/SMI instruction. Monitor 0x08
Prefetch Abort Invalid instruction memory access Abort 0x0C
Data Abort Invalid Data memory access Abort 0x10
IRQ Interrupt request to the core IRQ 0x18
FIQ FIQ request to core FIQ 0x1C

When any of these exceptions occurs in an ARM core, following set of sequences happens:

  • CPSR is copied to the SPSR of the mode being entered.
  • Processor mode is set to the new state
  • Whatever the existing instruction set being executed, it is changed to ARM state
  • Return address (of mode being left) is stored to the link register of the mode being entered
  • PC is set to the vector address corresponding to the entered exception

Now that the processor is in the new exception mode, the corresponding registers are banked. The software can choose to handle the exception as desired. Care should be taken that no registers are corrupted or lost, due to multiple or nested exceptions. Registers can be backed up in the stack.

To return back to the interrupted code, following operations can be done:

  • Restore the registers back to the original values (by popping from stack)
  • The above process can be done using a single instruction LDMFD^ if possible.

For AArch64, numerous exception classes are defined that are source of the exceptions like WFI, Illegal execution state, Misaligned PC Exception etc. The cause of exception can be obtained from the Exception Syndrome Register (ESR). The major happenings on an exception entry, as given by ARMv8 TRM,

  • The PE state is saved in the SPSR_ELx at the Exception level the exception is taken to.
  • The preferred return address is saved in the ELR_ELx at the Exception level the exception is taken to.
  • Execution moves to the target Exception level, and starts at the address defined by the exception vector.
  • The stack pointer register selected is the dedicated stack pointer register for the target Exception level.

To return from exception, an ERET instruction can be used. On executing the same:

  • PC is restored with the value held in the ELR_EL of level returning from.
  • PSTATE is restored by using the contents of the SPSR_EL of level returning from.

It is possible to switch from AArch64 to AArch32 states using exceptions.

Thus ARM Architecture is evolving fast to accommodate the growing requirements in computing. Now with basic idea about, the instruction set, register sets and exception model in ARM architecture, we will see about the Interrupt Architecture in specific in the upcoming blog.

 

Saravana Pandian Annamalai
21. July 2014 · Write a comment · Categories: Internet of Things, Technology · Tags: , , ,

Further to our discussion on Internet of Things, we will have a look in to one of the most promising standards proposed for IoT – LWM2M from OMA.

This post will provide a quick overview of the standards followed by a discussion on the opportunities it presents and challenges faced primarily in the object model more than the underlying communication protocols.

Light Weight M2M – LWM2M for IoT

Internet of Things presents challenges so far not seen in usual environment with known or well predicted communication and computing requirements. IoT brings in necessity to support few thousand types of devices with billions of actual devices. Further it needs even computationally less powered systems with limited network connectivity to be managed.

For these challenges, OMA (Open Mobile Alliance) a consortium of industry leaders proposed a new standard – LWM2M – Light Weight Machine-to-Machine. It is a Client-Server model and in the words used in the technical paper.

The LWM2M protocol, to be used for remote management of M2M devices and related service enablement, has at least four outstanding characteristics:

1) it features a modern architectural design based on REST appealing to software developers,

2) it defines a resource and data model that is extensible,

3) it has been designed with performance and the constraints of M2M devices in mind, and

4) it reuses and builds on an efficient secure data transfer standard called the Constrained Application Protocol (CoAP) that has been standardised by the Internet Engineering Taskforce (IETF) as a variation of the Internet’s HTTP protocol (appropriate for data transfer to and from low-cost connected IoT devices).

These words truly describe everything about LWM2M. LWM2M for IoT offers simple REST services for data logging and retrieval. It defines an Object/Instance/Resource model for data management and uses CoAP (a low-bandwidth protocol) for communication. The architecture diagram is given below.

Currently data transfer over UDP and SMS are defined with security using DTLS. There are numerous documentations and links available to describe the communication aspects of the standard and is not the scope for this discussion. Rather we will describe the data management layer.

LWM2M Object Model

LWM2M considers every device being connected to it having a set of parameters each mapped to an aspect of its functionality. Some may be Read-write that needs configuration and control and some may only be Read/Only used for observing status information.

An example might be a simple dimmer that controls the brightness of the light. The dimmer may have a variable to switch it on or off and another to set the brightness level.

LWM2M assigns a unique resource ID for each of these parameters and groups them in to something called an Object identified by a unique Object ID. For each actual device present, an instance ID is allocated which contains the actual resource values. The instance ID management is done by the LWM2M Client and typically starts from 0. There may be any number of instances based on the actual number of devices.

The example object description of a Light Control Object (object ID = 3311) will look like as follows

S.No

Resource ID

Description

Type

Access

 1 5851 Dimmer Integer 0 -100 R,W
 2 5850 On/Off Boolean R,W

Considering a LWM2M Client connected to 3 Light Control objects, the client will present itself like this:

LWM2M Device Instances

LWM2M Object Instances for Dimmers

The object model and resource ID definitions may be complex depending on the complexity of the device it represents.

In terms of object/instance/resource philosophy, it resembles the CIP standard from ODVA that is employed in DeviceNet & Ethernet/IP and other protocols being used in industrial automation.

LWM2M Model – Opportunities

Now about the opportunities it presents to the IoT segment, the salient points are.

New Standard

Since being a new standard being drafted in very recent time, LWM2M is designed with IoT and M2M requirements in consideration. Backed by the expertise of OMA, it should be very easy for the LWM2M to map and accommodate the changing needs of the industry. It should be possible to create object models for the new devices being supported under IoT.

Simplicity

The underlying communication technology and data model is very simple and robust unlike the OMA-DM. The devices implementing this technology could even be an 8-bit system with very few kilobytes of ROM and few bytes of RAM. Further the legacy systems could be easily accommodated using simple LWM2M gateways.

Acceptability

With IoT industry beginning to take shape and leaders in industry like ARM, Vodafone, etc backing it, it should be very easy for the industry to accept LWM2M for IoT. With a little aggressive push, the LwM2M can find far more deployments. With reference implementations available for C and Java, developer community need not sweat it out to bring a new LWM2M device.

LWM2M Model – Challenges

Some of the opportunities we believe LWM2M have to look out in terms of its object model are as follows.

Limited defined Objects

The virtue of being a new standards is a vice here. Very few objects are currently defined. At the time of this writing, only around 18 Object IDs and 42 resource IDs are defined excluding the basic ones. A far more definitions will help in faster adoption of the standard.

On the positive side, OMA provides users an interface to request for new object definitions, which should quickly bring many devices under this standard.

Dynamic IoT Instances

Probably true to its name, LWM2M might be designed with a higher preference on M2M devices. The main difference between an industrial and say a consumer ecosystem is the relative stability and identification of devices. In an industrial setup, when a device is set up and assigned an instance, it is highly unlikely to change over time. While it might be online or off-line, the instance ID can safely assumed to be same. Whereas in a typical consumer environment, the whole system constituent may change completely. Further it is very dynamic that the order of adding a device and removing them will be chaotic. An example could be a set of Bluetooth devices deployed spread across a large area and a mobile phone acting as a LWM2M Client. With LWM2M server in the cloud, the instance orders will drastically change depending up on the range of the Bluetooth coverage. With more smart-phone clients, things will be even more complex. The following diagram depicts the difference.

Instance ID mapping for M2M vs IoT

To overcome this, a UUID – Universally Unique ID resource ID might be assigned for each device. This should be a simple version 4 UUID based on Random numbers without dependency on any governing bodies. This will provide a totally unique reference at the server and reduces dependency and complexity on the gateways.

LWM2M Gateways

LWM2M Objects connected with gateways

Further it has an added advantage of consolidating the device view. For example, in the above diagram, multiple IoT devices are connected to the main LWM2M server via multiple gateways. Ultimately the last gateway will show the devices in completely different instance ID mapping. With a UUID being used, the LWM2M can correctly select the per-registered device for control. Also it can choose use that as an endpoint to control bypassing the instance ID’s.

Conclusion

LWM2M is going to be a major player in IoT and we expect a lot of deployments based on LWM2M soon. When UUID is available for individual device identification and more underlying physical communication layers defined, LWM2M is sure to be here for a very long time managing the ‘Internet of Things’.

Embien, with its rich expertise in IoT and allied segments, has launched its SkyCase – IoT solution for enabling IoT for devices across industry. Combing the best in class technologies – REST, LWM2M and Java, it offers a cloud system that enables LWM2M devices to be connected and controlled. Please visit our SkyCase product page more details of the same.

Internet of Things is the buzzword for the past couple of years. Without doubt technology companies across spectrum are vying for a slice in the IoT Pie. Acquisition of NEST by Google, ThingWorx by PTC, Pachube by Logmein are definite pointers towards the trend.

In this post we will see about IoT, architecture, applications etc and see how things are going to communicate more than human in their entire history.

What is Internet of Things?

Internet of Things is a concept where real world physical devices, each with a unique identifier, are connected to the Internet and decisions and actions are made based on the acquired data without any human interaction. The physical device could be anything like ambient light sensor in our home, a human heart rate monitor, a temperature controller in a refrigerator truck etc. The decision could be taken by a Cloud platform or by a gateway in our home or even by our mobile phone.

An IoT scenario can be as simple as our car, on detecting a crash, calling ambulance service automatically. Or it can be complex enough to manage complete inventory beginning with detection of reduced inventory, triggering an order based on financials, historical supply/demand parametric and other factors, monitoring the production, tracking the shipment, monitoring the quality, updating the inventory and so on.

IoT is a sort of extension of earlier technologies including data acquisition with sensors, internet and human intelligence. Earlier we had a data logger that collects all the data and pushes it to a central server. The user will view these parameters and take some decision based on that and controls the system.

But with IoT, the data analytics and decisions are taken by intelligent devices. Hence the human intervention is minimized or removed so that the Things manage themselves for bringing out a desired and optimal result.

Internet of Things Architecture

Basically IoT involves Sensors, Connectivity and Intelligence.

Internet of Things - An Overview

Internet of Things – An Overview

Connecting millions of devices on the internet is going to create a scenario that was not seen earlier. Technically IPv6 has enough unique addresses to identify devices that will be manufactured and connected to Internet for a long time from now.  The complexity arises from the way of handling the data from these devices, extract meaningful information from them and take decisions on the same.

The communication technology will be depending on various factors including its usage/applications, data rate, location and other requirements. For example it could be a low power ZigBee/BLE communication to a gateway and then to the Internet or directly to Internet using a GSM modem or WiFi/Broadband.

The architecture of IoT is evolving and most likely it is going to be based on events from the real time objects. The events are likely to be propagated to the control center and processed. The event could be interpreted in different ways depending on the current state of the object and action taken. Again it could originate from the command center and move towards the object.

It is expected that the architecture is expected to evolve and continue to evolve until a majority of the devices in the world are connected.

Internet of Things Standards

There are many standards currently being created for IoT, that soon the number of standards may become more than the number of devices. There are many organizations and consortium that are trying to define a common standard for these devices to communicate among them and for inter-operability. Some include the IoT-A by www.iot-a.eu, Global Standards Initiative on Internet of Things (IoT-GSI) by ITU, IEEE Standards Association, Open Mobile Alliance etc.

Since the applications for IoT are varied, each company is creating its own protocol for communication. But most are based on RESTful services, CoAP, JSON and other such technologies. Consolidation of these different standards towards a common one is no where in sight for the near future.

Internet of Things Applications

Internet of Things finds numerous applications. It will change the way we interact with the physical world and the devices around us. The devices will have understand us better and make our life easier. Many of the applications scenarios are available in Internet for reference.

Some prominent examples include:

  • IoT-A’s vision of IoT usage
  • Libelium take of IoT Applications

Internet of Things Opportunities

The IoT will create new business possibilities. Primarily it will be in the following segments.

Sensors: With requirement of more number of sensors, large scale production will lead to low cost devices.

Connectivity: Different connectivity options are expected to be employed for different scenarios. Along with new devices manufactured with connectivity, there will be huge opportunity for making existing devices connected using gateways, protocol converters and other technologies.

Cloud Services: Eventually the data generated by the devices are to be consumed by a central platform more likely to be a cloud based one. So cloud business models including SaaS and PaaS are expected to undergo radical changes.

Applications: The algorithms, that are going to understand the data and control the devices, are the most important part of the IoT universe. Hence they are going to be next mobile app store.

Conclusion

IoT are defiantly going to be the trend for a few years. We can expect some major changes in the way we live with these few years because of IoT.

Embien has launched its SkyCase solution for enabling IoT for devices across industry. As the first phase, it supports data collection and visualization using many widgets available. Soon the second phase of SkyCase will incorporate intelligence for manipulating data and controlling connected devices.