Цитата(Designer56 @ 26.7.2010, 21:06)
Я вообще не понимаю, из- за чего в программистких ветках сыр- бор разгорается.
...
Дело в том, что само по себе программирование - вещь достаточно простая.
В принципе, этим делом может заниматься любой - даже пионер.
Проблемы начинаются при увеличении объема проекта.
Отдельные личности, привыкшие к определенным правилам, тут же начинают притаскивать за уши всякие посторонние предметы, в виде дополнительных сущностей.
Пример - ООП.
Дабы обеспечить привычную среду обитания своему программному продукту.
При этом утверждаются абсолютно не очевидные вещи - типа так проще сохранять нетленку или разбираться с чужим кодом.
Или - при таком подходе возрастает надежность программного продукта.
Так же, якобы, упрощается проблема переноса проекта с одной платформы на другую (портирование).
Хотя у такого подхода есть и совершенно очевидные преимущества.
1. Можно спокойно использовать чужой код, если он достаточно надежен и проверен, абсолютно не вникая в его суть. Пример тому C++Builder.
2. Легко кодить в команде. Когда один делает индикацию, а другой, скажем, считает ряд Фурье в реал-тайме.
3. Модификация одного участка кода не приводит к фатальным последствиям для всего проекта в целом.
4. Замена игрока в команде или даже капитана команды не разрушает самого процесса создания продукта, а лишь слегка приостанавливает его.
5. Возрастает скорость создания программного продукта.
Вопрос в том, сколько Вы готовы заплатить за эти удобства и нужны ли они Вам?
Другие личности, уважаемый
Огурцов, например, наоборот, стремятся к минимализму.
В этом случае код будет специфичным для конкретной задачи, хотя и более емким и оптимальным по быстродействию.
Кроме этого, он будет очень жестко привязан к конкретному "железу".
Очевидно так же, что код будет авторским и без правильных комментариев постороннему лицу непонятным.
Вопрос. Стоит ли при нынешнем раскладе рисковать проектом в целом и зависеть от автора?
Или может проще пойти купить кристалл "пожирнее" и не зависеть ни от чего?
В большинстве современных приложений на МК возлагается решение нескольких задач одновременно.
Иногда их число доходит до нескольких десятков или даже сотен.
Причем, задачи эти разноплановые по времени.
К примеру, HMI (ЖКИ+кнопки), опрос входов с подавлением дребезга и шороха, получение сигналов с инкрементального энкодера, обработка информации от входов и энкодера с учетом параметров, выдача результатов на выходы, связь с внешним миром по последовательному каналу, запись/чтение параметров в/из EEPROM.
Задачи, перечисленные мною выше, постоянно и одновременно крутятся в простейшем, в общем-то, девайсе промышленной автоматики.
Здесь любителям правил приходит на помощь РТОС, организующая псевдопараллельную работу задач.
Базовое преимущество очевидно.
Платформенная независимость. Смена МК влечет за собой лишь переписывание малой доли софта в порте выбранной ОС для будущего МК.
Для любителей бритвы Оккама существуют разные подходы в организации псевдопараллельности, но суть остается одна.
Железо МК принимается за готовую систему. Собственно, оно и есть РТОС. Об этом я уже распинался выше.
Здесь мы уже попадаем в зависимость от производителя "железа", который может выкинуть любой фортель.
Опять же остаются вопросы стоимости "удобств".
Еще одной проблемой является человеческий фактор. А именно, характер, опыт, склонности человека, создающего программный продукт.
Кто-то перед решением задачи тщательно продумывает структуры данных, просматривает способы решения каждой из задач, рисует алгоритмы на бумаге и т.д.
Другой сразу в бой - решение тех или иных задач появляется уже в процессе работы, равно, как и взаимодействие между задачами.
Невозможно отдать предпочтение тому или иному способу. В данном случае все зависит от программиста.
Различия в подходах к решению перечисленных проблем и приводят к спорам в среде программистов.