Избегайте глобальных переменных во встроенном программировании

Если вы хотите сначала протестировать такой код, я бы порекомендовал прочитать Работа Эффективно с устаревшим кодом См. также это.

По сути, использование компоновщика для вставки фиктивных/фальшивых объектов и функций должно быть последним средством, но все же вполне допустимо.

Однако вы также можете использовать инверсию управления, без фреймворка это может возложить некоторую ответственность на клиентский код. Но это действительно помогает тестировать. Например, чтобы проверить FSW_taskStart()

tThreadConfig threadConfig[NUM_THREADS] = {
  { "Foo 1", %foo1, 0, ... },
  { "Foo 2", %foo2, 0, ... },
  { "Task",  %task, 0, ... }
};

void FSW_taskStart(tThreadConfig configs[], size_t len) {
    for (int i = 0; i < len; i++) {
        configs[i].taskptr->createThread(  );
    }
}

void FSW_taskStart() {
    FSW_taskStart(tThreadConfig, NUM_THREADS);
}

void testFSW_taskStart() {
    MockTask foo1, foo2, foo3;
    tThreadConfig mocks[3] = {
          { "Foo 1", &foo1, 0, ... },
          { "Foo 2", &foo2, 0, ... },
          { "Task",  &foo3, 0, ... }
        };
    FSW_taskStart(mocks, 3);
    assert(foo1.started);
    assert(foo2.started);
    assert(foo3.started);
}

Теперь вы можете передать фиктивную версию ваших потоков в FSW_taskStart, чтобы убедиться, что функция действительно запускает потоки по мере необходимости. К сожалению, вам приходится полагаться на тот факт, что оригинальный FSW_taskStart передает правильные аргументы, но теперь вы тестируете намного больше своего кода.

Поможет ли внедрение зависимостей в вашей ситуации? Это могло бы избавиться от всех глобальных переменных и позволить легко заменять зависимости в ваших модульных тестах.

Каждой основной функции потока передается карта, содержащая зависимости (драйверы, почтовые ящики и т. д.), и она сохраняет их в классах, которые будут их использовать (вместо доступа к какой-либо глобальной переменной).

Для каждой среды (целевой, симулятор, модульный тест...) вы создаете одну функцию «конфигурации», которая создает все необходимые объекты, драйверы и все потоки, предоставляя потокам их список зависимостей. Например, целевая конфигурация может создать USB-драйвер и внедрить его в какой-либо поток связи, а тестовая конфигурация модуля связи может создать заглушку USB-драйвера, которым будут управлять тесты.

Если вам абсолютно необходима эта «прозрачность» для важных переменных, создайте для них классы, которые будут хранить их по известному адресу, и внедряйте эти классы там, где это необходимо.

Это немного больше работы, чем статические списки объектов, но гибкость фантастическая, особенно когда вы сталкиваетесь с некоторыми сложными проблемами интеграции и хотите поменять местами компоненты для тестирования.

Грубо:

// Config specific to one target.
void configure_for_target_blah(System_config& cfg)
{   // create drivers
    cfg.drivers.push_back("USB", new USB_driver(...))
    // create threads
    Thread_cfg t;
    t.main = comms_main; // main function for that thread
    t.drivers += "USB"; // List of driver names to pass as dependencies
    cfg.threads += t;
}

// Main function for the comms thread.
void comms_main(Thread_config& cfg)
{
    USB_driver* usb = cfg.get_driver("USB");
    // check for null, then store it and use it...
}

// Same main for all configs.
int main()
{
    System_config& cfg;
    configure_for_target_blah(cfg);
    //for each cfg.drivers
    //    initialise driver
    //for each cfg.threads
    //    create_thread with the given main, and pass a Thread_config with dependencies
}

Вы можете выделить память, используя malloc, а затем получить новый оператор, чтобы сделать объект в этой позиции

void* mem = malloc(3*sizeof(SomeClass));
SomeClass *a = new(mem) SomeClass();
mem += sizeof(SomeClass);
SomeClass *b = new(mem) SomeClass();
mem += sizeof(SomeClass);
SomeClass *c = new(mem) SomeClass();

поэтому вы можете выделить всю память, а затем выделить ее по своему усмотрению. Примечание: убедитесь, что вы вызываете деконструкцию вручную, так как это не происходит при вызове удаления.