Skip navigation


1 2 3 Previous Next


677 posts

Payment card fraud

For every $100 in volume spent through payment cards, 5.65¢ was fraudulent in 2014 – and the numbers continue to climb. The attacks on payment systems that lead to card fraud amount to billions of dollars in losses annually. All of us are paying for it – both directly through personal loss and indirectly through added cost for payment transactions.

How can technology help protect us from these attacks and fraudulent use of our cards?

Let’s look at what the SLN-POS-RDR is designed to do and the meaning behind its nomenclature:

SLN = Solution
POS= Point of Sale
RDR = Reader

This is a class of products from NXP that brings together hardware, software and certifications, enabling you to implement devices that accept payment cards.

Picture the devices you use to pay in the check-out at the grocery store, coffee shop, clothing store or small food truck. Now that you have some idea of the type of device this solution supports, let’s focus on what a solution is.

There are a couple of common definitions for the word solution. A solution can be the means of solving a problem or dealing with a difficult situation. The word solution is also defined as a mixture in which the solute is distributed within the major component (the solvent). Both of these definitions can be applicable to the SLN-POS-RDR, the secure card reader solution that address the problems of developing a payment terminal with a high level of security integration.

Solving a problem

Solutions are built with an end goal in mind and to address specific problems. In the case of the secure card reader, the solution addresses the needs around the payment card interfaces. Beyond the software drivers and stacks that run on the microcontroller, there are hardware components for IC card readers (contact interface), and the NFC front ends (contactless interface). Bringing these pieces together and performing compliance testing leads to components that more completely address the specific challenges that a payment terminal manufacturer will face.


To show how the application problems are solved, the solutions being created by NXP are measured by certification and compliance testing where applicable. In this way, instead of simply showing the answer to the problem, the collateral built around the compliance testing provides the user of the card reader solution with the methodology that can be used to solve the problem.


A secure card reader is a complex device, having functions related to user interaction with display and a pin pad, the card reader interfaces and USB communications to a host. Bringing all of these functions together into one application means that interactions and dependencies for MCU resources have to be considered. The influence on the hardware and software components of the solution leads to a robustness and usability that benefits the user as they develop their end products.


A solution of security

A look inside the SLN-POS-RDR: Point-of-Sale Card Reader Solution

A look inside the SLN-POS-RDR: Point-of-Sale Card Reader Solution


Central to building a solution for payment systems is meeting the security requirements set in place to combat the staggering card fraud problem. For a secure card reader, there are two standards that are considered throughout the development and deployment of these devices. These standards are the Payment Card Industry Security Standards Council requirements for Pin Transaction Security (PCI PTS) and the EMVCo EMV Specifications.


In order to meet these standards, security has to be considered in all aspects of the card reader design. As an example, to achieve PCI PTS certification, the software development has to be shown to be secure and robust.  More about how processor features align to the security standards for payment systems will be covered in an upcoming ARM TechCon Session. For a payment application solution, security is distributed throughout the design creating a solution of security into the payment application.


There are many resources highlighting the MCU technology needed to meet security requirements. These are the trust, cryptography and anti-tamper capabilities for NXP MCUs. For the card reader solution, we get to see the technology in use. Some examples include the use of cryptography to secure the data transfers from payment cards to the card reader.  In addition to adhere to security requirements for card holder PIN information, the software functions that handle this data are protected by memory clear functions to ensure that sensitive data does not persist longer than necessary. The solution software also makes use of the system memory protection unit of the MCU, separating software functions with logical protection in order to protect highly secure data.


With regards to anti-tamper capabilities, there is an example built into the solution to demonstrate the capabilities of actively monitoring a tamper mesh. This example makes use of NXP’s Kinetis Software Development Kit in order to initialize the DryICE peripheral to detect a physical attack. In addition, grouped into the card reader solution will be documents related to the PCI evaluations done for the MCU and associated hardware. These documents will provide guidelines on which MCU features are necessary to meet the PCI PTS requirements.


Summing up

The benefits of creating a solution can go beyond the targeted use case. Just as complex mathematical problems can be broken down, so can the challenges of embedded design. With a solution, like the SLN-POS-RDR, not only are we addressing industry problems such as card fraud, but also the challenges of embedded design. Bringing security along with other common embedded functions around human interfacing and communications will enable the developer to confidently bring their devices to production.

Forlinx will attend ELEXCON 2016 as an exhibitor held in Shenzhen EXPO Center at booth no. 3C32 from August 24, 2016 to August 26, 2016. On the exhibition, some new items such as EV charger billing control unit TCU 335xD, single board computers i.MX6Q/DL/UL, OK335xD/S/xS-II etc.

Welcome to visit us at that time.

[re-printed from]


One of the really nice features of the PSoC Creator schematic editor is the ability to copy-paste parts of the design to replicate functionality. When you copy a component instance all the parameter settings come along for the ride and so you can set things up once and use the metaphorical cookie-cutter as often as you like. The tool even renames everything to avoid name space collisions. It is a feature I use all the time.

Until it goes wrong. This happens when I decide that I need to change a parameter and start making the edits in copied components. Then someone roams up to my desk and asks a difficult question (such as "ready for lunch?"). One extra-large burrito and a bucket of chips later I have forgotten which components I had edited and the whole system stops working! As a result this I always look for alternatives to making multiple copies of components and a hobby project of mine illustrates a good example of how to do that.


