embARC OSP Software Introduction - foss-for-synopsys-dwc-arc-processors/embarc_osp GitHub Wiki

Overview

embARC OSP is an open software platform to accelerate the development of embedded systems based on DesignWare® ARC® processors built on the ARCv2 ISA. embARC OSP provides a solid starting foundation for embedded developers, simplifying development and improving time to market through software reuse.

The embARC OSP software includes the following components:

  • ARC Hardware Abstraction Layer (HAL) provides the necessary hardware abstraction for ARCv2 ISA compatible processors. Device HAL provides hardware abstraction for common platform devices and implementation of DesignWare IP drivers, such as UART, I2C and SPI.
  • Board Support Package (BSP) layer provides support for different boards based on the ARCv2 processors.
  • OS layer provides embedded operating system support, provide both traditional Real Time Operating System (RTOS) and light weight Internet of Things (IoT) OS options.
  • Library layer provides basic common library support for embedded systems.
  • Middleware layer includes mainstream embedded software stack solutions, including FAT file system, network stack and simple shell/Command Line Interface (CLI).

ARC Hardware Abstraction Layer

The ARC HAL provides hardware abstraction for ARCv2 ISA compatible processors. In this layer, the following functions are provided:

  • Startup: common startup routines or templates to handle necessary initialization after power on, reset, and so on.
  • Exception and interrupt management: a standard exception and interrupt processing model and related resource definitions.
  • Unified intrinsic/built-in functions: covering both the MetaWare and GNU toolchains.
  • Unified resource definitions: registers, data types, macros, and so on.
  • Access to the resources: internal timers, cache, auxiliary registers, and build configuration registers.

Device Hardware Abstraction Layer

The device HAL provides abstraction for following devices:

  • GPIO
  • I2C
  • SPI
  • UART
  • WNIC

Common features between different devices such as UART, I2C and SPI are abstracted in the device HAL. Object-oriented concepts are adopted to provide the common device operation API and the device information access API. The following diagram provides examples for UART, SPI/I2C and GPIO devices.

Board Support Layer

The BSP layer provides support for different boards based on ARCv2 processors. The layer contains the following functions:

Peripherals Driver Instantiation

In embARC OSP, an object-oriented design is applied for device drivers. The peripheral driver implementations in the device abstraction layer are similar to the definition of class, so for each board, the peripheral drivers should be instantiated.

Common Board Initialization Process

A standard bootup process is defined for each board. The entry of this process is board_init, defined by the specific board and called by the application.

Board Resource Unified Definitions

Most boards share common peripherals, so unified definitions are provided. Examples include the UART used to print messages, SD card interface, buttons, LEDs, etc.

Linker Scripts for Boards

To compile an application for different boards, developers need to provide proper linker scripts to describe the board memory resource schemes. Developers can define their own linker scripts for specific schemes.

The BSP layer currently supports the ARC EM Starter Kit.

Real Time Operating Systems

embARC OSP provides a choice of well-known and accepted OS to use with DesignWare ARCv2 processors in embedded applications, with an emphasis on the IoT space. Three OS choices are currently supported in embARC: Contiki and FreeRTOS, which are delivered with embARC OSP, and ARC MQX RTOS, which is available separately from Synopsys.

FreeRTOS

FreeRTOS is the market-leading real time operating system (RTOS), and the de-facto standard solution for microcontrollers and small microprocessors.

  • Single and independent solution for many different architectures and development tools
  • Feature rich and undergoing continuous active development; Minimal ROM, RAM and processing overhead. RTOS kernel binary image typically in the region of 6K to 12K bytes
  • Simple - the core of the RTOS kernel is contained in only 3 C files. The majority of the many files included in the .zip file download relate only to the numerous demonstration applications.
  • Truly free for use in commercial applications
  • Comes with a porting, platform development, or application development service if required
  • Well established with a large and ever growing user base
  • Ample documentation
  • Scalable, simple and easy to use

