Naming Conventions

Naming conventions followed

  • No third party calls will be made directly. Everything will pass through a RS wrapper.

  • Small letters for folder/file names

File Naming Conventions

  • Use lowercase names with underscores (_) to separate words.

  • Header files should have a .h extension (e.g., rs_xx.h, Here, xx means corresponding module/protocol name).

  • Source files should have a .c extension (e.g., rs_xx.c, Here, xx means corresponding module/protocol name).

For Module/Protocol File

  • Must begin with rs_, followed by module/protocol name (Eg: Ring Buffer, Modbus server..,etc.).

Example,

Module : Ring Buffer

     rs_ring_buf.h - Header file
     rs_ring_buf.c - Source file

Protocol : Modbus server

     rs_modbus_server.h - Header file
     rs_modbus_server.c - Source file

For Modules,

rs_ring_buf.h - Include files are available under $REPO/inc//rapidsea/components/modules

rs_ring_buf.c - Source files(Linux) are available under $REPO/src/rapidsea/components/modules

For Protocols,

rs_modbus_server.h - Include files are available under $REPO/inc/rapidsea/components/protocols/modbus

rs_modbus_server.c - Source files(Linux) are available under $REPO/src/rapidsea/components/protocols/modbus

Note

  • Here is the provided example for module and protocol file naming. Similarly, the same file naming format must be followed for Manager, Formats, Utils, etc.

  • For protocols, multiple .c and .h files may be used. In this case, they should be split into rs_ and rcb_ prefixes, these API function definitions and declarations must be contained within rs_xx.h and rs_xx.c files (with the rs_ prefix). APIs without the rs_ prefix are considered local functions and must be used within xx.c and xx.h files (without the rs_ prefix). These local xx.c and xx.h files should be maintained in the same source directory for consistency.

See also

For more details on rs_xx and rcb_xx APIs, please refer the section Function Definitions.

For HAL File

  • Must begin with rs_hal_, followed by module name (Eg: Socket, I2C, SPI, etc.).

Example,

Header File : Socket

   rs_hal_socket.h

Source File : Socket (Linux)

   rs_linux_socket.c

Source File : Socket (Windows)

   rs_win32_socket.c

Note

  • HAL layer source file naming is different for the corresponding platforms, the example being the Linux and Windows platform HAL layer source file name mentioned above.

rs_hal_socket.h - Include files are available under $REPO/inc/rapidsea/hal

rs_linux_socket.c - Source files(Linux) are available under $REPO/src/hal/mach/linux

rs_win32_socket.c - Source files(Windows) are available under $REPO/src/hal/mach/win32

Header Files

