Author: Giancarlo Parodi, Renesas Electronics Europe<\/p>\n
When selecting commercial software, it is expected that the supplier has qualified it, tested it according to commercial standards, and ensure compatibility with the target microcontroller platform. This presentation will introduce the concept of an integrated software package that includes a real-time operating system, optimized stacks, application software, drivers, and configuration packages for hardware platforms. All of these components have been developed, integrated, and tested according to the IEC\/ISO\/IEEE 12207 standard.<\/strong><\/p>\n The complexity of today's networked, embedded systems has increased many times over compared to the past. Developers must invest significant time in providing basic functionalities: designing device drivers and middleware, integrating a real-time operating system, and potentially utilizing cloud-based applications. A well-developed software architecture is a key factor in enabling smooth development and testing, especially when multiple interconnected modules and protocol stacks are required.<\/p>\n The microcontroller manufacturer provides software, often in the form of an "application note" or "example." Developers can obtain this software free of charge and use it with a product from that manufacturer. However, the manufacturer assumes no responsibility for the features and behavior of this software, which is usually explicitly stated in the copyright notice. The phrase "provided as-is" is a typical way of shifting the responsibility for developing and testing the software entirely onto the user.<\/p>\n Very often, such software modules offer simple functionality and are therefore helpful for basic testing of a single peripheral device; however, they are not suitable for seamless integration into a more complex application. Furthermore, potentially more complex middleware protocols are neither provided in their entirety nor as tested software. This increases the risk of incompatibilities when integrating software packages from different sources, further complicating the evaluation and testing process.<\/p>\n Other difficulties arise when one of these software modules is updated by the software manufacturer. This update is not verified against other software packages, and the entire system must therefore be retested as soon as one of the components is replaced with a newer version or individual corrections to the error-prone software need to be made with a so-called "software patch".<\/p>\n The commercial barriers are also relatively high because in such a scenario it becomes difficult for software manufacturers to understand or be willing to trace any problems with their modules once these are integrated into a more complex, customer-specific application.<\/p>\n So what options are available to developers that can make their lives easier? There are various aspects related to tools, systems, and software architectures that can help reduce development time, minimize optimization and testing efforts, and ultimately lead to an application that is easier to manage in the future.<\/p>\n Starting with the tool landscape \u2013 the most widely used is still the "C" programming language. There are different versions of this standard; the recommendation is to use at least compilers that support the ANSI C99 standard. This offers several advantages, such as the ability to use... and Designated initializers, the ability to mix program and variable declarations, and other features are helpful for ensuring that all components of a structure can be assigned a certain value without having to adhere to a strict order. They also ensure that variables are only defined in the program when needed. Using enumeration types is also recommended to give the compiler better access to function parameters at compile time and to make the application more understandable for the developer through these mnemonic symbols.<\/p>\n Applications for embedded systems often require deviations, optimizations, or extensions to the programming standard. These are typically provided by each compiler vendor, but their use should be avoided or minimized whenever possible to reduce the associated dependencies. Sometimes, the use of such extensions is not entirely compatible with other development standards like MISRA and should therefore always be documented, especially if device certification is required.<\/p>\n Documenting the software is also an important aspect that is unfortunately often neglected, especially in the early stages of a project. Programs like "doxygen" automatically generate documentation from the comments embedded in the software. This can be a great help in keeping the documentation consistent with the software and reducing the effort required to generate it.<\/p>\n Agile programming techniques are now fundamental to modern application development. In a more traditional approach, different phases would occur sequentially \u2013 starting with defining a specification and then the software concept, followed by implementing the functionality, testing the application, and finally, at the end of the process, introducing a maintenance phase. In such a concept, each phase is more or less completed before the next one can begin.<\/p>\n In contrast, the principles of an "agile" approach stipulate that functional software modules are delivered within days or weeks instead of months. To achieve this, close collaboration between the requirements and implementation phases is essential, along with rapid adaptation to constantly changing specifications. Developers use short daily meetings to summarize project progress and address any implementation issues.<\/p>\n An "agile" process involves first identifying functional modules. These are then broken down into shorter "action streams" and evaluated according to their complexity. These are further broken down into even shorter tasks, and each task is then assigned to a developer. The time allotted to complete this task ("sprint") is usually quite short, for example, two weeks. At the end of this time, a development cycle is complete, the developer delivers their specific software module, and the process repeats (see figure "Agile Development Workflow").,\u00a0PDF<\/a>).<\/p>\n These short iterations make it possible to estimate the project's completion time and measure the speed of project progress during the development phase. This is crucial for identifying delays early and resolving related issues as soon as possible. In such cases, a project management tool like Atlassian Software's Jira can provide a robust infrastructure to enable agile development.<\/p>\n A common problem is that developers often lack a suitable hardware platform at the start of a project, yet still need to begin software development as early as possible. In such cases, tools like "CMock" can help. This allows developers to simulate and test modules at a functional level. A so-called "mock object" can represent the behavior of a hardware interaction using a software-based alternative, thereby providing that functionality.<\/p>\n Once the actual hardware platform is available, the developer can easily replace this simulated version with the real one. Naturally, this simulation must be validated, but at a functional level, the module has already been tested thanks to the "CMock object." Therefore, verifying the software's behavior can focus solely on hardware-related issues.<\/p>\n \u201eCMock is a natural companion to Unity, a C program designed for testing individual software modules. The two work very well together and are fundamental pillars of test-driven development (TDD; see figure "Developing Without Hardware").,\u00a0PDF<\/a>).<\/p>\n Following this process, the tests for verifying the functionality of a software module are defined and documented before its implementation. This allows the specification to be reviewed to ensure it conforms to the requirements. The module implementation will then be the simplest, ensuring it successfully passes the defined tests.<\/p>\n The main challenge lies in generating a set of tests that comprehensively examines the module's various functions from all angles and verifies them independently of the implementation. The advantage of this approach is that the implementation can be kept minimal, resulting in a simpler solution to the problem. This more efficient method also simplifies future software management. Furthermore, the ever-increasing number of tests, which can be automatically executed with every change, ensures that any problems or unintended side effects unintentionally introduced after an implementation change are quickly identified through automated testing.<\/p>\n Within a larger group, the question then arises of how collaboration among developers can be structured. Fortunately, there are professional tools like Atlassian's "Bitbucket" or "Mercurial" for this purpose. These can connect to other tools like the well-known "GIT" as a graphical user interface and simplify file version control.<\/p>\n To complete the picture of the tool landscape: there are additional options that can be successfully used. Programs like TeamCity are very well suited for the continuous integration of software modules and support an automated testing process that is initiated with every saved change in the software. Furthermore, Scons supports the generation of multiple versions of a software for different compiler environments or hardware platforms. The LDRA tool can be used to perform static program analysis and check consistency with other development standards and rules, such as those specified by MISRA-C. This same tool can also perform dynamic analysis to check implementation coverage with each test call, ensuring that all functions are utilized and that there are no unused parts of the software module.<\/p>\n All such programs are the fundamental building blocks that are relevant to enabling automated testing and the associated reporting, with the aim of freeing the developer from these tasks and giving him more time to pursue his main responsibility: writing efficient and well-designed software.<\/p>\n What might a process for defining a good and efficient software architecture look like? A modular concept is a natural consequence of the need to partition a complex problem into a set of simpler elements. A software element can be readily identified by a module and its interface. This reduces module dependencies, minimizes software maintenance effort, and enables individual module testing.<\/p>\n The IEC\/ISO\/IEEE-12207 standard (\u201eSystems and software engineering \u2013 Software life cycle processes\u201c) is a great help in defining the development flow, as it requires the specification of requirements, form and test procedure.<\/p>\n How can a "module" be defined in practice? A module is a basic building block related to the concept of providing and requesting services. This makes it possible to assemble a hierarchical and flexible solution. Some modules might not require services from child modules but will always provide services to parent modules; parent modules might combine and use multiple services from child modules. Once a module is identified, the problem arises that the application might use different modules for a specific purpose, all offering similar functionality. How can different implementations be supported in the software architecture? (See figures on page 6.),\u00a0PDF<\/a>).<\/p>\n The disadvantages are that often both the programming interface (API) and the implementation are not the same. There is a risk of introducing errors into the program during the modification process.<\/p>\n A second option could support both modules (see figure on page 7).,\u00a0PDF<\/a>However, this involves more effort because the changes must be implemented at every point where the module is used. The function parameters will most likely differ, and a performance decrease is to be expected due to the conditional execution of the function calls. A more elegant solution is to introduce an "interface." This "contractually" defines which options and functions a given module provides (see figure on page 8).,\u00a0PDF<\/a>).<\/p>\n To use this module, the application must generate an "instance" of it. An instance is an object that encapsulates everything necessary for using the module: a reference to its control structure (similar to a "this" or "self" reference found in other programming languages), a configuration structure, and a set of function calls (APIs) that support the interface to access the mode's services.<\/p>\n The configuration structure typically contains the common parameters relevant for that type of module (for example, for an I2C module: an I2C channel number, the maximum transmission speed, the bus address, and the address depth; see figure on page 8).,\u00a0PDF<\/a>).<\/p>\n For modules that communicate directly with the hardware, there is an additional need to define a function that is called when the hardware needs to notify the application of an event (a "callback" function), for example, when there is a change in the state of the peripherals or when new data becomes available.<\/p>\n This function is called in connection with an interrupt event and is able to provide a context to identify the trigger of this event (see figure on page 8).,\u00a0PDF<\/a>).<\/p>\n Defining the APIs within the interface allows for easy module replacement by assigning it to a different instance\/implementation. This makes it possible to interact with the module using a unified interface (see figures on page 9).,\u00a0PDF<\/a>).<\/p>\n Any change only requires replacing the reference to the current instance. This makes it easy to support new future implementations using the abstraction layer that enables the API definition (see figure on page 9).,\u00a0PDF<\/a>).<\/p>\n Any special function unique to a particular module, beyond the common functions for that module type, can be placed in an extension field within the structure; this can be used in the context of the module during its initialization (see figures on page 10).,\u00a0PDF<\/a>).<\/p>\n All these approaches can contribute to developing a robust, modular, and well-tested foundation for embedded software. From the developer's perspective, however, this effort has so far addressed a rather manageable portion of the overall application, likely focused on the driver level (see figure on page 10).,\u00a0PDF<\/a>).<\/p>\n However, the application consists of several parts and includes software for the hardware-level configuration of the board, presumably a real-time operating system (RTOS), complex software stacks for USB or Ethernet functionality, and possibly some function-related modules (framework) that combine the basic blocks to provide more complex functions to the application.<\/p>\n The problem the developer has to solve is still considerable. They must integrate several modules to define the board configuration and application services, test these as units, then place the modules in an RTOS and test them again in the RTOS environment (using JTAG-based debugging and tracing tools). For graphics applications, the developer must first implement the application's appearance on the PC and then integrate it into the system using a graphics library. If communication interfaces are required, integrating USB or Ethernet stacks could consume additional time. Furthermore, these application layers must then be tested against each other at a higher level.<\/p>\n Overall, bringing software development to the application level requires significant time and resources. Additional costs, not immediately apparent, arise from training, technical support, administration, optimization, and software integration.<\/p>\n To benefit developers and reduce the overall cost of a project, Renesas introduces a revolutionary software platform concept called Synergy. The delivered software is called the Synergy Software Package (SSP).<\/p>\n This software package contains many modules that provide all the necessary functionalities: peripheral drivers for low-level programming, application frameworks, the well-known and robust RTOS ThreadX, the matching middleware stacks (NetX, USBx) for connectivity via USB and Ethernet, FileX to use FAT-compatible file systems, GuiX and a PC tool called GuiX Studio to create graphical applications, and the PC-based TraceX tool to test the runtime behavior of an RTOS application using a non-invasive trace application.<\/p>\n Each of these modules can be used in an end application without modification. They were all developed or integrated according to the modern industry-standard practices mentioned earlier in this article. The SSP can be used for a completely new family of microcontrollers, which are available for all derivatives via a compatible API interface.<\/p>\n This software is provided by Renesas as a product. Therefore, Renesas is committed to developing new versions and improvements to the software in the future and to managing and maintaining these for the Synergy platform (see illustration on page 11).,\u00a0PDF<\/a>).<\/p>\n These modules are qualified and tested by Renesas and are guaranteed based on the associated software datasheets and user manuals. Renesas, as the sole point of contact, assumes responsibility for the functionality and quality of the software (see figure on page 11).,\u00a0PDF<\/a>).<\/p>\n Renesas used industry standards, tools, and processes (IEC\/ISO\/IEEE-12207) in the software development process to ensure high quality. These procedures include project management, configuration management, coding standards, testing and quality assurance, and continuous integration.<\/p>\n In addition, the user is provided with the documents and information to validate the specification and quality of the SSP software package, including test data if desired. Thanks to this revolutionary software approach, the software engineer can drastically reduce development and testing time.<\/p>\n This allows him to spend more time developing innovative products and to focus on what is most relevant to the success of the project: delivering added value at the application level.<\/p>\n Renesas Synergy<\/a> Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topic of implementation\/embedded and real-time software development.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in the field of implementation\/embedded and real-time software development is available.\u00a0here\u00a0<\/strong><\/a>Available for you to download free of charge.<\/p>\nReferences<\/h2>\n
\nAtlassian Jira<\/a>
\nAtlassian BitBucket
\nCmock
\nUnity
\nMercurial<\/a><\/p>\n
\nImplementation \u2013 our training & coaching<\/h2>\n
\nImplementation \u2013 Expertise<\/h2>\n