Board to board examples

Some examples are designed to be used with other examples:

  • Each example running on a board.

  • And the two boards are connected to each other.

Vocabulary

These examples are called “board to board” examples, and have “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 are designed to be used together, and they are not functional when used alone. Nevertheless, by implementing the proper sequence of communication, you can use your own implementation of one of the two participants

Hardware setup

The README file of each example provides the setup instructions:

  • In the section Detailed scenario : the communication sequence implemented by the two examples.

  • In the section Software environment and setup : the software configuration of the two boards.

And provides some useful information to ensure the proper operation of the examples:

  • In the section Example configuration : the hardware constraints to respect (for example, pull-up resistors).

  • In the section Troubleshooting : the common points of attention, issues, and their solutions.

Typical communication logic

The examples are not designed to be used as a ready-to-use product level application. 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 (usually indefinitely).

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 applicative logs describe the communication sequence and the status of the communication.

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