Не ребята, это мы разленились.
А есть серьезные проекты которые по прежнему развиваются без осей.
Например в решениях от Microchip нигде не применяют ось. А там функциональность покруче чем "мк + экран + тачскрин + tcp/ethernet + usb + ftdi"
Или вот, может кто видел, навороченные часы от Google из проекта ADK 2012, которые через BlueTooth и USB общаются с Android платформами, тоже без оси.
Или решения на базе .NET micro framework...

Вообщем вопрос не во вкусе и не в тупости разработчиков, а в чем то другом.
Короче тема похоже не раскрыта...

На мой взгляд, если по условию задачи требуется время срабатывания устройства на внешнее для неё событие менее 10 мкс, то применение оси - зло. Если же время срабатывания устройства на внешнее событие может быть более 10 мкс, то применение оси - благо.

А чего в абсолютных попугаях? Мода такая? 10 мкс на 210MIPS... 2100 тактов, почти команд ... слона можно схавать

Сообщение отредактировал _Pasha - Dec 5 2012, 20:04

Так это уже того... философия, путь, дао, до (кому как угодно). Неважно какой путь мы выбрали, все равно они ведут к одному - к конечному устройству, функционалу...


А ведь сейчас есть и двухядерные МК. Применить на одном ядре ОСь, а на другом ничего не применять. Это зло?

Да нет, не мода, исключительно собственный опыт. А насчет "слонов" скажу, что в ядре "Линукса", к примеру, уже более 12 млн. строк исходного кода.
Кроме того, применяя ось, следует иметь в виду вероятность сбоя в ячейках динамического ОЗУ при работе в режиме 24 часа в сутки и 365 дней в году, если ось будет исполняться оттуда. Я приводил ссылку об исследовании этого вопроса сотрудниками "Гугла" на их серверах когда-то раньше.

Мне более нравятся относительные показатели, в тактах.

Целостность и регенерация объектов - большая тема. Но на ошибки ECC реагировать не сложно, это не уязвимости, - тут мороки-то и нету.

Ну дак кто мешает применять более строгие ОСи чем Линукс и потом в динамическом ОЗУ храните какие-нибудь картинки а вот критический важный код который на 10 мксек храните внутри чипа

А данные (не константы) где хранить?

Внутри МК в SRAM.

используют прерывания и DMA

Сообщение отредактировал polyname - Dec 7 2012, 16:11

Согласен, только если требуется как-то обработать входные данные перед выдачей выходных сигналов, то в работу вступает программный планировщик задач операционной системы. А уж как он распределит очередность исполнения обработчика прерывания известно лишь разработчикам ОС. Тут все зависит от временного допуска обработки входных данных.
Если же рассуждать шире, то удел операционных систем - это всего лишь удобное средство отображения данных. На мой взгляд, поручать осям задачи управления в режиме 24/7/365 недопустимо из-за неизбежных сбоев в работе динамического ОЗУ. А для примера можно просто сравнить надежность работы сетей связи в телефонных сетях с АТС где, насколько мне известно, в передаче голосовых данных оси не применяются и IP-сети, где оси применяются изначально. Качество связи в расчет не берем, учитываем только разрывы связи. Увы, оси здесь проигрывают изначально, как и везде.

Смишно. Бред какой-то.

какая взаимосвяь между ос и динамическим озу? что под динамическим озу вы понимаете? если под динамическим озу вы понимаете динамическое выделение памяти, но так используйте ос без димамического выделения памяти. Если вы понимаете DRAM, и вы недоверяете апаратному динамическому ОЗУ, то используйье статическое ОЗУ. При чем тут ос? если озу имеет неизбежные сбои, то прога и без ос ляжет.

и насчет "24/7/365"..... прекрасно работают серьёзные проекты на осях. и на ртос, и на нертос, и без ос. годами и без перезапусков и выключений.

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

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


Это Вы о декадно-шаговых АТС?

Если ты приведешь пример устройств, которые работают надежнее под управлением ОС, чем без оной, то можно будет принять твои слова к делу.


1. Никто не мешает воспользоваться поисковиком.
2. Да нет, я говорил об обычной телефонной связи, для опробования качества которой необходимо лишь поднять трубку домашнего телефона.

Нет, не приведу. Я не утверждаю, что с ос устройство будет работать надежнее. Я утверждаю, использование ос - это не значит что надежность будет хуже.

Хотя опять же.... взять программу состоящую из 20-ти простых задач (опрос клавиатуры, вывод на экран, уарт, мигать диодом, контроль аккум. и т.п.). каждая задача сама по себе несложная. Школьник напишет. Но распределить между всеми процессор - это писать что-то типа своего планировщика, на прерываниях и флажках. Прожженый 15-ти летнем стажем прогер раскидает такую программу, используя уже написанные куски кода в своих ранних проектах и обойдет все грабли по которым он ходил по молодости. Но какойнить не опытный прогер, или прогер пересел на новую платформу, написав такой код - во первых у него уйдет много времени на написание и отладку своего планировщика, во вторых его планировщик не будет более надёжен, а скорее менее надёжен. И если взять надёжную ос и написать 20 элементарных задачь по опросу клавиатуры и т.п. - такой код будет написан быстрее и с осью будет гораздо надёжнее, ибо планировщик в осе и сама ос - это тот же самописный планировщик, только он вылизан и протестин многими людьми и в него вложен труд сотен, а то и тысяч людей.

ps есть конечно оси кривые, с дырами. например scmRTOS. Конечно такая ось принесёт только проблемы и не только в режиме 24/7/365. Но есть вылизанные оси. Почему бы их не использовать, если она разработчику приносит ++?

pps я вообще не вижу разницы между программой на "час" и "24/7/365". я пишу все программы так, чтобы они работали "24/7/365".
А что, кто то пишет по другому? у кого-то есть такое ТЗ: "Нужно написать программу, которая должна проработать минимум час." По такому ТЗ кто-то, например для ускорения написания кода, пишет с утечкой памяти, главное чтобы за час вся память не вытекла?