kalaschnikow пишет:Нууу, это вообще не дискуссия получается. Типа я и разговаривать не буду, потому что ПОТОМУ. Очень возможно что я чего-то не знаю. Я вообще много чего не знаю. По-моему ничего в этом страшного нет. Ну так поясните. Но у меня почему-то сложилось впечатление, что RTOS это фетиш такой.
Потому, что это достаточно обширный вопрос, требующий некоторых специальных знаний.
Если вкратце, то надо понимать, что современные терминалы получают массу информации в единицу времени (каждую секунду координаты, каждые х секунд показания ДУТ, и непредсказуемо - импульсы со дискретных входов, импульсных датчиков, состояния цифровых шин и т.п.) Всё это нужно успеть обработать, отфильтровать, принять решения, записать, передать или среагировать еще как-то до тех пор, пока не пришла очередная порция данных - иначе пойдут пропуски и алгоритмы последовательной обработки дадут сбой. При этом было бы неплохо, если бы еще система не падала из-за обработки кучи самых разных ситуаций.
Ранее писались линейные программы, где в основном цикле опрашивались входы, шины и т.п. и, при обнаружении нужного события управление передавалось в некую подрограмму, которая выполнялась и возвращала управление в основной цикл. Плюс механизм прерываний, который также передавал управление в подпрограммы с последующим возвратом в ту же точку. Аналог GOSUB...RETURN. При этом программер сам высчитывал и следил, чтобы каждая подпрограмма выполнялась не дольше необходимого и сумма времени выполнения подпрограмм тоже не превышала необходимый максимум - иначе основной цикл начнет пропускать события. Время идет, терминал выполняет все больше функций и подпрограмм становится нереально большое количество. Усложнять цикл и далее + вручную постоянно все считать - поедет крыша, да и не всегда это реально возможно. А при большом количестве комбинаций ситуаций, отследить такие сбои крайне тяжело.
Поэтому и осуществляется переход на многозадачные системы реального времени (RTOS).
RTOS позволяет сосредоточиться на выполнении специфичных задач, избавив от отслеживания рутинных процедур и коллизий.
Почему именно RTOS ? Позволю процитировать Wiki:
Ключевым отличием сервисов ядра RTOS от ОС общего назначения, является детерминированный, основанный на строгом контроле времени, характер их работы. В данном случае под детерминированностью понимается то, что для выполнения одного сервиса операционной системы требуется временной интервал заведомо известной продолжительности. Теоретически это время может быть вычислено по математическим формулам, которые должны быть строго алгебраическими и не должны включать никаких временных параметров случайного характера. Любая случайная величина, определяющая время выполнения задачи в ОСРВ, может вызвать нежелательную задержку в работе приложения, тогда следующая задача не уложится в свой квант времени, что послужит причиной для ошибки.
В этом смысле операционные системы общего назначения не являются детерминированными. Их сервисы могут допускать случайные задержки в своей работе, что может привести к замедлению ответной реакции приложения на действия пользователя в заведомо неизвестный момент времени. При проектировании обычных операционных систем разработчики не акцентируют своё внимание на математическом аппарате вычисления времени выполнения конкретной задачи и сервиса. Это не является критичным для подобного рода систем.
----
На самом деле у RTOS есть еще масса особенностей, которые Вы можете прочесть в той же Wiki:
http://ru.wikipedia.org/wiki/%CE%EF%E5% … C%E5%ED%E8
Кое-какие мифы о RTOS:
http://www.pic24.ru/doku.php/osa/articl … misbeliefs
Android, WinCE и т.п. в этом плане не удовлетворяют требованиям решаемых задач. Не говоря уже о том, что изначально являются гораздо более ресурсоемкими и требуют более жирных процессоров, памяти и т.п., нежели используются в терминалах. Кроме того, тот же Android ориентирован на определенный класс изделий, состоящих из достаточно детерминированного и ограниченного набора компонентов (заметьте, как похожи и ограничены все Android-изделия по функциям) и прикрутить к нему не совсем стандартные интерфейсы и протоколы напрямую имплантировав их в ядро - задача зачастую достаточно нетривиальная.
Что не мешает использовать Android и WinCE устройства в качестве устройств ввода-вывода информации, оставив обработку и прочие критичные ко времени выполнения и надежности задачи на устройстве под управлением RTOS.
На самом деле тут можно говорить много и долго. Пост и так получился длинным...
Поверьте, мы не используем микроскоп там, где достаточно молотка.
Добавлено спустя 5 минут :
kalaschnikow пишет:Когда пользуются выражениями "У ВСЕХ" и "серьезные игроки", то очень хочется это проверить И коту понятно, что вы просто не можете знать у всех или не у всех, точно так же как непонятно по каким критериям отделяются серьезные игроки от несерьезных.
Поверьте, мы очень хорошо знаем свою отрасль и все серьезные игроки на виду. Естественно, я не имею ввиду полное знание всех игроков отрасли во всем мире - сейчас я говорю про Россию и страны СНГ в основном, чья продукция составляет навигационный рынок в нашей стране и ближнем зарубежье.
Кроме того, производители не столь уж редко встречаются на мероприятиях типа НАВИТОРИНГ, слетах того же GURTAM и в частном порядке.
Добавлено спустя 9 минут 17 секунд:
kalaschnikow пишет:Но вот в трекере это зачем? Для жесткой системы реального времени пропуск одной единственной точки смертелен. А мы их в трекере пропускаем большинство. Не 80% и не 90, а иногда практически 99,9. Так зачем нам экскаватор если нужно посадить помидор?
Вы сделали неправильный вывод из того факта, что пишутся не все точки. Но ведь они НЕ ТУПО отбрасываются, а принимается решение - что делать с той или иной точкой. При этом рассматриваются ВСЕ поступающие с приемника точки, оцениваются, сравниваются, фильтруются, принимается решение - писать или нет и т.п. А "рассматриваются" - читай обрабатываются по весьма непростым алгоритмам. И это мы всего-лишь говорим о навиагционных точках, а ведь терминал получает массу других данных. По шине CAN ряд параметров передается с частотой в десятки и сотни раз выше, чем поступают точки с навигационного приемника и эти данные тоже нужно успеть обработать, а таких данных только по CAN может идти несколько десятков параметров, регистрируемых терминалом... не говоря про другие шины данных даже...
Для простейших трекеров, работающих только с навигационными данными + несколько дискретников + несколько аналоговых входов - действительно достаточно линейной программы. И так оно и было. Как я уже писал. Когда трекеры были проще. Сейчас RTOS даже в простых трекерах. Почему ? Да потому что никто не будет писать отдельные программы, да еще построенные по диаметрально противоположным принципам под простой и навороченный вариант трекера в линейке производителя. Пишется под навороченный, а в простом просто не используется часть блоков. (что позволяет, кстати, делать не только две крайние модели, но и при необходимости все промежуточные по функционалу варианты на одной прошивке)
ГК «ТехноКом», г. Челябинск (СМТ «АвтоГРАФ™») - - - Самцов Константин Юрьевич - зам. директора по коммерческой деятельности
https://glonassgps.com ***
https://www.tk-nav.ru | Раб. тел.: +7 (351) 211-30-40, 211-40-30
Просьба не писать вопросы через систему личных сообщений этого форума, так как я не присутствую здесь постоянно
Прошу использовать для связи с нами ресурсы и контакты из подписи
Есть навороченные, есть простые, есть оффлайн, есть онлайн, есть дорогие, есть бесплатные... Программ - море. Самое главное, чтобы карты вашего региона были хорошими. 
).
таксисты плюются, дабы виснет постоянно...