Налагало ли ви се е да ползвате тази благинка в следната хипотетична схема - имате у-во с ваш софтуер, което е съставено от няколко микроконтролера, но само единия от тях е свързан с някаква външна комуникация? Като искате да актуализирате "свързания" контролер е лесно. Как обаче актуализирате някой от останалите? Ползвате дебъг интерфейса или ползвате неговите възможности сам да си префлашва страници? Имате ли си собствен протокол за комуникация за това нещо или ползвате нещо стандартно разработено от производителя? Въобще какви са стратегиите при такава ситуация?

Аз винаги обновявам всичко през софтуера си !
Имам продукт с 6 контролера (1xARM, 4xDSP, 1x8bit) - всички се обновяват през интерфейсите с които си комуникират помежду си (USB, SPI, I2C, custom)
Например 8битовия се обновява през PC->АРМ->DSP->8бит
Всички фирмуери се обновяват автоматично - ако има нужда...
Всичко си е мой "стандарт"

За комуникацията си имаш собствен протокол, а за същинското записване във флаша използваш вградените функции на bootloader-а ли?

всичко е мое - никакви "вградени" функции нямам - че да ги ползвам!
за всеки контролер имам нещо като "буутлоадер" - който се занимава с флашването, но е съобразен със съотвения контролер (рам, флаш) и използвания протокол за комуникация (прекъсвания и т.н.).
като при флашването обновявам и самия "буутлоадер" - защото нищо не е последно.

Собствен бутлоудър във всяко MCU + прост флаш протокол, общ за всички дивайси.
В протокола имам команда 'open gateway' с параметри (примерно) име на дивайс. Всички следващи месиджи до 'close gateway' командата отиват директно в таргет MCU-то, там си отварят флаш сесия, тъпчат данни и т.н.

Ако всички контролери са на една платка мисля най-лесно и удобно ще е
да ги свържеш с по две жици за I2C и си ги програмирай през един конектор.
Можеш всички да програмираш едновременно

Как го виждаш обикновен юзър да се свърже с платката по I2C ? С какво ще се свърже?!?

Юзъра в най-масовия случай ще има USB и ще може да изтегли и пусне програмка под Windows. В някои случаи у-вото е свързано към някаква Ethernet мрежа - тогава може програмката да се пусне на кой-да-е компютър закачен към тази мрежа...

На мен ми беше интересно дали някой е използвал дебъг интерфейса за префлашване на микроконтролер или всички ползвате писане във флаша "отвътре" (тоест самия микроконтролер да си се префлашне страница по страница)?

Сега като се замислих - възможно е и записването на програмата през дебъг интерфейса също да е реализирано "отвътре"

Пъхаш всичко в паметта и при стартиране да си чете от там.

Ко речи ?

Който има брада си купува ножица. Най-евтиния процесор с USB и I2C струва около $1,
не е никакъв проблем да му се налее софт за USB към I2C конвертор по HID.
Сложи времето дето ще отделиш да пишеш отделни протоколи за различни
фамилии професори по различни интерфейси, а и ако се наложи през професори
посредници, умножи по заплатата ти на час и ще разбереш за какво иде реч.

В твоя вариант юзъра ще трябва да разполага с 4 отделни неща:

1. устройството което му върши някаква работа, но трябва да се актуализира
2. второ у-во което служи само за актуализация на първото (USB <--> I2C bridge)
3. кабелче между №1 и №2 (като това кабелче може евентуално да е запоено на у-во №2, а не да е отделен компонент)
4. USB кабел между компютъра и у-во №2

Според мен е много по-добре ако му трябва само един USB кабел между у-вото и компютъра. Ако трябва вътре в у-вото ще има специален чип само за актуализациите, но от него навън трябва да има само стандартни и масови интерфейси със стандартни кабели, които могат да се купят във всеки град.

А варианта да не се пише софтуер е възможен само ако има нещо готово стандартно, което да върши същата работа. Има ли такова нещо?!

Даниелчо какви са тия "хипотетични" ситуации? Кажи си конкретно какво ти трябва за каква платформа, какъв тип изделие, т.е. дали е мрежово и с достъп до интернет, дали се ползва от човек или е завряно самичко нейде си...

Най-добрият вариант е като излезе нов фърмуер устройството да си го дърпа и да си го сменя самичко, като фърмуерът е желателно да е криптиран и да не може лесно да ти клонират устройството. Отделно ъпгрейда трябва да е надежден, т.е. ако спре тока или ако нещо не се получи както трябва, устройството да си възстановява последната работеща версия и т.н. и т.н.

То е близко до акъла, че ако имаш USB на някои от професорите е най-добре да
е през USB… Аз ти разправях за случая, когато нямаш USB, а имаш една камара
професори (xипотетично де...). Но дори и така да е, пак е най-лесно да ги закачиш
всички през I2C и след това USB професора да ги програмира.

А стандартни неща готови колкото искаш има, само трябва да можеш да ги виждаш

Всичко е хипотетично защото още нищо не се знае как ще е... Процесора който ще има възможност да се свърже ще е или NXP или ST (Cortex-M4). Другия процесор ще е нещо по-слабо, но изобщо не се знае какъв ще е (избора на този процесор не го правя аз). Устройството ще е преносимо с батерийно захранване - така че мрежови или безжични връзки отпадат - само USB. Питам за стратегията за актуализация защото този проблем трябва да е решен и да работи гладко от ден 1-ви.

Аз понеже съм газил в точно такива лайна, ето и мойте 5 стинки:

Най-добре е да се ползват вградените бутлоадери, ако ги има налични разбира се. Така си връзваш гащите срещу проблем с твоя бутлоадер. Едно, че може да пропуснеш някакъв бъг при тестовете, другото е, че когато са хардкоднати в чипа, са железни и винаги са си там.

Една примерна конфигурация е STM, който наливаш през DFU (USB), и подчинение процесори накичени на UART и с вградени бутлоадери. Тая комбинация няма как да изпадне в безтегловност, винаги ще може да припали. Важното е само да подсигуриш хардуера още на ниво дизаин (активацията на бутлоадерите).

Напрактика повечето съвременни процесори си имат бутлоадер поне през UART.

Освен всичко друго, ако сертифицираш софтуера, бутлоадера е още една купчина бумаги... А и да не го сертифицираш, пак си трябва да се пишат бумаги ако правиш нещо сериозно, трябва яко да се тества и въобще - ако може без него - по - добре.