embedded-office / canopen-stm32f7xx

CANopen quickstart application for the STM32F769 to illustrate how the free CANopen Stack is used in your project.

Repository Structure

+- cmake        : submodule referencing the repository 'cmake-scripts'
+- debug        : debugger configurations
+- dependencies : external managed components
+- src          : canopen example project
|  +- app       : application source code
|  +- config    : configuration of startup and HAL
|  +- driver    : canopen target specific drivers

CANopen Demo for STM32F7xx Microcontrollers

This project demonstrates the usage of the free CANopen Stack Project. The included application is the Quickstart - "CANopen clock application", described in detail at the project website.

We use the STM32Cube MCU Full Package for the STM32F7 series made by ST Microelectronics as the low-level foundation for the chip configuration, the startup, and the driver implementation. With some slight enhancements to match our CMake build environment, we provide a small source code package out of a forked repository for integration in our demo projects.

My hardware setup for this development and testing is:

• the 32F769IDISCOVERY Discovery kit
• a CAN tranceiver Waveshare SN65HVD230 CAN Board
• an Atmel AT24C256 I2C EEPROM
• the KVaser USBcan II HS/HS for CAN bus monitoring
• the Saleae Logic Analyzer for low level measurements

The wiring is pretty simple. For your reference, see the essence in a small diagram:

For details, check:

• the User Manual for Discovery kit with STM32F769NI MCU
• the STM32F769xx Datasheet
• the Reference Manual for STM32F76xxx MCUs

Usage

Development Tools

Download and install these free tools for your system:

• Install the build tools Cmake
• Install the build system Ninja
• Install the cross-compiler Arm GNU Toolchain
• Install the STM32CubeProgrammer for uploading the program to the microcontroller.

Note: during development, you can alternatively use the free evaluation Ozone debugger with the ST-Link Reflash Utility from Segger.

Submodule: cmake-scripts

The basic collection of re-usable CMake scripts are placed as a Git submodule in the directory /cmake. The Git submodule is a reference to a specific commit hash of the Git repository cmake-scripts.

Small reminder: when cloning this repository you need to initialize and update the submodules:

# clone Git repository and initialize submodules:
$ git clone --recurse-submodules <repository>

# or, in case you have already cloned the Git repository:
$ git clone <repository>
$ cd <repository-directory>
$ git submodule update --init

Project dependencies

We use two extern managed components to build our target application. When using external projects it is important to define naming rules for exported CMake target names to eliminate name collisions.

For the example application in this repository we use:

• Target stm32f7xx-hal - a fork of the STM32CubeF7 package with enhancements for usage with CMake
• Target canopen-stack - the free CANopen Stack, provided by Embedded Office

Note: The used versions of the dependencies are defined in the directory /dependencies.

Build instructions

Just type in the project root directory:

# configure the project for debugging
$ cmake --preset debug

# build the application for your target
$ cmake --build ./build/debug

The target image file canopen-stm32f7xx.elf and the corresponding map file canopen-stm32f7xx.map are generated and placed in out/debug.

Load and Executing on target

For the Ozone debugger there is a basic debugger configuration debug/ozone.jdebug, which loads the image to the target and runs to function main().

• power up your STM32F769 discovery board
• double-click the debugger configuration
• watch the uploading and running to main ...

... and have fun playing with this tiny CANopen quickstart application :)

If you encounter any improvement in descriptions, project setup, build system, implementation or documentation, please rise an issue and help me to simplify the life of Embedded software engineers.

canopen-stm32f7xx's Issues

Improving driver organization - opened for discussion

For the long term, we need to establish a naming and storage location convention to get most out of existing and maybe new developed drivers.

One idea is:

+- src
|  +- driver                                            : the group of drivers for CANopen
|  |  +- <device-hal-name>                              : extern component from chip manufacturer
|  |  |  +- drv-(can|nvm|timer)-<hw-unit-name(s)>.c/h   : the hardware units we use

and with the exported interface structures:

const CO_IF_(CAN|NVM|TIMER)_DRV <device>_<hw-unit-name(s)_(Can|Nvm|Timer)Driver;

For example for existing driver in this repo:

src/driver/stm32f7xx-hal/drv-can-can1.c/h
src/driver/stm32f7xx-hal/drv-nvm-i2c1-at24c256.c/h
src/driver/stm32f7xx-hal/drv-timer-tim2.c/h

and

const CO_IF_CAN_DRV   STM32F7xx_CAN1_CanDriver;
const CO_IF_NVM_DRV   STM32F7xx_I2C1_AT24C256_NvmDriver;
const CO_IF_TIMER_DRV STM32F7xx_TIM2_TimerDriver;

Some notes:

• stm32f7xx-hal - it seems to be suitable to address a chip series, because a driver within a chip series is 99% identical. We need to allow some configuration (e.g. for pin mappings or clock frequencies).
• i2c1-at24c356 - this means external component at24c256 connected to the internal i2c1.
• Rather than writing complex configurable single driver files, I prefer multiple simple driver files where we decide essential configuration options by choosing the right driver file.

implement the EMCY demonstration

The quickstart example describes a tiny EMCY use-case: EEPROM is unplugged will rise a 5000h EMCY code (and error register bit 0).

Wait for release: canopen-stack V4.4.0

This project is ready for release, after the canopen-stack is updated to v4.4.0 (and all tests are passed).

add missing license file