Но в таком случае невозможно будет СРОЧНО перейти от обработки одной задачи к другой (по прерыванию или опросу флага). Придётся заканчивать обработку текущей задачи, всё сохранять в массивы, и уже затем переходить к следующей.
Или я что-то не понимаю?

Простейшая организация задачи:

Т.е контекст не переключается вовсе. И текущая задача может прерваться в заранее известных местах, не прерывая атомарных операций.Но это в простом случае.
Сложнее - никто не мешает "навернуть" эту конструкцию без использования оси.
В общем -кооперативная многозадачность.

Да, именно это я имел ввиду, но расстояние между такими местами (в тактах) может оказаться недопустимо большим. Или, к примеру, чтобы его уменьшить придётся идти на усложнение кода - скажем не просто на выход идти, а на "специальный выход именно из этого места". А ещё я обычно запоминаю точку (её адрес) в которой данная задача была прервана. Но код, при такой манере программирования, сложно изменять становится.
Хотя, если посмотреть, то у меня во всех проектах именно так и сделано (по подобной схеме и без оси).

К сожалению, кооперативные многозадачки на асме выглядят намного прямее, короче и читабельнее.
Такшта, может на ARM asm ?

А почему к сожалению?

Да, другой дороги видимо нет.

Посчитаем: 10 см дают задержку импульса где-то на 30 нс, для вашего 125 нс такта это где-то 25%. Если вам так важна полная фазировка, надо принимать соотв. меры. Можно, например, уменьшить размер проводника 8 МГц, разместив генератор в середину платы, а по четырём сторонам вокруг него расположить по 3 МК. Ну или сделать отдельные линии для каждого МК и выровнять все пути от генератора до всех МК, чтобы задержки были одинаковыми. В начале и конце каждой линии поставить по инвертору.


Не понимаю вашей идеи, зачем нужен триггер? Все 12 МК можно засинхронизировать по одному проводу безо всяких триггеров с точностью до перехода 0-1.

Петли, как на материнских платах, я разведу. Спасибо за совет. Но инверторы зачем? Да ещё по два.

Да они и будут синхронизироваться по одному проводу с точностью до такта (за два фронта синхросигнала). По первому фронту с точностью в 2 такта, и по второму уточнятся до такта. А триггер для того, чтобы сигнал синхронизации засинхронизировать с тактовым сигналом (изначально они не синхронны). Если так не делать, то фронт синхросигнала может попасть на границу тактов, и из-за небольшой разницы в фазах по процессорам, которая всётаки будет, один процессор может воспринять его в одном такте, а другой в другом.

Несмотря на то, что ARM семейство многочисленное и загнать себя асмом в угол тяжело, есть ведь и всякие DSP56xxx, dsPIC33xxx например...

Чем больше контроллеров в системе, тем выше вероятность сбоев и меньше её надёжность. А отладить такую систему просто кошмар. Теоретичести, скажем, mp3-декодер можно сделать на 20-и мегах, но трудоёмкость будет просто не оправдана. Разве что ради спортивного интереса.

Можно и без них, зависит от ваших требований к рассогласованию по фазе, скажем, 10 нс и 0.1 нс немного разные вещи. Инверторы развяжут и согласуют, согласитесь, одну линию легче проконтролировать, чем пучёк из 12. Ну поставьте 12 инверторов в начале, если будет всё нормально, кинете перемычку.

Всё равно не понимаю. Если будет разница в фазах, то триггер вам не поможет.

Вообще похоже, мы о разных вещах говорим. Когда я говорю засинхронизировать микроконтроллеры, я подразумеваю, что одинаковая программа будет выполняться на всех МК такт в такт.

Да, именно так. Во всех процессорах программа в один и тот-же такт должна начинаться и заканчиваться. Момент этого самого начала определяется по специальному сигналу синхронизации. Но этот сигнал внешний, и с тактовым генератором не связан. Поэтому его фронт может по периоду тактовой частоты гулять. Это может привести к рассинхронизации процессоров на 1 такт. А D-триггер обеспечит одновременность фронтов у тактового сигнала процессоров, и сигнала синхронизации этих процессоров. На вход данных D-триггера подаём внешний синхросигнал, на вход C - тактовый сигнал, и с выхода получаем, засинхронизированный по тактовому сигналу, внешний синхросигнал.

В аврках все входные процессы синхронизируются с тактовой частотой проца, что поделаешь, такая архитектура. Подаёте ваш сигнал на одинаковые пины всех процов и ваш сигнал легко синхронизируется внутре.

Начинаться в один такт она сможет, а вот заканчиваться - большой вопрос. Данные поступают разные, в какой-то AVR команда, к примеру BREQ, выполнится при 0, а в другой AVR нет. Число тактов получится разное, процесс рассинхронизируется. Или у вас строго линейный алгоритм (как в первых DSP)?

2=GM=
Начать выполнение программы одновременно не так просто. Даже если 2 процессора только тем и занимаются, что фронт внешнего сигнала ловят, то тут как ни крути точность в 2 такта получится. Т.к. никоим образом програмно считывать и анализировать состояние порта чаще чем 1 раз за 2 такта не получится. Но за 2 раза вполне можно с точностью в такт уложится. Тут мог-бы вход захвата таймера помочь, но я пока на железке не проверял, а описаниям не доверяю, как-то туманно в них всё написано.

Нет. Я таймер запущу.

Жесть!
Прошу прощенья за ремарку. Присоединюсь к предложению поставить более мощный контроллер. Выиграете во всех без исключения смыслах.
Я бы, правда, порекомендовал DSP.

По теме (хотя здесь это и не совсем к месту).
На выход генератора обязательно нужно ставить буфер. Проще всего взять 6-гейтовый буферный инвертор типа 74AC04. Расположить рядом с генератором. К каждому выходу буфера подключить два тактовых входа. Провода желательно тянуть от буфера отдельно для каждого из входов.
Собственно, согласование при такой длине проводников не играет особой роли. Однако, на каждую трассу следует поставить последовательный резистор 50-100 Ом для уменьшения добротности резонирующей цепи, обусловленной индуктивностью дорожки и ёмкостью входа приёмника. Резисторы располагать в непосредственной близости от выводов буфера.
Усё.