Подскажите как запустить исполняемый код из ОЗУ. Использую Keil 4 и процессор cortex-m3 sam3u от Atmel. Я ламер в этом вопросе.

Загрузить код в озу и передать ему управление ))
у ARM не разделяется память программ и данных.

в corterx-m3 это не дает профицита, работа из флеша на полной скорости скорее всего будет быстрее - чтение команд и обмен данными будуи выполнятся паралельно, если выполнение из озу - то чтение команд и обмен данными будут разделять шинную матрицу и шину к озу. если вам нужен полиморфный код котрый сам себя генерит и на лету выполняется то да! это конечно правильный метод. Как то так я все это понимаю.

Извиняюсь за ламерский вопрос, но как можно загрузить код в озу и передать ему управление?
Например загрузчиком по UART или это можно сделать из под Keil? Если да, то как?



Дела в том, что я планирую использовать медленную внешнюю ПЗУ. По ТЗ не могу пользоваться внутренней ПЗУ (есть требование спецстойкости). При инициализации МК перебрасываю медленно код программы из внешней ПЗУ во внутреннюю или внешнюю ОЗУ и исполняю. Сейчас как раз хочу померить потерю в производительности при такой конфигурации. Буду всем крайне признателен за помощь.

Если внутренний флэш "неспецстойкий", то получив к нему доступ, автоматически получаешь доступ ко всему остальному. Хотя, если денег платят, то какая разница...

А экономить энергию не получится?
Если отключить флеш и выполнять что-то короткое (прерывания) и засыпать на выходе?

вообще не понял что вы имеете в виду

если у вас спецстойкость, то причем здесь atmel?
или вы считаете, что процессор у вас выживет а его ПЗУ нет? - это бред.
меня трясет, когда я вижу перечни на согласование применения импорта, совершенно не оправданного!
создается впечатление, что среди военных до уровня министра нет ни одного инженера-электронщика!

просто используйте миландровский процессор.

На Atmel мы отрабатываем алгоритмы, которые в дальнейшем переносятся под миландровский процессор, это во-первых. Архитектура у них примерно одинакова.
Во вторых, FLASH память - это самый нестойкий элемент при спецвоздействии, если вы не в курсе. Это во-вторых.
Ваши домыслы оставьте при себе - это в третьих.

Разделите память на две страницы, и используйте DMA для копирования в память из внешнего EEPROM (или NOR флеш). Пока исполняется код из нижней памяти, параллельно копируйте в верхнюю, и наоборот. Процессорная начитка из периферии - самый медленный вариант.

По поводу МК - флеш там наверняка NOR что хорошо для спецвоздействий, а вот ОЗУ я сильно сомневаюсь что на статической памяти, хотя все может быть. Так что слабо верю что код не посыпется при облучении. С другой стороны, сейчас все очень сильно притянуто за уши, реально стойкой логики никто не делает.

нагрубил, извините,

у них одинакова архитектура только ядра, все остальное - нет, рекомендую быстрее начинать отладку на штатном процессоре.

по поводу памяти, в любом случае какой-то код должен исполняться из ПЗУ контроллера
этот код может подгружать основную программу из вне и прочее,
но он есть, и внешней памятью вы вряд-ли повысити стойкость

ps 1986ВЕ91Т 7.И1-3Ус,7.И6-3Ус,7.И7-10х1Ус,7.С1-5Ус,7.С4-0,1х1Ус,7.К1-1К,7.К4-0,05х1К не так уж и плохо...

Сообщение отредактировал sevastianovd - Mar 30 2012, 06:04

Мы уже начали отлаживаться на 1986ВЕ1Т, но пока плата одна, поэтому параллельно алгоритмы еще отлаживаем на sam3u. В 1986ВЕ1Т есть ROM которая по наличию сигналов на определенных ножках определяет откуда брать прошивку: из внутренней ПЗУ, внешней и тд.

У Миландра готовится к выпуску радиационно стойкое ОППЗУ 1645РТ2У.




это всё должен делать загрузчик? объясните, пожалуйста поподробнее



у Миландра есть ОЗУ на 16Мбит (1Мх16) 1645РУ4У
1645РУ4АУ 7.И1-4Ус,7.И6-0.3х1Ус,7.И7-1,6х4Ус,7.С1-50х4Ус,7.С4-0,8х5Ус,7.К1-0,4х2К,0,4х1К

Сообщение отредактировал rfserega - Mar 30 2012, 15:00

Само собой. Как писали выше - загрузчик, затем far call. И то и другое можно на С написать, думаю.
А я имел ввиду следующее - ведь вам производительность нужна? Тогда копирование из внешней ПЗУ надо делать с помощью ДМА, т.к. это быстрее. И поскольку ДМА работает независимо от процессора, этим можно воспользоваться: программа может начать работу раньше, чем вы скопируете всю программу внутрь.
Правда, это копирование должен кто то запустить. А для этого, как я понимаю, нужно использовать system memory boot mode, поскольку это единственный способ забутиться из внешней памяти.
Т.е. как это может выглядеть: внешняя маленькая микросхема с загрузчиком - мк с нее бутится. Далее, загрузчик начинает копировать основную программу из (другой, большой) микросхемы ПРОМ. Копирование лучше всего делать по дма (как писал выше), а пока дма работает можно заниамться чем то другим ... проинициализировать остальную периферию, к примеру; в общем, начать работу еще до окончания копирования.


Да, есть такие. Здоровенные керамические корпуса, после привычных tsop выглядят чудовищно, а место на плате занимают ... слёзы. Если бы в фобосгрунте использовали не китайские технологии с фабрики дядюшки Ляо, а по честному - суровую российскую электронику в металлокерамике, фобосгрунт бы просто не взлетел )
Кстати, и параллельная NOR флеш у них есть, и даже вроде последовательная, хотя не уверен. Что забавно, для прошивки nor флеша они предлагают купить у них программатор ) причем, даже не один - есть и для отдельного программирования на производстве, и для внутрисхемного, через наплатную гребенку.

А какой вариант расположения исполняемого кода вам видится наиболее приемлемым, если предположить что требования по уровню стойкости конечного изделия выше, чем способна удовлетворить Flash ПЗУ в миландровском процессоре?

требования по спецстойкости регламентируются на изделие, в данном случае на весь процессор. ни в одном ту отдельно память не выделена. если не лезет стойкость - либо защита в составе изделия - либо другая микросхема (правда другой нет )
у нас тоже такой вопрос стоит только немного иначе - как обеспечить ВБР изделия 0.99 на 100 тыс. часов. пока необходимости внешней памяти нет. может быть будем переписывать flash раз в пятилетку...