Есть N изделий с иксмегами и мс.флеш на борту.
Флэшки 1-2 мегагигабитники.
Надо организовать автоматическиое перепрограммирование флешей (дублирование оригинала на копию/и)
Нужно что бы чел. выбрал одно изделие в качестве оригинала (планирую DIPswich)
а остальные N шт. в качестве подчинённых, нажал кнопку и содержимое флэшки оригинала скопировалось на все подчинёные.
Как бы организовать обмен ??? SPI, TWI, COM ???
Каждое изделие имеет свой ID.
Любое из изделий может быть как мастером так и подчинённым.
У меня идеи есть, но не хочется изобретать велосипед.
Может есть наработки в этом плане?

Слишком мало конкретики: какие флешки, какой у них интерфейс, какая серия?


Флешки с COM-портом? Как называются?

Какая разница? проц знает как и что писать.


Надо связать несколько иксмег, передать содержимое флэши одного изделия в другое/ие.

Может достаточно просто кнопки на каждом устройстве? На каком нажал - тот и мастер. Мастер начинает обмен, остальные автоматом становятся слейвами. Я бы делал на UARTe, как самом простом из перечисленных трех.

А чем SPI плох, проще уж некуда. А если ему буффер привесить типа MAX13235E и быстро и далеко.

Устройств там N шт. Значит кроме трех линий собственно SPI понадобятся еще провода CS от каждого к каждому, ибо кто будет назначен мастером заранее неизвестно. В случае же UARTа можно обойтись одной линией с подтяжкой, которую все будут слушать и передавать открытым коллектором.

Это не принципиально.

То же склоняюсь к такому мнению.


Ну да, линий хочется поменьше.
С комом вроде бы всё красиво, но получается что все RX и TX будут соединены.
Для слейвов всё ок, а вот у мастера нужно наоборот.
Думаю использовать в каждом изделии по два компорта у которых RX первого соединён с TX второго а TX перв. с RX второго и в завмсимости от мастер/слейв активизировать нужный ком.
Но блин жалко два компорта под это дело занимать.

Интерфейс LIN...
У меня статья была про микроконтроллеры НЕК, там про этот интерфейс немного написано...
Удачи.

Не пойму что конкретно Вы предлагаете?



Ничего дополнительного вешать нельзя (бюджет ограничен).
Покумекал немного и действительно SPI лучше всего, да и на скорости 2 мегабита понадёжнее UARTA будет.
И поскольку в режиме SPI выходы настраиваются вручную, то у всех слейвов MISO всегда будет откр.коллектор и настраиваться на выход только по требованию мастера и не более одного.
Только раньше не делал ничего подобного.
Как думаете получится?

ЗЫ. я в топике чуток ошибся, не 1-2 мегабитники а 1-2 гигабитники

Используйте RS-485. Один UART каждого контроллера, через буфер ADM3485 или аналогичный все на общую шину соединяются, и ещё от контроллеру к буферу ещё одна линия нужна - разрешение передачи. Связь полудуплексная. То есть передаёт в каждый момент только один. Мастер передал команду - один из ведомых ответил. И так далее.
При маленьких расстояниях согласующие резисторы на концах шины RS-485 не обязательны.

В принципе идея хорошая, если бы это было нужно делать часто.
Но ставить дополнительный чип и в каждое изделие и только лишь для того что бы записать его флеши?
В большинстве случаях это будет делаться один единственный раз при производстве.
Это не наш метод!

ЗЫ. панельку ставить - не предлагать

Тогда, как предлагалось выше в теме, соединяйте вместе все RX и TX всех контроллеров. И подтяжку на + резистором на всякий случай, что уровень не плавал.
Здесь важно чтобы в каждый момент времени все контроллеры кроме не более чем одного переводили свою TX ногу в третье состояние. Такой вариант на самом деле мало отличается от RS-485. Протокол и логика работы точно такие же.

Для такаго варианта самое оно - это использовать драйвер CAN как приемо-передатчик, причем внешний и только для такого программирования, а остальное, да, кнопочка на мастере и вперед...
Передачу данных сделать аля широковещательной для одновременного программирования, потом контроллировать только CRC от слэйвов всей области либо кусками.

Либо вообще тупо , соединить ВСЕ RXD и TXD вместе на всех устройствах и между собой в подобие однопроводной шины и настраивать TXD на выход только в моменты ответа конкретного устройства... Ничего внешнего вообще не понадобится, как и предлагалось выше. И подтяжку просто включить на каждом RXD.

