Архитектура микроконтроллера

[Эдуард Анисимов]

Я не знаю куда закинуть эту информацию.
Закидываю сюда.

У меня вопрос ????
Вы все пишите проги, прошивки, скетчи (вообще за гранью фантастики, причём здесь сценарий для спектакля)

Вопрос такого плана. Есть две основные архитектуры компьютеров, микроконтроллеров и т.д.

• Фон Неймана
• Гарвардская

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

 

[Arhat109]

Кмк, отличие в них не настолько принципиальное.

Фон Нейман, в свое время совершил "прорыв", выделив из общей структуры "вычислительного устройства" три компоненты: "память" для хранения (в т.ч. программ) + "вычислитель" для собственно проведения операций по изменению данных + "шина" как способ передачи информации туда-сюда-обратно, в т.ч. и "команд вычислителю".
Гарвардская архитектура - незначительная, кмк, модификация Фон Неймана, а именно: отделение памяти команд от памяти для операндов в отдельное устройство и, соответственно, появление "двух шинной" архитектуры. Как понимал, сделано было с целью повышения скорости вычислений, т.к. в ней доступ к обоим блокам памяти как-бы не зависим и может производится одновременно. Остальное добавлено "от лукавого" и возможно несколько позже.
Для микроконтроллеров, Гарвардская архитектура - большой плюс, т.к. flash память достаточно медленная, и работает у тех же Атмелов где-то "на пороге" или даже немного "за ним" по скорости. А возможно и вообще "единственный вариант"..

По мне так, все что имеет разделенные на блоки "память", "вычислитель" и связанное промеж себя "шиной" - есть Фон Нейман. Как альтернативное решение - "нейропроцессор" под названием "моск чуловеков" (и не только) .. где нейроны - обобщенные "вычислители с памятью", то есть оно ТАК не разделено. И вычисления, хоть и идут с невысокой скоростью (до 20-30гц), но любое решение формируется "за 1 такт", то самое "озарение" ..

 

[Эдуард Анисимов]

@Arhat109, Очень радует, что есть не только писатели но и разбирающиеся люди.
Этот крик души возник из за этого поста.

Arduino и дозагрузка программы

Наверное ни кому не секрет, что в х86 процессор программу выполняет в RAM. На avr же, она исполняется прямо в ПЗУ. Вопрос: есть ли способ догружать программу на уже запущенной ардуино например с sd card?

community.alexgyver.ru

Люди начали давать советы совершенно не относящиеся к теме.

Гарвардская архитектура - незначительная, кмк, модификация Фон Неймана, а именно: отделение памяти команд от памяти для операндов в отдельное устройство и, соответственно, появление "двух шинной" архитектуры.

Тогда согласно этому мы не сможем в гарвардской архитектуре исполнять код из RAM? Или всётаки существуют методы?

 

[poty]

Мне кажется, интерпретация исходного вопроса несколько вольная. Впрочем, могу предположить, что автор вопроса имел в виду именно Ваше понимание, исходя из последнего его ответа в теме. Не очень понимаю смысла этого по причине отсутствия возможности адресовать память больше размера встроенного указателя на память. Т.е., это будет всё равно некоторый вариант того, что я описал чуть ниже.
Я этот вопрос понял так, что в процессе исполнения кода хочется менять куски программы, подгружая их из какой-либо внешней памяти и затем выполняя обычным образом (из программной памяти). По этому пути "большие" системы идут начиная с 70-х годов. Сама идея внешней памяти со своей адресацией явно присутствует в обеих архитектурах. Развитие этого направления сейчас - это виртуализация, когда вообще непонятно где и на каком виде ресурса лежит выполняющийся программный код. Это доступно и для микроконтроллеров, просто задачи под это крайне редкие.

 

[Эдуард Анисимов]

@poty, Я виртуализацию памяти видел только на архитектуре фон неймана.
Возможна ли она на гарвардской архитектуре.

