Difference between revisions of "Concept of meta"

From Ethersex_Wiki
Jump to: navigation, search
m
(Examlpe meta section)
 
(15 intermediate revisions by one other user not shown)
Line 3: Line 3:
 
== 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 exemaple of such meta information.
+
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

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".