When not eating burritos or writing articles for the PSoC Creator Start Page I often play with a PSoC-powered robot car. I can drive it from my phone because it has a Bluetooth module on-board, and I can set it up as either an automated line follower or maze solver. It happens to be the fastest line follower in the company by the way but that is probably more an indication of my lack of article writing than my skills as an embedded programmer. Anyway… the front of the car has a row of 5 reflectance sensors, connected to PSoC pins, that I use to detect the presence and position of the car relative to a line on the floor. The photodiodes are always powered on and the resistance of the phototransistor side varies according to the reflectance of the surface it is facing. By repeatedly charging up a capacitor and timing how long it takes to decay through the transistor I can detect a black line on a white surface (or vice versa). And it is 100% digital so I am not being forced into the kind of mathematical gymnastics I abandoned a long time ago!


Here is a picture of the circuit to handle one sensor. I am using a 2-output PWM to drive the pin's output enable terminal high, which charges up the capacitor (cap_charge). Then I disable the output and wait a "while" for it to decay. A second pulse (sensor_sample) copies the state of the pin through a flip-flop into a status register. I can read the register at any time and the flip-flop ensures the data is always good.

As you can imagine, making 5 copies of this circuit is dangerous. In my time I have messed up the PWM frequencies, the drive modes and initial states of the pins, the reset state of the flip-flop and, well, pretty much everything else! Here is a part of the full design showing just two of the five sensors.

While this design works fine, every time I edit it I manage to make a mistake. The wiring between the PWM and the status register gets complex and it is easy to make a parameter change in some, but not all, components. The fix is to use just one PWM for all the pins (pretty obvious I know) and use the other component's "size" parameter. Starting with the pin, you open the parameter editor dialog and set the "Number of pins" to 5 and, on the Mapping tab, select "Display as bus". The wire from the component becomes thick to indicate that it is a 5-bit bus rather than just a single wire. Notice how there is is just one Output Enable terminal so I can control all the pins with one PWM signal. Then you do basically the same thing with the flip-flop and the status register - give them a size of 5 and display their terminals as buses.

Et voila! Using buses allows me to compress the whole design into the minimum number of components and wiring. Best of all I can make parameter changes to all pins with just a single edit. I have a 5-sensor implementation that helps make my car super-fast but is barely more complex than the single sensor version. Best of all, it is really easy to maintain, regardless of all my burrito-fueled distractions!

SANTA CLARA, Calif.—They’re out!


Technical papers for ARM TechCon 2016 have been selected and published to the ARM TechCon website following a record number of submissions and diligent selection work from the Technical Program Committee.

Check out the highlights here in this blog and see the complete list here.


More than 70 papers were accepted from companies such as Mentor Graphics Corporation, Cadence Design Systems, Synopsys, Green Hills Software, Red Hat, Breker Verification Systems, VORAGO Technologies, NXP, Silicon Labs, Xilinx, GLOBALFOUNDRIES and many, many more!


If you haven't, please register for the event, and I hope to see you at ARM TechCon, Oct. 25-27, here at the Santa Clara Convention Center.


Related stories:

ARM TechCon 2016: What not to miss in training

Synopsys recently announced a new interface board connecting the Juno ARM® Development Platform to the Synopsys HAPS® FGPA-based prototyping system. Using the Juno board with ARM Cortex®-A72, or Cortex-A57 and Cortex-A53 MPCore™, Mali™-T624, and reference software through Linaro Linux. together with Synopsys' HAPS FPGA-based integrated hardware, you can accelerate software development, hardware/software integration and system validation for ARMv8-A based system-on-chips (SoCs). In addition, Synopsys DesignWare IP Prototyping Kits support the Juno ARM Development Platform through this prototyping system and interface to provide a proven reference design that enables designers to start implementing IP in a SoC in minutes.


Juno ARM Development Platform connected to
HAPS-80 FPGA-based Prototyping System:
Synopsys IP Prototyping Kit:


On, Don Dingee's put together a good writeup on this ARM-Synopsys collaboration and its benefits.


There's a short (4.5 minute) YouTube video on using the Juno board together with Synopsys' HAPS and IP Prototyping Kit to do USB 3.0 IP software development.


In addition, you can register to see a full webinar on this interface today:

This blog is the second in a series on the new debug features in SOMNIUM DRT. The first one was about the live expression view.


Debugging is difficult, especially when unexpected errors cause the program to behave unpredictably, such as writing to an invalid area of memory or executing an illegal instruction. The ARM architecture includes an exception mechanism to trap such faults. This is a powerful feature but it can be difficult to understand the information available.


SOMNIUM DRT includes features to support debugging embedded systems. One of these is a Fault Diagnosis tool that presents the fault information in a human-readable format. I have written briefly about the Fault Diagnosis view in DRT before. This article goes into a bit more detail about how to make the best use of it.



SOMNIUM DRT is is a set of development tools for ARM Cortex-M based devices such as SMART devices from Atmel, Kinetis and LPC devices from NXP, and STM32 devices from STMicroelectronics. It is fully compatible with industry-standard tools such as the GNU toolchain and Eclipse IDE. DRT uses our patented techniques to produce highly optimized code by exploiting information about the embedded processor, the memory system and other peripherals to deliver improved performance, lower code size and reduced energy use.


Fault Diagnosis

ARM processors raise an exception when a fault occurs. If the exception handler triggers a breakpoint, then you can use this when debugging to find errors in the program. In a live system, the exception handler could attempt to correct for the cause of the error and then restart execution.


There are four types of faults that are detected by Cortex-M3 and Cortex-M4 processors. These trap errors such as illegal memory accesses or attempting to execute non-existent instructions.


  • Bus Fault: An error during instruction fetch or data read/write. The amount of information available about the fault depends on whether the fault is "precise" or "imprecise". Precise bus faults are caused by the last instruction to execute. For example, data read faults are precise because the instruction cannot complete until the data has been read. In this case more detail about the instruction that caused the fault will be displayed. Imprecise bus faults are caused by an instruction that completed several cycles earlier and so the exact instruction that caused the problem is no longer known.
  • Memory Management Fault: For example, attempting to execute an instruction from a non-executable area of memory.
  • Usage Fault: An exception that occurs because of a fault related to instruction execution such as attempting to execute and undefined instruction.
  • Hard Fault: A hard fault is normally caused by one of the other types of fault occurring when the appropriate fault handler cannot be executed for some reason. In this case, the Fault Diagnosis view will display the original cause of the fault, when possible.


