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:03489
IoT Start up
25-10-2017 10:25588
Unittesting - CPPUNIT
24-10-2017 20:26484
Things on the radar
24-10-2017 20:06547
WCET - Worst Case Execution Timings Calculator
28-06-2015 19:2914680
16-03-2015 18:222690
NuttX - Step-By-Step
30-12-2013 17:187578
Tools used
27-10-2013 12:134043
List of my robots
My robots
19-07-2013 08:443645
JoKaBot - Home build from scratch
My robots
19-07-2013 08:047045
C-Sharp (references and projects)
18-07-2013 19:194178
Home communications
18-07-2013 18:234313
Various links
My Collection
17-07-2013 09:048324
ARM - ARM7/9/11 + Cortex
17-07-2013 08:494258
17-07-2013 08:414474

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.05 seconds
874,069 unique visits