адресовать память больше размера встроенного указателя на память.

У неймановской архитектуры чаще всего разрядность счётчика соответствует размеру адресуемой памяти. Когда этого нет, обычно делают страничную адресацию.

 

[poty]

Возможна ли она на гарвардской архитектуре.

А почему нет? Понятно, что без аппаратной поддержки её эффективность будет значительно снижена, особенно в приложениях реального времени, но для процессов, где требуется относительно нечастое обновление с интенсивными вычислениями - вполне может использоваться.
На самом деле, в микропроцессорах не применяется "чистая" гарвардская архитектура, так как программной шины как таковой нет. Есть ещё много ограничений, включая ограниченный ресурс перезаписей flash (т.е., она по дизайну не предусматривает многократной перезаписи, как и EEPROM). Собственно, это уже не ограничения архитектуры, это - ограничения конкретной практической реализации. Ваш вопрос, в этом плане, весьма интересен.

 

[Эдуард Анисимов]

@poty, Я с 1983 по 1993 года изучал микропроцессорную технику. Сначала специальность Конструирование Электронно Вычислительной Аппаратуры, затем Вычислительные Машины. Мои знания базируются только на этих специальностях. Вернулся я уже к микроконтроллерам пять лет назад. Т.К. после того как Союз развалился, я практически ни минуты не работал по специальности.
Поэтому более современные знания в микропроцессорной технике приходится получать по ходу дела. Поэтому меня и интересуют такие вещи. Не знаю где это можно применить. Но ведь интересно же. А вдруг это кто то уже умеет.

 

[poty]

Ну, получается, что мы с Вами примерно в одно время её изучали. У меня, правда, это не было основной специальностью, но работал именно по ней. Пришлось получать дополнительное образование уже во время работы.
А вопрос, действительно, жутко интересный. Даже для относительно простых применений, как здесь, в проектах Алекса, можно уже говорить о том, что это может быть интересно. Ну, как пример: большая ветка есть по "лампе Алекса" (возможно, не очень правильно называю этот проект). Там есть проблема - недостаточное количество памяти для воспроизводства эффектов, именно по программированию, да и по промежуточным данным тоже. Если бы можно было сделать, скажем, загрузчик эффектов, своего рода конфигуратор, без перезаливки скетча как такового, то было бы, с моей точки зрения, весьма круто! Насколько я знаю, через Wi-Fi уже возможно как-то влиять на код, можно было бы вообще грузить эффекты и управлять лампой через Интернет, не применяя никаких других локальных хранилищ.

 

[Arhat109]

@Эдуард Анисимов, ответ на поставленный вопрос, вообще-то положительный: да можно подгружать куски кода (программы) во флеш (ПЗУ) команд микроконтроллера, в т.ч. и с SD карт.
Обоснование простое: вы же как-то (загрузчиком) заливаете программу в микроконтроллер. Вот, именно эту работу он и делает, сам исполняясь в том же флеше.
Больше того, такие загрузчитки есть .. где-то видел, в т.ч. и загрузчики с сетевой карты по Сети. Начинал делать сам к своей версии платы Ар-го (тут есть даже начатая тема в проектах), но забросил .. как-то последнее время "не до того" все время.

У Атмелов для решения этой задачи вся флеш память разбита на 2 блока, и разрешается писать в один блок, программе находящейся во втором блоке. Сам загрузчик (писалка) "оптибут", насколько помню умещается в 500байт или даже меньше. Верхний блок флеша у Меги до 4 килобайт. Вполне можно реализовать задачу, кмк.

Далее. Если помните, то эта плата "Ар-Го" (Ардуино как Лего) реализована на базе Мега2560 и имеет суммарно 520килобайт ОЗУ (8 своих + 512 дополнительно) и SD карт ридер, который можно рассматривать как "жесткий диск" большой емкости.

