(Editor’s Note : In this Product How-To article , Harrold Spier and Ulrich Kloidt of Altium explain the importance of effective network aware software development tools in the age of the Internet and machine to machine devices and how the company’s Software Platform Builder can help in achieving that goal.)
Thirty or more years ago the Internet (then Arpanet), just broke through the 1000 node mark. Today billions of people and devices worldwide are connected, be they PCs, mobile phones, or Machine-to-Machine (M2M) devices. The big challenge – especially with M2M – is in extending this network to communicate with human beings or other devices without the need human interaction.
The number of applications which can benefit from this unhindered, automatic device-to-device communication is growing exponentially. Embedded applications often have limited resources regarding memory, CPU speed and power supply. Single-purpose designs might indeed have a decent user-interface, but even in those cases it’s almost always necessary to optimize power, CPU and memory usage to a minimum.
Whether the design uses wired or wireless connectivity, the trade-off remains between fine-tuning the embedded software for optimizing power and performance, versus getting the product out the door quickly. Additionally, it is desirable to re-use as much previously optimized code as possible. Modern developers do not have time to struggle with writing low-level functions and headers for peripheral drivers or communication protocol stacks.
Tools are needed which can facilitate this kind of rapid-but-optimal software development to allow the embedded developer to focus on what’s really important, their secret sauce: their application. Altium’s Software Platform Builder provides the necessary stacks in the familiar Eclipse IDE to allow this rapid development of IoT embedded applications.
What is it all about?
In retrospect some questions seems so obvious. And the idea for the Software Platform came with one: why does embedded software development take so much more time than developing a similar desktop application?
This seems a legitimate question, asked by many embarking on their first embedded coding project. Simply showing “Hello World!” on the LCD display of an embedded evaluation board requires a surprisingly large amount of effort. Driving the LCD, converting characters to pixels, keeping track of the cursor, etc. – nothing seems to work automatically. And even if convenient libraries are available, for example for TCP/IP communication, then there is still a lot of work to be done to make the new code fit into the application and to configure it correctly. This cycle often repeats itself for every new project.
These challenges motivated us to come up with what we now call the Software Platform. The basic concept is quite simple. Put generic software components in a repository and provide them with a uniform interface. Assure the software components can be configured in a standardized manner. This way, one does not have to know how each component is built up internally. Because of the unified interface, components can easily work together. A graphical environment presents the software components as coloured blocks. Required blocks are picked from the repository to create a starting point for the application. Components can be configured to match the application's requirements and relationships between selected components can be specified.
The Software Platform Builder is all about integration of content. It is not the content itself that makes it so special. Much of the current content comes from third parties and can be downloaded freely from the Internet.
But creating an application with a bunch of collected software components is not so easy. That is where the Software Platform is helpful. It provides the content in a way they can work smoothly together. All components can be configured in a similar way. And that combination creates the possibility to build reliable applications rapidly.
A Software Platform Builder for ARM Cortex-M CPUs
As it now stands, Altium’s Software Platform Builder is targeted for the creation of ARM Cortex-M CPU based applications. The Software Platform itself includes various software modules which are added to the application code if needed, like RTOS facilities, peripheral access and communications protocols. The Software Platform is both a graphical editor and a code generator. Collections of software modules are delivered as Software Platform repositories.
The repository may contain any kind of software, but typical modules include interrupt services, timers, peripherals (hardware wrappers), drivers, kernel services (such as POSIX multithreading), device I/O, file system (FatFs), networking (TCP/IP), graphical user interface, etc.
To make it even easier to get started, a large number of Software Platform reference projects for various STM32 evaluation boards are included, which utilize the available peripherals of the different boards.
Altium’s Software Platform repositories can contain numerous software modules that take care of lower level software routines as well as modules that offer extra functionality by providing the user with a convenient API. The Software Platform consists of device stacks and software services.
Device stacks (Figure 1 ) are all about making hardware peripherals available to application code through abstract and generic software interfaces. By placing more or less modules on a stack, the abstraction level which should be used in the application is specified. The lowest level modules are specific for a particular hardware device. On top of that, higher level modules can be added which provide more generic functionality to access the device.
For example, at the higher, abstract level a module to access a file system in the application can be selected. At the lower levels it is still possible to select modules to decide which specific storage device is accessed (a hard drive, SD card, RAM drive, etc.). Thus, the lower level modules are more specific for a particular peripheral while the higher level modules are less hardware specific and can even be used in combination with multiple peripheral devices.
Peripheral modules. Peripherals (the green stack items) are the lowest level modules. They provide information for the higher layers of the stack to access the peripherals. Information such as the base address and interrupt assignment is stored in the peripherals. In most situations, an application does not access the peripherals directly, because the application accesses them through the driver's interface on top of it.
Driver modules. Drivers (the yellow stack items) provide the next level of abstraction. They provide low-level access to specific hardware either via a peripheral or via another driver. The difference between a driver and a peripheral is well defined. The peripheral only defines basic information about the hardware but provides no further functionality. This basic information can be used by a driver which is placed on top of the peripheral. Drivers are hardware specific and so are the interfaces they offer. Hence, if the application contains code that accesses a driver's API, it will be hardware dependent. Drivers still operate at a low abstraction level, and using a device at the driver level requires knowledge of that particular driver's interface.
Some drivers are available as library wrappers. They only offer an initialization routine which is called from an application in order to configure pins, clocks and registers. After this initialization the peripheral driver libraries from silicon vendors can be used.
Stack services. Stack services (the blue stack items) are the most abstract layers of functionality. Stack services provide standardized, hardware independent access to devices. Stack services ensure the portability of an application. For example, if the application uses a generic TCP/IP service, it remains the same if Ethernet is replaced with PPP and serial. A portable TCP/IP application works exactly the same, whether linked to a UART or to an EMAC peripheral, since the Software Platform handles the lower level details.
Figure 2. Software services
Software services. Some services are static and not meant to be instantiated. They have no (direct) relationship with peripherals or other services and facilitate common functionality like POSIX multithreading, CMSIS, software timer or interrupt management support. The software services may also be added automatically if they are required by other services.
It takes just a few steps to integrate the Software Platform into an Eclipse based TASKING ARM Cortex tools project. First the Software Platform document needs to be added to the project. The required Software Services and Device Stacks are appended using the 'Add' menu (Figure 3) by enabling the related check box
Figure 3. Add Software Services and Device Stacks.
After a Device Stack has been selected in the Software Platform document the available stacks (for the device can be chosen using the Grow stack up or Grow stack down option. Figure 4 below shows the stack items for the USART interface.
Figure 4. Stack items for the USART interface.
Device stacks can be configured by changing the options in the Properties view (Figure 5 below)
Click on image to enlarge.
After the Software Platform is configured, all C files and header files which belong to the devices used are added (copied) to the Eclipse project. If device parameters are changed, the project files can be updated by selecting the 'Generate Code' button.
From within the source code of the embedded project the Software Platform functions are called like other C functions. The assignment of the functions, their parameters and also data structures used (if applicable) are described in an online API help. Figure 6 shows a list of the available functions and structures for the HTTP configuration.
Figure 6 . HTTP functions necessary for configuration.
Software Platform Builder components for IoTs
The Software Platform repository contains several components especially interesting for creating IoT applications. Since the whole Internet is based on TCP/IP networks, a TCP/IP stack service seems a necessary requirement to be able to communicate over the Internet.
The TCP/IP protocol can be on top of an Ethernet layer but there is also the possibility to communicate wirelessly (by using a WiFi USB stick) or over a serial connection using the Point-to-Point Protocol (PPP). This could be a serial cable but also a modem connection, a GSM data connection or even a GPRS connection.
On top of the TCP/IP stack the HTTP stack service can be added which, in IoT context, is frequently used for Representational State Transfer (REST). Another benefit of the HTTP service is the ability to support HTTP Secure (HTTPS).
Secure communication is important when the application handles sensitive information. It provides encrypted communication to prevent eavesdropping and secure identification of a network web server to know which web server it is really talking to. Some open API's, like the latest Twitter API, do not even accept non-secure communication anymore.
Harrold Spier is senior software engineer at Altium. He joined Altium Europe GmbH in 2001 and has over 20 years’ experience in embedded software design and product development. Ulrich Kloidt is senior support engineer at Altium Europe GmbH.