12 ATmega48 от одного тактового генератора (внешнего)., Можно ли провести 8 Мгц по всей плате? Опции

[galjoen]

Есть одна задача, требующая достаточно больших вычислений, но легко параллелящаяся на 12 потоков. Если можно установить 12 штук ATmega48 (или 88), работающих от одного внешнего тактового генератора, то задача очень красиво решается (питание процессоров 3В тактовая частота 8Мгц). Я понимаю, конечно, что можно использовать внутренние тактовые генераторы и их частоту подстраивать по внешнему сигналу. Но это не то. Частота совпадёт, но фаза будет отличатся, а необходимо именно совпадение фазы тактового сигнала.
Вобщем получается, что нужно около 100мм печатного проводника с частотой 8 Мгц по плате провести. Можно ли как-нибудь такое сделать? Ну там параллельно с обоих сторон землю провести, или ещё как? И как там со всякими затуханиями? И нужен ли терминальный резистор? Я в этих вопросах полный профан.

[domowoj]

10 см проводника с 8 Mhz, ИМХО, не самая страшная проблема ,
труднее будет добиться синхронизма вашего устройства.

[galjoen]

10 см проводника с 8 Mhz, ИМХО, не самая страшная проблема ,
труднее будет добиться синхронизма вашего устройства.

Если будет один тактовый генератор, то синхронизма я добьюсь. Вот тут и пригодится полностью синхронная архитектура АВР. А вот если тактовые генераторы будут разными, то с синхронизацией проблемма... Тогда уж лучше на каком нибудь одном 150 Мгц процессоре делать.

[_Pasha]

Дорожки с 8 МГц можно до 150 мм вести, если вспомнить ПК "Специалист" и его клоны
Синхронизм портится только по Power Up. А внешним ресетом его как раз и можно поднять. Имхо.

[slog]

8MHz "детская" частота. Тяни не бойся. Драйвер должен обеспечить нагрузочную способность достаточную для 12 входов. Ну и земля должна быть хорошая от всех процов, да и согласовать на конце тактовую линию не помешает. "На всякий случай".

[galjoen]

Дорожки с 8 МГц можно до 150 мм вести, если вспомнить ПК "Специалист" и его клоны
Синхронизм портится только по Power Up. А внешним ресетом его как раз и можно поднять. Имхо.

А вот какой выход у генератора тактовой д.б.? Нужно ли там резистор 100 Ом ставить чтоб слегка фронты завалить? А на другой стороне этого провода нужно ли два резистора один на питание, другой на землю ставить?
А для синхронизации там специальный сигнал будет. Он там есть уже, только в этом случае его через D-триггер пропустить придётся для синхронизации с тактовой частотой. А за 2 периода этого сигнала с точностью до такта засинхронизировать все процессоры не проблема.

8MHz "детская" частота. Тяни не бойся. Драйвер должен обеспечить нагрузочную способность достаточную для 12 входов. Ну и земля должна быть хорошая от всех процов, да и согласовать на конце тактовую линию не помешает. "На всякий случай".

А вот как эту линию согласовывать? У меня ведь не кабель, волновое сопротивление неизвестно. Хотя если и известно было-бы я всё равно в этом деле профан. Знаю только, что у RS485 и CAN на концах кабеля резисторы ставят, а вот у USB нет. Хотя вроде все кабели и сигналы в них у USB и RS485 аналогичны.

[bzx]

А почему бы не рассмотреть замену 12mcu на 1mcu с достаточной производительностью? Если посчитать стоимость этих 12mcu + стоимость их установки, то это в любом случае будет выгоднее использовать один камень, но более производительный.

[galjoen]

А почему бы не рассмотреть замену 12mcu на 1mcu с достаточной производительностью? Если посчитать стоимость этих 12mcu + стоимость их установки, то это в любом случае будет выгоднее использовать один камень, но более производительный.