In the case of the Cortex-M0 processor, only hard faults are available.

To make best use of the Fault Diagnosis view, you should make sure that your program is set up to catch any faults when they occur. There are two steps to this:

  1. Enable all relevant fault handlers
  2. Add a breakpoint to the fault handler(s) to stop execution immediately


There are various ways to ensure a breakpoint occurs when a fault handler is triggered. Perhaps the simplest, for occasional use, is to add a breakpoint to the default exception handler code. This is defined in the file startup_ device.S


A more flexible approach is to define your own exception handler. For example:

void __attribute__((naked)) HardFault_Handler(void)


__asm__("bkpt 0");

while (1);



The names of the other fault handlers are: MemManage_Handler, BusFault_Handler, and UsageFault_Handler. Using this approach allows you to quickly see what type of error occurred. You can also use this as the basis for a more complete exception handler that attempts to continue execution after the fault.


The next step is to enable all the necessary fault handlers.


Note that only the hard-fault handler is enabled by default. Also, fault handling is not enabled by default for for unaligned memory accesses and divide by zero errors, Therefore you should make sure that the exception handlers and fault types you need are enabled. To enable exception handlers for all the above, you can add the following code where you do most of your initialization (for example, at the start of the main() function):

// Enable all exception handlers







// Enable divide by zero and unaligned access faults






The hardware records information about the cause of the fault in various system registers. Different levels of detail are available depending on the architecture and the type of the fault.

The DRT Fault Diagnosis tool will automatically extract this information, decode it and display it in a readable form, relating it to the program source code (when possible). This is much easier than looking at register values, decoding bit-fields and referring to the ARM architecture manual.


The Fault Diagnosis view will display the source of the error (including the file name and line number, when available). You can display the source or the disassembly view of the code that caused the error, and see the values of the main registers when the error occurred.


For more information on the information displayed, see the DRT Reference Manual.


A free trial of DRT is available. DRT is able to automatically import projects from other development tools, making it simple to migrate your projects to DRT so you can quickly see the benefits for yourself. Download your free trial today and try out these powerful debug features for yourself.

Contest abstract



Every one of us faces problems every day and each problem has several solutions. It is the ease with which the solution can be deployed, to benefit as many end users as possible that determines the "smartness" of the solution. How many times have you had trouble with missing a bus and wondered "If only I had real-time information on the bus running status…" or experienced a traffic jam and all the drivers continuously honking for no reason and that left you thinking "wish the horn would be disabled from unnecessary honking" or entered into a parking lot and felt helpless finding an empty slot to park your car? Well, if you have that burning desire to try and come up with some creative solutions for ‘Smart Transportation Systems’, here is your big opportunity to bring out the innovative potential in you and address such day to day transport issues.



The Advanced Computing and Communications Society (ACCS) has announced the third edition of the ARM Student Design Challenge on “Smart Transport Systems” as part of its 22nd Annual International Conference on Advanced Computing and Communications (ADCOM 2016) at PES University, Bengaluru, in September 2016.



The ARM Design Challenge (ADC) is aimed to provide engineering students opportunities for learning beyond their regular curriculum to:


  • Study and understand current status and challenges in real world and identify opportunities for improvement.
  • Evolve innovative and cost effective solutions relevant and appropriate to the application environment
  • Study and develop good working knowledge in the use of the powerful ARM Processors Cortex-M series based Platforms.
  • Develop skills in System, HW, SW and control Design and Engineering
  • Understand Product Development Cycle in embedded system
  • Understand Project management in Engineering Development.
  • Motivate and prepare Engineers to take up their career in Automotive Research and Development.



Important dates


Submission of Proposal30th July 2016 7th August 2016
Declaration of Accepted Proposals8th August 2016
Preliminary Round - Presentation by Teams at ADCOM 201610th - 11th September 2016
Preliminary Round - Announcement of Shortlisted Teams11th September 2016
Second Round17th December 2016
Final Round17th March 2016



Connectivity is a top priority for makers and researchers working with drones and quadcopters: Data needs to be sent quickly and efficiently back and forth from a remote device and a home station, like a laptop.


Gumsitx’s AeroCore 2 expansion board for the Dragonboard 410C computer-on-module, including support for a Nimbelink LTE modem, is Gumstix’s most technologically advanced platform for launching a next-gen drone. Watch Gadget Guru Drone Demo video to learn how you can connect your drone.

For the last few months we’ve been working (at AdaCore) on a driver library entirely written in Ada for the STM32F4 and STM32F7 with the intent of supporting additional Cortex-M and Cortex-R vendors in the future. With this driver library we want to show that Ada is a good choice for writing hardware drivers, and we also want to lower the entry barrier for Ada on embedded platforms. The project is hosted on GitHub:


We also started an Ada embedded project competition : Make with Ada. With more than 8000 euros in prizes this competition is an opportunity for every programmer to try Ada.


In this article we are going to present the qualities which make Ada a powerful tool for embedded programming. In a second article we will talk about the design and implementation details of the driver library itself.


Ada for embedded


Ada is a general purpose language that has been originally designed to address the needs of embedded systems. To this end, it has a number of features that increase readability, maintenance and code quality while remaining very efficient in constrained environments. The language itself has evolved considerably from its initial inception (Ada83) to the current version (Ada2012). In the following sections, we will concentrate on the main features that make this language an excellent choice  for embedded programmers.


