Embedded systems are computer systems that do not look like computer systems to most people. They are hidden within and form a part of larger mechanical or electrical systems. Today more processors are used in embedded systems than in personal computers. And embedded systems are becoming smarter and more connected using wired or wireless connections as we enter the Internet of Things (IoT) age.
Embedded systems include hardware and software. The hardware typically includes a microcontroller unit (MCU), which is essentially a computer on a single integrated circuit. MCU architectures vary widely. However, nearly all contain memory (e.g., Flash memory) for storing embedded software, and one or more central processing units (CPUs) for executing instructions of the embedded software. The size of the Flash memory is limited to reduce MCU cost. The small size substantially constrains the size of embedded software an MCU can hold.
MCUs contain additional hardware such as random access memory (RAM), configuration registers, and programmable peripherals such as general purpose timers, general purpose input/output (GPIO) ports, serial communication controllers, Ethernet controllers, DMA controllers, LCD controllers, etc.
MCUs are often embedded in other machinery or products, and include embedded software specifically designed to control or otherwise interface with the specific product in which the microcontroller is embedded. As will be discussed in more detail below, embedded software can be stored in Flash memory on the MCU, after the MCU has been manufactured and sold. Thus, as can be seen from the disclosure provided herein, MCUs stand in contrast to the microprocessors used in general purpose computers or other general purpose applications.
By reducing the size and cost through the use of MCUs, particularly as compared to a design that uses a separate microprocessor, memory, and input/output devices, MCUs make it economical to digitally control many devices and processes. However, despite their many advantages particularly in the embedded space, MCUs typically have much less available memory than microprocessors because components such as the memory and CPU are built directly onto the chip. Moreover, the memory embedded in an MCU cannot easily be “swapped out” or “added to,” as is the case with the external memory devices that are typically connected to microprocessors. As such, making optimal use of a MCU's very limited memory is of the utmost importance when building embedded software for use in MCUs. Such constraints are much less significant when dealing with programs that are designed for use with microprocessors.
A software platform for embedded systems. In one embodiment, a package is received and stored in memory of a computer system. The package comprises a plurality of software components and a real time operating system (RTOS). The plurality of software components are configured to provide respective services to any one of a plurality of applications executing on a microcontroller. The RTOS is configured for direct exchange of information with each of the plurality of software components.
The present invention may be better understood in its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
The use of the same reference symbols in different drawings indicates similar or identical items.
Embedded software 102 typically includes one or more applications 106 and a software platform (also known as system software) 107 that supports the one or more embedded software developed applications 106. A software platform is an abstraction layer that hides the details an MCU. With little or no modification, software platform 107 can support application 106 on more than one of MCUs 104A-104C.
Software platform 107 includes several components that provide services or functionality to application 106 and to each other. Specifically, software platform 107 includes a system framework 108, common application programming interfaces (CAPIs) 110, qualified additional software components 112, and verified additional software components 114. All of these components can be delivered by one vendor, after the vendor extensively tests the components to insure they meet industry standards and interoperability with each other and MCU 104. Qualified additional software components 112 and verified additional software components 114 are optional components that embedded software developers can add to the software platforms they build.
Although extremely difficult and time consuming, embedded software developers could write “bare metal” software, which means an application that interacts directly with MCU hardware and without any intermediate software components like device drivers. Because embedded software development has reached a cost point and capability stand point, embedded software developers don't do this. Today developers can integrate preexisting components to create a software platform using integrated development environments (IDEs). Software platforms decouple the application development process from the underlying hardware implementations.
Vendors that supply MCUs typically provide software components for building a software platform. The vendor may also provide sample applications, which can be modified to fit the design goals of embedded software developers. In this disclosure, for ease of embedded system development the vendor (e.g. Renesas Electronics Corporation) that supplies MCU 104 can offer all components of a software platform that are needed by embedded software developers via a website. Many of the software components are developed by third party software vendors. For example, software platform 107 can include a real time operating system (RTOS) called ThreadX or a file allocation table (FAT) file system called FileX, both from Express Logic, Inc.
Prior to the creation of the systems and methods disclosed herein, embedded software developers faced a difficult task when attempting to build or modify embedded software for use in a specific dedicated product (e.g., a medical device). For instance, before any software platform could be built or modified, an embedded software developer faced a challenging task just in attempting to figure out how all of the components relate to each other. This was a particularly difficult task when components were developed by many different companies. Any modification was costly, time consuming, and inherently risky, since the modification could easily break the embedded software and prevent the proper functioning of the MCU and/or the product into which the MCU is embedded. Moreover, different MCUs are configured differently with respect to various aspects of their functionality, such as, e.g., memory, processor speed, and so forth. These variables further add to the complexity faced by embedded software developers in building or modifying embedded software to work for a given MCU
Computer 202 includes IDE 210 for building embedded software like embedded software 102. IDE 210 is an application program that executes on computer 202 and provides comprehensive facilities for software development. IDE 210 presents a single program in which most or all software development is done through use of tools that are chained together to make embedded software development easier. IDE 210 can be downloaded from server 204 and includes source code text editor, build automation tools including a complier and linker, and a debugger.
A source code editor of IDE 210 is a program executing on computer 202 for writing or modifying source code of, for example, application 106 via a graphical user interface (GUI). Source code is a collection of instructions, (possibly with comments), that is written using a human-readable programming language such as C. The present invention will be described with reference to a source code editor for writing or editing source code in C, it being understood the present invention should not be limited thereto. A higher level programming language like C is for the most part independent of an MCU's specific architecture.
Source code must be translated into binary object code before it can be executed on a CPU. A compiler of IDE 210 is a program executing on computer 202 that can translate or “compile” source code into binary object code (hereinafter object code). In contrast to source code, object code is not human-readable. Object code represents processor instructions using the binary number system's two binary digits, 0 and 1. Object code assigns a bit string to each instruction. A compiler can be configured to optimize the resulting object code for use with a particular MCU. Compilers can take into account various constraints and considerations such as limited memory that is typically available on an MCU. For example, a compiler can be configured to produce code that will run faster on a given MCU or occupy less Flash memory. The compiler of IDE 210 can compile the application 106 into an object code component. If they are provided in source code format, compiler IDE 210 can also compile software components 108-114 into object code components. A linker can used to combine the object code components into a unified executable image (i.e., .exe file). This image can be loaded into Flash memory of a test MCU of a development board 212.
Even the most experienced developers usually do not get it right on their first try. Certain errors, often called bugs, can occur in embedded software, causing it to function in an unexpected manner. For example, software being tested may crash when it tries to implement an instruction not available on the CPU, or the software may crash when it attempts to access unavailable or protected memory. Sometimes these errors are easy to fix, while other bugs are very difficult to trace. This is especially true for large software projects that consist of several thousand lines of code. Debuggers are used to test and debug code for problems. Common debuggers provide features that include the capability to examine an MCU's RAM; pausing or stopping the execution of code at defined instruction locations by setting breakpoints; single-stepping (execute one instruction at a time) through the code; and looking at a history of executed code (trace). When software crashes, the debugger can highlight the offending source code in a view if the debugger is a source-level debugger, which is commonly seen in IDEs.
With continuing reference to
All services and functions provided by MCU 104 and software platform 107, including qualified software components 112 and/or verified software components 114 added by a developer, can be accessed through CAPIs 110. Each CAPI 110 defines a high level interface of services implemented by an underlying software or hardware component, including its inputs and outputs. Application 106 can directly access registers of MCU 104 and bypass all of the CAPIs 110.
CAPIs 110 are “common” or implementation independent. Changes to an implementation does not require a change in the corresponding CAPI. To illustrate,
Each software module 302 will provide some functionality to the software component. In addition to supplying functionality (as output), a software module may also have an input requirement, or dependency, that must be met in order to work. As can be seen from the additional detail provided by
An interface defines a set of functionality that must be supported by a module 302 that adheres to that interface. In a sense, an interface provides an agreed upon “contract” between two software modules. Interfaces can be built from various data structures, such as, e.g., “typedefs,” enumerations, and macros, as some examples.
Interfaces allow embedded software developers to modify components by swapping modules in and out of a stack without having to access and/or modify the underlying code itself or the corresponding CAPI. This structure and functionality enables users to swap modules in and out to suit their needs, but without any risk of introducing bugs into (or otherwise compromising the integrity of) the software component.
Software modules that have an interface requirement must adhere to that interface. At least potentially, each module can also include a dependency, although some software modules may not be dependent on information received from any other module. If a software module has a dependency requirement, that dependency requirement will be for information received from another interface pursuant to the definition of that interface. For example, software module 302-1 is dependent on information received from interface Y, which is the interface of software module 302-2,1. Software module 302-2,1 is, in turn, dependent on information received from interface Z, which is the interface of software module 302-3. Software module 302-3 contains interface Z and thus can provide information to software module 302-2,1 according to the constraints and parameters of interface Z.
Importantly, software modules that do not “match” cannot be stacked directly on top of each other. For instance, using
As will be discussed in more detail below, the use of predefined interfaces enables software modules to be swapped in and out by embedded software developers. To illustrate, suppose framework 120-1 of
CDDs 124 create abstract functions that are used to make hardware (e.g., timers) of MCU 104 do something. CDDs 124 allow developers who aren't experts in MCU hardware to write useful applications without having to know the nitty-gritty details. This can be extremely useful for developers who work with multiple MCU hardware architectures and who need to port applications from one to another.
CDDs 124 operate based on CDD configuration information read from Flash memory of MCU 104 at runtime. In one embodiment, the MCU manufacturer writes the CDD configuration information to a designated area of Flash memory before an MCU is shipped. The designated area Flash memory that holds CDD configuration information is separate and apart from the Flash memory that receives and stores embedded software 102.
MCU 104 is one of a family of MCUs that vary in hardware features. CDD configuration information written to the designated area of Flash memory of an MCU depends on the hardware of the MCU. CDD configuration information for MCU 104A of
Each of the CDDs 124 access the designated area of Flash memory during runtime to read the CDD configuration for the CDD 124. CDD configuration information enables the “common” CDDs 124 to configure themselves into “specific” device drivers at runtime. In other words, the operation of CDDs 124 is directly dependent on CDD configuration information it reads from Flash memory during runtime. For example, a CDD 124 will operate one way when it reads a first version number for peripheral timers, and the CDD 124 will operate in another way when it reads a second version number for peripheral timers. This self-configuration enables CDDs 124 to adapt to the unique hardware resources of MCU 104. The ability to configure itself based on CDD configuration information stored in Flash memory by the MCU manufacturer makes CDDs 124 “commonly” usable on any one of the family of MCUs 104A-104C and provides advantages.
Stacks 118, frameworks 120, libraries 122, qualified additional software components 112, and verified additional software components 114 (collectively referred to as middleware components) provide services to application 106 and each other. Middleware components are often viewed as software that has been abstracted out of the application for a variety of reasons such as to allow reusability with other applications, to decrease development costs or time by purchasing it off-the-shelf (OTS) through a third party software vendor, or to simplify application code. Middleware makes it easier for software developers to implement communication, input/output, etc., so they can focus on the specific purpose of their application such as application 106. Example middleware components include TCP/IP stacks, application layer protocols (e.g., file transfer protocol (FTP), Hypertext Transfer Protocol (HTTP), etc.), WiFi stacks, etc.
Application complexity can increase when complex functional features such as wireless communication are needed, to the point where it becomes inefficient not to have an operating system to handle various tasks on behalf of the application. RTOS 116 is an operating system that can serve real-time application data as it comes in, typically without buffering delays. RTOS 116 has an advanced algorithm for scheduling tasks. RTOS 116 also has communication, synchronization, timer, memory management, and interrupt management facilities. An important difference between most embedded operating systems (e.g., RTOS 116) and desktop operating systems is that the embedded operating system and middleware components can be statically linked together with the application into a single executable, which can be stored in Flash memory of an MCU.
Software platform 107 is built from preexisting software components provided by a single vendor as noted above. The vendor, however, only provides RTOS 116 to developers via server 204, notwithstanding the fact that other, functionally different RTOS s are available and could also be provided to developers. RTOS 116 is extensively tested against the other middleware components offered by the vendor to insure interoperability. Importantly, software platform 107 is built with RTOS 116 directly coupled to middleware components and/or CAPIs 110; there is no operating system abstraction layer coupled to RTOS 116. In other words information is exchanged directly between RTOS 116 and, for example, middleware components 118-122. An operating system abstraction layer could be offered to developers, which in turn could provide the advantage of allowing developers to choose the RTOS they feel best optimizes their software project. Including an operating system abstraction layer in software platforms, however, will make the software platform slower and less compact. Perhaps more importantly, substantially more testing would be needed to guarantee interoperability of components such as middleware components of framework 108 with each of the RTOS s offered by the vendor.
Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims.
This application claims the domestic benefit under Title 35 of the United States Code §119(e) of U.S. Provisional Patent Application Ser. No. 62/239,945 , entitled “Microcontroller Development Platform,” filed Oct. 11, 2015, which is hereby incorporated by reference in its entirety and for all purposes as if completely and fully set forth herein.
Number | Date | Country | |
---|---|---|---|
62239945 | Oct 2015 | US |