Hitex ARM Conference Future Proof Software Introduction HCC is in - - PowerPoint PPT Presentation

Hitex ARM Conference

Future Proof Software

Introduction

HCC is in a fairly unique position

• Broad range of reusable software components for peripherals
• USB, Flash, Networking, Bootloaders, File Systems
• RTOS agnostic and as a consequence support at any time….

CPU compatibility across ARM cores does not help with peripherals

> 10 tool-chains > 100 microcontrollers > 15 RTOSes

Typical Embedded Scenario

• Every new project requires the use of files, templates

and methods from different sources

• ie compiler, hardware abstraction, middleware, libs etc.
• This can lead to an unstructured development

environment which is difficult to carry forward with guarantees of quality and correctness to the next project.

• Undesirable to change core code. Better to change

peripheral code to meet an interface standard

• There are attempts such as CMSIS to deal with some

aspects of peripheral portability

Advanced Embedded Framework

• AEF developed by HCC to deal with changing environments
• All code clean of anything specific to one environment
• Modules re-used without modification

PROJECT

Dev Board Tools MCUs Software Components

Future Proof Embedded Software

Portability Issues Approach

• API
• Includes
• Version checks
• Configuration

Implement Source Tree Management Establish Module Development Guidelines

• Version checks
• init/start/stop/delete
• External resource management (mutex/event/task)

Module inter-Dependency Management

• API
• Register access
• Configuration
• Drivers

Develop Reusable Peripheral Interfaces

• Pre-emption
• Endianess
• Types
• Timers
• Cache
• Memory Allocation
• Error handling

Platform Independent Module

TCP/IP API Config Version

Framework Overview

Source Tree Module Guidelines MDM Peripheral Interfaces OS AL PSP Toolchain Embedded Target Software Components

Source Tree Management

Module Development Guidelines

• Typically software from multiple sources is used in every project –

legacy/libs/middleware/hal/rtos/etc

• Usually developed either ‘freestyle’ or to different standards
• C language has known deficiencies

Ambiguity Quality Increased dev cycles Portability

Module Development Guidelines

• These problems are universal and attempts to address have resulted in

various attempts to harmonize approach to coding

• At HCC we have taken a rigorous systematic approach to future proof
• ur software since s/w developed to the highest standard can be re-

used in any environment from ‘freestyle’ to safety or certification

Coding standards Language definition C99 MISRA Etc

Code from Different Sources

• Approach does not obviate the need for 3rd party software written to differing

standards choice is either………………

• In either case the rules for approaching this problem are clearly defined and

consistent

• This strongly typed subset of C is akin to a new language. When developers

learn it they are happier that they can meet goals without ambiguity and it is no more difficult or time consuming than ‘freestyle’ coding.. rewrite legacy/lib to required standard abstract legacy/libs

Re-usable Peripheral Interfaces

• Software can only be reused without modification if external interfaces are

consistent => driver interface must conform to desired standards

• all supporting components are designed to expose interfaces that are

consistent with any quality standard to be reached.

• Wrapper layers could be used to achieve some of these goals on an ad hoc

basis. There are drawbacks to this approach – it obfuscates the design and the code and is difficult to standardize. The more you add the worse it gets. And it is not necessarily easy to use a wrapper layer in projects requiring a higher level of quality.

Traditional Approach

Conclusion

• We have tried to present some of the core issues involved in building a

development environment suitable for the production of high quality embedded products

• Reusability of
• software elements
• learnt techniques.
• There are, of course many more elements to this – and in an upcoming

webinar we will take this model much further by describing a complete development process for managing high reliability projects – suitable for use in safety environments

thank you – questions ?