5 years, 8 months ago.

I used the CAN module/library a couple years ago and (as I recall) if micro RX was not pulled high at startup it would halt the whole program. That might be what you’re running into. By the design of the library, you need to have the right physical connection (RX pin must see a high level) or the CAN module will not initialize and the program stops. I believe a connected CAN transceiver will provide the right levels all the time as long as the chip is powered.

Creating the object, should work in either location. If it works in one location and not another, it may be an accident of timing.

A good way to get started with micro CAN is to short the micro’s tx and rx pins, the tx line will provide the high level and allow rx to initialize. This allows you to do a loopback test with just the micro’s CAN module – don’t even need to connect the transceiver.

I have a product with a CAN module and worrying about waiting to enable CAN has never been an issue. But if you need to delay starting the CAN module, you can’t create it in the ctor. You could make another top level CAN wrapper module that is created at startup and then is responsible for dynamically creating actual CAN driver when conditions are right. If you’re waiting for RX to go high, you should be able to figure out how to test for this.

If you create them before main they are global scope. They get their very own space in RAM not on main() stack and they live for the duration of the program. And other files/modules can access those objects (so you could share object with another file). And the ctors are called before main() of course.

Regarding organizing a larger program, in most cases your micro is probably dedicated to doing a small number of tasks in perpetuity, so global scope often makes the most sense for the building blocks of a program. I can show you my approach for C++ firmware (which is probably pretty normal). I have top level classes that contain major functionality. Basically you are creating semi-independant blocks of functionality and wiring them up through the ctors. This is dependency injection where an object gets its dependencies passed down from the top.

For scheduling, I like the mbed EventQueue. You pass it around and objects simply tell it which member function to call and when, using call_in() and call_every(). Simple polling loop in main is another way to do it, but I like EventQueue better. The Updater class here contains the EventQueue and a Thread so that top level is as clean as possible.

Non functioning example:

#include "mbed.h"

Watchdog  watchdog;            // Owns a thread. Manages IWDG hardware. Monitors other threads.  Threads register at runtime with contract check-in time.
I2C       i2c;                 // More or less standard mbed I2C library
Updater   updater(watchdog);   // Owns a thread. Most things run in this thread. Pass around and objects can schedule themseleves.
API       api(watchdog);       // Owns its own thread because comm channel is slow.
Sensors   sensors(updater);    // All AD Data acquisition.
Eeprom    eeprom(i2c);         // Eeprom peripheral.  I2C needs to be mocked for testing, so probably should be passed in from top.
Config    config(api, eeprom); // Registers with API at runtime so it can handle User Config API calls. Saves config to eeprom.
Stats     stats(api, updater); // Track maxes, mins, avgs, totals, times, etc. Respond to API request to get stats.

int main() {

    // threads created in class ctors, just need to start
    watchdog.start();
    api.start();
    updater.start();

    while(true) {
        Thread::wait(100);
    }
}