SOFTWARECOMPONENTS

SOFTWARECOMPONENTS
Component-based Software Development
for Cortex-M Microcontrollers
Reinhard Keil
Director of MCU Tools
1
Software Complexity – The Challenge
Development Costs
(Industrial MCU Application)
1970
1980
1990
2000
2010
SD/MD
Connector
RS232
Driver
Ethernet
Connector
PHY
SD/MD
Card
SD/MD
Connector
RAM
MCU
BUS
Flash
Hardware Components can be easily exchanged
 Well-known issues that drive software development costs
 Increasing product requirements that are implemented by software
 Hardware problems tend to become compensated by software
 Hardware uses defined interfaces that simplify re-use
 Software components are hard to integrate
Software Standards and Software Components are key for productivity!
2
An Ecosystem is considered helpful…
Source: UBM Electronics – 2012 Embedded Market Study
3
…but Software Reuse is Limited
Source: UBM Electronics – 2012 Embedded Market Study
4
Questions when using external source code
 Usage of files (source code, header, library) is unclear





Will my Compiler and Tool Environment work?
Where is the documentation to the software component?
What other requirements (i.e. libraries or RTOS) does this software have?
Will the source code run on my target hardware?
Does the source code need adaptations or configuration?
 Project Maintenance after files are integrated



Where did I get the source code from; who to contact for support?
What is the version of that source code?
What do I need to change when I update the files?
 What are the License conditions of the code

Can I use this files in my project?
5
Packing Software is a Solution
 All software components are delivered in one
Software Pack that is easy to install (like an IC)
 A package description file (PDSC) contains:
Software Pack
Component
Libraries
Configuration Files
 Supplier information
 Download URL
 License
 Release version
Header File (API)
Documentation
Device Parameters
Flash Algorithm
Component
Component
 Usage of source code and libraries files for:
 Specific processors
 Specific microcontroller families and devices
 Tool Chains
 Other components that are required or related
6
Pack Description File Example
<package schemaVersion="1.0" xmlns:xs="..." xs:noNamespaceSchemaLocation="PACK.xsd">
<vendor>Keil</vendor>
<name>CMSIS_RTX</name>
<description>RTX is a CMSIS-RTOS compliant RTOS for Cortex-M based devices</description>
<license>License.txt</license>
<url>http://www.keil.com/demo/eval/rtx.htm</url>
<releases>
Supplier and release
<release version="4.70.0">
Updates:
- osTimerCreate can be called prior to osKernelStart (but after osKernelInitialize)
- initialization of external timer corrected for Cortex-M0/M0+/M1
- Message/Mail Queue behaviour corrected when timeout expires
</release>
</releases>
<conditions>
<condition id= "CMSIS_Core">
<description>This component requires the CMSIS CORE component</description>
Dependency
<require Cclass ="CMSIS" Cgroup="CORE"/>
</condition>
information
on other component
<!-- ARMCC -->
<condition id="CM0_LE_ARMCC">
<description>Cortex-M0 or Cortex-M0+ or SC000 processor based device in little endian mode for the ARM
Compiler</description>
<accept Dcore="Cortex-M0"/>
Dependency on core, endianness and toolchain
<accept Dcore="Cortex-M0+"/>
<accept Dcore="SC000"/>
<require Dendian="Little-endian"/>
<require Tcompiler="ARMCC"/>
</condition>
7
Pack Description File Example
<components>
<component Cclass="CMSIS" Cgroup="RTOS" Csub="Keil RTX" condition="CMSIS_Core">
<description>RTX is a CMSIS RTOS implementation for Cortex-M, processor based devices.</description>
<files>
<!-- CPU and Compiler independent -->
<file category="doc" name="Doc\index.html"/>
<file category="header" name="INC\cmsis_os.h"/>
Common files
Component Description
<file category="source" name="Templates\RTX_Conf_CM.c" copy="true"/>
<!-- CPU and Compiler dependent -->
<!-- ARMCC -->
<file category="library" condition="CM0_LE_ARMCC"
name="Lib\ARM\RTX_CM0.lib"/>
<file category="library" condition="CM0_BE_ARMCC"
name="Lib\ARM\RTX_CM0_B.lib"/>
<file category="library" condition="CM3_LE_ARMCC"
name="Lib\ARM\RTX_CM3.lib"/>
<file category="library" condition="CM3_BE_ARMCC"
Files with processor dependencies
for ARM Compiler
name="Lib\ARM\RTX_CM3_B.lib"/>
<file category="library" condition="CM4F_LE_ARMCC" name="Lib\ARM\RTX_CM4.lib"/>
<file category="library" condition="CM4F_BE_ARMCC" name="Lib\ARM\RTX_CM4_B.lib"/>
<!-- GCC -->
<file category="library" condition="CM0_LE_GCC"
name="Lib\GCC\libRTX_CM0.a"/>
Files with processor dependencies
<file category="library" condition="CM0_BE_GCC"
name="Lib\GCC\libRTX_CM0_B.a"/>
for GCC Compiler
:
<!-- IAR -->
:
<file category="library" condition="CM4F_LE_IAR"
Files with processor dependencies
name="Lib\IAR\RTX_CM4.a"/>
for IAR Compiler
<file category="library" condition="CM4F_BE_IAR" name="Lib\IAR\RTX_CM4_B.a"/>
</files>
</component>
</components>
</package>
8
Pack Installation and Updates
Web Page #1
Pack
*.PDSC
Pack
*.PDSC
Pack
*.PDSC
Pack
Installer
access protection
Development Tool
and
Project Environment
Web Page #2
Pack
*.PDSC
Pack
*.PDSC
*.PDSC
access protection
Pack #2
local files
 Pack Installer copies relevant
