Loose-coupling patterns for embedded systems programming [closed]

Question

Where can I find some good, proven guidelines or examples on writing extensible, modular, loosely-coupled code in C (if possible)?

Background of our problem is that we are maintaining large plain C, legacy code project for a low-cost microcontroller with limited computing and memory resources. Due to the fact that the system must be extremely reliable and the memory is rather limited, one of the first constraints is not to use dynamic memory allocation at all. All structures are mapped statically.

So we are looking for ways to make this code more maintainable and more modular. We are not interested in coding standards, but rather design suggestions. We have good coding conventions (naming, organizing code, SVN) so this is not a problem.

From what I've seen on the web (I may be wrong), it seems most of the programmers which program exclusively in plain C or assembler, at least in the uC/Embedded community, restrain from using anything more that plain procedural programming.

For example, we could get most of the OOP benefits and decoupling in plain C using callback functions, structs containing function pointers and similar stuff (it wouldn't require dynamic allocation, just passing around pointers to structs), but we would like to see if there are some proven methods already around.

Do you know of such resources, or have similar suggestions besides from "why don't you switch to C++ or other programming language"?

[Edit]

Thanks a lot for all the answers, I haven't had the time to examine them yet. Platform is 16-bit (XC166 or similar) uC, naked hw (no RTOS).

Answer 1

We're in a similar situation. To address these concerns, we've implemented a build system that supports multiple implementations of desired interfaces (which implementation used is a function of the compilation target), and avoid use of API features that aren't included in the portable wrappers. The wrapper definition lives in a .h file that #include's the implementation-specific header file. The following mock-up demonstrates how we might handle a semaphore interface:

#ifndef __SCHEDULER_H
#define __SCHEDULER_H

/*! \addtogroup semaphore Routines for working with semaphores.
 * @{
 */

/* impl/impl_scheduler.h gets copied into place before any file using
 * this interface gets compiled. */
#include "impl/impl_scheduler.h"

/* semaphore operation return values */
typedef enum _semaphoreErr_e
{
    SEMAPHORE_OK = impl_SEMAPHORE_OK,
    SEMAPHORE_TIMEOUT = impl_SEMAPHORE_TIMEOUT
} semaphoreErr_e;

/*! public data type - clients always use the semaphore_t type. */
typedef impl_semaphore_t semaphore_t;

/*! create a semaphore. */
inline semaphore_t *semaphoreCreate(int InitialValue) {
  return impl_semaphoreCreate(InitialValue);
}
/*! block on a semaphore. */
inline semaphoreErr_e semaphorePend(semaphore_t *Sem, int Timeout) {
  return impl_semaphorePend(Sem, Timeout);
}
/*! Allow another client to take a semaphore. */
inline void semaphorePost(semaphore_t *Sem) {
  impl_semaphorePost(Sem);
}

/*! @} */

#endif

The public API is documented for use, and the implementation is hidden until compilation time. Using these wrappers also should not impose any overhead (though it might, depending on your compiler). There is a lot of purely mechanical typing involved, though.