Тестирование операционной системы реального времени для твердости
Здесь это находится в Java:
import static java.lang.Math.round;
import static java.lang.Math.random;
import static java.lang.Math.pow;
import static java.lang.Math.abs;
import static java.lang.Math.min;
import static org.apache.commons.lang.StringUtils.leftPad
public class RandomAlphaNum {
public static String gen(int length) {
StringBuffer sb = new StringBuffer();
for (int i = length; i > 0; i -= 12) {
int n = min(12, abs(i));
sb.append(leftPad(Long.toString(round(random() * pow(36, n)), 36), n, '0'));
}
return sb.toString();
}
}
Вот выполненный образец:
scala> RandomAlphaNum.gen(42)
res3: java.lang.String = uja6snx21bswf9t89s00bxssu8g6qlu16ffzqaxxoy
6 ответов
У меня здесь на работе такая же плата. Я считаю, что это слегка модифицированное ядро 2.6 ... не версия для реального времени.
Я не знаю, читал ли я что-нибудь в документации, что указывает на то, что оно предназначено для работы в строгом режиме RTOS.
С таким оборудованием должно быть довольно легко синхронизировать осциллограф с постоянными часами, производить всплеск каждый раз, когда система реального времени выдает выходной сигнал, и посмотрите, как сильно этот всплеск варьируется от центра. Чем меньше вариация, тем выше твердость.
Чтобы прояснить ответ Боба, возможно:
Используйте генератор сигналов для генерации импульса с некоторой переменной частотой. Лучше всего было бы случайное распределение по некоторому диапазону.
используйте генератор сигналов (сигнал запуска) для запуска осциллографа.
ОСРВ должна ответить, сделать это и отправить выходной импульс.
подать выходной сигнал ОСРВ. во вход 2 области.
переводит область в режим сохранения / сбора. запустите осциллограф на A, остановитесь на B., если можете.
в идеальном случае заставьте его измерить распределение за вас. А Лекрой будет.
Начните с гораздо более медленной трассировки, чем вы ожидали. Вы должны уметь видеть медленные выбросы.
Вы сможете увидеть распределение.
Если предположить нормальное распределение, SD изменения времени отклика будет МЯГКОСТЬЮ.
(На практике этого не произойдет, но если вы не получите выбросов, это будет достаточно полезно.)
Если есть выбросы с большой задержкой, то ОСРВ НЕ очень сложна. Не соблюдает сроки. Тогда это непригодно для тяжелой работы в реальном времени.
Многие вещи, подобные RTOS, имеют хороший левый край кривой, спускающийся вниз, как кривая 1 / f.
Это свидетельствует о смешанном возбуждении. На что следует обратить внимание - это всплески медленной реакции на правом конце прицела. Продолжайте повторять эксперимент с более быстрыми трассами, если нет выбросов, чтобы получить хорошее изображение уклона. Это должно быть хорошо для некоторых умозрительных выводов в вашей статье.
Если для вашего приложения допустима дельта в 1 мкс, а вы измеряете 0,5 мкс, это все круто.
В любом случае, вы можете опубликовать результаты (и, возможно, в смысле публикации , но обязательно в Интернете.)
Ссылка из этого вопроса на статью, когда вы ее написали.
Я думаю, что это не устройство жесткого реального времени, поскольку оно не работает без ОСРВ.
Жесткое реальное время больше связано с тем, как работает ваше программное обеспечение, чем с оборудованием само по себе. Когда вы спрашиваете, является ли что-то жестким в реальном времени, это должно быть применено ко всей системе (оборудование, ОСРВ и приложение). Это означает, что аппаратный или программный режим реального времени является проблемой проектирования системы.
При загрузке, превышающей спецификацию, даже система аппаратного реального времени выйдет из строя (надеюсь, с правильной индикацией отказа), в то время как система мягкого реального времени с низкой загрузкой выдаст ошибку. результаты в реальном времени. Сколько обработки должно произойти во времени и сколько предварительной / постобработки может быть выполнено, является реальным ключом к жесткому / мягкому реальному времени.
В некоторых приложениях реального времени потеря некоторых данных не является ошибкой, она должна быть ниже определенный уровень, опять же системный критерий.
Вы можете сгенерировать входные данные для платы и попросить небольшое приложение подсчитать их и проверить, на каком уровне данные будут потеряны. Но это дает вам рейтинг, специфичный для той системы, в которой запущено это приложение. Как только вы начнете больше выполнять обработку, ваша вычислительная нагрузка возрастет, и теперь у вас будет другой предел жесткого реального времени.
На этой плате будет запущен простой планировщик, что обеспечит отличную предсказуемую производительность в жестком реальном времени для большинства задач. Запустив полную ОСРВ с большой вычислительной нагрузкой, вы, вероятно, получите только мягкое реальное время.
Редактировать после комментария
Самый эффективный и простой способ, который я использовал для измерения производительности моего программного обеспечения (при условии, что вы используете расписание), - это использовать свободный аппаратный таймер на плате и отметка времени начала и конца цикла. Или, если вы запустите полную метку времени RTOS, вы приобретаете и переходите. Сохраните максимальное время и рассчитайте среднее значение за секунду. Если ваш средний показатель составляет около 50%, а максимальный - в пределах 20% от среднего, все в порядке. Если нет, то пора рефакторинг вашего приложения. По мере роста вашего приложения время цикла будет расти. Вы можете контролировать влияние всех изменений вашего программного обеспечения на время цикла.
Другой способ - использовать аппаратный таймер для генерации циклического прерывания. Если вы успели, сбросьте прерывание. Если вы пропустите крайний срок, обработчик прерывания сигнализирует об ошибке. Однако это даст вам предупреждение только тогда, когда ваше приложение работает слишком долго, но оно полагается на оборудование и прерывания, поэтому вы не можете пропустить.
Эти решения также устраняют необходимость подключения осциллографа для мониторинга вывода с тех пор, как информация может отображаться на любом терминале с помощью фоновой задачи. Если это легко контролировать, вы будете следить за ним регулярно, избегая решения проблем с синхронизацией в конце, но сразу после их появления.
Надеюсь, это поможет
Эти решения также устраняют необходимость подключения осциллографа для мониторинга вывода, поскольку информация о времени может отображаться на любом виде терминала с помощью фоновой задачи. Если это легко контролировать, вы будете следить за ним регулярно, избегая решения проблем с синхронизацией в конце, но сразу после их появления.
Надеюсь, это поможет
Эти решения также устраняют необходимость подключения осциллографа для мониторинга вывода, поскольку информация о времени может отображаться на любом виде терминала с помощью фоновой задачи. Если это легко контролировать, вы будете следить за ним регулярно, избегая решения проблем с синхронизацией в конце, но сразу после их появления.
Надеюсь, это поможет
Я понимаю, что я компьютерный фанат, но использование осциллографа для тестирования компьютера с Ethernet / USB / другими цифровыми портами и ОГРОМНЫМ внутренним состоянием (ОЗУ) неэффективно и ненадежно.
Вместо наблюдения за волной форм, вы можете подключить любой ПК к выходному порту и выполнить надлежащий статистический анализ.
Установленная процедура (если входной сигнал является аналоговым по своей природе) заключается в проверке системы на нескольких характерных входных сигналах - традиционно пиках, ступенчатых функциях и синусоидальных волнах. различных частот - и измерьте фазовый сдвиг и дисперсию для каждого типа входа. Затем в спецификациях системы используется наихудший случай.
Опять же, если вы используете стандартные порты, вы можете легко сгенерировать их на ПК. Если вход действительно аналоговый, потребуется отдельный ЦАП или просто хорошая звуковая карта.
Теперь это победило. Я ничего не могу сказать о том, что ОС работает в реальном времени - она может работать под управлением ванильного Linux или даже Win CE и по-прежнему давать хорошие и стабильные результаты в этих тестах, если оборудование достаточно быстрое.
Итак, вам нужно смоделировать тяжелые и переменные нагрузки на процессор, память и все порты, дайте ему нагреться и съесть память в течение нескольких часов, а затем повторите тесты. Если задержка остается постоянной, это тяжелый режим реального времени. Если этого не происходит при любой нагрузке и при любом типе входного сигнала, превышающем допустимый предел, это мягко. В противном случае это реклама.
PS: Смысл в том, что даже для критически важных систем вам действительно не нужно аппаратное обеспечение реального времени, если у вас есть оборудование.
вам нужно смоделировать большие и переменные нагрузки на процессор, память и все порты, дать ему нагреться и съесть память в течение нескольких часов, а затем повторить тесты. Если задержка остается постоянной, это тяжелый режим реального времени. Если этого не происходит при любой нагрузке и при любом типе входного сигнала, превышающем допустимый предел, это мягко. В противном случае это реклама.PS: Смысл в том, что даже для критически важных систем вам действительно не нужно аппаратное обеспечение реального времени, если у вас есть оборудование.
вам нужно смоделировать большие и переменные нагрузки на процессор, память и все порты, дать ему нагреться и съесть память в течение нескольких часов, а затем повторить тесты. Если задержка остается постоянной, это тяжелый режим реального времени. Если этого не происходит при любой нагрузке и при любом типе входного сигнала, превышающем допустимый предел, это мягко. В противном случае это реклама.PS: Смысл в том, что даже для критически важных систем вам действительно не нужно аппаратное обеспечение реального времени, если у вас есть оборудование.