[Protocol] Analysis of the layered structure of freemodbus

The compatibility of freemodbus is very good, and it can be easily ported on many platforms, which has a great relationship with its code architecture.
Here we do not consider the code transplant process, only analyze its hierarchy.

    In my opinion, the freemodbus protocol is actually divided into three levels
    1. Application layer (or interface exposed to the application layer): the
        interface definitions are all included in the header file mb.h and implemented in mb.c.
        Including the parts that do not need to be changed during the migration (some initialization, enabling, poll, etc.), and the parts that need to be modified or implemented (register the callback handler corresponding to the given function code, register-related operations, etc.).
            And in the initialization, the callback function points to the function interface of the second layer, which is equivalent to providing a unified interface for the entire program to access the function of the second layer, without considering the changes of the second layer.
    2. Protocol (transplantation) layer:
        This layer reflects the diverse types of freemodbus (RTU mode, ASCII mode, TCP mode, etc.)
        interface definition type.h (mbrtu.h / mbascii.h), which is included in the corresponding .c Implemented in.
        All the functions you see so far can be called directly without modification. Partial functions such as specific (RTU) initialization, start, stop, reception processing, and transmission processing are implemented.
        This layer function directly calls the physical layer interface.
    3. Physical layer:
        The interface definition is defined in mbport.h. The user only needs to implement the relevant interfaces according to the specific implementation of the platform (initializing the serial port, initializing the timer with a minimum unit of 50us, enabling the serial port and timer, etc.) For the specific location, the basic operations related to the serial port are in portserial.c, the timer is related to porttimer.c, and the state machine is in portevent.h.
        
    4. Special point:    
        there is a special place here, which is to receive and send interrupt functions . The actual acceptance and processing is defined and implemented at the protocol (transplantation) layer, but the clear interrupt must be transferred to the physical layer to adapt to different platforms.
        Therefore, freemodbus stipulates that the receiving interrupt and the sending interrupt must include two functions respectively, and these two functions finally point to the receiving and sending processing functions of the protocol transplantation layer through the form of callbacks. Accepting the interrupt processing function and sending the interrupt processing function need to be registered in the serial port initialization part of this layer (physical layer).
        So I think it can be said that the freemodbus protocol stipulates the flow of interrupt processing functions.
                           It can also be said that freemodbus has completed the interrupt processing function, but only allows the user to help clear the interrupt flag at the physical layer. If other operations are needed, they can also be added at the same time.

    5. Summary: This architecture is obviously divided into three levels, corresponding to the three situations of user migration:
    (1) Business: serial port receiving data is completely separated from the business, the business only needs to call the interface, without doing anything to the serial port architecture Just modify it.
    (2) Switching protocol: Assuming switching from RTU to ASCII, then only need to register the callback of ASCii in the application layer interface to complete, the bottom layer and business need not be modified.
    (3) Switching the platform: Take the single-chip microcomputer as an example, only the hardware of the physical layer needs to be re-adapted when switching, without any changes to the upper layer.
    Then the call flow is:
                     Application-> (call) application layer interface-> (callback) protocol (port) layer function-> (call) physical layer interface


Of course, this agreement is far more complicated and specific than my analysis, and I will continue to study, analyze, and organize in the future.

Turn: https://www.cnblogs.com/guoqingpeng/p/12422482.html

Guess you like

Origin www.cnblogs.com/TonyJia/p/12715240.html