При емкости указателя адреса ОЗУ в 16бит (64кб ОЗУ макс), тем не менее, всё легко адресуется программным способом (там в темах есть пример теста ОЗУ и как работать с ним из программы). Так что .. ограничение разрядности адреса не помеха ни разу.

 

[poty]

Для ОЗУ - да, помех нет, а для программной памяти - есть.

 

[Arhat109]

Мега2560 программной памяти 256килобайт .. куда "больше"?

 

[kDn]

Дополнительные SRAM модули имеют смысл только для специфических применений, например в той же esp32cam где нужно где-то хранить буфер кадра - под это и стоит подобный модуль, т.к. встроенной RAM под задачу не хватает. Что же касается ROM/памяти кода - то в той же esp8266 от 1 до 4мб - этого более чем достаточно. Та же наша прошивка лампы - сейчас 700кб, 2мб под файловую систему и 1мб под OTA, то чего реально не хватает это именно RAM и по большей мере для кеширования разного рода информации - буферы кадров, кеш названий эффектов и внутренние буферы эффектов и т.д.

Ну а по теме - прикручивать доп. хранилища разного рода к ардуине или городить страничные адресации/подгрузки на ней же - это из разряда извращений, ИМХО проще взять контроллер умеющий из коробки то что нужно и не морочить голову. Именно по этому нет подобного рода решений, прошли время спектрум48/128/256 и иже с ними, поскольку тогда камень популярный был один, а поверх уже накручивали кто во что горазд.

 

[poty]

Я разве против? Я вообще не говорю сейчас о "usability", тут каждой задаче - своё решение (абсолютно согласен с @kDn).
Я говорю о том, что без аппаратной поддержки адресовать такую память программно не получится. Т.е., шины как таковой просто нет.

 

[kDn]

Я разве против? Я вообще не говорю сейчас о "usability", тут каждой задаче - своё решение (абсолютно согласен с @kDn).
Я говорю о том, что без аппаратной поддержки адресовать такую память программно не получится. Т.е., шины как таковой просто нет.

Ну что касается той же лампы, то изначально я месяц делал прошивку для ардуины нано, пока ждал когда esp8266 приедут, далее попросту свернул все работы и начал с чистого листа. Что получилось на выходе можно поглядеть в теме и гите. На мой взгляд получилось более-менее нормально, как для первого проекта . Под спойлером картинка одновременной работы двух клиентов, свободной RAM не то чтобы много - 20кб, но в общем-то хватает. При этом вообще пользователю доступно около 40кб изначально, поскольку половина из 80 занято SDK от Espressif

Спойлер: картинко

Но если я решу, что памяти мне не хватает, то скорее возьму esp32 и продолжу там (это может быть актуально только для матриц от 32*32), т.к. чем больше размер матрицы, тем больше расход памяти под буферы. Что же касается аппаратной поддержки - то как бы просто нужно выяснить - есть ли возможность переустанавливать регистр команд куда-то или же мапить какую-то память на адресное пространство с которым может работать контроллер - и в общем-то это все . Скорее всего это реализуемо чуть ли не везде, а вот нужно ли - совершенно другой вопрос.

 

[Arhat109]

Я разве против? Я вообще не говорю сейчас о "usability", тут каждой задаче - своё решение (абсолютно согласен с @kDn).
Я говорю о том, что без аппаратной поддержки адресовать такую память программно не получится. Т.е., шины как таковой просто нет.

ну вот как "не получится"? Я же вам привел как раз пример "получилось". Вполне штатная страничная организация ОЗУ. Был бы выход с шины флеша вовне, ровно так же оно наворачивалось бы и на ПЗУ. Вопрос не в размере указателя (адреса), а в отсутствии доступа. ОЗУ тоже наращивается далеко не у всех Атмелов.

