Changes relative to the previous patch set:
- Moved GPIO pin interrupts to rtems chains, instead of a local linked list;
- Restructured the pin tracking structure, separating the interrupt information for each pin meaning that a pin without any interrupt enabled only requires 8 bytes, while keeping interrupt information (handling information, handler chain control, ...) requires 24 additional bytes (total of 32 bytes per pin with interrupts enabled);
- Added support for 'parallel' pin function assignment, allowing the function assignment to be set for multiple pins in a single GPIO hardware call. If a BSP does not support this feature it becomes a sequence of individual calls per pin. Also added support for GPIO pin groupings, allowing to write and read byte data to a series of pins which behave as a single entity;
- Added bank tracking structure to maintain the bank lock and bank level interrupt information (threaded/normal handling, interrupt counter);
- Changed GPIO settings to BSP defined constants, reducing dynamic memory allocation;
- Switched interrupt tasks for a rtems interrupt server, with the possibility of using normal interrupts (user handlers being called within ISR context).
This mutex implementation uses a thread priority queue with a simple
priority inheritance mechanism (similar to the object based mutexes).
The storage space must be supplied by the user (16 bytes on 32-bit
targets).
This enables external libraries to use thread locks since they are
independent of the actual RTEMS build configuration, e.g. profiling
enabled or disabled.
These SMP lock statistics are used for all lock objects that lack a
storage space for the statistics. Examples are lock objects used in
external libraries which are independent of the actual RTEMS build
configuration.
Move the storage for the thread queue heads to the threads. Each thread
provides a set of thread queue heads allocated from a dedicated memory
pool. In case a thread blocks on a queue, then it lends its heads to
the queue. In case the thread unblocks, then it takes a free set of
threads from the queue. Since a thread can block on at most one queue
this works. This mechanism is used in FreeBSD. The motivation for this
change is to reduce the memory demands of the synchronization objects.
On a 32-bit uni-processor configuration the Thread_queue_Control size is
now 8 bytes, compared to 64 bytes in RTEMS 4.10 (other changes reduced
the size as well).
