Вот это и имелось ввиду. Но уточню: уровень абстрагирования приводит Гарвардскую к фон Неймановской. Но не наоборот. Наверное (добавлю на всяк случай )
Калькуляторы, если брать старые программируемые - фон Нейман. Одна память, одна шина (хоть и разорванная), АЛУ и управление.

Главное отличие Гарвардской архитектуры от фон-Неймановской - отсутствие принципа однородности памяти. Т.е. память для команд и память для данных в Гарвардской архитектуре разные. В МК это можно сделать достаточно просто: ПЗУ - для команд, ОЗУ для данных. Только тут возникает одна проблема - часто бывает необходимо хранить в ПЗУ не только команды, но и данные. А доступ к данным в ПЗУ отсутствует. С этой проблемой я впервые столкнулся, когда начал работать с PIC. Не то, чтобы там совсем не было доступа к данным, но как это доступ был реализован, это всё равно, что летать с Урала на Дальний Восток через Москву. В AVR эта проблема была частично решена, там для доступа к данным в памяти команд имеется специальная инструкция.
Если верить документам, то STM8 и STM32 используют модифицированную Гарвардскую архитектуру
https://studfile.net/preview/9324525/page:3/
Там нет разницы (во всяком случае она не чувствуется) где именно находятся данные. Доступ к ним абсолютно свободен.

Все эти гарварды и нейманы имели смысл, когда процессоры были примитивные. Адресное пространство и шина были связаны и их можно было делить. Сейчас же, когда в микроконтроллере вот такое, это деление не имеет никакого смысла.

Разница есть и она существенная. Код из ОЗУ выполняется медленнее кода с флеша. Конвейер же. В котрексах еще и отдельные шины icode и dcode.

Посмотрите картинку выше. Из какого именно ОЗУ? Из какого именно флэша? На каком процессоре? С кэшем или без?

например на STM8. В programming manual там подробно об этом описано. я полагаю, на stm32 тоже есть такое явление.
Ну и BusMatrix так себе решение. Судя по картинке, связь между флешем и озу идет по мосту d1-d2 AHB. Если его забить у остальной периферии доступа к шине не будет. Как понимаю, должен быть механизм приорететов доступа к шине.

На картинке STM32, если что.

И?

как я и предполагал:

источник: http://we.easyelectronics.ru/STM32/vypo ... v-iar.html

То что вы цитируете верно для одного конкретного чипа. В целом это неверно.

я могу еще вспомнить TCM RAM. скажете между нею и обычной RAM тоже нет разницы?

Я имел в виду не быстродействие, а возможность доступа к данным. Если потребуется увеличить скорость, то достаточно просто указать какие функции нужно запускать из RAM. Лично мне пока этого не требовалось.

Если потребуеся блочная запиcь в EEPROM, то запись вы должны будете выполнять из ОЗУ, т.к. флеш на время записи "отлетает".

Не надо полагать, надо изучать и пробовать. На Cortex-M везде всё по-разному: где-то из ОЗУ быстрее, где-то - из флеша. Зависит от наличия и размеров кеша, ширины шин к флеши, частоты флеши, частоты ядра, конфигурации матрицы шин, выполняющегося алгоритма, загруженности обращениями ОЗУ и т.п.

PS: А судить о работе ARM по STM8, это примерно то же самое, что судить о конструкции небоскрёба глядя на дачный сарай.

     Да нет же! Отсутствие принципа однородности памяти заключается вовсе не в разделении на команды и данные, ибо данные от команд отличить невозможно в принципе. Любая команда, обращающаяся к данным, просто обязана содержать где-то в себе поле адреса, и этот адрес никак не является командой, а является уже данным для обращения к другому данному. Принципиально возможно разделить данные по критерию константы/переменные (то есть ПЗУ и ОЗУ), но отделить адреса от команд невозможно в принципе. Я уж не говорю о командах, содержащих в своём теле сразу данные. Команды переходов сюда же.
     Весьма некорректно говорить о принципе, ссылаясь на конкретные примеры. В математике это называется индукцией. Она не всегда приводит к правильным результатам. Ваш печальный опыт работы с ПИКами лишь подтверждает это. Вы наткнулись на отсутствие нужной команды в системе команд конкретного МК и сделали вывод о принадлежности его к той или иной архитектуре. А это всего лишь система команд, но не архитектура.

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

о каком ARM речь? ARMv8? Cortex? или о чем-то другом? Прекрастно знаю STM32F1xx и STM8(A/L) и ваш небоскреб не сильно отличается от сарая.

На f103 свет клином не сошёлся. Чуть выше картинка тоже от stm32 и тоже на Cortex-M. Но там есть как SRAM быстре FLASH, так и наоборот. Есть блоки памяти с отдельными шинами только для кода и только для данных. И т.д.

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

Весь вопрос только в том: что именно читать и как читать? Представьте себе, человеку порекомендовали тот же STM32. Открывает он datasheet, смотрит и видит - какие-то порты, таймеры, SPI, UART ... И что ему делать дальше? Дальше ему подсказывают - читай мануал! А в этом мануале около 1000 страниц, и хорошо, если есть его перевод на русский. А если его нет? Словом, "куды бедному крестьянину податься"?

Для понимания мануала в 1000 стр. (видимо предполагается сУрьёзный МК) необходимо (1) иметь образование чуть выше церковно-приходского и (2) умение "читать по диагонали" с уже пониманием аббревиатур. Товарищ не могёт и не понимает чего сиё такЭ - так ещё наш вождь говАривал: учиться, учиться и учиться. А пока НЕ, так начинать надо с простых МК и их "мурзилки", т. е. основ. А как только придёт понимание что есть МК и что в нём как, то дальше проблем не будет, т.к. будет искаться только нужное и которое, ежели не иероглифы, (поверьте) плевать на каком языке.
Гы. Мы же ведь научились понимать даже перевод китайцами с китайского на русский.
Кому хочется совсем вглубь, да на любых забугорных языках, тоже ведь понятно - велкам учить язык или искать хороший технический переводчик.