12 штук ATmega48 - это менее чем $12. Причём там уже есть и ОЗУ, и FLASH для программ, и всё, что нужно для работы. Программируются они по 1 проводу, т.е. 12 двухконтактных разъёмов для программирования добавляется. Реальная замена всему этому - это АРМ, работающий из ОЗУ. Что-то типа AT91RM9200. Он один стоит в разы дороже, чем все эти меги, а к нему ешё и быстрое ОЗУ нужно, и FLASH, из которой он загружаться будет, и плата там 4х слойная получается. Да вроде и правило такое, что цена возрастает быстрее, чем производительность. Но вот только не все задачи так легко распараллеливаются как эта.

[_Pasha]

А цепочкой там проще не выйдет ? (clko -> clki)
Так, по-идее там достаточно только ТТЛ-выход и никаких терминаторов не надо. Но это было на макс. 4 ТТЛ входа... Надо подумать.

[galjoen]

А цепочкой там проще не выйдет ? (clko -> clki)

Думал я насчёт цепочки. Но вроде каждая мега задержку в тактовый сигнал вносить будет. И к последней тактовая со значительным сдвигом по фазе прийдёт. И вся синхронизация рушится.

Так, по-идее там достаточно только ТТЛ-выход и никаких терминаторов не надо. Но это было на макс. 4 ТТЛ входа... Надо подумать.

Ну можно к одному ТТЛ-выходу ещё 3 ТТЛ-входа инверторов (или повторителей - неважно) подключить, а уже к каждому из их выходов по 4 процессора. Единственный момент, что питание там 3,3 вольта, но современная логика вроде хорошо от такого напряжения работает. Я вообще-то с логикой со времени синклеров дела не имел, всё как-то без неё удавалось обойтись. А терминаторы хоть и ставлю, но зачем - для меня загадка.

P.S. Там ещё 13й процессор поставить придётся. Он будет обработанные данные у этих собирать, буферизировать и дальше отправлять. Какой нибудь с возможностью аппаратного подключения внешнего ОЗУ желательно. Даже ATmega64 подойдёт.

[bzx]

12 штук ATmega48 - это менее чем $12.

Если уж начали считать, то сюда надо добавить и стоимость работ по монтажу, ну и стоимость платы под этими mcu.

Будем считать, что Вам повезло, и стоимость точки-пайки на автомате (подготовка к производству не учитывается) обходится в 16коп. Так же считаем, что Вы заложили самый маленький корпус - MLF28. Всего точек паек 28*12=336, тогда стоимость сборки 336*0.16=~54р.

Размер корпуса MLF28 - 4 x 4 мм, зазор по установке между корпусами компонентов на pcb пусть 2.5 мм, тогда площадь платы под 12mcu 12*(4+2.5) *(4+2.5)=~500мм^2. Будем считать, что у Вас заказ в несколько десятков дм^2, тогда при данном заказе стоимость 1 дм^2 можно условно принять в 100р. Стоимость платы под 12mcu = 100*0.05=5р

Итого затраты 54+5=59р и это минимум, скорее всего в Вашем случае будет в разы больше. Это ещё $2 к Вашим $12.

Реальная замена всему этому - это АРМ, работающий из ОЗУ. Что-то типа AT91RM9200.

На самом деле RM9200 уже староват, есть более удачные камни и с приличным быстродействием, и со встроенной flash.

PS: чем больше в вычислительной связке mcu, тем больше геморроя будет и при запуске, и на серии.
PS: По питанию 12mcu так же проиграют одному более шустрому камню

[defunct]

12 штук ATmega48 - это менее чем $12. Причём там уже есть и ОЗУ, и FLASH для программ, и всё, что нужно для работы. Программируются они по 1 проводу, т.е. 12 двухконтактных разъёмов для программирования добавляется. Реальная замена всему этому - это АРМ, работающий из ОЗУ. Что-то типа AT91RM9200.

С чего вы взяли что именно этот АРМ?

Реальная замена всей вашей требухи из 12-ти M48 @8Mhz - это LPC2101(2KB sram/8KB flash)@72Mhz который стоит 2$.

P.S. Там ещё 13й процессор поставить придётся. Он будет обработанные данные у этих собирать, буферизировать и дальше отправлять. Какой нибудь с возможностью аппаратного подключения внешнего ОЗУ желательно. Даже ATmega64 подойдёт.

