Host-Based Development with Apache NuttX – CAN Network Simulation

Application

We base this demonstration on an application introduced in a previous post: small CAN node. The application implements the following fetures:

1. Sending periodic heartbeats.

2. Reading the state of a button and reporting changes over CAN bus.

3. Controlling the state of an LED over CAN bus.

Since we are not using real hardware with GPIO support, we need to introduce a few minor changes to the code. The Simulator and QEMU don't implement the correct USERLEDS and BUTTONS drivers, so we replace them with a simple software implementation. The proper solution in this case would be to implement dedicated simulated drivers on the kernel side, allowing the application to use the same kernel interfaces as in the case of real hardware. However, for simplicity, we take the easy way out and modify the application code directly.

The button handling code is modified to generate random button state changes and report them on the CAN bus. Our new button thread looks like this:

FAR void *thread_button(FAR void* data)
{
  FAR struct cannode_env_s *env = (FAR struct cannode_env_s *)data;
  struct canmsg_s           msg;
  btn_buttonset_t           sample;
  btn_buttonset_t           sample_last = 0;
  int                       ret;

  DEBUGASSERT(env);

  /* Seed the random number generator */

  srand(time(NULL));

  while (1)
    {
      /* Sleep some random time */

      sleep((rand() % 10)   1);

      /* Get button state */

      sample = rand() % 2;

      /* Next cycle if sample is the same */

      if (sample_last == sample)
        {
          continue;
        }

      sample_last = sample;

      /* Fill frame */

      button_msg(env, &msg, sample);

      /* Send frame */

      ret = can_send(env->fd, &msg);
      if (ret < 0)
        {
          PRINTF("can_send failed %d\n", ret);
        }
    }

  return NULL;
}

For the LED support, we use a simple console message when a request to change the LED state arrives on the CAN bus:

#ifdef CONFIG_USERLED
/* Set LED */

ret = led_set(fd, msg.data[0]);
if (ret < 0)
  {
    PRINTF("led_set failed %d\n", ret);
  }
#else
/* Just print message request */

printf("Set LED request %d\n", msg.data[0]);
#endif

Now it's time to discuss CAN network support in a simulated environment for Apache NuttX. NuttX currently offers two useful solutions for this:

1. A CAN bus card over PCI, which can be run in QEMU environment.

2. A simulator target with direct access to the host's SocketCAN interface.

Two PCI CAN cards compatible with QEMU [1] are currently supported in NuttX:

1. Kvaser PCI CAN-S, based on the SJA1000.

2. CTU CAN FD

The Kvaser card supports only CAN 2.0, while the CTU CAN FD card also supports CAN FD. For our demo, we chose the second option.

All the mentioned CAN solutions for the host are available in NuttX in two versions of CAN interfaces: as a character device or as a SocketCAN interface.

CONFIG_DEVICE_TREE=y
CONFIG_PCI=y
CONFIG_CAN_CTUCANFD=y

CONFIG_ALLOW_BSD_COMPONENTS=y
CONFIG_CANUTILS_CANDUMP=y
CONFIG_CANUTILS_CANSEND=y
CONFIG_CANUTILS_LIBCANUTILS=y

Summary

This post explored how CAN network development can be moved partly into a simulated Linux environment, making both development and debugging significantly easier compared to working with physical hardware. Of course, testing on real hardware remains essential when working with embedded systems and cannot be omitted, but simulations save a lot of time and make life easier.

Although the example presented uses a relatively simple CAN setup, the same approach can scale to much more complex systems or be adapted for minimal configurations involving only a single CAN node. Working with multiple NuttX images in parallel becomes especially easy with CMake's support for out-of-tree builds, something that would be far less efficient using the traditional Make build system available in NuttX.

While the demo uses the NuttX Simulator and QEMU, other tools like Renode with the host's SocketCAN interface [2] are worth exploring. Moreover, the network isn't limited to NuttX nodes; any system or tool that can interface with SocketCAN—such as Linux images or even host-side programs—can participate in the simulation.

Beyond development, this simulated setup provides an excellent foundation for automated testing using tools like python-can [3] or Vector SIL Kit [4]. There's even the possibility of combining virtual and physical environments using tools like cangw [5], which allows forwarding traffic between simulated nodes and real CAN hardware.

The main limitation of this workflow lies in the relatively limited peripheral support in QEMU and the NuttX simulator. Expanding device support and enhancing NuttX's infrastructure for host-side driver development would make this approach even more powerful.

In future posts, we'll look at more advanced scenarios, including running CANopen-based applications with the Lely CANopen stack [6] supported in NuttX.

References