Board-to-board examples

Some examples work together with other examples:

  • Each example must run on a board.

  • And the two boards are connected to each other.

Vocabulary

These examples are called “board-to-board” examples, and have the term “two_boards” in their names. To distinguish the participants in the interactions between the two boards, we use the terms “controller” and “responder”.

This terminology is independent of the actual protocol being demonstrated. The controller is the initiator of the communication, and the responder is the target of the communication. In some protocols, the controller is called “master” and the responder is called “slave” (for example, in the I2C legacy terminology).

Typical usage

The communication protocols such as UART, I2C, SPI or CAN are demonstrated with this approach.

For example:

  • hal_i2c_two_boards_com_polling_controller: the initiator of the communication

  • hal_i2c_two_boards_com_polling_responder: the target of the communication

These two example projects demonstrate transmit-receive transactions between two boards based on the I2C-bus protocol with the HAL API, in polling mode. Each binary must be flashed to a different board, and the two boards must be connected to each other.

Note

The two examples must be used together, and they are not functional when used alone. Nevertheless, by implementing the proper communication sequence, a custom implementation can replace one of the participants

Hardware setup

The README file of each example provides the setup instructions:

  • The Detailed scenario section describes the communication sequence implemented by the two examples.

  • The Hardware environment and setup section describes the wiring and the pins used to connect the two boards.

The README file also provides some useful information to ensure the proper operation of the examples:

  • The Example configuration section defines the hardware constraints such as pull-up resistors and so on.

  • The Troubleshooting section defines the common points of attention, issues, and their solutions.

Typical communication logic

The examples are for demonstration purposes. They are not ready-to-use, product level applications. Nevertheless, a minimal error handling is implemented to demonstrate the use of the HAL API.

The controller is in charge of handling the communication issues. It uses a com_attempts counter to retry the communication in case of error. The MAX_COM_ATTEMPTS threshold limits the number of attempts.

If the communication is not established properly within this threshold, the controller reports an error and stops the communication. If the communication is established, the two participants exchange messages, and this sequence can run in an infinite loop.

Observing the board-to-board communication

As it is complex to follow the real-time communication between two boards with a debugger, we recommend using a serial terminal. This type of example usually provides a serial output to observe the communication (see Using the console), except for UART. The application logs describe the communication sequence and the status of the communication.

Additionally, use an oscilloscope to observe the signals on the pins of the STM32.