Решили науку двигать? Научитесь вначале делать обзор существующего.
Берем LPC2106 - гонится до 110Mhz, ОЗУ 64KB, Flash 128KB, корпус 48ног, стоит ~7$
потенят всю вашу задачу как пить дать.

[dENIM]

шайтан-устройство
MegaCELL

[galjoen]

2 'defunct', 'bzx'
Там проблемма в том, что между задачами очень часто переключаться придётся. За 50 mks всем 12 задачам нужно управление передать (а в идеале в 4 раза чаще). При тактовой частоте 100 Mhz это 5000 тактов на всё. Т.е. в среднем 417 тактов на задачу. Из этих 417 тактов, думаю, тактов 80 сохранение и восстановление регистров и переменных займёт. Т.е. собственно на задачу 300 с небольшим тактов останется.
А в случае с 12 мегами на 8 Mhz - 400 тактов, и ничего сохранять-восстанавливать не надо. Ну, по питанию там всё примерно одинаково. Мега в таком режим примерно 4 ма кушать будет.
Хотя я понимаю, что на одном процессоре всё это легче сделать. Но вот красота при этом пропадает...

[_Pasha]

Но вот красота при этом пропадает...

Зачем переключать контексты если можно все данные свести к массивам, а дерево алгоритма потока - к switch(state[task_num]) ?

[galjoen]

Зачем переключать контексты если можно все данные свести к массивам, а дерево алгоритма потока - к switch(state[task_num]) ?

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

[_Pasha]

Придётся заканчивать обработку текущей задачи, всё сохранять в массивы, и уже затем переходить к следующей.
Или я что-то не понимаю?

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

Код

uint8_t task(uint8_t tasknum)
{
/*
подразумевает, что Вы обращаетесь с данными, описанными в виде static массивов
в любой момент можете нас.ать на плохое отношение к goto
и при желании выйти из задачи написать goto exit_task
*/
exit_task:
               return 0; // возвращаемое значение может показывать какой-нить статус задачи
}

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

[galjoen]

И текущая задача может прерваться в заранее известных местах, не прерывая атомарных операций.

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

[_Pasha]

Да, именно это я имел ввиду

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

[galjoen]

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

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

Такшта, может на ARM asm ?

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

[=GM=]

...нужно около 100мм печатного проводника с частотой 8 Мгц по плате провести

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

А для синхронизации там специальный сигнал будет. Он там есть уже, только в этом случае его через D-триггер пропустить придётся для синхронизации с тактовой частотой

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

[galjoen]

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

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

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

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

[_Pasha]

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

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

[МП41]

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

[=GM=]

Но инверторы зачем? Да ещё по два

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

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

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

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

[galjoen]

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

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

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

[=GM=]

Момент этого самого начала определяется по специальному сигналу синхронизации. Но этот сигнал внешний, и с тактовым генератором не связан

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

[Nanobyte]

...Да, именно так. Во всех процессорах программа в один и тот-же такт должна начинаться и заканчиваться. ...

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

[galjoen]

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

Или у вас строго линейный алгоритм (как в первых DSP)?

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

[Stanislav]

Есть одна задача, требующая достаточно больших вычислений, но легко параллелящаяся на 12 потоков. Если можно установить 12 штук ATmega48 (или 88), работающих от одного внешнего тактового генератора, то задача очень красиво решается (питание процессоров 3В тактовая частота 8Мгц)...

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

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

[ae_]

Посчитаем: 10 см дают задержку импульса где-то на 30 нс ...

10 см это 0.33 нс, что для 125 нс (8МГц) не существенно.

[_Pasha]

2=GM=
Начать выполнение программы одновременно не так просто.

Я Вас умоляю!
Берете Int0 - на него вешаете "готовность номер 1"
Int1 - собственно синхронизация, и его надо подать в течение времени не более, скажем 1 мкс, иначе
все опять придет в начальное состояние.

Код

.org 0
rjmp start
rjmp int0_isr
rjmp int1_isr
;..........
start:
; config SFR

forever:
              wdr
              rjmp forever
int0_isr:
              sei
              nop
              nop
; натыкать нопов столько сколько надо  чтобы гарантированно отработалась точная синхронизация
              rjmp forever; кто не успел-тот опоздал
