Боже меня упаси! Причем здесь ОВЕН?! Инженерный подход в схемотехнике любого устройства ОВЕН - классический и исчерпывающе прозрачен. Реализация более чем удовлетворительная. Да здравствует ОВЕН!
Речь даже не об “OWEN Logic” и “CoDeSys”. Их назначение понятно.
Если мои знания и навыки позволяют мне отказаться от OWEN Logic и ваять в MPLAB’е, то у инженера-КИПовца при всем богатстве выбора другой альтернативы нет. Когда он сравнивает мой результат со своим и как он был достигнут. Когда он видит, что мне достаточно иметь даташит и принципиальную схему прибора, а он часами сидит за инструкциями и копошиться в форуме. То рано или поздно он предъявит следующее: «Неужели вы не как не можете создать надежную интегрированную предсказуемую среду разработки?!». Чем я могу ему помочь? А сам себя спрашиваю: «А нужно ли?». А ему отвечаю: «Хочешь быть богом при разработке?! Хочешь насладиться абсолютной властью над проектом?! Изучай программирование и MPLAB!».
Когда инженер видит в моем ST-коде конструкцию CASE OF или FOR … ENDFOR, где я лаконично и просто обрабатываю массивы функциональных блоков, используя указатели, и ставит меня в тупик вопросом: «А как это сделать в CFC, например?», что мне ему отвечать? Или «Почему у меня не получается реализовать заявленную функциональность?».
- Жди. Терпеливо жди. Веди список всех обнаруженных багов и способов борьбы с ними. Внимательно читай изменения в релизах. Читай и перечитывай документацию. Если не дурак, то придет озарение. Расти над собой. Ну и так далее..
Пропасть между программистами и инженерами растет!!!
Все. Тему можно закрывать.





Ответить с цитированием