Авто перепрограммирование флешей в устройствах, как бы сделать Опции

[zombi]

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

[_Артём_]

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

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

Как бы организовать обмен ??? SPI, TWI, COM ???

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

[zombi]

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

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

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

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

[Сергей Борщ]

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

[zombi]

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

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

Я бы делал на UARTe, как самом простом из перечисленных трех.

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

В случае же UARTа можно обойтись одной линией с подтяжкой, которую все будут слушать и передавать открытым коллектором.

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

[maksimp]

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

[YAM]

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

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

[Сергей Борщ]

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

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

[YAM]

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

.... А ОК на выходе предлагал, чтобы после передачи все слейвы могли ответить одновременно. Ответ 0xFF - удалось записать блок, ответ 0x00 - не удалось. И пока мастер получает ответ отличный от 0xFF - он повторяет блок....

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