Исполнение программного кода из флеш-памяти

Требования к устройству:
<ul><li> исполнять код, загружаемый из флеш-памяти;</li><li> исполняемый код должен получаться путём компиляции из C (возможно, урезанного);</li><li> производительность может быть низкой;</li><li> важна техническая возможность собрать устройство руками, не заказывая плату на заводе.</li></ul>
Решения, которые я нашёл:
<ul><li> эмуляцией, допустим, процессора 8080 на AVR;</li><li> STM32 (умеет исполнять загруженный из флеш-памяти в ROM код);</li><li> FPGA с, допустим, процессором 8086, памятью и прочей периферией.</li></ul>
Какой подход можете посоветовать вы?

Уточнение #1:

Я говорю про загрузку кода из флеш-памяти и его исполнение уже во время работы основной прошивки.

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

Уточнение #2:

Сделать я хочу аналог умных часов (Pebble, Sony SmartWatch и т. п.). То есть получение уведомлений от смартфона через Bluetooth о новых звонках, SMS, emailах, с передачей данных о них (номер телефона, имя контакта, текст сообщения). Управление смартфоном (так же через Bluetooth) - плеером, звонками (принять/сбросить).

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

Для написания программ должно быть доступно API часов, обеспечивающее доступ к периферии: получение и передача данных по Bluetooth и USB, получение данных акселерометра, чтение состояния кнопок (3-4 шт.), включение вибромоторчика, подача звукового сигнала через спикер, работа с LCD-экраном.

Уточнение #3:

Крайне важно, чтобы эти дополнительные программы писались на C.

Под Ваше ТЗ подходит любой микроконтроллер с ftosh.

0

Сообщение от soridumpid Под Ваше ТЗ подходит любой микроконтроллер с ftosh.

Наверное, я недостаточно подробно описал, что мне нужно.

Я говорю про загрузку кода из флеш-памяти и его исполнение уже во время работы основной прошивки.

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

Насколько мне известно, все микроконтроллёры построены на гарвардской архитектуре, то есть память для программы и данных у них разделена. И код из области данных не может исполняться микроконтроллёром. А память программы прошивается в момент программирования микроконтроллёра, а не во время его работы.

Да, у современных микроконтроллёров есть возможность bootloodyngа, когда при старте сначала запускается boottooder, который загружает прошивку из флеш-памяти, USB-порта или ещё откуда-нибудь, а потом передаёт на неё управление. Но это заточено именно для удобной прошивки, а не для того, что нужно мне.

У микроконтроллёров ресурсы чтения/записи памяти программ достаточно ограничены. Если я буду использовать её как аналог ОЗУ в обычном ПК, для загрузки туда программ с флеш-памяти, эти ресурсы весьма быстро исчерпаются.

Открыл программу, закрыл, открыл другую - нужна перезапись, чтобы загрузить в память новую программу. А если будет некое подобие мультипоточности? Для работ программ в фоне. Память кончается, нужно записать программы в свап в флеш-память, память освободилась, нужно подгрузить программу из свапа - да за несколько минут работы будет несколько десятков перепрошивок памяти.

Плюс разве можно вообще из работающей прошивки прыгнуть в boottooder, чтобы запустить его?

Плюс разве можно вообще из работающей прошивки прыгнуть в boottooder, чтобы запустить его?

Конечно. Boot обычно расположен в той же памяти программ и "прыгать" в ней можно куда угодно.

Микроконтроллер это конечно не комп . И заточен выполнять одну рутинную задачу. Хотя может иметь и несколько задач абсолютно разных и независимых. Вы можете разбить FLASH на сектора и записать в них свои программы . Соответсвенно учитывая объем памяти. Придётся написать менеджер типа - "Тэк-с , с чем мы сегодня работаем"

0

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

