так как по цене нынче самые мелкие stm8, и даже stm32f0 почти сравнялись со сдвиговыми регистрами, когда понадобилось сделать очень много небыстрого IO, причем в обе стороны и заодно i2c размножить, вместо спец размножителей i2c и сдвиговых регистров появилась мысль понаставить мелких МК и по SPI в daisy chain их всех собрать.

единственно что напрягает это прошивка и возможный update прошивки для кучи МК, соответственно вопрос: как бы это попроще сделать.
прошивка получается одинаковая и вроде бы если просто запараллелить у всех SWD, то должно получиться, так как какая разница что они там отвечают по SWDIO, отвечать должны все одинаковое.

Вот самое интересное и начнётся, когда где-то в середине цепочки (а SWD цепочку-то, вообще, допускает?) кто-то не ответит положенное

"Сквозняков" наловите - кто-то чуть быстрее ответит, а кто-то чуть медленнее.
Тут проще свой бутлоадер, SPI, соединить в звезду, а все CS завести на один процессор - он принимает прошивки и раздает остальным.

так SWD же синхронный вроде как (i2c грубо говоря, только push-pull, а не открытый коллектор, так как точка-точка) по клоку всё делать должен?
и где я столько CSов возьму. пусть будут друг за дружкой в daisy chain.
со своим бутлоадером понятно, что потом можно наверное научить по SPI прошивку принимать, но в первый раз всё равно придётся к каждому программатором подключаться.

как-раз push-pull и даст сквозняк, а открытый коллектор - нет.
SWD не daisy chain, а точка-точка.
Вот JTAG это daisy chain, но как я понял несколько устройств в цепочке будет требовать специальных программ.

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

Последняя SWD спецификация предусматривает подключение нескольких устройств в параллель (работать только с одним можно, естественно). Но я не уверен, что эту спецификацию поддерживают реальные программаторы и МК.

Как уже указали, SWD нельзя в цепочку собрать, или быть уверенным, что при "широковещательной" записи по SWD каждый безоговорочно пропишется. Остается только выводить RESET каждого процессора на разъем и делать адаптер для программатора: все RESET кроме одного, держатся в нуле, а свободный будет доступен по SWD. И селектором переключать. Впрочем, так можно и без RESET обойтись, если переключать SWDCLK.

ответ от st - текущая версия st-link не поддерживает цепочки
проверено, что старые камни не могут работать параллельно на один swd
зато новые (проверены нулевая и третья) серии отвечают адекватно
вот сможете ли вы написать правильный программатор ?


т.е. вы думаете, что reset в нуле мешает шить по swd ?

Reset не влияет на SWD интерфейс, но он влияет на контроллер флеша и шину, так что прошить все-равно не получится. Но и SWD интерфейс Reset не сделает неактивным.

не, ну пусть же KnightIgor сам подумает

Я так понимаю, нужно осуществить похожее:
http://forums.parallax.com/discussion/1612...-swd-programmer

Но это все-равно 5 отдельных линий SWD. Такое легко сделать не заморачиваясь с пропеллерами.

старые f4 не шьются
новые, типа 469 или 769 не пробовал

А че тут думать: не будет шить, и не шьет. Проверено. Прикол в том, что SWD не шьет сам, а пишет в RAM загрузчик, с которым и общается потом. Не знаю, как там в IAR и открытых системах, а под KEIL есть файлы алгоритмов прошивки для разных MCU и образчик, как свое написать. Я, например, с такого образчика написал загрузку User Page в EFM32G, которая не была в комплекте пакета KEIL. Однако Вы правы в том, что RESET не заставит SWDIO "поднять лапки".

Интересная тема от пользователя со статусом Профессионал

Так делать не стоит. Я бы делал бутлоадер + максимально автоматизировал этот процесс.

так делать стоит, ибо бутлодырь тоже надо как-то заливать


так вы предлагаете сделать робота, который будет ползать по плате и перетыкать разъем swd ?



кстати, а про fpga/cpld мысль не появилась ?

Человек пишет что они будут на одной плате, и его волнует как он их одним махом обновлять будет. Один раз ведь поработать можно, а потом обновлять уже более цивильно

