У меня есть прошивка C, которая реализует ведомый Modbus. Как только моя команда RTU (скажем, func 03 «чтение регистра») получена, я просто иду в LUT и выбираю данные, которые мне нужно вернуть. Мои структуры данных являются глобальными. Мой массив выглядит примерно так:
int* modbusLUT[]={
&motorControl_t.counter.degrees,
&motorControl_t.counter.dir,
&glueControl_t.nozzle.temp,
&paintControl_t.hopper.level,
...
};
и я строю ответ Modbus примерно так:
temp = *modbusLUT[startAddr+j];
...
это одна нить код работает отлично и довольно эффективно.
Сейчас я пишу отдельный код «системного менеджера» на C ++, который необходим без заголовка, и он тоже должен действовать как раб Modbus. Я намерен обернуть механику системы в три класса. Каждый класс создается в куче и начинает его собственный поток в ожидании событий от main (). Что-то вроде этого:
m_ptrMotorMachine = new CMotorMachine();
m_ptrGlueMachine = new CGlueMachine();
m_ptrPaintMachine = new CPaintMachine();
...
m_ptrGlueMachine->m_pThread->PostThreadMesageA(SW_PART_IN_PLACE,0,0);
Мне нужны параметры (переменная-член) из всех трех доступных классов, чтобы мой обработчик modbus мог обращаться к ним и читать / записывать их … В идеале, как и в массиве C выше.
Итак, как я могу безопасно сделать что-то вроде выше в C ++? Нужны замки? Псевдокод примерно так:
class CModBusSlave{
void initLUT()
{
int* modbusLUT[]={
&m_ptrMotorMachine->velocity,
&m_ptrMotorMachine->accel,
&m_ptrGlueMachine->psi,
&m_ptrPaintMachine->stroke,
...
};
};
};
Любые мысли или альтернативные проекты высоко ценится.
если бы я понял вашу проблему, вам не нужно реализовывать какой-то многопоточный механизм, с многопоточностью вы должны беспокоиться, когда ресурсы конкурируют, с протоколом Modbus у вас есть отдельные адреса и регистровые адреса, а механизм связи — ответ / ответ основан на том, что мастер просит что-то сделать, и только заинтересованный раб делает это по адресу примечания.
Вы можете использовать свой поток для обработки информации и использовать менеджер, чтобы запустить соответствующий поток. нет параллелизма, если вы строго соблюдаете стандартный протокол, так что вам не придется сильно волноваться.
Может быть, мы можем подумать о чем-то, когда вы определите, что именно будут делать ваши темы.
если у вас нет особых проблем, я думаю, что ваш однопотоковый вариант будет достаточно хорош!
Других решений пока нет …