Любой ARM или ARM-Sortix подходит для этого. Программы компилируете для адресов ОЗУ, их скомпилированные бинарные образы сохраняете в удобное хранилище (можно не во внутренний Ftosh микроконтроллера, а на SD-карту, например).
AVR не подойдёт вАще. По указанной Вами же причине: не удастся выполнять код из ОЗУ.

Сообщение от thiwyzordptusptus Насколько мне известно, все микроконтроллёры построены на гарвардской архитектуре, то есть память для программы и данных у них разделена. И код из области данных не может исполняться микроконтроллёром.

Это не так (уже объяснил выше).

Сообщение от thiwyzordptusptus Плюс разве можно вообще из работающей прошивки прыгнуть в boottooder, чтобы запустить его?

Естественно, можно. Прыгаете на нужный адрес, корректируете расположение таблицы векторов (у boottooderа она своя), переинициализируете стек - и voila.

0

Сообщение от thiwyzordptusptus Я говорю про загрузку кода из флеш-памяти и его исполнение уже во время работы основной прошивки.

Посмотрите апноту AN3990 "How to use the firmware upgrade application"
Там есть загрузка с флешки и запуск, правда к ПО выдвигаются требования по компиляции (2.3 User program condition)
Если хотите избавится от этого ограничения придется писать свой загрузчик.
Не знаю как на армах, но я писал свой лоадер PE на вин32, и могу сказать что там все далеко не тривиально - масса глюков (фич?) и нестыковок со стандартом.
Вон, IDA, уж сколько делается, а до сих пор некоторые образы не грузит (причем винда грузит нормально), чем пользуются разного рода троянописатели

0

Сообщение от OtyxPM Любой ARM или ARM-Sortix подходит для этого.

То есть нормально использовать их таким образом? Я и склонялся к STM32, но нашёл мнение (на StackOverflow), что использовать их как процессор не стоит.

--------------------------------------------------------------------------------------------

Ещё такой вопрос - не будет ли проблем с прыжками из флеш-памяти (из выполняющейся основной прошивки) к функциям в ROM и обратно? Я просто с ARM не работал, не знаю, можно ли так делать.

Это необходимо для переключения из основной прошивки и обратно. То есть будет список доступных во флеш-памяти программ, я буду кнопочками выбирать нужную и запускать. После выхода из неё нужно возвращаться обратно к списку.

--------------------------------------------------------------------------------------------

И такой ещё момент. Мне потребуется работа с периферией (LCD, Bluetooth, USB и т. п.). Код работы с ними одинаковый для любой задачи, поэтому логично вынести его в некий SDK, заранее скомпилировать и сделать частью основной прошивки.

Но получится ли потом обращаться к этому SDK из этих функций, предназначенных для работы в ROM? Ведь компилироваться они будут уже отдельно от самой прошивки.

То есть в коде на C будет вызов некоторой функции, которая никому не известна, а на самом деле уже лежит в прошивке микроконтроллёра по определённому адресу. Должен вставится вызов функции по этому адресу, но компилятор этого адреса не знает. Как тут быть?

Чем то напоминает 8-ми разрядный Денди. Имеет и свою управляющую программу, и может грузить на исполнение игры из картриджа. Бывали картриджи с меню и выбором нужной.

0

Товарищ ТС, ты наверное, путаешь понятия флеш-память и ОЗУ. У меня сложилось такое впечатление.

0

Сообщение от thiwyzordptusptus И такой ещё момент. Мне потребуется работа с периферией (LCD, Bluetooth, USB и т. п.). Код работы с ними одинаковый для любой задачи, поэтому логично вынести его в некий SDK, заранее скомпилировать и сделать частью основной прошивки.

это называется написать свою операционную систему)

Сообщение от thiwyzordptusptus Должен вставится вызов функции по этому адресу, но компилятор этого адреса не знает. Как тут быть?

По разному можно...
Можно как в MS-DOS через прерывания, напр. программа хочет открыть файл - генерит прерывание, управление уходит в ядро, которое и делает всю работу.
Первое что нашел