The name of the language is not an acronym, but rather refers to Lady Ada Lovelace, daughter of Lord Byron and considered as the first programmer. So please, no ada, or ADA, but Ada


General-purpose features



Ada has been designed for readability. To this purpose, the language defines the notion of packages. This concept somewhat resembles name spaces, but with some significant differences that make it closer to class definitions in C++ or Java.


Specification and implementation (respectively package spec and package body) are clearly separated in Ada. Only those entities declared in a spec (for example types and subprograms) can be used by other packages. Packages can contain code that is executed when the package is used (elaborated).


Unfortunately, ARM community blogs do not have syntax highlighting for Ada. This will make the code difficult to read...


package Pkg is

   procedure Hello_World (Name : String);

end Pkg;


with Ada.Text_IO;

package body Pkg is

   procedure Hello_World (Name : String) is
      Ada.Text_IO.Put_Line (“Hello, “ & Name & “!”);
   end Hello_World;

   Hello_World (“Elaboration time”);
end Pkg;


with Pkg;

procedure Prog is
   Pkg.Hello_World(“Main program”);
end Prog;


When Prog is executed, it will output two lines:


Hello, Elaboration time!

Hello, Main program!

The first is displayed by the invocation of the Hello_World procedure during the elaboration of package Pkg before Prog starts, and the second is displayed by the call on Hello_World from Prog.


Strong typing

Some general-purpose features of the language work just fine in the embedded context. For example, Ada is a strongly typed language: the type of each variable is specified when the variable is declared and cannot be subsequently changed. Although this may seem constraining compared with loosely typed languages, this allows a greater understandability of the intent of the program, a higher level semantics, and  powerful means to control the data flow, and check the usage of values (in terms of allowed bounds for example).

For example:



   type Mile is new Float;

   type Kilometer is new Float;

   Length1 : Mile := 1.0;

   Length2 : Kilometer;


   Length2 := Length1;
   --  This produces a compilation error: miles are not kilometers,
   --  even though they’re both represented as floats.


This type system is great for maintenance and refactoring. As most of the checks are performed at compile time - the compiler knows the type of each variable or parameter, and reports errors in case of invalid assignments - it is fairly easy to perform large scale refactoring by introducing or modifying just a type. All you then need to do is to fix the compiler-reported errors as they appear.


Ada’s typing facility is very general. For example in Ada you can define a variety of scalar types: integer types with specific ranges, both signed and unsigned (modular), floating or  fixed point types, and enumeration types. Below are some examples:



   type Meter is new Float;
   type Height is new Meter range 0.0 .. Meter’Last;
   type Degree is mod 360;
   type Manhattan_Avenues is range 1 .. 12;
   type Midtown_Streets is range 42 .. 59;
   type Months is

   subtype Summer_Months is Months range July .. September;


   Height := -1.0; --  Will raise an exception at run-time and a compilation warning

   Degree := 359;
   Degree := Degree + 1; --  Degree is now 0

   Midtown_Streets := 59;
   Midtown_Streets := Midtown_Streets + 1; --  Raises an exception

   for Month in Months loop
      --  Enums are iterable
      Ada.Text_IO.Put_Line (Months’Image (Month));
   end loop;

   for Month in Summer_Months loop

      --  This will iterate on July, August and September

      Ada.Text_IO.Put_Line (“Summer :” & Months’Image (Month));

      --  As this is a subtype, using Months’Image or Summer_Months’Image is equivalent.
      --  Also you can assign to a value of type Months any value of type Summer_Months,
      --  but the reverse will raise an exception if the value is not in the expected range.
   end loop;


Contract-based programming

Designing an interface is like writing a contract with the user of that interface. For instance with this function:


function Image (A : Integer) return String;


The contract for the caller is that the function can only be called with an Integer as first and only argument. The contract for the callee is that the function will return a String. The compiler will check that both caller and callee respect the contract.


Most programming languages support, to some degree, contract-based programming, but the more you can specify in your contract the more information you give to the user of the interface and the to the compiler. The result is a better interfacing of your software modules and more error checking at compile time.


Parameter modes

Every parameter of an Ada subprogram (function or procedure) can be “in”, “out” or “in out”. “In” means that the subprogram can only read the parameter and will not modify it. “Out” means that the subprogram can modify the parameter (and also read it, after it has been assigned). “In out” means that the subprogram can both read and assign to the parameter. This feature is a safe replacement for many of the pointer usages in C.


type My_List is private;

function Is_Empty (List : in My_List) return Boolean;
procedure Append (List : in out My_List; Element : in Integer);
procedure Get_Last (List : in out My_List; Element : out Integer);

Not null access

Whenever you are dealing with pointers (access) in Ada you can specify that the pointer should not be null.


This works for variable:

X : Integer := 32;
Ptr : not null access Integer := X’Access;


type My_Data is record
   Ptr : not null access Integer;
end record;

Or subprograms:

function Is_Empty (List : not null access My_List) return Boolean;

And it can be used with function pointers as well:

   type My_Function_Ptr is access function (X : Integer) return Integer;

   procedure Map (List : in out My_Integer_List; Func : not null My_Function_Ptr);


This is very powerful because when dealing with pointers we often don’t know what to do when the pointer is null. For instance, if someone calls the Map procedure above with a null function pointer, what should implementation do? Raise an exception or do nothing? The answer is that the implementer of the Map procedure should not have to handle this case, because it doesn’t make sense to call Map with a null function pointer. Therefore the responsibility of not calling Map with a null pointer is transferred to the caller, which will have more context awareness to decide what to do.