files of a PACK to tool/project
environment
 *.PDSC file contains web URL
for initial download & update
9
MDK-ARM Version 5 – Overview
 MDK-ARM Core: contains development tools
MDK Core
µVision IDE with Editor
ARM C/C++ Compiler
Pack Installer
µVision Debugger with Trace
Software Packs
Device
CMSIS
MDK Professional Middleware
Startup / System
CMSIS-CORE
TCP/IP Networking
File System
CMSIS-DSP
USB Host Stack
Graphical User
Interface
CMSIS-RTOS
USB Device Stack
CAN Interface
Driver 1: SPI
Driver 2: Ethernet
…
Driver n: USB
 Software Packs: contain device support & middleware
 Installed & updated on demand using the Pack Installer
10
Component Example: TCP/IP Networking
Compact
Web Server
Full Web Server
FTP
TFTP
Telnet
using File System
Server
Server
Server
DNS
SNTP
FTP
TFTP
SMTP
Agent
Client
Client
Client
Client
Client
TCP
UDP
BSD
Ethernet
PPP (Serial)
SLIP (Serial)
Driver
Socket
SNMP
Interface
Service
Network Component
Ethernet MAC
UART
Ethernet PHY
 TCP/IP Networking Components
 Easy customization of application requirements
11
CORE
Variants:
• Debug
• Release
Component View in MDK-ARM
The Run-Time Environment is
created by selecting available
software components
12
Dependencies and conflicts
between components can be
automatically resolved
Design with Software Components
1.
Explore available Software Components from the installed Software Packs
MDK Pro Middleware
Middleware
Device
CMSIS
Startup / System
CMSIS-CORE
TCP/IP Networking
File System
SQLite
CMSIS-DSP
USB Host Stack
Graphical User
Interface
Motor Control
CMSIS-RTOS
USB Device Stack
CAN Interface
WiFi Stack
3rd Party
Driver 1: SPI
Driver 2: Ethernet
…
Driver n: USB
2.
Choose components and create a configurable Run-Time Environment (RTE)
3.
Develop application in C/C++ using the APIs of RTE components
13
Using external source code needs Standards
What is required to use standard Software Components on Microcontrollers?
 Standard Processor Architecture

ARM Cortex™-M series ensure a compatible target processor and provide
common core peripherals (i.e. NVIC interrupt system, SysTick timer)
 Programming Standards on ARM Cortex-M series already provide






Consistent Code Generation and Parameter Passing (ARM EABI)
ABI for Special Processor Instructions and Core Peripherals (CMSIS-CORE)
Guidelines for definition of Peripheral-Registers & Interrupts (CMSIS-CORE)
A rich set of optimized DSP Functions (CMSIS-DSP Library)
A standardized RTOS Kernel API (CMSIS-RTOS API)
APIs and Drivers for Peripherals are provided by Silicon vendors
 But have problems: RTOS interface, DMA, Interrupt, Low-power modes ...
 Inconsistent APIs across silicon vendors
14
USER
CMSIS-Drivers: Structure with Drivers
Application Code
Middleware
CMSIS
(3rd Party)
CMSIS-DSP
CMSIS-RTOS
Drivers
DSP-Library
API
(unified)
Real Time Kernel
(3rd
Templates
Device HAL
(Silicon Vendor)
Party)
CMSIS-CORE
SIMD
Cortex-M4
MCU
Templates
Cortex
CPU
Core Access Functions, Peripheral & Interrupt Definitions
SysTick
NVIC
RTOS Kernel
Timer
Nested Vectored
Interrupt Controller
15
Debug
+ Trace
Other
Peripherals
CoreSight
Consistent Driver APIs for Peripherals

Device Pack
RTE_Device.h
Configuration File
Startup / System
UART Driver
Each driver module provides one or more
drivers for a specific peripheral type
 Devices may offer several peripherals of same type
 Driver is configurable to use interrupt and/or DMA
 Driver uses CMSIS-RTOS functionality to
synchronise interrupt and DMA events
SPI Driver

