Keeping your code footprint small for Arm Cortex M0/M0+ Applications
Processors using Arm Cortex M0/M0+ cores typically have a limited amount of memory, necessitating efficient, compact application code. So, a small code size becomes an absolute necessity.
The first approach an embedded developer might consider is to “strip down” an RTOS, but even with a drastic pruning of unwanted functions, the resultant code would most likely still be a complete overkill in terms of size and complexity.
The other thing to consider is the time and effort required in creating the documentation covering the changes made to the RTOS configuration. The end-result could easily be an undocumented, unsustainable solution. Imagine stripping-down a Rolls-Royce to create a small, agile go-kart – you should have got a go-kart in the first place!
The next approach a developer might then consider would be to write the entire application code from scratch, and because of the relative simplicity of Arm Cortex M0/M0+ applications, it’s tempting to think “I’m only using a small processor and I just need to get on with writing my code”. This is understandable, but it will still be hard, laborious work, even for a relatively simple architecture such as Super Loop, to take one example.
Also, the time spent on thorough testing and debugging is often not considered. Not to mention the documentation required to make life easy for another developer to take over when the original developer leaves the company.
The best approach to developing the application code would be to would be to write an “Application Framework”. What exactly is this type of framework? Embedded systems typically consist of application-specific code sitting on top of a Library of lower-level functions code (Services). The Services provide a Framework of support for a particular software architecture, including passing data between execution entities, synchronizing with events, allowing time-based events and more. Application code calls on the Services to achieve a desired system behavior.
So, an Application Framework is a Library of Services than can be called upon to enable the different aspects of behavior that the application requires. These standard Libraries can be called up time and again, supporting different parts of the application program. As explained above, these Libraries are time-consuming to write and the developer will also need to carry out extensive testing and debugging, and write comprehensive documentation.
The Novos family of five Free, pre-packaged Application Frameworks offers a convenient solution. To state things simply, Novos plugs a gap in the market by providing five tiny, time-saving “oven-ready” real-time Application Frameworks. Current RTOS or Kernel products are not suited to applications using small CPUs like the Arm Cortex M0/M0+.
Each Novos Application Framework is a Library of fully-tested, fully-documented Services designed and scaled to match the needs of a commonly-used software architecture.
From a Super Loop to fully pre-emptive multitasking, whatever behavior the application needs, and whatever the software architecture, there is a Novos Environment available pre-packaged, off-the-shelf. Because each Novos Framework comes with a default configuration, the time required to configure a Novos Application Framework is minimal, minutes even. The developer can concentrate on what matters most – the actual application.
The ROM/Flash on Cortex-M0 / M0+ processors vary extensively from a few hundred bytes to a few kilobytes. How much of that space the Novos environment takes determines how much is available for the application. That’s why the small size of each Novos environment, whether in a minimum or maximum configuration, ensures the application has maximum access to the available ROM/Flash.
The following table gives nominal code sizes for both minimum and maximum configurations of each Novos environment. The exact size you experience depends on the compiler you use and the services you invoke in the application. The minimum sizes in the table are for a configuration and kernel services that support an application using the scheduling policy of the environment. An application rarely makes use of every service supported by an operating system, making the maximum size a worst case number.
Novos RAM Requirements – each Novos environment imposes a fixed amount of RAM, regardless of its configuration, ranging from 226 Bytes to 304 Bytes. More…