Contiki

Contiki is an open-source operating system for networked, memory-constrained systems with a particular focus on low-power wireless IoT devices such as street lighting systems, sound monitoring for smart cities, radiation monitoring systems, and alarm systems. Contiki was created by Adam Dunkels in 2002 and has been further developed by a world-wide team of developers from Atmel, Cisco, Enea, ETH Zurich, Redwire, RWTH Aachen University, Oxford University, SAP, Sensinode, Swedish Institute of Computer Science, STMicroelectronics, Zolertia, and many others.

Contiki comes out of the box with a very rich set of communication protocols and applications including:

  • Full IP Networking: Contiki provides a full IP network stack, with standard IP protocols such as UDP, TCP, and HTTP, in addition to the new low-power standards like 6lowpan, RPL, and CoAP. The Contiki IPv6 stack, developed by and contributed to Contiki by Cisco, is fully certified under the IPv6 Ready Logo program.
  • 6lowpan, RPL, CoAP: Contiki supports the recently standardized IETF protocols for low-power IPv6 networking, including the 6lowpan adaptation layer, the RPL IPv6 multi-hop routing protocol, and the CoAP RESTful application-layer protocol.
  • The Rime Stack: In situations when bandwidth is at a premium or where the full IPv6 networking stack is overkill, Contiki provides a tailored wireless networking stack called Rime. The Rime stack supports simple operations such as sending a message to all neighbors or to a specified neighbor, as well as more complex mechanisms such as network flooding and address-free multi-hop semi-reliable scalable data collection. Everything runs with sleepy routers to save power. This is not an industry standard but a Contiki specific implementation.
  • The Contiki shell: Contiki provides an optional command-line shell with a set of commands that are useful during development and debugging of Contiki systems. With Unix-style pipelines, shell commands can be combined in powerful ways. Applications can define their own shell commands that work together with existing commands.
  • Coffee flash file system: For devices supporting an external flash memory chip, Contiki provides a lightweight flash file system, called Coffee. With Coffee, application programs can open, close, read from, write to, and append to files on the external flash. All of this can be done without worrying about flash sectors needing to be erased before writing or flash wear-leveling. The performance of Coffee is within 95% of the raw throughput of the flash memory.

MQX RTOS

The ARC MQX RTOS offers leading-edge technology for embedded designs based on the ARC processor platforms. Unlike general-purpose operating systems, the MQX RTOS was designed for speed and size efficiency in embedded systems. The MQX RTOS delivers true RTOS performance, with context switch and low-level interrupt routines hand-optimized in assembly, which can be configured to use as little as 3.4 KB of ROM, including kernel, interrupts, semaphores, queues, and memory manager. MQX RTOS components are linked in only if needed, preventing unused functions increasing the memory footprint. MQX RTOS is available separately from Synopsys.

Middleware Layer

embARC OSP leverages several open source projects to deliver integrated IoT protocol stack choices for embedded devices based on ARC processors. This section describes various middleware packages that have ported and integrated for use in embARC.

Common

Common middleware consists of ringbuffer and xprintf() packages; xprintf() is a lightweight printf() library used in embedded systems without support for floating point.

Shell Application: Natural Tiny Shell (NT-Shell)

Natural Tiny Shell (NT-Shell) is a tiny shell software component for small embedded systems. NT-Shell is licensed under an MIT license.

File System: FatFs

FatFs is a generic FAT file system module for small embedded systems. The FatFs module is written in compliance with ANSI C (C89) and completely separated from the disk I/O layer and therefore platform independent. FatFs is licensed under a permissive BSD style license.

TCP/IP Stack: lwIP

lwIP is a small independent implementation of the TCP/IP protocol suite, initially developed by Adam Dunkels. The focus of the lwIP TCP/IP implementation is to reduce resource usage while still having a full scale TCP. This makes lwIP suitable for use in embedded systems with as little as tens of KBs of free RAM and 40 KB of code ROM.