Другое дело, что "оно не нужно, ибо время таких решений прошло" и проще взять микроконтроллер с большим ресурсом, если "не хватает". Мои поделки - это из разряда "что можно выжать из Мега2560", безотностиельно к вопросу "надо ли"? Есть шина внешнего ОЗУ .. вот и применил по делу.

 

[Эдуард Анисимов]

@Эдуард Анисимов, ответ на поставленный вопрос, вообще-то положительный: да можно подгружать куски кода (программы) во флеш (ПЗУ) команд микроконтроллера, в т.ч. и с SD карт.

Ребят. Вы опять попутали тёплое с мягким.
Вопрос был не про ROM, я перкрасно знаю что туда можно на ходу подгружать.
Вопрос был про RAM, можно ли в гарвардской архитектуре выполнять код загруженный в RAM.
Вот на этот вопрос пока никто не ответил.

 

[kDn]

@Эдуард Анисимов, если регистр команд можно выставить на RAM, то будет исполнять в RAM. Если нельзя - то нельзя.

Но вообще решать задачу можно иначе, а именно:

Обратная задача - можно ли брать из памяти программы что-то (константы) также решаемо с разного рода извращениями (для ESP8266 обертки - F(), PSTR() FPSTR(), для ESP32 - без оберток вроде работает). Также типа "ROM" память вполне успешно используется как хранилище - та же LittleFS попросту использует все ту же флешку. Принципиально не важно пишет ли драйвер ФС в свою область, которая на это отдана или туда откуда программа выполняется. Следствие - возможно написать код, который тупо будет писать что-то поверх прошивки))). Если это что-то будет должным образом сформировано, а не просто мусор, то это нечто будет элементарно выполнено, как только на данный код будет передано управление.

* Тут дело в том, что в контроллерах достаточно часть мало RAM и много FLASH-памяти, обратные случаи тоже бывают, но редко и обычно для спец. применений типа описанного мною ранее PSRAM у esp32cam

 

[Arhat109]

@Эдуард Анисимов, нет, нельзя. Все дело в том, что это принципиально РАЗНЫЕ адресные пространства, и когда указатель смотрит на данные - он указывает в память ОЗУ, а когда указатель - это ПЕРЕХОД (адрес команды), то он всегда смотрит в ПЗУ команд (flash).
То есть способ использования указателя определяет куда он смотрит.
Есть отдельные команды загрузки (и только!) в ОЗУ из флеша, что позволяет хранить объемные наборы данных в ПЗУ, подгружая их по мере необходимости.
Есть отдельные команды записи из ОЗУ во флеш, с ограничениями, тк. сам процесс записи флеша "проблематичен" (иное напряжение питания)
Нет никаких способов указать саму команду в ОЗУ. Счетчик команд всегда смотрит во флеш.
Но, есть команды косвенных переходов (по содержимому регистра к примеру), что позволяет организовать "исполнение в ОЗУ" методами построения интерпретаторов и "байт-кодированием".

Как-то так, смотря что Вы называете "исполнением в оЗУ" .. оно может быть разным. И, при желании, вполне можно организовать код и таким способом .. дорого и не зачем.

 

[Эдуард Анисимов]

@Arhat109, Вот, наконец то развёрнутый ответ и в тему.
Я поддерживался того же мнения, но вдруг я ошибался.

Как-то так, смотря что Вы называете "исполнением в оЗУ" .. оно может быть разным. И, при желании, вполне можно организовать код и таким способом .. дорого и не зачем.

Просто интересно правильно ли я ответил тому чуваку.
И при наличии МК на любой вкус, такая тема малоактуальна.

 

[poty]

