Вопрос не о совершении невозможного, а о поиске механизма обхода этого технологического ограничения с применением внешних запоминающих устройств
Наличие однократно-программируемой памяти МК, даже на фоне многократно-программируемой отладочной ОЗУ в объеме, повторяющем ПЗУ - это, как ни крути, довольно скверная ситуация в перспективе долговременной поддержке изделия.
Предлагается обсудить варианты решения этой проблемы, находящейся на стыке программного и аппаратного уровней.
Для начала попробуем ответить на вопрос: а для чего?.. при каких обстоятельствах вообще может понадобиться перепрограммируемость именно ПЗУ? Точно ли НЕ хватает механизма отладки из ОЗУ?
Попытаюсь уменьшить объем текста: варианты решения административными способами будут спрятаны под спойлерами. Но помним, что предмет вопроса - это технические решения, а не бумажные.
1) Отладка агрегата до начала каких-либо испытаний. Хотелось бы, чтобы каждое включения питания (или перезагрузку питания) агрегата НЕ сопровождалось обрядом прошивки ОЗУ всех МК в агрегате (а МК часто будет не 1 и не 2, и расположены они будут [9 из 10] в довольно труднодоступных местах) - в общем просто неудобно, хотя и не смертельно. Но может возникнуть ситуация, когда захочется посмотреть поведение агрегата именно сразу после включения, а условная 5ти минутная прошивка ОЗУ по определению не даст это сделать.
2) Внесение изменений на этапе предъявительских или заводских испытаний. Вылез ли косяк во время сдачи или же появилось какое-то субъективное требование заказчика, так или иначе, нужно перепрошивать.
Вариант административного решения:
Как правило агрегат на этих этапах еще находятся на территории родного завода и проблему можно решить административными способами - протащить в ТУ на агрегат указания, не допускающие прожигание ПЗУ МК до конца или до определенной стадии испытания агрегата. Т.е. дождаться того момента, когда все согласятся, что агрегат работает именно так, как того требует ТЗ и только после этого прожигать. Звучит тоже пока еще сносно, но держим в голове, что к моменту завершению заводских испытаний все МК в агрегате уже абсолютно точно должны быть прозжены.
3) Внесение изменений на этапе автономных и более серьезных испытаний. Тут уже всё (имеем что имеем), а если мы имеем прозженный МК, то это только замена. Откуда же взять новый МК, не грабить же ЗИП?
Вариант административного решения:
В ГОСТ на ведомость покупных изделий (ВП) есть разъяснение назначения графы “на регулирование”. Из этого разъяснения следует, что туда вписываются (и приобретаются) покупные изделия (в частности наши МК), которые могут (и должны быть) быть амортизированы (израсходованы) на этапе испытаний. Т.е. можно закупить МК больше на число микросхем в агрегате, помноженное на число этапов испытаний, следующих за заводскими. Звучит очень переразмеренно, но ГОСТ явно регламентирует такую графу расходов. Насколько рентабельно закупать в 2-4 раза больше микросхем, чем требуется в агрегате, при том, что они могут и не понадобиться? А, с другой стороны, насколько дорого сорвать этап контракта на 9 месяцев, затянув испытания, пока изготавливают и поставляют новые МК и во сколько денег можно оценить нервотрепку или даже свободу ответственных за исполнение контракта лиц? Последние 2 вопроса следует соотносить между собой, но суть такова, что существует механизм заблаговременного приобретения запасных МК для замены прозженных с новой программой на любом этапе испытаний.
4) Доработка серийного изделия. По результатам эксплуатации может возникнуть потребность изменить ПО в МК, в том числе в тех МК, которые сейчас находятся в эксплуатации в составе изделий.
Вариант административного решения:
Ну тут довольно просто - ТЗ на доработку, в рамках которых закупят изготовят, испытают и установят составную часть с новым МК и новым ПО. Как правило, когда дело доходит до ТЗ на доработку, у людей есть понимание, что дело это не быстрое. 9 месяцев - значит 9 месяцев
В сухом остатке имеем, что административными методами выкрутиться можно, но стоит попытаться не доводить до крайностей.
На ум приходит 4 базовых концепции, которые будут помещены под спойлер
Концепция 1, конфигурационная:
Самая простая в реализации и компромиссная по гибкости концепция, когда основной код по-прежнему прожигается в ПЗУ МК, но часть параметров выносится на внешнюю микросхему памяти (например по SPI), например:
начальная инициализация периферии, скорость работы интерфейсов, адреса на шинах данных и т.д. в зависимости от специфики конкретного применения. Т.о. можно заложить определенный запас гибкости, хоть и не на все случаи жизни.
Концепция 2, самозагрузка:
В этой концепции вся память программы (полезная прошивка) исходно хранится на внешней(их) микросхеме(ах) памяти и существует единственный МК. При подаче питания из прозженной ПЗУ МК запускает программа бутлодера, которая в свою очередь считывает полезную прошивку из внешней памяти в область отладочной ОЗУ. Затем с помощью некоторой внешней схемотехники переключается режим работы из хард в софт и обеспечивается аппаратный ресет без отключения питания. Тот факт, что аппаратный ресет без отключения питания не очищает ОЗУ, дает принципиальную возможность такой смены режима, но это вроде как не гарантированно, так что в начале полезной прошивки обязательно должна быть верификация ПО и в случае не прохождения ее - возврат в режим хард для повторной загрузки. Лично мне кажется этот способ крутым, принципиально возможным, но не гарантированным/безопасным, а значит не перспективным 🙁
Концепция 3, загрузка другим МК:
В этой концепции вся память программы (полезная прошивка) также исходно хранится на внешней(их) микросхеме(ах) памяти, но существует основной МК и МК-бутлодер. Тут вроде очевидно из названия - прозженный МК-бутлодер при включении питания по jtag прошивает в отладочную ОЗУ основного МК полезную прошивку и запускает его в режиме софт. Вроде всё красиво, но нужно х2 микроконтроллеров.
Концепция 4, исполнение команд:
Это java-подобный концепт, при котором на внешней памяти хранится некоторый алгоритм в специфическом бинарном коде, а на МК в режиме хард из прозженной ПЗУ запущено ПО, которое поэтапно берет команды из внешней памяти и исполняет их по подготовленным сценариям выполнения этих команд. Степень вложенности и витиеватости полезного ПО будет зависеть от сложности/хитрости реализации хранения алгоритма. Лично для меня эта концепция звучит довольно интригующе, но с учетом не слишком высокой производительности МК снизить эту производительность еще в разы за счет обращения к памяти и разбора команды звучит уже не так перспективно. Хотя может какие-то простые и небыстрые задачи этот концепт для себя найдет.
И самый главный вопрос: кто-нибудь пробовал реализовать какой-то механизм добавления внешней памяти этому МК для реализации многократной программируемости ПЗУ?
P.S. В рамках своего освоения этого МК мы (автор и его команда) начнем с концепции выноса на внешнюю ПЗУ конфигурационных параметров (концепция 1)
