Отправлено SM 17 октября 2006 г. 15:28 В ответ на: Я понимаю, но (+) отправлено <font color=gray>homekvn</font> 17 октября 2006 г. 15:01

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

• Понимаю, но не всегда такой подход годится. Например (+) — homekvn   (17.10.2006 15:44 212.185.161.237, 989 байт)
  • Ответ: (+) — SM   (17.10.2006 16:01 85.21.237.237, 778 байт)
    • Ответ (+) — homekvn   (17.10.2006 16:26 212.185.161.237, 821 байт)
      • Ответ: (+) — SM   (17.10.2006 16:45 85.21.237.237, 1273 байт)
        • Не, ну понятно. Просто тогда Вы фактически реализуете свое ядро. Хорошо это, или плохо, рассуждать не берусь. Наверное, когда-нибудь и хорошо (например, если однажды Вы его уже написали, а потом надо только под задачу адаптировать). — homekvn   (17.10.2006 16:57 212.185.161.237, пустое)
          • Фактически я не делаю ядра вообще. Задачи сами друг с другом разбираются. Хотя если пачку вызовов подпрограмм из бесконечного цикла назвать ядром, то я не против :) — SM   (17.10.2006 17:30 85.21.237.237, пустое)
            • Видимо задачи простенькие — Fat Robot   (18.10.2006 09:17 62.105.138.5, 130 байт)
              • Все это мелочи и нюансы, какая задача чем прервана должна быть. Просто разные принципы мультизадачности. А сбор обычно в прерывании от соотв "железа" делается. Или в дма, и потом прерывание от него. — SM   (18.10.2006 10:18 213.141.159.26, пустое)
                • Ну про сбор в прерывании - это, конечно, возможно. И сам иногда так делаю. Просто такой подход имеет ряд ограничений и годится только для случаев, когда не так много задач, прерывающих одна другую. По-хорошему в прерывании надо только сделать release semaphore и все. Все остальное сделает операционка (+) — homekvn   (18.10.2006 13:04 212.185.161.237, 384 байт)
                  • Ответ: (+) — SM   (18.10.2006 13:29 213.208.180.51, 672 байт)
                    • Но это философский принцип - за универсальность надо платить всеми ресурсами, за скорость - памятью, за память - скоростью... Что лучше в конкретном случае - решать разработчику. — homekvn   (18.10.2006 13:51 212.185.161.237, пустое)
    • Я вобщем-то с homekvn солидарен - всегда променяю 5% производительности CPU на простоту и быстроту разработки. — andy_P   (17.10.2006 16:09 80.82.63.185, пустое)
      • А я не всегда :) Если из-за этих 5% придется ставить дороже камень, а продукт массовый... Я лучше ужмусь в дешовый, а разницу с единицы продукции себе в карман :) — SM   (17.10.2006 16:55 85.21.237.237, пустое)
        • Опыта с большими сериями не имел - хотя такую ситацию что все надо в маленький камень впихнуть представляю. Тогда наверное действительно надо от оски отказаться или оптовую скидку на железо получать :-) — andy_P   (17.10.2006 17:15 80.82.63.185, пустое)