@Эдуард Анисимов, прошу прощения, что снова не совсем по теме, которую Вы предполагали. Думаю, это последний пост в таком качестве.
@Arhat109, могу ошибаться, но маппинг флэш, насколько я понимаю, не поддерживается. Я понимаю, что теоретически возможно использовать методы, аналогичные EMS, XMS и т.д., но как это отслеживать в коде? Формировать "неприкасаемые" области, обеспечивающие репагинацию памяти и находящиеся в основной, неизменяемой области? Ограниченно применимо из-за необходимости дублировать все точки входа функций в основной памяти. Да и выхода программной шины нет, чтобы в железе организовать. В таком случае проще, к.м.к, использовать массив МК и использовать методы параллельных вычислений с внешней шиной - гораздо меньшие накладные расходы. SRAM можно управлять в этом случае параллельно из каждого МК (т.е., использовать общий и т.о. передавать данные между МК). Но всё это умозрительно и не обладает удобством правильного выбора МК для задачи.
Теперь по поводу Вашего вопроса:

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

В чистой гарвардской архитектуре - нет. Но так как существует масса "улучшенных" архитектур, там, где используются мультиплексированные или общие шины, в них - бывает можно.
Я только не очень понимаю надобность такого дела. Подход (хоть я и не нашёл пока практической его реализации, но наверняка такой существует) использования ремаппинга флэш, о котором говорит @Arhat109, гораздо более практичен.

 

[Arhat109]

@Эдуард Анисимов, прошу прощения, что снова не совсем по теме, которую Вы предполагали. Думаю, это последний пост в таком качестве.
@Arhat109, могу ошибаться, но маппинг флэш, насколько я понимаю, не поддерживается. Я понимаю, что теоретически возможно использовать методы, аналогичные EMS, XMS и т.д., но как это отслеживать в коде? Формировать "неприкасаемые" области, обеспечивающие репагинацию памяти и находящиеся в основной, неизменяемой области? Ограниченно применимо из-за необходимости дублировать все точки входа функций в основной памяти. Да и выхода программной шины нет, чтобы в железе организовать. В таком случае проще, к.м.к, использовать массив МК и использовать методы параллельных вычислений с внешней шиной - гораздо меньшие накладные расходы. SRAM можно управлять в этом случае параллельно из каждого МК (т.е., использовать общий и т.о. передавать данные между МК). Но всё это умозрительно и не обладает удобством правильного выбора МК для задачи.
Теперь по поводу Вашего вопроса:
В чистой гарвардской архитектуре - нет. Но так как существует масса "улучшенных" архитектур, там, где используются мультиплексированные или общие шины, в них - бывает можно.
Я только не очень понимаю надобность такого дела. Подход (хоть я и не нашёл пока практической его реализации, но наверняка такой существует) использования ремаппинга флэш, о котором говорит @Arhat109, гораздо более практичен.

Если хотите внятный ответ, пишите пожалуйста по-русски, я не понимаю что такое "маппинг флеш" и зачем оно должно "поддерживаться" и кем тоже ..
Что такое методы EMS,XMS применимо в микроконтроллеру .. тоже хотелось чтобы Вы развернули мыс ль "лицом к народу" ..
Зачем надо формировать "неприкасаемые" области и что это такое? .. дальше вообще неясно:
"Ограниченно применимо из-за необходимости дублировать все точки входа функций в основной памяти." -- это вообще что такое и зачем микроконтроллеру с гарвардской архитектурой?
"Да и выхода программной шины нет, чтобы в железе организовать." .. э-э-э, что имелось ввиду? А я КАКУЮ тогда шину расширял? Вроду ту самую .. программную из ОЗУ..
"В таком случае проще, к.м.к, использовать массив МК и использовать методы параллельных вычислений с внешней шиной - гораздо меньшие накладные расходы." ... ?!? В каком "таком" случае? Массив МК (и вообще многоядерность) вполне себе применяется но .. в иных областях. Оно тут зачем? И главное КАК вы это собираетесь "организовать", если внутренние сигналы МК не выходят наружу? По УэСБи шине чтоли или ИдваЦэ? Так это и так можно .. только не нужно.
Нельзя управлять SRAM из нескольких МК. Нет у них таковых сигналов "управления" .. у Атмелов точно нет, за другие не знаю, но там как-то аналогично була..

