/Generic_MCU_Software_Infrastructure

Provide necessary software infrastructure, service, macros to support some high level abstract concept or paradigm, such as OOPC, FSM, delegate (event-driven) and etc

Primary LanguageCApache License 2.0Apache-2.0

Generic_MCU_Software_Infrastructure

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.

...