Перейти к содержанию
    

wedmeed

Свой
  • Постов

    107
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о wedmeed

  • Звание
    Частый гость
    Частый гость
  • День рождения 11.04.1989

Старые поля

  • skype
    Array
  • Facebook
    Array
  • Vkontakte
    Array
  • LinkedIn
    Array
  • Twitter
    Array
  • G+
    Array
  • Одноклассники
    Array

Контакты

  • AIM
    Array
  • MSN
    Array
  • Сайт
    Array
  • ICQ
    Array
  • Yahoo
    Array

Информация

  • Город
    Array

Посетители профиля

1 026 просмотров профиля
  1. Опробовал, не могу нарадоваться. Спасибо!!!
  2. P.S. Я зря обрадовался. Вылеченная 705я адекватно работает только с уже созданными проектами. При попытке создать новый или сменить target старого видим пустую базу данных (именно при этих операциях, при просмотре базы данных отдельно все отображается). Стоит удалить лицензию - база на месте.
  3. Попробовал вашу версию - та же беда. Пробовал лечить медкомплектом от 705, что на ftp - та же беда. Пробовал лечить прилагающимся, а длл из 705 - та же беда. Пробовал разные комбинации - и опять не помогло. Однако, заработала 705я версия с ftp, чего мне на данный момент вполне достаточно. Просьба к Xenia - пожалуйста, проверьте работоспособность 753 комплекта на фтп. Лицензии там генерируются, кейлом распознаются, а вот ни один пример не компилируется (Device is not supported by Toolchain). Хочется знать, не у одного ли меня такие проблемы (хотя ошибка повторяется на 2х разных компьютерах с 7 и XP, но все же).
  4. Более того, когда скармливаю лицезию менеджеру, она даже распознается (пишет PK166). Попробовал брать лицензии по отдельности (компилятор, ассемблер, отладчик) - та же история, что описывал выше для любой из лицензий.
  5. К сожалению. Симптомы, появляющиеся после попытки вылечить PK166 PDK v.7.0 таблеткой от MDK ARM 4.71a (и после перезапуска среды): при выборе target device в списке присутствуют только ARM-платформы, при попытке скомпилировать проект, созданый для C166 ранее - сообщение *** Device is not supported by Toolchain ! ***. Примечание. Keil нужен для работы с двумя архитектурами одновременно (ARM и C166), что и прописано в tools.ini. ARM-тулчейн лечится нормально и прекрасно ладит с evaluation версией C166.
  6. Не могу найти KeilUv4 для 166. Для новых, что с сайта их качаются, не подходят лекарства, а старые (6.11) как в воду канули. Если кто-нибудь знает где искать, подскажите, пожалуйста...
  7. Я уже давно тут не отписывался, так как пока хочу лучше изучить предложенные решения (конкретно L4 и Forth). Но параллельно встречаются и другие вопросы, которые хотелось бы обсудить. 1) Какие способы оценки качества (а в случае моей целевой системы читать - надежности) существуют и могут быть актуальны. Последний классический учебник который я встречал (Майерс) датировани 1980 годом. Кнниги Липаева классическими не называют, да и основываются на совсем другом классе систем (большие, сложны, распределенные). То, что предлагают современные стандарты (чаще взаимодействуйте при разработке с сертифицирующим органом) не устраивает в связи с наличием человеческого фактора и отсутствием математически обоснованных методик. Грубо говоря - как мне по науке доказать что то или иное решение принесет лучший результат. 2) Экзоядро. Я давно о нем слышал, но только недавно нашел хорошее объяснение, которое меня немного вдохновило. Еще раз про целевую систему: нет мму/мпу, памяти мало (дробить на страницы тяжело), не меняющийся набор программ, можно выполнять инструкции из флеш, много периферии, надо работать быстро, преобладание цикличных задач, вредоносного кода нет. Все так и подталкивает - отказаться от процессов в сторону потоков, написать простейшую переключалку по таймеру, а все остальное - в библиотеках. Защита - за счет инкапсуляции библиотек (ну и надеяться что в будущем к платформе пришьют мпу). Кто сталкивался, поделитесь соображениями/ссылками/книжками.
  8. Прошу прощения, я не сразу понял суть. Идея в том , чтобы использовать ЯВУ для мат. доказательства правильности работы ядра (или хотя бы его алгоритмов)? Основное преимущество форта (говорим про быстродействие) - в малом объеме программ на нем? За счет отсутствия необходимости частой подкачки? Теперь про L4. Я не особо силен в иностранном, поэтому чтобы вникнуть воспользовался этим: обзор. Есть пара вопросов: Синхронная передача сообщений означает что оба процесса должны одновременно быть в режимах приемника (один) и передатчика (другой). То есть для передачи оба процесса должны сменить состояние и отдать управление ядру, так? Наличие многоуровневых менеджеров памяти. То есть аппаратно виртуализацию/защиту поддерживает только менеджер высшего уровня (в ядре L4)? В остальных виртуализация программна и менеджер работает в usermode? Например, ОС, работающая поверх L4 не имеет внутри абсолютных защит между своими процессами?
  9. Хаскель - функциональный "чистый" язык. В нем по логике не может быть коллизий памяти, пока не начать использовать функции с побочными эффектами. А как без последнего работать со временем или реализовать закон управления по передаточной функции (где обязательно иметь переменные состояния) я не представляю. Буду рад если сможете привести пример. Почему прототип? Какие функции он выполняет и есть ли среди них защита процессов друг от друга? Есть ли подобная реализация на Си? Человек есть человек. Все ошибки найти или гарантировать что они все найдены невозможно. http://www.osp.ru/os/1998/06/179592/ Или зачем тогда делают системы с резервированием? Доказать надёжность кода поддержки MPU можно один раз и использовать во всех дальнейших проектах. При защищенности процессов друг от друга можно плотно доказывать надежность только критических модулей программы, остальных - поверхностно. Если классифицировать уровень критичности модуля в соответствии с тем же КТ178.
  10. Извиняюсь, только сейчас понял что это аббревиатура. Тогда не понимаю. В теме говорилось про возможность контроля за процессом и защита памяти. Си, даже Си++, это не умеют. А вот джава-подобные (с виртуальной машиной) умеют.
  11. Я Вас понял. Виртуальные машины вещь очень сильная, но и расточительная. Когда люди говорят о микроконтроллерах - часто это связано с маломощными платформами и ужатыми ресурсами. С другой стороны, у меня есть специфицеская задача со специфическим набором функций. Чтобы сократить расходы на интерпретацию байт-кода, очень пригодился бы такой же специфический набор функций. Но разрабатывать новый язык я не возмусь. Даже если он выродится в небольшой набор скриптов. На мой взгляд, маленькая простенькая ОС с MMU/MPU выглядет гораздо элегантнее. Даже не ОС, диспетчер. Какие еще преимущества кроме контроля исполнения дают ЯВА-подобные среды? Почему микроконроллеры с флэшью >64 Кб не оснащают MMU/MPU? Ведь уже в таком объеме можно наворотить довольно сложную систему. Насколько я понимаю это, по крайней мере MPU, не такой сложный модуль, который можно сделать даже не влезая в ядро (просто мониторить шину и генерировать прерывания-ловушки).
  12. Это если необходимо защищать встроенную память. Если пользуется внешняя - можно и MMU, правда выглядеть он будет довольно монстроидально. Исходя из задачи - да, MPU достаточно и гораздо оптимальнее. Насколько сложно портировать среду явы? Сложно ли гарантировать корретность портирования и отсутствие ошибок в среде? Насколько понимаю, это накладные расходы x3 минимум? З.Ы. На яве никогда не писал и, тем более, не портировал.
  13. Ну, собственно, да. Или от своих соседей. Да, защищать остается именно ОЗУ. Системы управления, для которых разрабатывается ПО обладают одним опасным свойством - "лучше не работать, чем работать неправильно". И ПО обычно больше напоминает конечный автомат, чем умную программу. И вот если этот конечный автомат при расчете порции топлива для самолета на взлете случайно "выхватит" нолик, занесенный редким и трудновычислимым багом в неприоритетном модуле предполетного контроля, будет беда. Про источник ошибок. Программа записана на флеш. Ни о каком вредоносном коде речь, соответственно, не идет. Источник ошибок - радиация, всковырнувшая бит, или ошибка программиста. Защита от первого хоть и принесет плюс, но не обязательна, т.к. должна обеспечиваться стойкостью аппаратуры. А вот ошибки программиста, среди которых так часто переполнения стека или неуправляемые циклы, контролировать бы надо. И как бы того не хотелось, от ошибок не защищен никто...
  14. Где можно найти какие методы они используют для обеспечения надежности? Ну и к моей учебной проблеме. Написание банального диспетчера или портирование одной из осей/сред на новый МК тянет на кандидатскую?
  15. Какие еще есть способы защитить программу? Как это делают FreeRTOS и остальные без MMU. Офтоп. А, например, QNX, имеет порты на МК без MMU (напр. для Cortex-M3 оно опционально)?
×
×
  • Создать...