вы как всегда в ударе, капитан очевидность



использовать на таких процессорах голые RTOS - это как в анекдоте про лису "обманула, обманула - деньги таксисту заплатила, а сама не поехала", а теперь куда вы засунете эти бумажки от uC/OS, если нужно что-то чуть более, чем круто дернуть ножкой ? Нормальные парни давно об этом подумали, даже комитеты создали по стандартизации Trusted Computing Group & ISO/IEC, GlobalPlatform TEE. А виртуализацией пользуются многие, например
http://www.ok-labs.com/releases/release/ok...quipment-from-k

Сообщение отредактировал sasamy - Oct 29 2012, 12:17

От кого защитить? От своей же соседней программы?
Смысл защиты памяти в том чтобы оградить программу (и ядро) от произвольной сторонней программы, написанной кулхацкером Васей из 7а, осилившим журнал "какер". Или от одноклассника Васи - Пети, который осиливает указатели в Си по K&R и то и дело портит данные в драйвере файловой системы и теряет данные на диске.
В МК же вы заранее пишите весь софт, который там будет работать, и, соответственно вылавливаете баги и уж точно не станете специально портить данные ядра или других программ.
Например, во FreeRTOS-MPU чтобы для Cortex-M3 настроить правильно распределение памяти для задач уйдёт много больше времени и сил чем отлов реальных багов. А попытка программы обратиться куда нельзя так же вызовет MemFault. Надёжность только если на случай порчи данных, например вдруг так совпало и записываем неверные данные в буфер отправки сообщения по какому-либо каналу связи и так получится что вместо "привет" отправится что-то нецензурное. Т.е. гарантируется "плановый" сбой на случай бага с указателями или иными косяками в работе с памятью. Так на этот случай вроде достаточно простого MPU в кортексах М3

L4 -- это семейство ядер почти все из них ориентированы на наличие MMU. И вообще наверное скорее следует говорить о MPU! Поэтому Вас не поддерживаю в этом, а вот в том чтобы "использовать ЯВУ" с защитой -- это да!
На мой взгляд java и Lua лучшие кандидаты.




Опять таки L4-тое ядро.



1. По надёжности -- Нет MPU -- нет надёжности от быдлокода!
2. По методикам -- различные стандарты требуют куча всего для того чтобы код был надёжным.
То есть направо не ходить, налево не ходить, компиляторными нестандартными фишками не пользоваться,
память выделять так, именовать так и так далее -- все эти требования выглядят как ритуал который впринципе помогает кодить среднеквалифицированым специалистам. НО! это всё не даёт 100% гарантии на выполнение!
ДЛЯ доказательства того что ВСЯ система надёжна нужно доказывать всё до последнего байта!

Если есть MPU -- то для доказательства надёжности нужно доказать что ядро+аппаратный механиз защиты памяти надёжны (L4 и прочее тут как раз рулит!) и то что нужные Вам высокоприритетные важные процессы надёжны!

3. РТОС без ММU c "гарантирванным временем вытеснения!" даёт возможность проводить математическое докозательство того что при любых условях самые высокоприоритетные процессы-"элита" получат себе нужное быстродействие а система уложится в отведённые дедлайны!
ВСЁ!


Сообщение отредактировал SyncLair - Oct 29 2012, 15:18

Это если необходимо защищать встроенную память. Если пользуется внешняя - можно и MMU, правда выглядеть он будет довольно монстроидально. Исходя из задачи - да, MPU достаточно и гораздо оптимальнее.


Насколько сложно портировать среду явы?
Сложно ли гарантировать корретность портирования и отсутствие ошибок в среде?
Насколько понимаю, это накладные расходы x3 минимум?

З.Ы. На яве никогда не писал и, тем более, не портировал.

ЯВУ не означает ТОЛЬКО ява. Ничем помочь не могу у самого реальный опыт ноль! Но на то она и диссертация....

Я Вас понял.
Виртуальные машины вещь очень сильная, но и расточительная. Когда люди говорят о микроконтроллерах - часто это связано с маломощными платформами и ужатыми ресурсами.
С другой стороны, у меня есть специфицеская задача со специфическим набором функций. Чтобы сократить расходы на интерпретацию байт-кода, очень пригодился бы такой же специфический набор функций. Но разрабатывать новый язык я не возмусь. Даже если он выродится в небольшой набор скриптов.
На мой взгляд, маленькая простенькая ОС с MMU/MPU выглядет гораздо элегантнее. Даже не ОС, диспетчер. Какие еще преимущества кроме контроля исполнения дают ЯВА-подобные среды?

