Flint integration

Flint is the auto-configuration tool from Embien that can be used for code less development.

In RAPIDSEA, there is a separate layer with which the auto-generated code from Flint is used along with otherwise generic components of the library. All these part of code are organized under flint directory.

Organization

The System configurator of Flint can be configured as per the user requirements on the underlying hardware (i.e, eStormC2, Raspberry Pi). The blocks generated by Flint can be broadly classified into 2 types:

1.Driver Modules 2.Application Modules

Driver Modules:

These are the hardware interface specific modules such as UART, I2C, Ethernet, CAN or a little higher abstraction like EEPROM, TCP/IP stack. All the driver modules has a common base strucure rs_driver_module_base_t

App Modules:

The higher level application functionalities such as Modbus Server, CAN IVN Stack All the app modules has a common base strucure rs_app_module_base_t All the output are in constant section with exception of RAM regions needed for say UART FIFO, Modbus server instance

Implementation:

It is possible to run the hole project in BareMetal mode or OS mode. The current mode can be obtained with int flint_sys_con_os_enable (); If OS, generally go for blocking mode and nob-blocking mode for BareMetal. In BareMetal mode, a common task context will execute void process_init_modules() once on bootup and process_app_modules () periodically. All the other modules must be called from this context. Flint have the intelligence to create memory structure based on need such as rs_modbus_rtu_server_instance_t vs rs_modbus_ascii_server_instance_t vs rs_modbus_tcp_server_instance_t

Modbus Sys Con:

Modbus config structure had to be kept in RAM and Flint will generate structure for that Flint have the intelligence to create memory structure based on need such as rs_modbus_rtu_server_instance_t vs rs_modbus_ascii_server_instance_t vs rs_modbus_tcp_server_instance_t