Type ranges and subtypes

In Ada it is possible to define ranges for every scalar type (integer, floating point, fixed point, enumeration).


type Integer_Percentage is new Integer range 0 .. 100;
type Float_Percentage is new Float range 0.0 .. 1.0;


For example, when writing a driver for a temperature sensor, you may read in the datasheet that the sensor has a temperature range of -55C to 125C; in Ada you can define this type, with the assurance that the value returned by the driver will always be within this range.


type Sensor is private; -- encapsulated data type

type Temperature is range -55 .. 125;

function Read_Temperature (This : Sensor) return Temperature;


Preconditions, and postconditions

In the temperature sensor example, it’s likely that the sensor requires an initialization before users can read the temperature. This is how you can specify such a constraint in Ada:


type Sensor is private;

procedure Initialize (This : in out Sensor)
   with Post => Initialized (This);

function Initialized (This : Sensor) return Boolean;

function Read_Temperature (This : Sensor) return Temperature
   with Pre => Initialized (This);


It’s is clear here that the sensor has to be initialized before reading the temperature. Not only is this information available to the user of this sensor driver, it is also possible to enable run-time checks of the pre and post conditions. In that case an exception will be raised if Read_Temperature is called on a uninitialized sensor, which means the error will be caught early in the software life cycle instead of lurking during the development and testing phase until someone realizes that the driver returns garbage data because the sensor is not initialized.


Object oriented features

OO concepts are now present in most languages used for servers or desktop development, but are much less common in the embedded world. There are several reasons for that. Historically, OO languages have relied on automatic garbage collection for storage management, complicating (or precluding) execution time predictability and adding time and space overhead. OO features have also raised certification concerns (achieving full confidence of complete coverage of the testing is non trivial with inheritance and dynamic dispatching).


Ada and GNAT offer full OO support even on the most stringent target environments, without the intrusion of garbage collection. Predictable execution time is achieved through a combination of language features (for example storage pools for memory management) and implementation techniques (such as static dispatching tables).


It’s also important to notice that in Ada, programmers are not required to use OO to realize some of its benefits; for example encapsulation can be achieved simply through packages and private types..


Embedded programming features


Where Ada really flies compared to similar programming languages, is when it comes to embedded programming. The main features useful in this context are representation clause (being able to express exactly how a type is organized in memory), interrupt handling, and multitasking (right, on bare metal). There are several other features that are useful as well such as storage pools, and the general control over the memory usage, but in the context of this article I will only concentrate on the ‘block busters’.


Representation clauses

Ada offers various means to control exactly how a particular data structure has to be interpreted by the compiler and represented in memory. This is extremely useful in the context of bare metal development as this is a powerful means to describe registers.


Following are example of such representation clauses.


Representing register fields

First, let’s describe register fields. For example a 4 bit field that stores powers of 2 ranging from 2^1 to 2^4 can be expressed this way in Ada:


type Field is range 1 .. 16 with Size => 4;


In this example, having 16 as a value is allowed, even though its ‘natural’ representation would exceed the 4 bits range. This is possible because the range starts at 1, so all values can be represented by shifting their representation by 1. So 1 will be represented as ‘0’ by the compiler, 2 as ‘1’, etc. Ada (and GNAT) support these sorts of “biased” representations.


Enumeration types can also have representation clauses. For example a simple bit could be represented as:


type Edge_Detection is (Rising_Edge, Falling_Edge) with Size => 1;


This definition implicitly defines Rising_Edge as 0 and Falling_Edge as 1. Explicit representation values can be also given, in particular if some values are reserved.


type Power_Value is (Min_VCC, Max_VCC) with Size => 2;
for Power_Value use (Min_VCC => 0, Max_VCC => 3);
--  In this case, values 1 and 2 are reserved by the hardware
--  manufacturer, so not represented at the software level.


In case we have a sequence of fields, each with the same structure, Ada arrays can be used, taking advantage of the ability to specify array bounds.


Let’s say we have a GPIO with 16 banks. Each bank is configured via a field that is 4 bits wide. This means we will need two 32-bit registers.


--  Definition of the GPIO config field
type GPIO_Config is … with Size => 4;

type GPIO_Low_List is array (1 .. 8) of GPIO_Config
  with Pack, Element_Size => 4, Size => 32;

type GPIO_High_List is array (9 .. 16) of GPIO_Config
  with Pack, Element_Size => 4, Size => 32;


The above definition tells the compiler (and the reader) that:

  • The array is packed: the compiler should not try to align the values, but instead will make sure that values are consecutive in memory, even though they’re not even byte-aligned.
  • Each element is 4 bits wide, the total size is 32 bits. If the programmer makes a mistake here (for example by trying to fit too many bits in the structure because one of the values is incorrect), the compiler will complain.
  • The bounds keep the natural numbering of the GPIO banks: if we identify the last bank as ‘bank 16’, then GPIO_High_List (16) will return the proper value.


Representing registers

Since a register is generally a collection of fields (the only exception being a register containing just one value), we will use Ada records to represent them. Such records can be defined with explicit representations this way:


type Field1 is … with Size => 5;
type Field2 is .. with Size => 15;
type Field3 is … with Size => 12;

type The_Register is record
   F1 : Field1;
   F2 : Field2;
   F3 : Field3;
end record
  with Size => 32, 
       Bit_Order => System.Low_Order_First;

for The_Register use record
   F1 at 0 range 0 .. 4;
   F2 at 0 range 5 .. 19;
   F3 at 0 range 20 .. 31;
end record;


