STM3220G programming under eCos
We have one project whose idea is to create a framework for quick programming of intelligent gateways and hubs. This is when one, in general, inexpensive controller serves a group of sensors according to a certain algorithm and at the same time has a connection with the server. Such a way to implement the internet of things .
Understandably, the framework is cross-platform and should cover the maximum possible number of hardware and software platforms. So, one of the tasks of the project is the port of the framework for eCos, and Cortex-M3 (STM32F2) was chosen as the hardware platform for this, in the implementation of the STM3220G Eval board. I want to share the experience of mastering such a tandem.
The choice of the operating system and hardware platform was made before I arrived at the project, i.e. It can be considered a given.
')
Having studied the requirements for the framework, the choice of language was clearly made - C ++. There is a lot of controversy about using C ++ in embedded, but it’s better to write a separate article about it. Debian GNU / Linux AMD64 is used as the main development system, for which of course there is a separate framework port.
1. eCos
eCos (I call it eXotic OS) is a configurable real-time operating system for embedded applications. It has been developed for a long time, but it is not very common (once I saw one chart with statistics on its use - something around 3-5% of the polled users use it). There is also a commercial option - eCosCentric, but it has not been done with it so far. The developers of the latter, by the way, passed the port for the STM3220G Eval board. Much has been written on the Internet.
2. Configuration of eCos for STM3220G
On the eCos website you can find links to binary versions of utilities and toolchain. The port for STM3220G is still in the CVS repository. Binary versions and toolchain are loaded using the ecos-install.tcl script. In the case of STM32F2, the GCC port for arm-eabi is required.
A feature of eCos is that it literally turns everything off. Moreover, this is done by define and exotic, written by eCos developers, a configuration system that is represented by two utilities: configtool and ecosconfig. The first has a GTK + graphical interface, the second is a console. In our case, the configtool is used.
You need to start the configuration by specifying the directory in which the files obtained from the CVS repository are in the configtool directory (menu Build / Repository). After that, in the configuration templates (menu Build / Templates) the option Hardware ST STM 3220G EVAL board will appear.
Next is a feature: you must specify the basic set of packages that will be included in the assembly of the operating system. I’ll say right away that not all the options will be able to be assembled so that an image is obtained that is ready for firmware in the controller's flash memory. Our framework needs threads and a scheduler, and therefore choose the Kernel option. The first option is ready - you can build the system (menu Build / Library). In fact, the whole system is a set of header files, a static library, and instructions for the linker. All this is collected in a separate directory utility configtool.
Since the framework is cross-platform, it is necessary to add C library packages to the eCos assembly, all packages related to ISO C Library and POSIX Compartibility. This will slightly increase the base image of the system, but it will allow you to write in the usual C / C ++ language, rather than invent the wheel (ie, the standard C library) again.
In eCos, program execution does not begin with the main function as in ISO C, but with the cyg_start () functions, which adversely affects the portability of the code. To fix this, you need to add the ISO environment startup / termination package.
Finishing touch. To build an image that can be written to the controller ROM, you must specify Startup type == ROM (Configuation / eCos HAL / Cortex-M Architecture / Cortex-M3 / -M4 STM32 Variant / STM32x0G-EVAL ... / Startup type). This will allow the compiler to collect the correct instructions file.
We execute again Build / Library, Build / Tests and that's it, you can start programming.
3. Programming for eCos
As mentioned earlier, the main language for developing the framework is C ++. Most of the language constructs are used, including encapsulation, inheritance, polymorphism (using virtual methods), patterns, and even dynamic information about types. Only three things were immediately excluded from the application: exceptions, dynamic memory allocation and the use of STL (although the eCos bundle has an analog library). All this as a result significantly simplifies the life of developers, and at the same time the image of the program (including the operating system itself) does not exceed 256K (ROM) in volume, and 128K RAM is enough for normal operation.
So, eCos provides us with a C library that is almost ISO compliant, and C ++ allows us to write code that is easy to read and maintain. It is worth noting that in eCos there are minor inconsistencies with the standards of ISO and POSIX.
Another feature. To correctly compile C ++ code without using standard C ++ libraries, you must use a C-shny compiler (in our case, gcc-arm-eabi).
4. Compile and build project
To build and test the system, autoconf / automake and cmake scripts are written. They duplicate each other as much as possible and are made to meet the needs of supporters of both autotools and cmake. Personally, my preference is autotools, because with this example I will continue to narrate.
To select the correct build platform (toolchain + compiler setup), it is enough to use the standard keys for the autoconf script (configure.ac file):
$ ../configure --host = arm-eabi --prefix = $ ECOS_INSTALL_DIR CXX = gcc-arm-eabi
at the same time, the ECOS_INSTALL_DIR variable must contain the path of the directory where the header files and the eCos library are collected (as indicated above - configured using configtool).
In addition to these keys, the autoconf script should add keys for the linker and compiler, for example, like this:
CFLAGS = "$ CFLAGS -ffunction-sections -fdata-sections"
CXXFLAGS = "$ CXXFLAGS -ffunction-sections -fdata-sections"
CPPFLAGS = "$ CPPFLAGS -I $ prefix / include -mcpu = cortex-m3 -mthumb"
LDFLAGS = "$ LDFLAGS -L $ prefix / lib -Ttarget.ld -mcpu = cortex-m3 -mthumb -Wl, - gc-sections -Wl, -n -Wl, -static -nostartfiles -nostdlib"
I can share full versions of scripts if anyone is interested.
That's the whole configuration.
5. Preparing an image for flashing flash
The autotools / cmake build scripts allow you to get an executable file in ELF format. It is not suitable for downloading to the controller's flash memory. In order to get an image suitable for firmware, you must use the program objcopy:
$ arm-eabi-objcopy -O binary <your-elf-file> <your-image> .bin
This command can be placed in an automake script (Makefile.am file), for example, like this:
install-exec-hook:
if PLATFORM_ECOS
$ (host_alias) -objcopy -O binary $ (bindir) / $ (PROGRAM_NAME) $ (EXEEXT) $ (bindir) / $ (PROGRAM_NAME) $ (EXEEXT) .bin
endif
Having done all this you can get an image ready for firmware in the controller's flash memory with a simple command:
$ make install
That's all.
Understandably, the framework is cross-platform and should cover the maximum possible number of hardware and software platforms. So, one of the tasks of the project is the port of the framework for eCos, and Cortex-M3 (STM32F2) was chosen as the hardware platform for this, in the implementation of the STM3220G Eval board. I want to share the experience of mastering such a tandem.
The choice of the operating system and hardware platform was made before I arrived at the project, i.e. It can be considered a given.
')
Having studied the requirements for the framework, the choice of language was clearly made - C ++. There is a lot of controversy about using C ++ in embedded, but it’s better to write a separate article about it. Debian GNU / Linux AMD64 is used as the main development system, for which of course there is a separate framework port.
1. eCos
eCos (I call it eXotic OS) is a configurable real-time operating system for embedded applications. It has been developed for a long time, but it is not very common (once I saw one chart with statistics on its use - something around 3-5% of the polled users use it). There is also a commercial option - eCosCentric, but it has not been done with it so far. The developers of the latter, by the way, passed the port for the STM3220G Eval board. Much has been written on the Internet.
2. Configuration of eCos for STM3220G
On the eCos website you can find links to binary versions of utilities and toolchain. The port for STM3220G is still in the CVS repository. Binary versions and toolchain are loaded using the ecos-install.tcl script. In the case of STM32F2, the GCC port for arm-eabi is required.
A feature of eCos is that it literally turns everything off. Moreover, this is done by define and exotic, written by eCos developers, a configuration system that is represented by two utilities: configtool and ecosconfig. The first has a GTK + graphical interface, the second is a console. In our case, the configtool is used.
You need to start the configuration by specifying the directory in which the files obtained from the CVS repository are in the configtool directory (menu Build / Repository). After that, in the configuration templates (menu Build / Templates) the option Hardware ST STM 3220G EVAL board will appear.
Next is a feature: you must specify the basic set of packages that will be included in the assembly of the operating system. I’ll say right away that not all the options will be able to be assembled so that an image is obtained that is ready for firmware in the controller's flash memory. Our framework needs threads and a scheduler, and therefore choose the Kernel option. The first option is ready - you can build the system (menu Build / Library). In fact, the whole system is a set of header files, a static library, and instructions for the linker. All this is collected in a separate directory utility configtool.
Since the framework is cross-platform, it is necessary to add C library packages to the eCos assembly, all packages related to ISO C Library and POSIX Compartibility. This will slightly increase the base image of the system, but it will allow you to write in the usual C / C ++ language, rather than invent the wheel (ie, the standard C library) again.
In eCos, program execution does not begin with the main function as in ISO C, but with the cyg_start () functions, which adversely affects the portability of the code. To fix this, you need to add the ISO environment startup / termination package.
Finishing touch. To build an image that can be written to the controller ROM, you must specify Startup type == ROM (Configuation / eCos HAL / Cortex-M Architecture / Cortex-M3 / -M4 STM32 Variant / STM32x0G-EVAL ... / Startup type). This will allow the compiler to collect the correct instructions file.
We execute again Build / Library, Build / Tests and that's it, you can start programming.
3. Programming for eCos
As mentioned earlier, the main language for developing the framework is C ++. Most of the language constructs are used, including encapsulation, inheritance, polymorphism (using virtual methods), patterns, and even dynamic information about types. Only three things were immediately excluded from the application: exceptions, dynamic memory allocation and the use of STL (although the eCos bundle has an analog library). All this as a result significantly simplifies the life of developers, and at the same time the image of the program (including the operating system itself) does not exceed 256K (ROM) in volume, and 128K RAM is enough for normal operation.
So, eCos provides us with a C library that is almost ISO compliant, and C ++ allows us to write code that is easy to read and maintain. It is worth noting that in eCos there are minor inconsistencies with the standards of ISO and POSIX.
Another feature. To correctly compile C ++ code without using standard C ++ libraries, you must use a C-shny compiler (in our case, gcc-arm-eabi).
4. Compile and build project
To build and test the system, autoconf / automake and cmake scripts are written. They duplicate each other as much as possible and are made to meet the needs of supporters of both autotools and cmake. Personally, my preference is autotools, because with this example I will continue to narrate.
To select the correct build platform (toolchain + compiler setup), it is enough to use the standard keys for the autoconf script (configure.ac file):
$ ../configure --host = arm-eabi --prefix = $ ECOS_INSTALL_DIR CXX = gcc-arm-eabi
at the same time, the ECOS_INSTALL_DIR variable must contain the path of the directory where the header files and the eCos library are collected (as indicated above - configured using configtool).
In addition to these keys, the autoconf script should add keys for the linker and compiler, for example, like this:
CFLAGS = "$ CFLAGS -ffunction-sections -fdata-sections"
CXXFLAGS = "$ CXXFLAGS -ffunction-sections -fdata-sections"
CPPFLAGS = "$ CPPFLAGS -I $ prefix / include -mcpu = cortex-m3 -mthumb"
LDFLAGS = "$ LDFLAGS -L $ prefix / lib -Ttarget.ld -mcpu = cortex-m3 -mthumb -Wl, - gc-sections -Wl, -n -Wl, -static -nostartfiles -nostdlib"
I can share full versions of scripts if anyone is interested.
That's the whole configuration.
5. Preparing an image for flashing flash
The autotools / cmake build scripts allow you to get an executable file in ELF format. It is not suitable for downloading to the controller's flash memory. In order to get an image suitable for firmware, you must use the program objcopy:
$ arm-eabi-objcopy -O binary <your-elf-file> <your-image> .bin
This command can be placed in an automake script (Makefile.am file), for example, like this:
install-exec-hook:
if PLATFORM_ECOS
$ (host_alias) -objcopy -O binary $ (bindir) / $ (PROGRAM_NAME) $ (EXEEXT) $ (bindir) / $ (PROGRAM_NAME) $ (EXEEXT) .bin
endif
Having done all this you can get an image ready for firmware in the controller's flash memory with a simple command:
$ make install
That's all.
Source: https://habr.com/ru/post/196240/
All Articles