Main features include:

  • Protocols: IP, ICMP, UDP, TCP, IGMP, ARP, PPPoS, PPPoE.
  • DHCP client, DNS client, AutoIP/APIPA (Zeroconf), SNMP agent (private MIB support).
  • APIs: specialized APIs for enhanced performance, optional Berkeley-alike socket API.
  • Extended features: IP forwarding over multiple network interfaces, TCP congestion control, RTT estimation and fast recovery/fast retransmit.
  • Add-on applications: HTTP server, SNTP client, SMTP client, ping, NetBIOS nameserver.

lwIP is licensed under a BSD-style license: http://lwip.wikia.com/wiki/License.

TCP/IP Stack: uIP

IP stack integrated into Contiki, supports both IPv4 and IPv6, IPv4/IPv6, RPL, 6LowPAN. uIP is licensed under a 3-clause BSD-style license as part of Contiki.

IoT Protocols

CoAP

Contiki includes native support for CoAP. With FreeRTOS, sources from the libcoap project are used to provide CoAP functionality - http://libcoap.sourceforge.net/.

libcoap sources are redistributed under the available BSD 2-clause license.

MQTT

Contiki includes native MQTT support. With FreeRTOS, sources from the iot.eclipse.org Paho project are used to provide MQTT functionality.

REST/HTTP

Contiki provides support for REST through the low-power Erbium (Er) REST Engine. The REST layer is useful to develop server-side applications that can be run over either COAP or HTTP.

LW2M2M

LWM2M is an Open Mobile Alliance (OMA) standard that is often used with CoAP. It also supports the UDP Transport Layer Protocol and DTLS-based security.

JSON

JavaScript Object Notation (JSON) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

Parson is a lightweight JSON library written in C. It provides full JSON support and simple API.

HTTP Parser

HTTP Parser is a parser for HTTP messages written in C. It parses both requests and responses. The parser is designed to be used in performance HTTP applications. It does not make any syscalls nor allocations. It does not buffer data. It can be interrupted at anytime. Depending on architectures, it only requires about 40 bytes of data per message stream (in a web server that is per connection).

Xively Library

Xively Library is a c library is an extremely portable way to interface your embedded product to the Xively API. For more information about xively IoT cloud platform please visit the xively developer center.

AWS IoT device SDK

AWS IoT device SDK for embedded C is a collection of C source files which can be used in embedded applications to securely connect to the AWS IoT platform. It includes transport clients MQTT, TLS implementations and examples for their use. It also supports AWS IoT specific features such as Thing Shadow. For more information on the AWS IoT platform please visit the AWS IoT developer guide.

Security Protocols

SSL/TLS

SSL/TLS are cryptographic protocols designed to provide communication security over a computer network. The embARC Open Software Platform provides support for the following implementations:

  • MatrixSSL: An embedded SSL and TLS implementation designed for small footprint applications and devices
  • wolfSSL: A lightweight, portable, C-language-based SSL/TLS library targeting IoT embedded systems
  • mbed TLS: mbed TLS (formerly known as PolarSSL) makes it trivially easy for developers to include cryptographic and SSL/TLS capabilities in their (embedded) products, facilitating this functionality with a minimal coding footprint. mbed TLS is available as open source under the Apache 2.0 license. embARC supports mbed TLS in FreeRTOS.
  • TinyDTLS: tinydtls provides a lightweight implementation of the DTLS protocol that can be used in devices with tight memory constraints, on the order of 100 KiB flash memory and about 10 KiB RAM. embARC supports tinydtls in Contiki.

Graphics

U8glib

U8glib is a monochrome graphics library for LCDs and OLEDs. It supports many different monochrome displays, a large number of fonts and well-defined C/C++ APIs. U8glib code is licensed under the terms of the new BSD license (two-clause BSD license).

YModem Protocol

fymodem

YMODEM is a file transfer protocol used between microcomputers connected together using modems.