Here several aspects are used to precisely represent the register:

  •     Size => 32: thus a 32-bit register
  •     Volatile_Full_Access: the register is volatile (can change without the software doing anything), and has to be fully accessed when written (so the full 32-bit needs to be written at once). I’ll come back to this aspect a bit later.
  •     Bit_Order => Low_Order_First: it’s a LSB (“little endian”) representation.


This means that F1 is at bits [0-4], F2 at [5-19], etc. The Volatile_Full_Access aspect is currently not part of the language standard, but a GNAT compiler extension. This makes use of read-mask-assign-storage patterns when a field is set.

As an example, using the type above:


   Register : The_Register with Address => Reg_Addr;
  Register.F2 := 5;


This has the same effect as writing in C:


#define F2_MASK 0xfffe0
#define F2_OFFSET 5

uint32_t* reg = F2_ADDR;*reg = (*reg & ~F2_MASK) | (5 << F2_OFFSET);


Mapping peripherals

As briefly seen with the preceding example, one other representation aspect that is useful for embedded programmers is the ‘Address’ aspect, which allows you to place instances at specific addresses.This can be used in particular to represent the complete mapping of a peripheral:


type My_Peripheral is record
   Reg1 : Reg1_Type;
   Reg2 : Reg2_Type;
end record with Volatile;

for My_Peripheral use record
   Reg1 at 0 range 0 .. 31;
   Reg2 at 4 range 0 .. 31;
end record;

Periph1 : My_Peripheral
 with Import, Address => Base_Peripheral_Address;


Using the above tells the following:

  • Volatile: values contained in this structure can change asynchronously
  • Import: the actual values are defined outside of the application, so the compiler should not try to perform any initialization when creating instances of the type.
  • Address: base peripheral address is set for the instance.

Registers are then accessed as offsets from the base address, which is exactly what we want.



