ERMT - Embedded Resource Management System

ERMS – Embedded Resource Management System

Example on simple resource management system – for a menu management system or traditional resource alloc/free.


Actually the principles here are more resource management – but below text is realized in a menu system!

This idea was initially launched in the 1990 for a customer - later for a couple of the companies I worked for!
It has been re-think'd and reworked (I got a bit wiser during the years) ....

Especially regarding the embedded capability and demands in relation to resource management.

So after having implemented various variants and many discussions later ... I have the following design now.

The advantage of this system design & architecture  is the flexible and yet straight design & implementation. 

The absolute main idea was that in any menu system, each menu should never have knowledge about any of the other - if any - menus. No strings attached between applications, no special interaction of the users I/O. Basically the same approach as I did for the other menu management system I made (see here).

Each application as-well as each MMI have the focus - only dependent of the initial and system defined priority's.

Various drivers and tools seams to support this, but digging a bit down in to this, one gets frustrated and often ends up writing a menu system from scratch.
Speaking about drivers and the presentation layers relations – I would recommend U to take a look at the RAMTEX capabilities (here).


When I get some more time, and when I have formalized my hand drawings on the menu management system, some more graphical pictures and a lot more information will be made available ...


First let’s look at the various applications part (or component) on an (embedded) system.  

We often discussed

  • where did the application belong,
  • how did the menu’s applied to the application layers,
  • where did the protocol’s and their user data applied to
    • a phone number,
    • a DSC data field,
    • a notification field (and many more examples).


Because of the systems limited capacity, limitation in memory and to some extent the willingness in the developer organisations to change existing practices, we were often facing solutions that wasn’t portable, not easy scalable nor were they very flexible. Giving a lot of rewriting and adjustments, from model to model, feature to feature … (luckily flash gets cheaper and so do RAM).

 On that type of a - hard-core real low tech - embedded system you have 3 levels or ‘component’:

1)      Purely application – no MMI.
Actual mostly drivers, some protocols, application having controlling mechanism (speed, pressure, flow, direction, …)  …

2)       Typical 'real' application layer with some MMI – could be a protocol.

3)       Pure MMI (looking into data, changing data etc)

Article Images: prj_resourcemngt_menulevels.gif




But back t the real stuff – resource management!

We implemented a “Display Handling system”  in the following way ...

Article Images: prj_resourcemngt_modules1.gif

 Resource organization and the way-of-communication between the entities.

Simple handles for accessing resources, administration of these resource and broad but well specified access schemes resulted in a very smooth running and simple testable and portable system.

An architecture on which we later added other resources like protocols, I/O channels, USB memory. We even on a project added the opportunity of having multiple external handsets but only real master.

Article Images: prj_resourcemngt_signalling.gif



Display update examples by the application’s

Applications update their individual display resource, by simple writing to the display.

They have the options for write

  • Full
  • Fields
  • Area (top, left, right or bottom part)
  • Other

 Though it’s the Update manager which defines/decides what virtual display has this highest priority.


Article Images: prj_resourcemngt_menudatatransport.gif






No application awareness - giving full free design capability 


No MMI awareness - means free design capabiliti in the presentation layer


Multible menu systems - you can easily change/swap presentations


Priority messages possible - priority on each level (application, interrupt, focus, UI)


Each Applications operates fully integrated with out knowledge about other application, current priority and so on ...


Using shadow memory increases general system I/O performance (display update sequence)









Little overhead on memory usage


Little overhead on signalling (though not much) due to priority selection


Requires some sort of messaging passing (RTOS) ... though it can be implemented with out!




No Comments have been Posted.

Post Comment

Please Login to Post a Comment.

Articles Panel

  Article Posted By Date Reads
System-Of-Systems Ingineering
Process & Methods
31-10-2017 23:03211
IoT Start up
25-10-2017 10:25294
Unittesting - CPPUNIT
24-10-2017 20:26226
Things on the radar
24-10-2017 20:06221
WCET - Worst Case Execution Timings Calculator
28-06-2015 19:2913506
16-03-2015 18:222299
NuttX - Step-By-Step
30-12-2013 17:186423
Tools used
27-10-2013 12:133623
List of my robots
My robots
19-07-2013 08:443288
JoKaBot - Home build from scratch
My robots
19-07-2013 08:046229
C-Sharp (references and projects)
18-07-2013 19:193759
Home communications
18-07-2013 18:233859
Various links
My Collection
17-07-2013 09:047554
ARM - ARM7/9/11 + Cortex
17-07-2013 08:493892
17-07-2013 08:413958

Total Articles: 58 :: Total Article Categories: 16


My Collection (1) My robots (2)
Oldies (5)
Old Projects - very old
Process & Methods (8)
Projects (12) Robotics (1)
Technology (7) Testing (1)
Tools (14) Working on ... (7)
Projects Im currently working on
Render time: 0.03 seconds
782,675 unique visits