embedded-office / canopen-stm32f7xx Goto Github PK

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

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

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.