A Few Design Tips

When developing a program it is important to give it structure . If the program is designed as a big blob that is asking for disaster . As a parallel - instead of designing it like a jellyfish - it should be designed like a higher order mammal . As such it should be fully componentised - each component having a specific function - a specfic area of responsibility . Each component should fully self contained .

The components , as a general rule , should be pluggable - that is - if it's features are required - the component is included in the build - with minimal changes - if not - it is just left out of the build .

RTOS's should be used with care . Very often how they are used actually introduces problems into the program - problems , rather , should be designed out of the program . Typically - the use of mutex's , semaphores and event flags ( synchronous method ) are made introducing the following problems :- 1) task blocking - task locks up , 2) task blindness - task does not see what is happening externally , 3) priority inversion - task locks up completely , 4) task sequencing - order of operation of tasks not maintained , 5) task operations out of task context - data not initially protected etc. . These can be designed out simply and effectively by using mailboxes - event message queues . This introduces an asynchronous method and allows the task to operate without any of the problems associated with the synchronous method .

In designing and developing a program it is very important to rationalise and consolidate the design . Elements like , for example , the event messaging system can be consolidated such that all events go through a central Event Manager that then distributes the events to their destination task irrespective of destination - on the local processor or remotely located . This also allows test harnesses to isolate and to connect to individual components and to test them separately as well as testing them as part of the whole system . Similarly error codes can be consolidated such that they indicate both the source of the error and the error type and are logged within a platform specific logging facility .