Provides necessary software infrastructures, services, macros to support some high level abstruct concepts and/or paradigm, such as OOPC, FSM, delegate (event-driven) and etc
Currently GMSI provides following services:
-
epool
a common pool infrastructure, which could be considered as an abstract class for pool (heap). The letter "e" here represents "embedded".
-
block
a building block class which provides the basis of block based buffer services. block_t will be used by other services, such as block_queue, stream2block, es_simple_frame and etc. Both dynamic(heap) and static memory allocation are supported.
-
block_queue
A queue of block_t which implemented as a block list.
-
stream2block
a dedicated stream-based service which provides stream interface for block devices, i.e. IO devices which support burst transfer mode (such as SPI, USART using DMA). A serial port tempalte is provided to use USART with the minimal requirments of Data-Receiving-Complete interrupt and Data-Transfering-Complete interrupt. Example project demostrates how to use stream2block with usart.
WHY using stream2block service rather than simple QUEUE + ISR ?
Simple QUEUE + ISR does works for normal applications, but you have to provide atomicity protection for queues. This will hurt real-time response of interrupt significantly if the stream is accessed frequently in super-loop, i.e. enqueue or dequeue. On the other hand, some device might encourage users to use DMA or other methods which can generate burst transations, in other words, a stream has to be converted into blocks. When stream2block is designed, it works like a double-bufferred system, so when one block is used for queue access, another block is used for a burst transaction. The burst IO transactiond and the queue are connected via a list, which works like a queue of blocks. You only need to provide atomicity protection on the list but not the queue. So, frequenly accessing queue in the super-loop will not hurt any real-time response, as list accesses are relatively less freqently comparing those accesses in normal QUEUE + ISR scheme.
-
es_simple_frame
A communication service with provides encoding and decoding functions based on a simple frame structure, which only contains a 8bit header, a 16bit length, an optional data field and a 16bits CRC checksum. This service can be configured working with exchangable buffer ( block_t ) or static memory buffer.
-
multiple_delay
A dedicated temporal module which can provide delay monitoring service for finite state machine or tasks in RTOS. A 1ms timer event handler is required to drive a 32bit counter.
-
scheduler
A dedicated non-preeptive finite state machine scheduler.
-
crc
Various CRC functions.
-
xmodem
A dedicated module which implements Xmodem communication protocal.
-
bootloader
A bootloader logic template. You just need to 1) implement the memories access driver, 2)describe the supported memories in the target device, and 3) provide a stream interface (i_byte_pipe_t) for communication.
-
key A dedicated module which provides general key-board services, such as signal filtering, key event detection and key buffer.
-
sw_sdio
A dedicated module which provides software-implemented sdio driver.
-
mal
Memory Abstruct Layer, provides unified, random access API for all kinds of page-based and/or non-page-based memories.
-
page
A dedicated service which provide random accesses for page-based memories.
...