int1_isr:
              sei
; начало Вашей суперзадачи

Где-то так

[galjoen]

На выход генератора обязательно нужно ставить буфер. Проще всего взять 6-гейтовый буферный инвертор типа 74AC04. Расположить рядом с генератором.

Я примерно в таком духе и планировал сделать, на 74AC04. На двух из шести его инверторов генератор сделать, а остальные как буфера использовать. Т.е. к каждому из буферов через резистор по 3 тактовых входа подключить. Вот только к каждой меге свой провод тянуть проблематично. Думал может там (около входа меги), вместо этого, тоже резистор 50..100 Ом поставить для исключения взаимовлияния?

Я Вас умоляю!
Берете Int0 - на него вешаете "готовность номер 1"
Int1 - собственно синхронизация, и его надо подать в течение времени не более, скажем 1 мкс, иначе
все опять придет в начальное состояние.

В качестве "готовности N1" и собственно синхронизации можно один сигнал использовать. Нулевой уровень которого будет готовностью N1, а переход 0-1 собственно синхронизацией. Завести его на int0 и прерывания по 0му уровню разрешить. А в самом прерывании переинициализировать прерывание int0 на срабатывание по переходу 0-1, ну и цепочка nop-ов. Ну ещё там, в прерывании, придётся смотреть как оно сейчас проинициализировано (от чего произошло), ну и стек там подправить (как впрочем и в вашем случае).
Но всётаки способ со входом захвата таймера лучше. Если получится конечно. А судя по описанию получится должно. Но попробовать надо.

А вообще я конечно понимаю, что на одном процессоре это легче сделать. И всю эту тему поднял только для того, чтобы все варианты рассмотреть. Но сейчас как-то втянулся. Думаю так: ну сделаю я всё это на каком-нибудь АРМе, ну будет ещё одно устройство, каких много. А вот если на 12 мегах сделать - это будет круто! Какой ещё дурак до такого додуматься сможет? Когда ещё такая задача подвернётся? М.б. и никогда... А проигрыш в $5 и 10 кв. см платы - это ерунда. Таких девайсов точно много не будет. Десятки, ну м.б. несколько сотен.
Ну вобщем взвешиваю все за и против...

[_Pasha]

В качестве "готовности N1" и собственно синхронизации можно один сигнал использовать. Нулевой уровень которого будет готовностью N1, а переход 0-1 собственно синхронизацией. Завести его на int0 и прерывания по 0му уровню разрешить. А в самом прерывании переинициализировать прерывание int0 на срабатывание по переходу 0-1, ну и цепочка nop-ов.

Стоп-стоп! На кой ему тогда переход в "готовность 1" делать по прерыванию ? Просто поллинг пина, затем переход к нопам. И стек не обеднеет оттого что у него съели 2 байта.
Попутно замечу, что по сбросу можно делать тестирование МК и выдавать сигнал "тест ок"

А вот если на 12 мегах сделать - это будет круто!

Лично я не знаю, как там крутизна, но если посмотреть на групповые абонкомплекты цифровых АТС - количество микрух пугать не должно.

[galjoen]

Стоп-стоп! На кой ему тогда переход в "готовность 1" делать по прерыванию ? Просто поллинг пина, затем переход к нопам.

Если сделать по прерыванию, то можно фоновые задачи в свободное время запускать.

И стек не обеднеет оттого что у него съели 2 байта.

Ну это только первые несколько раз. А такие синхронизации около 100 раз в секунду проходить будут.

Задача, в основном, состоит в том, чтобы от 12 аналоговых, гальванически развязанных, сигналов всякие там среднеквадратические вычислять + на табличные значения помножать и перерабатывать + передавать результаты. Так-то требования небольшие, но это всё строго синхронно делать надо. Я хотел 2 сшестерённых сигма-дельта АЦП использовать (аналог девайс), но оказывается нельзя - гальваноразвязка. Вот и думаю, пусть каждая из мег со своим гальваноразвязанным АЦП работает. В идеале и АЦП на меге-бы сделать, но скорости-разрядности не хватает. А м.б. ко мне уже в цифровом виде эти сигналы прийдут - сейчас решается.