Configuration of Boards and Pins

Intro

This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more ....

make menuconfig

Integration of modules into menuconfig is described on this page Own module#Menuconfig - here a look at the results and the output of menuconfig.

The configuration is saved in two different formats:

• file .config for the menuconfig itself -
  • it is used for including it into the makefile
  • it influences also the build process of the binary file
  • definition auf makefile variables

• file autoconfig.h -
  • it is for including it in the compilation
  • definition of C preprocessor macros and defines

I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later.

make

The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: m4 - very short intro

meta.m4

If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --".

You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: Concept of meta.

meta.m4 is the extraction and collection of these sections.

The files which are used, are defined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC".

A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e.

MODULX_GENERAL_SUPPORT=y

Then in the makefile of ModuleX:

$(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ...

If the module is not activated the files added to _SRC instead of y_SRC.

meta.c

Is generated by m4 macros.

The inputs are: (controlled centrally in the Makefile!)

• autoconfig.h

  is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname>

• scripts/meta_magic.m4

  contains the framework for meta.c

• protocols/ecmd/ecmd_magic.m4

  only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y"

• protocols/soap/soap_magic.m4

  only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y"

• meta.m4

  see above

• protocols/ecmd/ecmd_defs.m4

  only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y"

• files referenced by the make var ${named_pin_simple_files}

  only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y"

• files referenced by the make var $(y_NP_SIMPLE_META_SRC)

  unconditional ... but contain the following files, if ECMD parser or SOAP support is activated:

  • protocols/ecmd/ecmd_defs.m4
  • ${named_pin_simple_files}

  so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter.

What is in ${named_pin_simple_files}?

That should be a chapter for itself - containing how the internals of defining pins works.

In the default case that are probably the following files:

• core/portio/np_simple.m4
• protocols/ecmd/np_simple_glue.m4

meta.h

is also generated from m4 macros.

Files used:

• scripts/meta_header_magic.m4

  framework of meta.h and macros.

• meta.m4

meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded.

More about the interesting concept of meta.

pinning.c

The detailied concept of pinning will be descriped in a chapter by its own.

At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor.

Files from which pinning.c is build:

• pinning/internals/header.m4
• pinning/controllers/<mcuname>.m4

  mcuname is defined by the make var MCU

• pinning/internals/hackery_<mcuname>.m4
• pinning/hardware/<boardname>.m4

  <boardname> is definned by make var HARDWARE

• pinning/internals/footer.m4
• autoconfig.h

  is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname>

What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files!

pinning/internals/header.m4

Is difficult to understand at the first look. Looks like to much module specific stuff (macros) is placed in this file (for convinience I think).

So it is hard to identify the multi purpose macros. Perhabs I will find out later, what is important.

Here the important one used very often:

pin(<module_named_pin>, <processer_named_pin>[, OUTPUT])

With this macros the pin name, with is used in a module is assigned to a pin of the processor or mcu. It is some kind of wiring - here on the level of the software.

With the optionnal parameter OUTPUT you define the direction of the connection: from mcu to the addon modul. Otherwise it is the oposite direction.

pinning/controllers/<mcuname>.m4

Here connections of special functions like SPI or I2C are connected to ports, because this ports are often fixed and cannot be switched to another port.

Furtheron some mcu features are defined like number ADC_CHANNELS and other defines for special characteristics of the mcu, which need extra handling.

pinning/internals/hackery_<mcuname>.m4

????

pinning/hardware/<boardname>.m4

Here you find the connections between processor an onboard hardware like the network module.

Also you find pin configuration of modules that need connected hardware, i.e. the DCF77 module.

So you see, this is the place, where all connections to external devices are defined.

I think, when connect your own hardware or want to use other ports as defined here, make a copy of the default m4 file and work with your version of the board file.

You can choose the new board when you call make menuconfig in the General Setup - Hardware/Periphery Class.

pinning/internals/footer.m4

Just some final defines ... needed some where.

processor named pins

If you read carefully you have notices 2 place holder in the pin macro.

If you want to know what processor named pin stands for, you have go into the details of avr-libc. Because the processor named pins are defined there already. Also the lib contains the details of how to adress these PINs.

The naming schema is like this:

PA0 - pin 0 at port A
PA1 - pin 1 at port A
...
PA7 - pin 7 at port A
PB0 - pin 0 at port B
...
PC0 - pin 0 at port C
...

Besides these neutral names some pins have also predefined functions like SPI. This pins have sometimes a secondary name.