Про тип флешей нам ничего не известно. Но гигабитники вполне могут иметь на борту JTAG, вывести его на разъем и через него программировать внешним программатором на производстве. Зачем делать замороку с прошиванием через проц?
Второй вариант, если JTAG-а нет. Прошивать в проц специальную прошивку, а потом через любой уже доступный наружу интерфейс с компа заливать прошивку во флешь.
Еще вариант, если флешь подключена по последовательному интерфейсу, то вывести наружу его и, опять же, внешним программатором шить.

Еще непонятна фраза "дублировать оригинал на копию", это что имелось в виду? Что есть одно устройство с некой прошивкой во флешь и ее надо зашить в остальные устройства? Тогда по любому из выше названных вариантов сливаете содержимое флешь на комп и далее прошиваете в остальные.

Вот тоже хотел вчера расписать этот вариант. А ОК на выходе предлагал, чтобы после передачи все слейвы могли ответить одновременно. Ответ 0xFF - удалось записать блок, ответ 0x00 - не удалось. И пока мастер получает ответ отличный от 0xFF - он повторяет блок. Получится, что все слейвы получают блок одновременно и пишут его параллельно, таким образом сокращается общее время и обмена и записи. Естественно, посылка блока должна содержать адрес блока и CRC. Слейвы, успешно записавшие блок с последним адресом игнорируют следующие посылки пока не пойдет посылка с новым адресом блока.

Нафинг?
Все вместе пишут.
Упс .... Это уже обсуждается

Слейвы, успешно НЕ записавшие блок в дальнейшей раздачи не учавствуют , а то найдётся один , который ни в какую писать не захочет - всё висяк. Пусть уж как-то индицируют , что не прошла запись.

Ну хоть пару попыток надо ему дать? Мало ли - блок принят с ошибкой. Но это уже детали реализации.

Тут асинхронная передача

одновременно не получится.
Я еще обычно перед записью проверяю, а надо ли вообще что-то записывать, так уменьшается износ флэша...

Если все отвечают на один запрос и в момент запроса уже ничем кроме него не заняты, то 0xFF от не-0xFF мастер отличит. Зато ему не нужно знать адреса слейвов и их количество.

Идея хорошая. Но не хочется бы что бы слейвы "слышали" друг друга (хочется потокол попроще).



Обычная Parallel Flash Macronix или Spansion.
JTAG-ов нет.

Я как раз и хочу реализовать это для того чтобы максимально упростить процесс и
избежать любого использования компа (в поле например), только шлейфик пинов на 6 pin to pin!




Нафига это надо?
Считаю что если слейв по какой либо причине не может записать свою флэш мастеру это по барабану - это проблема слейва. В ремонт его надо!
А то что запись не прошла будет понятно когда слейв включат в рабочем режиме.

Соединяете вместе RX всех ведомых - и к TX мастера. Соединяете вместе TX всех ведомых - и к RX мастера. Ведомые слышать друг друга не будут.

Тогда ещё проще, достаточно одной линии - соединяете вместе RX всех ведомых - и к TX мастера. Мастер отправлет первый пакет. Ждёт сколько по даташиту на флэш достаточно для записи. Отправляет ещё пакет. И так далее.

Я об этом писал :Сообщение #7


Соединяю всместе где? Спец кабель должен быть?
Хочу кабель пин то пин чтоб любой юзверь смог сделать.


Это уже перебор простоты

Вобщем останавливаюсь на SPI. Всем спасибо.

А у этих N-девайсов нет интерфейса, которым они наружу или друг с другом общаются во время нормальной работы? Почему бы не использовать этот интерфейс?

Да, да SPI , сами же себе противоречите...

Ну, успехов тогда.

Поменьше но без фанатизма
Три линии меня вполне устраивает, и протокол не сложный.

Ну, ОК тогда.


Есть обычный ком порт на 9600.
В режиме перепрограммирования нужна скорость 2000000.
Процессоры тактируются от внутр. RC 32MHz c автоподстройкой частоты от часового кварца.
Боюсь на скорости 2Mb/s будут проблемы.

Девайсы получают команду на перепрограммирование на скорости 9600 - и перенастраиваются на 2000000 -3 - 4000000. И могут спокойненько на сихронном режиме........

Всё равно нужно три линии да и RX/TX на мастере нужно где то переворачивать.

А почему Вы против SPI?

Да я не против SPI. Есть ведь USART вот и прикинул. Кстати USART может работать как нормальный SPI , но линию SCK -выводить придётся