Почему микроконроллеры с флэшью >64 Кб не оснащают MMU/MPU? Ведь уже в таком объеме можно наворотить довольно сложную систему. Насколько я понимаю это, по крайней мере MPU, не такой сложный модуль, который можно сделать даже не влезая в ядро (просто мониторить шину и генерировать прерывания-ловушки).

Сообщение отредактировал wedmeed - Nov 1 2012, 06:16

По-моему не поняли. ЯВУ - язык высокого уровня. Си, например. В отличие от ассемблера который низкоуровневый.

Извиняюсь, только сейчас понял что это аббревиатура.
Тогда не понимаю. В теме говорилось про возможность контроля за процессом и защита памяти. Си, даже Си++, это не умеют. А вот джава-подобные (с виртуальной машиной) умеют.

Сообщение отредактировал wedmeed - Nov 1 2012, 07:04

В теме говорилось о том что "Только придется среду исполнения портировать", так вот ее не обязательно портировать - ЯВУ (Haskell по ссылке) используется для создания прототипа микроядра

Voyager-1 летит уже 35 лет. Никакого MMU на нем нет.

Планировщики в осях тоже никакого отношения к MMU не имеют.
Если вы согласны с мыслью, что в RTOS вообще не может быть ошибок, то должны сконцентрироваться на их отлавливании на этапе разработки, а не на фиксации сбоев благодаря MMU на этапе эксплуатации.

Поэтому для RTOS гораздо важнее JTAG отладчики и трассировщики.
Использовать же MMU на этапе разработки только для того чтобы вычислить пару специфических ошибок сильно расточительно.

а кто вам сказал что если есть MPU - то сразу появляется надёжность от быдлокода? надёжность с наличием/отсутствием MPU никак не связана (конечно, в проектах, где внешнюю программу подгрузить нельзя). надёжность зависит только от количества быдлокода.


то есть к доказательству надёжности каждой строчки проекта надо ещё и доказать надёжность дополнительного кода поддержки MPU?

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


Человек есть человек. Все ошибки найти или гарантировать что они все найдены невозможно. http://www.osp.ru/os/1998/06/179592/
Или зачем тогда делают системы с резервированием?


Доказать надёжность кода поддержки MPU можно один раз и использовать во всех дальнейших проектах.
При защищенности процессов друг от друга можно плотно доказывать надежность только критических модулей программы, остальных - поверхностно. Если классифицировать уровень критичности модуля в соответствии с тем же КТ178.

Вы похоже не то что по ссылкам не ходите - даже не читаете то что тут цитируют - удачной беседы самому с собой

А не удивительно, что за столько лет все продолжают приводить в пример замусоленные случаи с Ariane 5 и Therac-25?

Почему бы не привести проблему с Opportunity?

Вообще-то известная и яркая проблема человеческого фактора который может легко убить даже систему с MMU.

Там речь шла о том, что марсоход в определенный момент экпедиции вдруг стал жутко тормозным и долго не реагировал на команды.
Его пришлось остановить и долго перезаливать софт.
Там была RTOS VxWorks. Поскольку нынче на космической технике применяю радиационно стойкие RAD750 (аналог PowerPC) то WxVorks там использует MMU.
Программист то ли из-за лени, то ли из-за невысокой своей квалификации подумал, что в RTOS можно кое в каких местах пропустить использование мьютексов.
Дескать вызов мьютекса вносит лишнюю задержку, а там надо было записать какую-то мелочь межзадачную.
Хотя проблема инверсии приоритетов ему была прекрасно известна.
Ну инверсия и произошла. Низкоприоритетная задача в результате остановила важные задачи по оперативному управлению.

Теперь вопрос. Как MMU могло бы помочь этой проблеме? Ответите и докторская у вас в кармане.

Да уж! ... вообще то средне-инженерная задача, но с неё делают кандидатскую и/или затем на докторскую замахиваются.
Что дальше? Или такое сильное отставание по OS в стране и какой!?

проблема с Opportunity ... хороша, но не фейк ли это? Они же тестируют все на модели на земле потом туда, или просто прохлопали.