NAND Flash
Driver
Each driver is accessed by a control structure
containing control and data functions
 Each driver provides the functions:
NOR Flash
Driver
Initialize, Uninitialize, and PowerControl
Other functions are specific to the peripheral type
MCI: Memory Card
Interface Driver

USB Device
Driver
USB Host
Driver

The RTE_Device.h file centralizes the
configuration for all drivers
 RTE_Device.h could be controlled by a configuration
utility.
Ethernet Driver
16
Drivers: Potential Design Flow
1.
Device Pack
RTE_Device.h
Configuration File
Startup / System
Define Peripheral Pin Assignment and
Configure Peripherals
UART1
UART Driver
SPI Driver
SPI2
SPI3
Ethernet Driver
RMII
MCI: Memory Card
Interface Driver
NAND Flash
Driver
NAND
NOR Flash
Driver
USB Device
Driver
USBH1
USB Host
Driver
USBD2
17
Configuration creates control structures
Drivers: Potential Design Flow
1.
Device Pack
RTE_Device.h
Configuration File
Startup / System
Define Peripheral Pin Assignment and
Configure Peripherals
UART1
UART Driver
SPI Driver
SPI2
SPI3
Ethernet Driver
RMII
MCI: Memory Card
Interface Driver
NAND Flash
Driver
NAND
NOR Flash
Driver
USB Device
Driver
USBH1
USB Host
Driver
USBD2
18
Possible vendor Config Tool integration
Drivers: Potential Design Flow
2.
Device Pack
RTE_Device.h
Configuration File
Startup / System
Assign Middleware to Peripherals by
selecting the right control structure
UART1
UART Driver
SPI Driver
SPI2
SPI3
Ethernet Driver
RMII
Middleware
Graphical User
Interface
File System
MCI: Memory Card
Interface Driver
NAND Flash
Driver
NAND
NOR Flash
Driver
TCP/IP Networking
USB Device Stack
USB Device
Driver
USBH1
USB Host
Driver
USBD2
19
USB Host Stack
Drivers: Implementation & Optimization

Driver functions are accessed via a struct
 Pre-configured drivers (or middleware) may reside in on-chip ROM
typedef struct DRIVER_SPI {
DRV_VERSION (*GetVersion)
(void);
SPI_CAPABILITIES (*GetCapabilities)(void);
SPI_STATUS (*Initialize)
(SPI_SignalEvent_t cb_event);
SPI_STATUS (*Uninitialize) (uint32_t slave);
SPI_STATUS (*PowerControl) (POWER_STATE state);
SPI_STATUS (*Configure)
(uint32_t slave, SPI_FRAME_FORMAT frame_format,
SPI_BIT_ORDER bit_order);
uint32_t
(*BusSpeed)
(uint32_t slave, uint32_t bps);
SPI_STATUS (*SlaveSelect)
(uint32_t slave, SPI_SS_SIGNAL ss);
uint8_t
(*TransferByte) (uint8_t out);
SPI_STATUS (*SendData)
(const uint8_t *buf, uint32_t len);
SPI_STATUS (*ReceiveData)
(
uint8_t *buf, uint32_t len, uint8_t out);
SPI_STATUS (*AbortTransfer) (void);
} const DRIVER_SPI;


Driver implementation uses CMSIS-RTOS
 Synchronisation via Semaphore or Mail/Message passing
Optimal implementations use interrupts and DMA
 Configuration options are stored in RTE_Drivers.h
20
Drivers: Function Call Sequence
Function Call Sequence

Drivers provide common functions, even for power control
 After initialization, drivers are in power-off mode (minimal power consumption)
 Before using “transfer” functions, power-on mode must be activated
 “transfer” functions may cause thread switches







GetVersion (optional): middleware may use this to insure a certain driver
GetCapabilities (optional): implemented capabilities may differ;
middleware can adjust to implemented functionality
Initialize: allocate memory, reserve RTOS & peripheral resources,
register (optional) call back events
PowerControl: put the peripheral into low-power (to detect events) or
power-up (to transfer data) mode
Transfer: receive or transmit information; buffers are available after the
call to hold new data
PowerControl: put the peripheral into low-power (to detect events) or
power-off (to stop operation) mode
Uninitialize: release resources consumed by driver
21
User Benefits: Component-based Approach
 Faster development of complex projects



Software components are selected with a mouse click from a library
Clean overview of available software components relevant to a device
RTE Manager identifies component requirements and connects to device drivers
 Components are separate and give a clean view to application code



Libraries: not copied to the project folder; separate of the project
Configuration files: accessed as part of a component; stored separate from application
code
Version control: Select a specific version of a component
 Help System integrated provides painless reading of user manuals

Easy access to the API documentation of a component
 Easy adaption to new project requirements


Software components can be added or removed any time; project is kept up-to-date
Devices can be changed quickly; RTE Manager selects device-relevant software
components
22
Thank you!
23
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement