Алгоритм прикидывается в табличке. Реализовал такое по
последовательному интерфейсу. Идёт обмен кадрами между МК. Размеры
кадров фиксированы. Кадры поделены на управляющую часть, данные
реального времени и пакетную часть для данных, не критичных ко
времени. В части кадра с управлением, передаются флаги запросов на обновление того или иного типа данных (данные поделены по группам, чтобы можно было проводить разнонаправленную синхронизацию в пределах одного цикла обмена). Данные реального времени передаются каждый кадр, поэтому синхронизируются быстро. Менее критичные к скорости данные, собираются в пакеты из нескольких кадров и подписываются отдельно для контроля верности сборки пакета.
Набор данных общий. Любая сторона может запросить изменения. Та сторона, которая вносит изменения, сначала взводит флаг запроса на изменение на своей стороне. Этот флаг блокирует местные данные от перезаписи данными от другой стороны. Затем МК вносит желаемые изменения и в следующем кадре или пакете, взводится флаг запроса на изменение к противоположной стороне.
Приняв в кадре флаг запроса на изменение, принимающая сторона либо сразу вносит изменения из данных реального времени или ожидает завершения сборки текущего пакета данных, после чего принимает изменения. После успешного приёма данных и внесения изменений по запросу, принявшая запрос на изменения сторона, взводит флаг подтверждения приёма изменений. И лишь приняв подтверждение изменений данных, инициировавшая изменения сторона, снимает свой флаг запроса/блокировки.
Возможна ситуация, когда обе стороны поднимут свои запросы на один и тот же тип данных. В таком случае, чтобы не зависнуть без подтверждений, одна из сторон либо всегда принимает и подтверждает запросы безусловно, либо всегда подтверждает, даже отказавшись принять. В зависимости от того, какое направление передачи данных этого типа приоритетное (приоритеты нужно расставить).