А почему кстати SWD? Не JTAG ли предназначен для таких целей?

Заводской загрузчик забыли рассмотреть?
У меня есть система, в которой 1 ведущий (в который прошивается свой загрузчик) и несколько ведомых, которые прошиваются и запускаются заводским загрузчиком.

Можно сделать так: SWD завести на один из процессоров, две его ноги завести на SWD следующего, две его ноги - на SWD следующего и т.д. В первый заливаем прошивку, запускаем, она копирует себя в следующий процессор, тот, запустившись, копирует свою в следующий и т.д. Да, придется написать SWD-ведущего и это займет много времени. А можно по совету scifi использовать заводской загрузчик, правда придется кроме TX-RX еще BOOT0 и RESET кидать по цепочке.

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

если взять кучу, например, i2c или spi еепромов соединённых параллельно, с одинаковым адресом, и очень неспешно, чтобы гарантированно всё успело записаться, прошить их, забив на опрос статуса, то все прошьются как один.

тем более что МК дополнительно соединены в цепочку по SPI так что если кто не прошьётся - можно будет потом выяснить дополнительно.

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


потому что у самых мелких stm32f0 или stm8 нормального JTAGa нет


из-за асинхронности, уарт параллелить не хочется, иначе стандартными средствами прошить может не получиться, так как программатор в ответ должен что-то вменяемое всё-таки прочитать.

а вариант от Сергея протащить ещё цепочкой от одного МК к другому SWD или UART не нравится тем что придётся в МК изображать SWD хост или мастера для встроенного бутлоадера. ну и лишние 4, а то и 6 ног под это.

и почему тогда это не сделать на хосте ?

Есть еще идея с EEPROM и загрузчиком. Она не исключает первого нудного программирования каждого процессора изначальным загрузчиком, но должна упростить последующие актуализации.
Итак, все процы своим I2C интерфейсом могут читать одну EEPROM, и этот I2C еще и выведен на разъемчик. Заливаем обновление снаружи в EEPROM, а процы уже из нее и самопрошиваются.

+1

Как-то это прошло мимо меня, где почитать про возможности заводского загрузчика в stm32? Для меня это шок что он там есть (слышал лишь про загрузчики в более крупных камнях).

Как это где? В гугле, конечно.

а проверьте лучше кто-нибудь какой-то другой, не st-link, программатор на паре запараллеленных swd в мк типа stm32f0 ?

AN3156 USB DFU protocol used in the STM32T bootloader
и далее
AN3154 CAN protocol used in the STM32T bootloader
AN3155 USART protocol used in the STM32 bootloader

I2C боюсь занят, можно конечно и программный сделать, но опять же тратятся ноги (можно и 1wire программный сделать),
и все МК и так по spi соединены, так что с обновлением проблемы вобщем-то и нет.
есть проблема с первоначальным прошиванием этих "сдвиговых регистров"
и если есть возможность прошить их все разом параллельно в первый раз, то со своим бутлоадером можно не париться, а просто прошивать их так всегда.
от МК нужна фунциональность 74HC595 + 74HC165, плюс возможно моста SPI->i2c, так что обновлять там особо-то и нечего.

частично написал загрузчик через swd - уже могу сказать, что мульти-дроп для сабжа бесполезен, ибо в протоколе swd не реализовано перечисление девайсов на шине
т.е. можно программировать только камни, id которых уже знаешь
а брутфорсом искать id нелогично и очень долго

Прочитал про этот multi-drop. Не совсем ясно откуда этот target ID берется в первую очередь (4-х битная часть).

Их всего 16 шт получается, так что не долго. Но опять-же как их конфигурировать изначально - не ясно.

4 бита лишь под id программатора

Не вижу откуда это следует. Ну и упоминания о нескольких программаторах тоже не вижу.

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

можно, для этого посылается команда выбора определённого камня по его id
разрядность id таргета - 32 бита, перебирайте

Ну да, вот только этот ID уникален для семейства, но не для индивидуального чипа, так что работать с несколькими абсолютно одинаковыми чипами - нельзя.

Это одна из самых тупых особенностей всего этого дела - невозможно точно определить тип чипа если не известен производитель и где они хранят их собственный ID.