И таки да, ни о каком "ремаппинге флеш" я вроде не говорил .. или переведите на русский. Вы все-таки на русском форуме ..

P.S. Перечитал раза 4 .. мне кажется, что Вы слабо знакомы с архитектурой МК в целом, и тупо переносите свои знания из области "универсальных ЦВМ" а-ля "IBM PC" на микроконтроллеры. Если это так, то я вас разачарую:

Забудьте всё, что вы знали про "универсальные ЭВМ". Тут это знание не только не помогает, но в значительной степени ВРЕДИТ пониманию работы и практик программирования МК. Это - другое. Совсем. Честно-честно. И это самая первая ошибка, которую совершают все, кто приходит в программирование и разработку на МК из "персоналок".. тут все несколько не так как там.

И большое ПЗУ в сравнении с мелким размером ОЗУ - ОПРАВДАНО и сделано ВЕРНО. Многие реальные МК вообще не имеют ОЗУ и это ПРАВИЛЬНО. Оно в общем-то микроконтроллеру ник чему, от слова СОВСЕМ.
Как только эта банальная истина станет понятна "почто так" - так сразу можно будет признать себя как "программистом микроконтроллеров" (повесить себе медальку на грудь)

 

[poty]

Пожалуй, это нужно перенести в отдельную ветку. @Arhat109, Вы так часто апеллируете к гарвардской архитектуре, что у меня возникает впечатление, что это просто отговорка.

А я КАКУЮ тогда шину расширял? Вроду ту самую .. программную из ОЗУ..

Выдержка из datasheet на ATmega640/1280/1281/2560/2561:
"An optional external data SRAM can be used with the ATmega640/1280/1281/2560/2561. " Я говорю уже в четвёртый раз о программной памяти - "In-System Reprogrammable Flash Program Memory". Разговор шёл о том, чтобы обеспечить работу программного кода, а, как Вы правильно заметили, в гарвардской архитектуре это - два разных вида памяти. О памяти данных речь шла исключительно с точки зрения вопроса о том, можно ли "из неё выполнять команды". Опять же, Вы на это ответили, что нельзя.
Для того, чтобы расширять Flash Program Memory нужно иметь такой же механизм, как для памяти данных, а именно (снова из datasheet) "external memory map". Поэтому "маппинг флэш" - это, по-русски, отображение внешней памяти на адресное пространство, поддерживаемое микропроцессором.
EMS, XMS - технологии, которые наверняка известны @Эдуард Анисимов, из 80-х, когда в 16-битных процессорах память пытались расширить за пределы 1МБайта за счёт маппинга (извините, отображения) внешней памяти в адресное пространство выше 640кБайт - типичного для XT-архитектуры Intel 8086.
Надеюсь, остальное будет Вами понято на основе этих базовых понятий.
Последнее уточнение:

Нельзя управлять SRAM из нескольких МК. Нет у них таковых сигналов "управления"

Можно, это делается за счёт любого внешнего пина (или пинов) в комбинации с пинами External Memory (тоже из datasheet).

 

[Arhat109]

Пожалуй, это нужно перенести в отдельную ветку. @Arhat109, Вы так часто апеллируете к гарвардской архитектуре, что у меня возникает впечатление, что это просто отговорка.
Выдержка из datasheet на ATmega640/1280/1281/2560/2561:
"An optional external data SRAM can be used with the ATmega640/1280/1281/2560/2561. " Я говорю уже в четвёртый раз о программной памяти - "In-System Reprogrammable Flash Program Memory". Разговор шёл о том, чтобы обеспечить работу программного кода, а, как Вы правильно заметили, в гарвардской архитектуре это - два разных вида памяти. О памяти данных речь шла исключительно с точки зрения вопроса о том, можно ли "из неё выполнять команды". Опять же, Вы на это ответили, что нельзя.
Для того, чтобы расширять Flash Program Memory нужно иметь такой же механизм, как для памяти данных, а именно (снова из datasheet) "external memory map". Поэтому "маппинг флэш" - это, по-русски, отображение внешней памяти на адресное пространство, поддерживаемое микропроцессором.
EMS, XMS - технологии, которые наверняка известны @Эдуард Анисимов, из 80-х, когда в 16-битных процессорах память пытались расширить за пределы 1МБайта за счёт маппинга (извините, отображения) внешней памяти в адресное пространство выше 640кБайт - типичного для XT-архитектуры Intel 8086.
Надеюсь, остальное будет Вами понято на основе этих базовых понятий.
Последнее уточнение:
Можно, это делается за счёт любого внешнего пина (или пинов) в комбинации с пинами External Memory (тоже из datasheet).

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