Header Guard

  • Always use include guards (Use #ifndef, #define, and #endif) to prevent multiple inclusions of the same file.

  • The include guard should be named based on the file name, e.g., H_RS_MODBUS_SERVER_H for rs_modbus_server.h.

Example:

#ifndef H_RS_MODBUS_SERVER_H
#define H_RS_MODBUS_SERVER_H

// Header file contents

#endif // H_RS_MODBUS_SERVER_H

Includes

  • Must use angle brackets (<>) for RAPIDSEA library header

Example:

#ifndef H_RS_MODBUS_SERVER_H
#define H_RS_MODBUS_SERVER_H

/*Includes*/
#include <rs_lib.h>

// Header file contents

#endif // H_RS_MODBUS_SERVER_H

Note

  • rs_lib.h is the RAPIDSEA stack’s full library header. This header accommodates different platform architectures and configurations, including HAL, interfaces, modules, and protocols.

  • The RAPIDSEA stack configuration (enabling/disabling modules and protocols) is managed through rs_config.h, which is included in rs_lib.h.

Function Prototypes

  • Must use meaningful names and provide clear parameter descriptions.

  • Must use `rs_ret_val_t` as the return type for all functions prefixed with rs_ and rcb_, except for rs_xx_open().

  • Must use `rs_handle_t` as the return type for `rs_xx_open()` functions.

  • Must use a prefix for function arguments name.

  • Must use verbs to describe actions.

See also

For more details on variable naming, please refer the section Variable Naming.

Example:

// rs_  API
rs_handle_t rs_modbus_server_open(rs_modbus_server_instance_t *ptr_instance, rs_modbus_server_config_t *ptr_config);
rs_ret_val_t rs_modbus_server_run(rs_handle_t handle, uint32_t u32_run);

// rcb_  API
rs_ret_val_t rcb_mb_get_input_register_value(rs_handle_t handle, uint16_t u16_reg_addr, uint16_t *ptr_reg_value);

See also

For more details on return type and data types, please refer the section Variable Naming.

Variable Naming

  • Must use `snake_case` for variables and function names.

  • Must use meaningful and descriptive names.

Macros

  • Must use `UPPER_CASE` with underscores for macros.

  • Prefix macros with a module/protocol name to avoid conflicts.

  • Example: if the file name begins with rs_, it means the macro name must begins with RS_ followed by Module/Protocol/HAL/Interface/Manager name.

Example:

//! Modbus Communication Type (RTU, ASCII and TCP)
#define RS_MODBUS_COMM_TYPE_RTU              0U
#define RS_MODBUS_COMM_TYPE_ASCII            1U
#define RS_MODBUS_COMM_TYPE_TCP_IP           2U

Structure, Enums, and Typedefs

  • Must use `snake_case` for `typedef` struct names and members of structures.

  • Must begin with `tag_` for struct tag names. Example: if the file name begins with rs_, it means the macro name must begins with tag_rs_ followed by Module/Protocol name.

  • Must end with `_t` for `typedef` struct names.

  • Must use `snake_case` for eNUMs. Example: if the file name begins with rs_, it means the eNUM name must begins with rs_ followed by Module/Protocol/HAL/Interface/Manager name.

Note

  • Member of the structure variables does not need a prefix except for a pointer. Pointer only must need prefix (ptr_) for members of structures.

Example:

//! Contains information about server
typedef struct tag_rs_modbus_server_instance
{
   rs_modbus_server_config_t *ptr_config;    //!< Pointer to containing server configuration
   void *ptr_user_data;                                            //!< Pointer to user data by flint
   rs_handle_t transport_handle;             //!< Handle to the Modbus server interface (RTU/TCP)
   uint32_t data_len;                        //!< Data length of RX/TX packet
   uint8_t state;                            //!< Modbus server process state
   uint8_t run_state;                        //!< Modbus server run state
   uint8_t reconfigure;                      //!< Modbus server reconfiguration flag
   uint32_t comm_time_out;                   //!< Modbus server timeout for RX/TX
   uint8_t *ptr_buff;                        //!< Pointer to the buffer for RX/TX
   uint16_t buf_len;                         //!< Buffer length for RX/TX
   rs_handle_t modbus_handle;                //!< Handle to the Modbus server interface visible to the user
} rs_modbus_server_instance_t;

//! Contains information about list of module id's
typedef enum
{
   RS_MODULE_SPARKLET = 0,                   //!< Sparklet module
   RS_AM_SPEEDOMETER,                    //!< Speedometer module
   RS_AM_ODOMETER,                       //!< Odometer module
   RS_AM_TRIPMETER,                      //!< Trip meter module
   RS_AM_TEMPERATURE,                    //!< Temperature module
   RS_AM_FUELGAUGE,                      //!< Fuel gauge module
   RS_AM_TACHOMETER,                     //!< Tachometer module
   RS_AM_TELLTALE,
   RS_AM_GEAR,                           //!<Gear module
   RS_AM_USER_DISPLAY,                   //!< Display module
   RS_ALL_MODULES,                               //!< All modules
} rs_module_id_t;

Source Files

Includes

  • Include the corresponding header file first.

  • Maintain the order: RAPIDSEA library header local headers External headers.

Example:

/*! \file
\brief      Modbus Server Module
\author     Embien RAPIDSEA Team
\copyright  Embien Technologies India Pvt. Ltd.


This file contains the APIs for handling modbus registers and server functionalities
*/

#include <rs_lib.h>
#include "modbus.h"

Note

  • rs_lib.h is the RAPIDSEA stack’s full library header. This header accommodates different platform architectures and configurations, including HAL, interfaces, modules, and protocols.

Function Definitions

  • Define functions in the same order as declared in the header file.

  • Must use consistent indentation (4 spaces per levels).

  • Must use verbs to describe actions.

  • Must use a prefix for function arguments.

See also

For more details on variable naming, please refer the section Variable Naming.

Static Functions

  • Local functions within the same file must not begin with rs_.

  • Local functions must be declared as `static`.

  • Functions must be defined at the top of the source file.

  • Return type : Any

Example:

/*! \fn          static uint16_t modbus_rtu_frame_pack(uint8_t *ptr_request, uint16_t u16_len)
        \brief       Function for RTU framing
        \details     This function performs the frame pack for RTU
        \param[in]   ptr_request - Pointer to the buffer
        \param[in]   u16_length - Length of the data
        \return      return length of RTU frame
*/
static uint16_t modbus_rtu_frame_pack(uint8_t *ptr_request, uint16_t u16_len)
{
        // Function contents
        return u16_len;
}

For APIs

  • Must begin with rs_, followed by module name (i2c, ring_buf) followed by operation verb (write, delete, push).

  • Return type : rs_ret_val_t , rs_handle_t

Example:

rs_ring_buf_push ();
rs_i2c_write ();

For HAL Calls

  • Must begin with rs_hal_, followed by module name (i2c, ring_buf) followed by operation verb (write, delete, push).

  • Return type : rs_ret_val_t , rs_handle_t

Example:

rs_hal_i2c_write ();

For Callbacks

  • Must begin with rcb_, followed by module name (i2c, ring_buf) followed by operation actions (written, deletion, pushed).

  • Return type : rs_ret_val_t , rs_handle_t

Example:

rcb_i2c_data_written ();

Variable Naming

  • Must use snake_case for variables and use data type as a prefix.

  • Must use meaningful and descriptive names.

Data Types Naming

  • The table below captures the naming conventions for data types in our RAPIDSEA.

Data Types Naming

Data Type Name (Common)

Data Type Name (RAPIDSEA)

Description

char

int8_t

Signed 8 bit

unsigned char

uint8_t

Unsigned 8 bit

short

int16_t

Signed 16 bit

unsigned short

uint16_t

Unsigned 16 bit

int

int32_t

signed 32 bit

int

rs_ret_val_t

signed 32 bit. Function return type.

int

rs_handle_t

signed 32 bit. Function return type for Open call.

unsigned int

uint32_t

Unsigned 32 bit

long

int64_t

signed 64 bit

unsigned long

uint64_t

Unsigned 64 bit

float

float

Single precision 32 bit

double

double

Double precision 64 bit

Prefix for Variable Names

  • Must use a prefix for variable names corresponding to their data types.

  • The table below lists the prefixes used for variable names.

Variable Name Prefix

Data Type

Prefix (Begin with)

int8_t

s8_

uint8_t

u8_

int16_t

s16_

uint16_t

u16_

int32_t

s32_

uint32_t

u32_

int64_t

s64_

uint64_t

u64_

float

f_

double

d_

Global variable

g_

Pointer

ptr_

Double Pointer

ptr_ptr_

Array

u8_arr_ (Eg: uint8_t array means)

Example:

// Example
int8_t s8_value = 0;
int16_t s16_value = 0;
int32_t s32_value = 0;
int64_t s64_value = 0;

uint8_t u8_value = 0;
uint16_t u16_value = 0;
uint32_t u32_value = 0;
uint64_t u64_value = 0;

float f_value = 0.0;
double d_value = 0.0;

uint8_t *ptr_value = NULL;
uint8_t **ptr_ptr_value = NULL;

uint16_t u16_arr_value[10] = {0};

//Global variable
int32_t g_s32_value = 0;

Note

  • In our RAPIDSEA stack, global variables must not be used inside the stack source. They are only allowed in demo application source files (.c)

Ensure the same is followed for uniform coding.