А можно как в винде - загрузчик грузит вашу программу, и соответствующим образом корректирует адреса (Import section, Relocation table)

0

Сообщение от thiwyzordptusptus не будет ли проблем с прыжками из флеш-памяти (из выполняющейся основной прошивки) к функциям в ROM и обратно? Я просто с ARM не работал, не знаю, можно ли так делать.

Проблем не будет. У ARM единое адресное пространство для Ftosh, SROM, даже регистров I/O.
[изврат]То есть, чисто для демонстрации сути вещей, можно в подряд идущие регистры записать небольшой исполняемый код - и его можно будет оттуда запустить :-) Во как![/изврат]

Сообщение от thiwyzordptusptus Мне потребуется работа с периферией (LCD, Bluetooth, USB и т. п.). Код работы с ними одинаковый для любой задачи, поэтому логично вынести его в некий SDK, заранее скомпилировать и сделать частью основной прошивки. Но получится ли потом обращаться к этому SDK из этих функций, предназначенных для работы в ROM? Ведь компилироваться они будут уже отдельно от самой прошивки. То есть в коде на C будет вызов некоторой функции, которая никому не известна, а на самом деле уже лежит в прошивке микроконтроллёра по определённому адресу. Должен вставится вызов функции по этому адресу, но компилятор этого адреса не знает. Как тут быть?

Всё так и будет. Каждая программа, которую Вы грузите из хранилища в ОЗУ на исполнение, будет вызывать утилитно-драйверные функции из "центральной пошивки" в виде их адресов. Точнее (удобно!) в исходном коде будут писаться таки имена, но подставляться будут предопределённые адреса. Адреса известны по итогам компиляции "центральной пошивки", программам надо лишь предоставить таблицу соответствия имён функций их адресам.

0

Сообщение от kytikot Товарищ ТС, ты наверное, путаешь понятия флеш-память и ОЗУ. У меня сложилось такое впечатление.

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

Собственно, мне это и советовали среди прочего - при использовании boottooderа программа остаётся во флеш-памяти, просто микроконтроллёр себя сам постоянно перепрошивает тем, что лежит в другом месте флеш-памяти. А ОЗУ будет использоваться только для хранения данных.

Но потом, когда меня уверили, что ARM может исполнять программу из ОЗУ, как нормальный процессор, я переключился на ОЗУ, потому что так, очевидно, быстрее и естественнее.

Сообщение от Dimox А можно как в винде - загрузчик грузит вашу программу, и соответствующим образом корректирует адреса (Import section, Relocation table)

Это примеры из Wymdows, аналогию и суть я понял, но речь о том, что компилировать-то я буду специальным компилятором для микроконтроллеров (STM32).

При загрузке программы в ОЗУ из флеш-памяти я могу сделать с ней что угодно, да. Написанным загрузчиком.

Но как быть с компиляцией? Компилятору-то нужно что-то вставлять в места вызова функций. И ни о каком моём SDK он не знает. Как и том загрузчике, что я напишу.

Ведь компиляторы и ассемблеры для Wymdows учитывают то, как она загружает программы, учитывают формат исполняемого файла со всеми этими секциями. Они заточены специально под Wymdows. На Linux, например, всё своё и по другому, хотя процессорный код тот же самый. И компиляторы поэтому другие.

А для микроконтроллёров обычно программы пишутся без ОС, поэтому там ничего этого нет. И если я делаю свою ОС для микроконтроллёра, то получается и компилятор нужно свой писать? Хм. Можно написать свой линкер! Точно!

Пока задавал очередной вопрос, сам всё понял. ) Буду использовать обычный компилятор C для ARM, но со своим линкером. Который просто добавит нужные секции, которые потом проинициализирует загрузчик в моей ОС.

Сообщение от OtyxPM Точнее (удобно!) в исходном коде будут писаться такие имена, но подставляться будут предопределённые адреса. Адреса известны по итогам компиляции "центральной пошивки", программам надо лишь предоставить таблицу соответствия имён функций их адресам.