Users of the Cortex-M family of microcontrollers now have the opportunity to benefit from CMSIS/SVD hardware description files. We (AdaCore) have developed SVD2Ada, a tool that reads such descriptions and generates Ada specs with the proper representation clauses as described above. This tool is available on github ( and you can see an example of the generated code here:


Tasking support and interrupt handling: the Ravenscar profile

Ada includes tasking features as part of the language standard (task creation, synchronization, message passing, etc.), thus allowing portable multi-tasking applications. However,  support for the full Ada tasking model is not practical for limited targets such as microcontrollers. Moreover, use of full Ada makes it difficult to demonstrate real-time properties and lock-free computation. For this reason, a particular subset of the concurrency features has been defined to allow embedded real-time multitasking with Ada. That subset is known as the Ravenscar profile, first defined in the late 1990s. It’s like having a RTOS embedded in the language.


Here is an example of how to create a periodic task in Ada:


task body Periodic_Hello is
   Print_Time : Time := Clock;
   Period     : constant Time_Span := Milliseconds (500);
      Print_Time := Print_Time + Period;
      delay until Print_Time;

    Put_Line (“Periodic hello world!”);   end loop;
end Periodic_Hello;


Tasking management in Ada involves two types of structures:

  • Tasks: as you would expect from the name, those are the actual active objects (control threads, requiring a stack and a processor).
  • Protected types: providing mutually exclusive access to data, possibly state based. Protected types also provide a means to handle interrupts from the hardware.

For example:


User_Button_Interrupt : constant Interrupt_ID := EXTI0_Interrupt;

protected User_Button is
   pragma Interrupt_Priority;

   function Get_State return Boolean;
   procedure Clear_State;
   entry Wait_Press;

   procedure Interrupt;
   pragma Attach_Handler (Interrupt, User_Button_Interrupt);

   Pressed : Boolean := False;
end User_Button;


The semantics of such a protected object is the following:

  • functions only perform read access of values stored in the object. Hence simultaneous calls to functions are allowed.
  • procedures can change the values. Hence function calls are not allowed when a procedure is called, simultaneous calls to procedures are not allowed either.
  • entries have the same properties as procedures, and also have barriers that make a task wait for the barrier to be lifted before entering the entry.


In order to ensure real-time properties, the Ravenscar profile disallows dynamic creation or destruction of task-related objects (e.g. the tasks themselves, and also the protected objects).


To be continued...


Jerome Lambourg is a senior engineer at AdaCore. After graduating from the french High School Telecom ParisTech in 2000, he worked first for Canal+Technologies, and then as a consultant for General Electrics Medical Systems, SAGEM Mobile, and Thales Naval. He then joined AdaCore in 2005. There he worked on various parts of the technology: GPS, GNAT Pro for .NET, AUnit, certification tools (the Qualifying Machine). He is now involved in cross and bare metal platforms, in particular as product manager of GNAT Pro for VxWorks.
profile.jpgFabien Chouteau joined AdaCore in 2010 after his engineering degree at the EPITA (Paris). He is involved in real-time, embedded, hardware simulation technology and author of the Make with Ada blog post series. Maker/DIYer in his spare time, his projects include electronics, music and woodworking.

This interview at the IOT Devcon turned into a mini-connectivity training discussion with Vivek Mohan from Silicon Labs. Here are the questions answered by Vivek concerning iot connectivity

> How are standards and proprietary systems addressing the multiple protocols of the IOT?

> Why is IOT connectivity not as concerned with multi-antenna systems as Wi-Fi?

> What is the difference between Thread and Zigbee?

> “Don’t look for too much consolidation from the IOT physical to application layer.” Why?




Video: Clarifying IOT Connectivity Confusion


[re-printed from]


In a recent blog I talked about wiring tips for faster design. One of the risks with being a wire-drawing wizard, though, is that it can lead to a bit of a messy schematic. It is tempting to just drop in your components anywhere on the page and hook them up. If you ever look at an old design and wonder what you were thinking about at the time then I recommend naming your wires.

PSoC Creator resolves wires with the same name into a single signal path when it builds a project and so two (or more) wires with the same name are functionally equivalent to a single wire with fourteen elbows meandering around a cluster of components.

Here is a design I made recently that uses a PWM with two outputs to drive a reflectance sensor. The first output (pwm1) turns the LED on briefly and the second (pwm2) triggers the D flip-flop to read the state of the pin a little while later. The reflectiveness of the surface determines how long the transistor takes to decay and so the output of the flip-flop is always a snapshot of the state of the sensor. In firmware, I read the status register and can make decisions based on the surface my board is lying on.



The problem is that I have five of these sensors and I wanted to drive them all from the same PWM and read them from one status register. I made copies of the pin and flip-flop and started wiring but it took quite a while. I kept making mistakes because I could not remember which wire should go where and I would inadvertently connect two wires that were driven by different signals. I managed to get three sensors working.


I was daunted by the prospect of more wiring and I was running out of room on the page! How would I  ever maintain this project? So, in the end, I gave up and took the extra 30 seconds to just name the wires coming from the PWM and those going to the status register. You just right-click on the wire and choose "Edit Name and Width" to do this.



I then tidied up the design in no time. As you can see, naming the wires let me break the whole design into three pieces; the PWM, the pins and flip-flops, and the status register. I managed this without ever making a bad connection and it is much easier to see the connectivity when there are not wires running around and crossing each other.

Taking a few seconds to name wires can save you a lot of time drawing your schematics. Not only can you make designs (that work) quickly but you can do so in a way that is far easier for other engineers to understand. In a future blog I will expand on that idea with some more tips on making schematics with lots of repeated content, like all these pins and flip-flops, even easier to read and maintain.

This article discusses traditional code optimization techniques and describes how SOMNIUM DRT's patented optimizations extend that to provide smaller code, higher performance and lower energy consumption.

(This article is based on our webinar on optimization:


Compiler optimization

The current state of the art in compiler technology means that compilers make a very good job of optimising the code. This generally makes trying to optimize the source code fairly pointless - the compiler will usually generate pretty much the same code even if you reorder equations and statements (assuming the code is semantically equivalent).

However, there are hints you can give the compiler which can improve the optimization by giving it information that it may not be able to deduce from analysing the source code - particularly because the compiler only looks at one compilation unit at a time.

These are things like adding annotations to indicate a const variable or that a function is "pure" and returns a value depending only on its arguments.


const int n = 42;

f __attribute__((pure));


On the other hand, you might need to tell the compiler *not* to perform certain optimizations. A common one is marking a variable as volatile so that every read or write in the source code is preserved (and correctly ordered) in the compiled code. Also, for embedded systems with limited memory, it is useful to be able to tell the compiler not to inline certain functions, to avoid excessive code size.


volatile int p;

g __attribute__((noinline));


Although modern compilers do an excellent job, there are two major limitations on what they can do. One is that the compiler only looks at instruction sequences for each compilation unit. Also, the compiler only knows about the CPU (for example, instruction sizes and timings) but has no information about the speed and sizes of different types of memory, the presence of caches, etc.

This places a limit on how much "real world" optimization is possible using existing compiler technology - a system-level view is required to fully optimize the code.



SOMNIUM DRT is is a set of development tools for ARM Cortex-M based devices such as the Kinetis and LPC devices from NXP and the STM32 devices from STMicroelectronics. It is fully compatible with industry-standard tools such as the GNU toolchain and Eclipse IDE. DRT uses our patented techniques to produce highly optimized code by exploiting information about the embedded processor and the memory system to deliver improved performance, lower code size and reduced energy use.



The DRT toolchain extends the existing compiler infrastructure and optimizations to tune them for the specific device you are using

The DRT resequencing linker looks at the whole program generated by the compiler and, using knowledge of the system architecture (including the memory system), applies a number of optimizations that the compiler is not able to do. This includes replacing instruction sequences for more efficient ones, removing redundant instructions, reordering functions to make better use of caches, and so on.

The exact set of optimizations performed by the linker depends on the optimization level you specify (for example, -O3 to optimize for speed or -Os for size).

The resequencing linker provides improvements in code size, performance AND energy consumption - all at the same time. This requires no changes to your source code or development process.

Several of the optimizations remove unused or redundant instruction sequences. Others replace instructions or instruction sequences with better ones. Some examples of the optimizations performed by the linker are:

  • Changing PC relative load instructions (ldr) to adr instructions to allow the associated data to be removed
  • Optimizing the alignment of branch target addresses
  • Finding duplicate constants in text sections and merging them
  • Replacing some 32-bit instructions with shorter equivalents
  • Reordering functions to make the best use of cache
  • Performing advanced data flow analysis and further optimizations of register usage and instruction selection

DRT also automatically chooses the best compilation options for the target device and optimization level you specify.

More detail can be found in the DRT Reference Manual.


DRT Toolchain & IDE

The DRT toolchain currently supports ARM Cortex-M devices from NXP, STMicroelectronics and Atmel. We are working with other vendors to extend this range.

The DRT toolchain is available in two products: an Atmel Studio plugin that just provides the toolchain (including the resequencing linker and the optimized libraries) and a complete IDE that includes the toolchain plus extra debugging tools such as trace, live expressions and fault diagnosis.. The DRT IDE supports multiple vendors and provides extra features for debugging and ease of use. It is currently available for both Windows and Linux. A Mac OS version is coming soon.


We use a number of different ways of evaluating the benefits of the DRT toolchain. This includes tests we have generated internally, some based on customer code, standard examples from semiconductor vendors, and a number of industry standard benchmarks such as Nullstone and EEMBC CoreMark.


Run-time library overheads

One interesting test we have done, is to compare the size of the code for an "empty" C program - a program newly created in the IDE that contains a minimal main function. This is a useful way of understanding the overheads of the C run-time libraries and startup code. We find that most development system use between 2KB and 5KB of ROM for this empty program. DRT uses significantly less ROM and/or RAM than any other toolchain.


empty c results table


This is particularly significant for very small memory footprint devices used in embedded systems such as IoT nodes. With some development tools it would not be possible to use C with these devices with very small amounts of memory.

Our benchmark document shows detailed results for Kinetis, LPC and STM32 examples.


EEMBC CoreMark

SOMNIUM is a member of the EEMBC Automotive Subcommittee and we use their industry standard benchmarks.

We believe that in order to be useful, benchmarks should show 3 dimensions. Not just performance, but memory size and energy use as well. The CoreMark benchmarks are great for this.

It's easy to obtain higher performance by unrolling, inlining and specializing functions to the extreme, but real world systems are memory limited so this approach makes little sense if you want to get an accurate understanding of real world behaviour. We always measure memory size, performance and where possible we measure energy, measured to the micro-joule using the high accuracy EEMBC EnergyMonitor.

Here we have a few examples of typical results:


coremark results graphs


NXP KL02 devices are quite constrained by their memory size and performance. Using DRT increases performance whilst saving significant amounts of ROM, RAM and energy.

KV10 devices have high performance memory systems, with a 16-entry, 4-way set associated flash cache. Even with this high performance hardware, DRT still increases KV10 performance and saves energy whilst reducing code size.

We compared against the vanilla GNU tools from Atmel Studio 6 and 7. DRT didn't affect RAM usage, but always generated the smallest, fastest, lowest energy results.

STM32L053 is an ultra-low-power device with a very simple flash buffer, rather than a cache. DRT can significantly improve its performance and energy behaviour.


NXP Attach demo

As an example of vendor code, we can look at the Attach demo from NXP. This uses the NXP Sensor Fusion library to combine the data from various sensors. It uses the NXP eGUI library to display the data in various forms and allow user interaction. So it demonstrates many of the features that might appear in a real embedded system.

Note that libraries such as Sensor Fusion are only available for GNU-compatible toolchains and so not supported by Keil or IAR.

attach results

Although the savings in the particular example are not huge, they demonstrate an important point: only the DRT toolchain is able to fit the application into the available ROM and RAM. Using the KDS tools would have required using a larger memory - and therefore more expensive - device.


DRT provides industry-leading optimization resulting in smaller, faster code which uses less energy. It supports the latest C and C++ standards, including C++ exceptions and is extensively tested by several test and validation suites. It includes ease of use enhancements and easier debugging with trace, live expression view and fault diagnosis.

A free trial of DRT is available form the SOMNIUM Portal.

DRT provides automatic import of projects from other Eclipse-based development environments, making it simple to evaluate. Download your free trial today from the SOMNIUM Portal and try it for yourself.

For more information on benchmarking and results, see the white paper on our website.

Time is running out. Don't miss the opportunity to get an EagleSoC development kit featuring a Cortex-M3 PSoC 5LP device.

I posted about this a couple of weeks ago and there is still time to back the kickstarter project. Here are the creators, explaining a little more about the kit.



The kits provide isolated analog and digital power domains so they are a great way to learn about Cortex-M, analog signal processing, and embedded systems programming in general. There is also a free software package called EZ-PSoC Library, which makes the job of interacting with device peripherals really simple.

I think these kits are great and so, if you're looking for a powerful but low-cost development kit with an 80MHz ARM device, don't wait too long and miss this opportunity!

Вебинар по продукции TechNexion "Процессорные платы на базе iMX6 (ARM)"


OK, maybe not everyone of you speak Russian. For example I don't speak.

But I know there is a big Russian community out there, developing great stuff just like the rest of us by using ARM Processors.


This Friday Ilya from IPC2U will hold a Webinar to give a Technical overview about the capabilities ARM processors have and how you can use them in today's world.


I had a chat with Ilya and he told me he is planing to give a overview why ARM now is more suitable to be used in many different industrial areas due to increased capabilities and the increased usability of Linux. I had the luck that Ilya gave me an overview about what he will present, so even my Russian is limited (limited as in 'non existing') I still get some useful updates, even for me.



The Link to register is here:




It's at 11:30 Moscow time (I guess, please check link above) and the Agenda is like this:


Темы вебинара:

  • Что такое ARM
  • Семейство процессоров iMX6 на базе архитектуры ARM Cortex-A9
  • О компании TechNexion
  • Обзор продукции компании TechNexion (встраиваемые системы, панельные компьютеры)
  • Подробный обзор процессорных модулей формата PICO


Talking with Ilya he told me this Agenda is roughly and he will cover like this:

-ARM overview

-ARM for industrial usage

-NXP and it’s ARM i.MX6 Processors

-TechNexion Product overview

-TechNexion PICO Modules in detail



I don't know if there is a limit in maximum people to attend but 1h ago Ilya told me he is overwhelmed by the sign up rate of people... you better hurry if you speak Russian and want join!



Hey you are attending? Tell me here how it was after it, ok?


Looking forward to hear from you!



Internet of Things


P.S.: I work for TechNexion. Thats the Company IPC2U is talking about in this Webinar, just to be clear about that.

Eric Gowland

Make With Ada Competition

Posted by Eric Gowland Jun 20, 2016


AdaCore has announced a design competition for Ada and Spark projects on ARM Cortex-R and Cortex-M processors. Head on over to the Make with Ada website for more details. The competition is partially to mark the release of more extensive open source ADA drivers for Cortex-M - check out the github here.

Filter Blog

By date:
By tag:

More Like This