Memory management

The MultiTask! system is a fairly typical RTOS in this regard: you can set up pools, each of which consists of some number of memory buffers. In any given pool, all of the buffers are the same size. The reqbuf and getbut functions allocate a. memory buffer from a pool. Each returns a pointer to the allocated buffer; the only difference between them is that if no memory buffers are available, get but will block the task that calls it, whereas reqbuf will return a NULL pointer right away.

void *getbuf (unsigned int uPoolId, unsigned int uTimeout);

void *reqbuf (unsigned int uPoolId);

In each of these functions, the uPoolId parameter indicates the pool from which the memory buffer is to be allocated. The uTimeout parameter in getbuf indicates the length of time that the task is willing to wait for a buffer if none are free. The size of the buffer that is returned is determined by the pool from which the buffer is allocated, since all the buffers in anyone pool are the same size. The tasks that call, these functions must know the sizes of the buffers in each pool.

The relbuf function frees a memory buffer.

void relbuf (unsigned int uPoolId, void *p_vBuffer);

Note that relbuf does not check that p_vBufter really points to a buffer in the pool indicated by uPoolId. If your code passes an invalid value for p_vBuffer, the results are usually catastrophic.

The MultiTask! system is also typical of many RTOSs in that it does not know where the memory on your system is. Remember that in most embedded systems, unlike desktop systems, your software, not the operating system, gets control of a machine first. When it starts, the RTOS has no way of knowing what memory is free and what memory your application is already using. MultiTask! will manage a pool of memory buffers for you, but you must tell it where the memory is. The init_mem_pool function allows you to do this.

int init_mem_pool (

unsigned int uPoolId,

void *p_vMemory,

unsigned int.uBufSize,

unsigned int uBufCount,

unsigned int uPoolType

);

The uPoolId parameter is the identifier you will use in later calls to getbuf, reqbuf, and relbuf. The p_vMemory parameter points to the block of memory to use as the pool; you must make sure that it points to available memory. The uBufSize and uBufCount parameters indicate how large each buffer is and how many of them there are the pool. (The uPoolType parameter indicates whether these buffers will be used by tasks or by interrupt routines. This distinction is peculiar to MultiTask!, and we will not discuss it here.) The picture shows how this function allocates the pool of memory buffers.

Research and Development

With a focus on R&D, Micromagine embedded software engineers go far and wide exploring the breadth of capabilities and fields of application for the next generation of industry hallmarks, identifying the potential pockets of growth for our customers.
Some of the latest examples of our R&D include studying and testing Android OS porting to custom hardware platforms and trying new dimension technologies such as motion controller in game development.

Embedded System Expertise

  • Deep experience across multiple embedded platforms (ARM Cortex M series, ARM64/aarch64, Intel x86-64)

  • Custom device driver design and implementation (Linux or microcontroller or otherwise)

  • Video- and audio-rate (or higher), low-latency DSP algorithms

  • Multi-threaded applications and data processing

  • Rapid prototyping

Quality Assurance

Quality Assurance of embedded systems is also available as a separate service for our clients. We provide testing and debugging for a range of embedded solutions.
To craft efficient, resilient, and infallible software, we’ve established two focused QA Labs: Firmware & Embedded QA Lab, and Mobile QA Lab, which are applicable during unit, integration, system, and acceptance testing.

 

Powered By by Micromagine Web Solutions