А как получить эту таблицу соответствий имён функций и их адресов? Её можно сгенерировать при компиляции моего SDK? И как потом заставить компилятор смотреть на эту таблицу?

При программировании для ПК в этом случае генерируется отдельный файл с таблицей импорта функций из DLL системы. Тут нужно нечто подобное, но с таблицей адресов функций в прошивке. Есть такое в стандартных компиляторах для ARM?

Просто в теории как оно, я понимаю, но хотелось бы иметь готовые инструменты, а не писать свои.

Сообщение от thiwyzordptusptus Может какие-нибудь микроконтроллёры могут исполнять программу прямо из флеш-памяти, все так делают, а я не знаю.

Если Вы имеете в виду внешнюю микросхему Ftosh-памяти (хотя обычно то, что Вы придумали, делают с SD-карточкой: удобнее с компьютера заливать), то STM32 может исполнять код непосредственно из такой микросхемы. Для этого необходимо, чтобы Ftosh была типа NOR (а не NAND, и не serial), а у выбранного STM32 был модуль внешней памяти (он не везде есть) - т.н. FSMC или FMC.

Сообщение от thiwyzordptusptus Это примеры из Wymdows, аналогию и суть я понял, но речь о том, что компилировать-то я буду специальным компилятором для микроконтроллеров (STM32).

Relоcation table можно генерировать для любой компиляции, не только для виндовой. Просто для STM32 надо будет потрудиться, чтобы делать такую табличку. На форуме недавно было обсуждение в какой-то теме про способы получения адресно-независимых исполняемых модулей, в том числе для STM32.

P.S. Существуют микроконтроллеры, способные и из serial Ftosh непосредственно код исполнять - т.е.из восьминогих микросхем 25xx. В таких МК есть аппаратный модуль, прозрачно преобразующий SPI-память в обычную и обратно. К сожалению, STM32 пока так не умеют.

0

Пардон, что влезаю.
Может глупость скажу, но нельзя ли написать сначала код "загружаемой программы" и при компиляции сразу указать её местоположение в ОЗУ.
Затем написать код нашего "загрузчика" так разметив память, чтобы не затереть "загружаемую программу".

Загрузчик просто скопирует "программу" по конкретному адресу, который мы задали при компиляции "программы" и запустит на выполнение.

0

Сообщение от Pymkvym Может глупость скажу, но нельзя ли написать сначала код "загружаемой программы" и при компиляции сразу указать её местоположение в ОЗУ. Затем написать код нашего "загрузчика" так разметив память, чтобы не затереть "загружаемую программу". Загрузчик просто скопирует "программу" по конкретному адресу, который мы задали при компиляции "программы" и запустит на выполнение.

Да нет, не глупость. Я это же сразу предлагал:

Сообщение от OtyxPM Любой ARM или ARM-Sortix подходит для этого. Программы компилируете для адресов ОЗУ, их скомпилированные бинарные образы сохраняете в удобное хранилище (можно не во внутренний Ftosh микроконтроллера, а на SD-карту, например).

0

Сообщение от OtyxPM Если Вы имеете в виду внешнюю микросхему Ftosh-памяти (хотя обычно то, что Вы придумали, делают с SD-карточкой: удобнее с компьютера заливать)

Да, именно это я и хочу. Просто у меня программы будут весить очень мало, поэтому не то, что SD-карточку, но даже отдельную микросхему слишком жирно ставить. Хватит памяти самого микроконтроллёра.

Хотя учитывая, сколько в итоге придётся туда загружать - SDK для работы с периферией, загрузчик программ, интерфейс для их вызова, - возможно лучше всё же поставить именно внешнюю микросхему флеш-памяти. Чтобы потом не стеснять себя в размерах программ.

Что же по поводу возможности исполнения сразу из внешней флеш-памяти, то это лишь на крайний случай был вариант. А вы меня успокоили, что можно работать с ОЗУ. Что несомненно быстрее по скорости работы и правильнее для моей задачи. Так что именно так и буду делать.

