Difference between revisions of "Concept of meta"
m (Created page with "{{i18n:Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. AT the end there will be a short exemaple of…") |
(→Examlpe meta section) |
||
(16 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
− | {{i18n | + | {{i18n|Concept of meta}} |
== Intro == | == Intro == | ||
With meta information in each module the main program is set up depending on the configuration. | With meta information in each module the main program is set up depending on the configuration. | ||
− | + | At the end there will be a short example of such meta information. | |
− | == meta.c == | + | If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] |
+ | |||
+ | Also have a look at the files explained while reading - that will help. | ||
+ | |||
+ | == meta.c / meta_magic.m4 == | ||
The creation of this file is mainly controlled by the file "meta_magic.m4". | The creation of this file is mainly controlled by the file "meta_magic.m4". | ||
− | What is in the file? | + | What is in the file meta_magic.m4? |
+ | |||
+ | === framework for the file meta.c === | ||
+ | The framework consists of several divert sections, in which code of the used modules is injected. | ||
+ | |||
+ | Only the idea of the injection is explained with the first injection point. | ||
+ | |||
+ | The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". | ||
+ | |||
+ | Therefore later in in the file some macros are defined - in this case it is named "initearly". | ||
+ | |||
+ | This macros and some others are all defined the same way: | ||
+ | |||
+ | define(`initearly',`dnl | ||
+ | divert(initearly_divert) $1 (); | ||
+ | divert(-1)') | ||
+ | |||
+ | So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. | ||
+ | |||
+ | The closing brace of the function is part of the next section "divert(net_init_divert)". | ||
+ | |||
+ | === structure of meta.c === | ||
+ | meta.c itself contains several functions, which are called at important points in the firmware: | ||
+ | |||
+ | * ethersex_meta_init | ||
+ | *: is called in the startup before the pins are initialized | ||
+ | * ethersex_meta_startup | ||
+ | *: is called before the main loop starts | ||
+ | * ethersex_meta_mainloop | ||
+ | *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... | ||
+ | * periodic_process | ||
+ | *: is the last function called in ethersex_meta_mainloop - after all the injected modules function | ||
+ | *: does some network and console reading (ECMD support and other) - at the moment I don't know the backgrounds of this operations. | ||
+ | *: further operations can be injected here - by use of the "timer" macro see below. | ||
+ | * ethersex_meta_exit | ||
+ | *: is called when a sigint is detected ... | ||
+ | * ethersex_meta_netinit | ||
+ | *: is called in network.c in the function network_init - after the initialization of the network stack | ||
+ | *: remark: network.c has is own meta section which, is used to include the network functionality. | ||
+ | |||
+ | === m4 macros === | ||
+ | |||
+ | * header | ||
+ | *: define include file for meta.c | ||
+ | * initearly | ||
+ | *: define a call at the start of ethersex_meta_init | ||
+ | * init | ||
+ | *: define a normal call in ethersex_meta_init | ||
+ | * atexit | ||
+ | *: define a call on shutdown - in ethersex_meta_exit | ||
+ | * net_init | ||
+ | *: define a call in ethersex_meta_netinit | ||
+ | * startup | ||
+ | *: define a call in ethersex_meta_startup | ||
+ | * mainloop | ||
+ | *: define a call in ethersex_meta_mainloop | ||
+ | *: this call is done unconditional every time ethersex_meta_mainloop is called. After that the watchdog timer is resetted. | ||
+ | *: I think, it is only for important fuctions - use timer instead. | ||
+ | * timer | ||
+ | *: takes two parameters, the first one says in which run of periodic_process function the second paramater will be executed (every nth run). | ||
+ | |||
+ | == meta.h / meta_header_magic.m4 == | ||
+ | |||
+ | Contains the structures | ||
+ | * uip_udp_connection_state and | ||
+ | * uip_tcp_conenction state | ||
+ | which can be extended with the macros | ||
+ | * state_udp | ||
+ | * state_tcp | ||
+ | |||
+ | If a module wants to save a network relevant state as part of it's functionality, it has to be part of the connection_state structure. | ||
+ | Since it is a union, I think, it is neccessary for passing the structure to the network functions. | ||
+ | |||
+ | I.e. the module dyndns puts the dyndns connection state structure there. | ||
+ | |||
+ | But look into the details by yourself - if you like. | ||
+ | |||
+ | |||
+ | === Macro state_header === | ||
+ | |||
+ | By use if this macro it is possible to include additional ".h" files into meta.h. | ||
+ | |||
+ | Usage: | ||
+ | state_header(<path_and_filename>) | ||
+ | |||
+ | Expands to | ||
+ | #include "<path_and_filename>" | ||
+ | |||
+ | == Example meta section == | ||
+ | |||
+ | From tanklevel.c | ||
+ | -- Ethersex META -- | ||
+ | header(services/tanklevel/tanklevel.h) | ||
+ | init(tanklevel_init) | ||
+ | timer(1, tanklevel_periodic()) | ||
+ | * header | ||
+ | ** include file for meta.c | ||
+ | * init | ||
+ | ** call of tanklevel_init() in meta_init | ||
+ | * timer | ||
+ | ** call of tanklevel_periodic() in every time (1) the main_loop function is called. | ||
+ | == Closing == | ||
+ | After all this explained I want to mention that some modules are not only in that structured way integrated into the project. | ||
+ | There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". | ||
[[Category:Development]] | [[Category:Development]] |
Latest revision as of 01:46, 11 November 2012
Contents
Intro
With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information.
If you continue to read, you should understand this concept: M4 - very short intro (Deutsch)#divert
Also have a look at the files explained while reading - that will help.
meta.c / meta_magic.m4
The creation of this file is mainly controlled by the file "meta_magic.m4".
What is in the file meta_magic.m4?
framework for the file meta.c
The framework consists of several divert sections, in which code of the used modules is injected.
Only the idea of the injection is explained with the first injection point.
The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init".
Therefore later in in the file some macros are defined - in this case it is named "initearly".
This macros and some others are all defined the same way:
define(`initearly',`dnl divert(initearly_divert) $1 (); divert(-1)')
So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section.
The closing brace of the function is part of the next section "divert(net_init_divert)".
structure of meta.c
meta.c itself contains several functions, which are called at important points in the firmware:
- ethersex_meta_init
- is called in the startup before the pins are initialized
- ethersex_meta_startup
- is called before the main loop starts
- ethersex_meta_mainloop
- is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ...
- periodic_process
- is the last function called in ethersex_meta_mainloop - after all the injected modules function
- does some network and console reading (ECMD support and other) - at the moment I don't know the backgrounds of this operations.
- further operations can be injected here - by use of the "timer" macro see below.
- ethersex_meta_exit
- is called when a sigint is detected ...
- ethersex_meta_netinit
- is called in network.c in the function network_init - after the initialization of the network stack
- remark: network.c has is own meta section which, is used to include the network functionality.
m4 macros
- header
- define include file for meta.c
- initearly
- define a call at the start of ethersex_meta_init
- init
- define a normal call in ethersex_meta_init
- atexit
- define a call on shutdown - in ethersex_meta_exit
- net_init
- define a call in ethersex_meta_netinit
- startup
- define a call in ethersex_meta_startup
- mainloop
- define a call in ethersex_meta_mainloop
- this call is done unconditional every time ethersex_meta_mainloop is called. After that the watchdog timer is resetted.
- I think, it is only for important fuctions - use timer instead.
- timer
- takes two parameters, the first one says in which run of periodic_process function the second paramater will be executed (every nth run).
meta.h / meta_header_magic.m4
Contains the structures
- uip_udp_connection_state and
- uip_tcp_conenction state
which can be extended with the macros
- state_udp
- state_tcp
If a module wants to save a network relevant state as part of it's functionality, it has to be part of the connection_state structure. Since it is a union, I think, it is neccessary for passing the structure to the network functions.
I.e. the module dyndns puts the dyndns connection state structure there.
But look into the details by yourself - if you like.
Macro state_header
By use if this macro it is possible to include additional ".h" files into meta.h.
Usage:
state_header(<path_and_filename>)
Expands to
#include "<path_and_filename>"
Example meta section
From tanklevel.c
-- Ethersex META -- header(services/tanklevel/tanklevel.h) init(tanklevel_init) timer(1, tanklevel_periodic())
- header
- include file for meta.c
- init
- call of tanklevel_init() in meta_init
- timer
- call of tanklevel_periodic() in every time (1) the main_loop function is called.
Closing
After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks".