Профессиональный цифровой диммер и пульт DMX512
Программа управления световыми приборами DMX512
Фонтаны, визуализация Изготовление фонтанов и оборудования

Заказчики программного обеспечения постоянно мечтают о том, чтобы программы создавались мгновенно и работали так же надёжно, как устройства на логических элементах. Я пережил уже несколько ярких преобразований в программировании, и каждая новая программная среда преподносилось как идеальное решение. Но, как и всегда было и, думаю, еще очень долго будет, каждая новая идея приносит новые глюки и проблемы. К примеру, у всех на виду перипетии с ОС Била Гейтса. Описывать их нет смысла, в Интернете этого много, а моя статья о другом. Я хочу проанализировать и вынести на обсуждение, насколько быстро и надежно можно писать программы для микроконтроллеров, используя тот инструментарий, который оптимально можно использовать в данный момент времени.
Для начала попытаемся понять как происходит процесс программирования. На сегодняшний день цепочка людей, еще недавно состоящая из заказчик - тех.специалист - аналитик - программист, сократилась до заказчик - программист, и посредником между ними является какой-нибудь менеджер, который представляет решение задачи еще хуже, чем сам заказчик. Поэтому программисту необходимо взвалить на свои плечи решение еще дополнительных проблем, связанных с ветвлением вариантов получающихся изделий, что влечет за собой не пропорциональное увеличение временных затрат. Иногда решение проще всего реализовать в цифровом устройстве, спаянном из набора логических элементов. В 90-е годы, когда элементная база была откровенное Г., для  ремонта чего-либо из него выбрасывался микропроцессор и заменялся платой с целой кучей различных микросхем. И работало не хуже, чем микропроцессор. При этом, время на ремонт было не более 1-3 дня. И больше всего времени уходило на анализ работы устройства. Я не ностальгирую. Просто бешенство программирования доходит иногда до того, что обычный, достаточно быстрый, инвертор реализуется на MPU с прерыванием . Жалко на плату ставить лишнюю микросхему. Но вернемся к связке заказчик - программист. Для того, чтобы решить задачу как можно быстрее и лучше были неоднократные попытки создать программную среду, которая взвалила на себя хотя бы часть проблем программиста. Но, как известно, умных программ нет, а безумных валом! Любая программа способна отрабатывать только те события, которые предусмотрел программист. В 90-е годы попытку превратить разработку программного обеспечения в инженерную дисциплину с помощью концепции CBSE (component based software engineering – «компонентная разработка программного обеспечения») и COTS (commercial off the shelf – «готовые коммерчески доступные компоненты») и на сегодняшний день – это SCADA, наиболее распространенная среда с предоставлением готовых модулей, алгоритмы которых можно менять по своему усмотрению. Можно вспомнить о MicroCAP от Spectrum SoftWare, но все это только попытки создания далеко не самых удачных решений, не говоря уже об идеальных. Кто-то верит в появление чуда – какой-нибудь новой системы, которая поднимет программирование и сроки разработки программного обеспечения на невиданный уровень, позволяя при этом создавать сложнейшее программное обеспечение человеку, который просто умеет раскрывать рот. Тема эта постоянно "мусолится" на разных форумах и решения пока нет. Я использую симулятор фирмы "Фитон" для серии PIC и, поскольку использую его давно и часто, то и достал он меня соответственно. Не говоря уж о том, что симуляторы работают в условной временной шкале, а не в режиме реального времени, и требуют больших ресурсов РС. Вообще верить, что  всё это – временные проблемы, которые, конечно же, будут устранены, к примеру, с появлением новой версии соответствующей среды - утопизм. Идеальной программы не будет никогда, человек существо неудовлетворенное и ленивое. И лень будет возрастать, поэтому всегда будет появляться желание переложить следующую часть проблем на компьютер. Немного истории: вспоминаю, как писал первые программы в машинных кодах и радовало тогда одно, что программы решали сравнительно не сложные задачи и были сравнительно невелики. Хотя и в таких программах появлялись ошибки, но для их поиска не надо было перелопачивать тысячи строк кода. Попробуйте перенести метку в программе из машинных кодов не пользуясь ассемблером и Вы меня поймете! Поэтому когда у меня появилась возможность использовать ассемблер - я испытал нечто похожее на оргазм. Далее был Pascal и DELPHI, улучшающие качество и скорость программирования. Но для разработки программ с MPU пока все выглядит по старинке. Описание режимов работы устройства, схема, алгоритмы из кубиков и кружочков на бумаге и рутинный набор текста на MPASM. Пробовал и Паскаль - написал несколько программ, не увидел особых преимуществ перед MPASMом и пристрелил его до лучших времен. 

Вообще переход от алгоритма к программированию представляет определённую проблему. Тут получается следующее: любая задача может быть решена несколькими алгоритмами, а каждый алгоритм неоднозначно реализуется одним программистом в разное время суток и зависит от скорости ветра в коридоре. И получается, что от ветра тоже зависит скорость работы программы и её качественные показатели. То есть преобразование решения задачи и даже алгоритма в коды, понятные MPU каждый программист проделывает по своему, в зависимости от интеллекта и знания языка программирования. Поэтому принято считать программирование все таки искусством и затраты времени и средств, выделяемых на проект, находятся в прямой зависимости от способностей программиста. Поиск эффективного алгоритма и его реализация - задача творческая, и автоматизировать не получается.  Сейчас развивается подход к разработке программного обеспечения, названный «автоматным программированием», которое можно рассматривать в качестве разновидности синхронного программирования. Предлагаемая концепция проектирования позволяет описывать процессы, которые необходимо автоматизировать, используя при этом понятный всем формальный язык конечных автоматов. И еще: вне зависимости от методов разработки у любой программы есть состояния, в каждый момент времени определяемые значениями всех её переменных. Тогда изменение значения одной из управляющих переменных будет означать изменение состояния программы, а число состояний программы будет определяться максимально возможным количеством комбинаций значений управляющих переменных, возникающим при её работе. Если предположить, что в программе используются только двоичные управляющие переменные (флаги), то в этом случае количество состояний будет стремиться к 2n. Поэтому нет никакой гарантии, что в процессе работы программы не возникнет неожиданное сочетание входных воздействий, вследствие чего программа перейдёт в непредсказуемое состояние.

Как избежать непредсказуемых состояний, быстро написать программу и иметь возможность ее модифицировать?   А для этого надо иметь в своём арсенале готовые и тщательно отлаженные программные кусочки кода, подпрограммы, макросы и т.д. то, что я называю «кубики». Идея использовать кубики появилась когда программных модулей накопилось много, и я понял, что написание следующей программы сводится к переписыванию и повторению как минимум 50% уже когда-то выполненной работы. Поэтому идея «кубиков» была воспринята как естественное решение проблемы. Под «кубиками» будем понимать тщательно отлаженные программные модули, имеющие жесткие адреса для своих меток и данных. Частично здесь я отвечаю на вопрос: Почему я делаю системы на 2 и более процессорах? Ведь даже половины или четверти ресурсов одного процессора с головой будет достаточно для выполнения этих задач и более. Все просто. Поскольку большинство приборов выпускается малыми сериями, а некоторые даже не более 3-х, то самый примитивный экономический расчет покажет целесообразность такого подхода. Я бы назвал это назвал игрой в электронные кубики. Если позволяет место, то количество микропроцессоров можно увеличивать до, казалось бы, неразумного предела. Теперь на пальцах. Допустим, стоит задача: изготовление устройства регулирования температуры от 10 датчиков, меняющие пороги и данные, 10-ПИД регуляторов, и в течение суток выводящая информацию на светодиоды, меняющие яркость в зависимости от температуры по принципу шим модулятора. При превышении или понижении температуры светодиоды меняют яркость и переходе порога мигают с частотой тем частой, чем больше реальная температура отличается от температуры установки. Порог температуры всех уровней (индивидуально установленная) одновременно меняется одним потенциометром. Данные температуры интегрируются и записываются в память 24с65 каждую минуту. При этом пороги и другие установки системы программируется извне и отсылаются данные по 485 протоколу назад по запросу. В принципе задачу можно реализовать на PIC16F877. ресурсов хватит, 8К ПЗУ, 368 ОЗУ, 20 МГЦ. Почти Каждый алгоритм детский: опрос датчиков DS1821, прерывание от таймера для часов, умножения, сложения, ШИМы, опрос аналового входа, процедуры 24с65, прерывания от 485, вычисления ПИД регулятора. Все просто, но есть несколько но. Первое память. Раз это не войдет в 2к ПЗУ и один банк ОЗУ, значит принесет кучу головной боли. Несмотря на все старания будет несколько мест в программе которые вымотают все нервы. Компиляторы не находят ошибки при переходе из банка в банк. Не поможет ни эмулятор, ни симулятор. Да он вообще ни в чем не помогает, это не симулятор, а удобный текстовый процессор. Эмулятор помогает, но только как внутрисхемное быстрое программирование. Светодиоды с шим будут просто убийством. их нельзя выделить в процедуру, к которой можно периодически обращаться. Они не будут светиться, а будут противно мигать. Прерывание не задействуешь, если его сделать часто, чтоб получит 256 градаций, все станет медленным редким, светодиод будут мигать. Значит все процедуры придется впихивать в паузы между светодиодами, разбив их на куски. Куски программ, банки, куча дополнительных операторов типа установки PCLACH, прерывание от таймера, от 485 и получится такой пирог при отладке, что долбаться придется не одну неделю. Имеет смысл, если изделие предполагается выпускать тоннами или заказчик "пушистый", и ему плевать, сколько стоит работа. А текст набивать в любом случае. А теперь вариант «кубиков». Все MPU общаются между собой по USART. MPU N1: опрос датчиков DS1821 и отправка в MPU N2 и MPU3. MPU N2: вывод яркости на светодиоды. прием порогов от MPU N4. MPU N3: обработка ПИД и отправка в MPU N4. MPU N4: работа с памятью 24с64, часы и фэдер. MPU N5: синхронная или I2C связь с MPU N4 и работа с 485. теперь видно что на каждый процессор достаточно одного дня, мах двух, и система готова, и это в случае первого изготовления. экономия времени мин неделю при небольшом изменении подобной системы достаточно добавить еще недостающий кубик и все. Я здесь молчу о возможных незамеченных ошибках, которые по закону Мерфи выявятся через неделю, когда устройство уже должно пахать как лошадь. В кубике ошибка будет один раз, потом можно не думать, а контролировать с помощью потокового дисплея (по USART) очень легко. (См здесь) А когда разных кубиков станет 20, отладка станет анахронизмом и Вам останется только подправлять кубики для конкретного проекта. К примеру: пришел заказчик и желает добавить 2 дисплея 1602 для вывода всех температур до и после ПИД регулятора и блок с реле (а на фига тогда ПИД регулятор?). А попробуйте впихнуть теперь два дисплея и 10 реле в проект на 877. Крыша поедет. Нужно будет ставить что-то типа PIC18с452 и начинать все сначала. Экономический расклад: один PIC16F877 стоит около 200р, а 5 процессоров типа PIC16F628 стоят 300р разница = 100р если устройств 1-10, то даже и думать не надо. 100 и ли даже 1000р не стоит недели работы. В принципе подобную технологию я применяю и для однопроцессорных устройств. Процедуры обслуживания выполнены в виде отдельных файлов и при компиляции я только вписываю их в основной листинг. Когда нахожу ошибку или недоработку, она исправляется в этом проекте и не появляется в следующих разработках, тем более, что основные проблемы не с основным алгоритмом, а с кирпичиками системы. Применимо к данному случаю это: опрос датчиков, работа с памятью, часы, алгоритм прерывания, умножение и ПИД регулятор.

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

На Главную
Новости
Наверх страницы

хочу купить
фонтан

Контакты

Инженер и веб-мастер Богданов Андрей Александрович Water LAB ©