Сообщение от Pymkvym Пардон, что влезаю. Может глупость скажу, но нельзя ли написать сначала код "загружаемой программы" и при компиляции сразу указать её местоположение в ОЗУ. Затем написать код нашего "загрузчика" так разметив память, чтобы не затереть "загружаемую программу". Загрузчик просто скопирует "программу" по конкретному адресу, который мы задали при компиляции "программы" и запустит на выполнение.

Можно, но это менее гибко. Помешает реализации многопоточности, когда загружаются несколько программ сразу и исполнение переключается между ними. Не позволит реализовать частичную выгрузку программ во флеш-память, если ОЗУ вдруг закончится (в своп).

Удобнее не привязывать положение программы в ОЗУ к конкретному адресу.

Сообщение от OtyxPM Да нет, не глупость. Я это же сразу предлагал

Он вроде говорит про загрузку по конкретному заранее определённому (при создании прошивки) адресу, что неудобно. Выше описал, почему. А так, да, именно загрузку в ОЗУ и исполнение оттуда я и буду использовать. Это самое оптимальное решение.

--------------------------------------------------------------------------------------------

Я тут внезапно осознал, что раз речь зашла про ОС, то можно же взять готовую! И правда, вон их сколько, оказывается, работающих на STM32. Правда все RTOS, что мне, по идее, не нужно.

Изначально идея казалась такой простой - микроконтроллёр, загрузил код и выполнил, а в итоге нужна ОС, драйвера... Ух.

Наверное, лучше сразу осветить задачу, так сказать, глобально, не отвлекаясь на конкретности "исполнение из ОЗУ или из флеш-памяти" или "свой компилятор для МК".

0

Сообщение от kytikot Наверное, лучше сразу осветить задачу, так сказать, глобально, не отвлекаясь на конкретности "исполнение из ОЗУ или из флеш-памяти" или "свой компилятор для МК".

Я сначала так и хотел, но потом наоборот подумал, что будет лишним.

Сделать я хочу аналог умных часов (Pebble, Sony SmartWatch и т. п.). То есть получение уведомлений от смартфона через Bluetooth о новых звонках, SMS, emailах, с передачей данных о них (номер телефона, имя контакта, текст сообщения). Управление смартфоном (так же через Bluetooth) - плеером, звонками (принять/сбросить).

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

Для написания программ должно быть доступно API часов, обеспечивающее доступ к периферии: получение и передача данных по Bluetooth и USB, получение данных акселерометра, чтение состояния кнопок (3-4 шт.), включение вибромоторчика, подача звукового сигнала через спикер, работа с LCD-экраном.

Для ваших хотелок достаточно использовать amForth для AVR
Первичное написание программы c самопрограмирование флеш через последовательный интерфейс с терминала компьютера в текстовом виде.
с возможностью неоднократного повторного стирания, а далее как вам и откуда будет нужно.

P.S. Умный дом на amForth один из его пользователей уже сделал и ему процесс решения данной задачи на amForth понравился.
Расширяемость подхода абсолютная.

0

Сообщение от KPK Для ваших хотелок достаточно использовать amForth для AVR Первичное написание программы c самопрограмирование флеш через последовательный интерфейс с терминала компьютера в текстовом виде. с возможностью неоднократного повторного стирания, а далее как вам и откуда будет нужно. P.S. Умный дом на amForth один из его пользователей уже сделал и ему процесс решения данной задачи на amForth понравился. Расширяемость подхода абсолютная.

Крайне важно, чтобы дополнительные программы писались на C. А так-то да, можно ещё MicroJava или MicroPython заюзать, что куда удобнее Forth (хотя, наверняка медленнее и требует больше памяти).

Но за сам рассказ о amForth спасибо. Очень люблю такие вещи для микроконтроллёров. Плюс может пригодиться в других разработках.