[AlexandrY 3]

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

 

а заявление коллеги хорошо бы проиллюстрировать количеством строк кода в проекте и колличеством программистов этот код писавших

 

Не ребята, это мы разленились.

А есть серьезные проекты которые по прежнему развиваются без осей.

Например в решениях от Microchip нигде не применяют ось. А там функциональность покруче чем "мк + экран + тачскрин + tcp/ethernet + usb + ftdi" ;)

Или вот, может кто видел, навороченные часы от Google из проекта ADK 2012, которые через BlueTooth и USB общаются с Android платформами, тоже без оси.

Или решения на базе .NET micro framework...

 

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

Короче тема похоже не раскрыта...

 

 

[Enthusiast 0]

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

[_Pasha 0]

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

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

Изменено 5 декабря, 2012 пользователем _Pasha

[haker_fox 61]

Короче тема похоже не раскрыта...

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

 

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

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

[Enthusiast 0]

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

Да нет, не мода, исключительно собственный опыт. А насчет "слонов" скажу, что в ядре "Линукса", к примеру, уже более 12 млн. строк исходного кода.

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

[_Pasha 0]

Да нет, не мода, исключительно собственный опыт.

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

Кроме того, применяя ось, следует иметь в виду вероятность сбоя в ячейках динамического ОЗУ при работе в режиме 24 часа в сутки и 365 дней в году

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

[SyncLair 0]

Да нет, не мода, исключительно собственный опыт. А насчет "слонов" скажу, что в ядре "Линукса", к примеру, уже более 12 млн. строк исходного кода.

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

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

 

[haker_fox 61]

Кроме того, применяя ось, следует иметь в виду вероятность сбоя в ячейках динамического ОЗУ при работе в режиме 24 часа в сутки и 365 дней в году, если ось будет исполняться оттуда.

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

[SyncLair 0]

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

Внутри МК в SRAM.

 

[polyname 0]

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

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

Изменено 7 декабря, 2012 пользователем polyname

[Enthusiast 0]

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

Согласен, только если требуется как-то обработать входные данные перед выдачей выходных сигналов, то в работу вступает программный планировщик задач операционной системы. А уж как он распределит очередность исполнения обработчика прерывания известно лишь разработчикам ОС. Тут все зависит от временного допуска обработки входных данных.

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

[juvf 17]

На мой взгляд, поручать осям задачи управления в режиме 24/7/365 недопустимо из-за неизбежных сбоев в работе динамического ОЗУ. Увы, оси здесь проигрывают изначально, как и везде.

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

 

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

 

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

 

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

[haker_fox 61]

Внутри МК в SRAM.

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

 

в передаче голосовых данных оси не применяются

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

[Enthusiast 0]

Смишно...

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

 

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

 

 

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

1. Никто не мешает воспользоваться поисковиком.

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

[juvf 17]

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

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

 

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

 

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

 

pps я вообще не вижу разницы между программой на "час" и "24/7/365". я пишу все программы так, чтобы они работали "24/7/365".

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