Вопрос расширения ФЛЕША программы в микроконтроллере не стоит вообще никак. Это не нужно согласно назначению МК "в общем виде". Совсем.

Внешнее разделение интерфейса расширения SRAM нельзя использовать между несколькими МК, даже с применением пинов общего назначения. По крайней мере у Атмелов. При включенном интерфейсе, сигнал ALE выставляется на шину КАЖДЫЙ такт, независимо от адреса назначения: хоть доступ к внутренней части адресов, хоть ко внешней. Никаких "циклов ожидания доступа" организовать нельзя.
Все что Вы можете сделать дополнительным пином - это "организовать протокол доступа", по типу мьютекса (семафора) разрешая или запрещая обращение к внешнему SRAM другим МК, т.е. переводя их в "режим ожидания", что полностью дискредитирует идею "общей памяти" ибо крайне не производительно. Ну и не надежно. Никто не мешает наплевать на ваш внешний сигнал (прерывания запрещены к примеру) и спокойно получить монтажное ИЛИ на ногах адреса .. тогда уж полезней смотреть в сторону многопортовой SRAM .. только зачем?

Ну и этта (не хотелось) в ИТ работаю с примерно 1979года. Как говорил мой коллега: "не пугайте меня клавиатурой. Я начинал когда их ещё не было". Это к вопросу устройства IBM PC XT и его схем расширения ОЗУ. Где-то в 1986-м даже принимал участие в разработке "многопроцессорного комплекса" на базе i8080 (КР580ИК01), z80, i8086, i8089 (процессор ввода-вывода по аналогии с большими IBM, не применялся в PC), К1804ВС1, ВС2, К1802 (модуль Квант) как с собственным ОЗУ так и с "разделяемым блоком многопортового ОЗУ" с возможностью сборки до 256 "ядер" в одном ЦВМ.
Меня смутило то, что Вы эти термины применили к микроконтроллерам .. оно тут иное. Честно.

 

[Arhat109]

@poty, напишите в личку с чем конкретно не согласны и почему.

Хотел дополнить пост, оставлю тут:

P.S. Дополню. Давайте отделим "мух от котлет", а именно вспомним основное назначение микроконтроллеров: это железяка, призванная решать ровно ОДНУ задачу, которая ПРОШИТА в ее программной памяти "намертво". Все остальное - от лукавого. Это может быть процесс отладки и написания прошивки (и тогда ее надо перезаливать до состояния рабочая), это процесс обновления прошивки по тем или иным причинам.
Отсюда:
Следствие раз: микроконтроллеры выпускаются "линейками" по размеру флеша. Его должно хватать на задачу (ед.ч.!) и если это не так - возьми следующий МК в линейке.
Следствие два: все константы (неизменяемые наборы данных) обязаны храниться во флеш и прошиваться вместе с кодом. Всё, для чего требуется ОЗУ - это стек возвратов (устраняется кодом без подпрограмм т.к. флеша достаточно априори, см.1 - просто "режим компиляции") и для хранения промежуточных данных, которые также в значительной степени устраняются разработкой алгоритма прошивки.
Скрипач - не нужен.