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

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

 

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

 

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

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

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

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

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

 

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Изменено пользователем _Pasha

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Внутри МК в SRAM.

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Смишно...

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

 

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

 

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...