| Все для программирования. |
| начало | почта | статьи | файлы | ссылки | сайты | RSS | о нас | опубликовать | оформление | авторы | друзья | реклама |
|
Каталог статей
|
Статья
«Hello World!» в embedded-исполнении. Часть 7 © Dale, 14.11.2011 — 19.11.2011. Окончание. Начало: часть 1, часть 2, часть 3, часть 4, часть 5, часть 6. Оглавление Реализуем HAL Наша программная модель приложения на инструментальной системе работает, и работает вполне хорошо. Мы можем быть уверены с высокой степенью, что явных ошибок в коде нет. Конечно, не следует забывать, что успешно прошедший тест ни в коей мере не является доказательством правильности программы; однако мы не обнаружили расхождений между реальным поведением программы и поведением, предписанным спецификациями. Собственно, иначе и быть не могло, ведь модульные тесты по совместительству являются спецификациями. Почивать на лаврах не дает одна небольшая, но очень существенная деталь: HAL. Мы до сих пор ничего не сделали в данном направлении. Конечно, мы можем утешать себя тем, что и так сделали все, что могли; что отсутствие аппаратных средств (по причине нерадивости коллег) не позволяет нам двигаться дальше; наконец, что прослойка HAL достаточно тонка и может быть реализована быстро и легко.
Принимаясь за написание HAL, недурно бы вначале выяснить, как выглядит оборудование, программную поддержку которого нам предстоит реализовать. Для этого придется вновь посетить наших коллег-электронщиков и взять у них схему устройства (уж ее-то можно было нарисовать за столько времени). Вот он, наш трофей (рис. 1). Что мы можем почерпнуть их этой схемы? Прежде всего, мы видим, что светодиод подключен к младшему разряду порта C микроконтроллера. Кроме того, балластный резистор R1 подключен к шине питания +5V. Следовательно, чтобы зажечь светодиод, мы должны подать на младший разряд порта C низкий потенциал, то есть логический ноль. И наоборот, чтобы погасить светодиод, на младший разряд порта C следует подать высокий потенциал, или логическую единицу. Такое «инверсное» управление начинающим может показаться нелогичным, а инженеры со стажем воспринимают это как само собой разумеющееся. Оно имеет исторические корни: во времена господства логики TTL, которая долгое время была стандартом де-факто в области цифровой электроники, выходные каскады могли принимать втекающий ток (при низком потенциале на выходе) во много раз больше, чем выдавать вытекающий (при высоком потенциале). Современные микросхемы CMOS (к которым, в частности, относится и выбранный нами микроконтроллер ATmega16) имеют выходные каскады с симметричными характеристиками, но подход уже устоялся. Кстати, оттуда же берет начало привычка «подтягивать» логические входы к логической единице посредством резистора. Разобравшись со схемой, мы можем загрузить Atmel AVR Studio (я использую версию 5, но знаю, что и у прежней, 4-й, осталось немало поклонников; я не вижу явных причин, по которой наш проект не мог бы быть откомпилирован в предыдущей версии). Порт управления светодиодом У нас уже есть модуль Led и его инструментальная реализация Led\src\PC\Led.c, которую мы использовали в модели устройства на инструментальной системе. Теперь мы разработаем целевую версию модуля Led\src\AVR\Led.c. Разумеется, он реализует тот же интерфейс Led\include.Led.h: Код: (C) Led\src\AVR\Led.c #include "Led.h" #include <avr/io.h> /* Инициализаци порта светодиода. * Выбран порт C, бит 0, управление инверсное. */ void Led_init(void) { // программируем бит 0 порта C на вывод DDRC |= _BV(PC0); // выключить светодиод Led_off(); } // включить светодиод void Led_on(void) { PORTC &= ~_BV(PC0); } // выключить светодиод void Led_off(void) { PORTC |= _BV(PC0); } Несколько комментариев для тех, кому это все в новинку:
Этой информации должно быть достаточно для того, чтобы разобраться в приведенном коде. Программная задержка Поскольку, согласно спецификациям, других задач у нашего устройства нет, мы вполне можем воспользоваться программной задержкой. Для начала так и сделаем: Код: (C) Timer\src\AVR\Timer.c #include "Timer.h" #include <stddef.h> #include <util/delay_basic.h> void Timer_init(void) { // в версии в программной задержкой инициализация не требуется } // программная задержка 1 ms static void wait1ms(void) { _delay_loop_2(4000); } void Timer_wait(uint16_t ms) { for (unsigned short i = 0; i < ms; ++i) { wait1ms(); } } В библиотечном файле util/delay_basic.h находятся уже готовые к употреблению функции программной задержки. Одной из них, _delay_loop_2(), мы и воспользуемся. Эта функция выполняет задержку в 4 такта на каждый внутренний цикл, а аргумент задает количество этих самых циклов. Нетрудно подсчитать, что при тактовой частоте 16 мегагерц такая задержка составит четверть микросекунды. Чтобы выждать одну миллисекунду, таких задержек потребуется ровно 4000. Остальное комментировать нет необходимости. Симуляция целевой системы Мы вроде бы написали HAL и теперь со спокойной совестью можем ожидать прототип, чтобы испытать на нем написанную программу. Впрочем, у нас есть возможность продвинуться еще на шаг дальше. Эту возможность дарит нам симуляция целевой системы. Как я уже говорил ранее, существует множество инструментов для симуляции микроконтроллеров (в частности, интересующих нас Atmel AVR). Наиболее простой из них (и впридачу совершенно бесплатный) — VMLAB. Конечно, его простота накладывает множество ограничений, но для нашего проекта почти все эти ограничения несущественны. За исключением одного: VMLAB требует, чтобы все проектные файлы находились в одной директории. Если бы мы не использовали TDD, наша программа уместилась бы в одном файле, и проблема с деревом иерархии файлов проекта ушла бы сама собой. Однако я считаю это слишком высокой ценой за отказ от TDD. В конце концов, оттестированная программная модель на инструментальной системе внушает мне куда больше доверия, чем вроде бы работающая симуляция на VMLAB. Примечание. Если кому-то известны способы преодоления этой трудности (например, каким-то образом подключить к VMLAB готовый модуль ELF и таким образом вообще отказаться от использования исходных текстов в модели), прошу поделиться, буду очень признателен. Если бы не это досадное недоразумение, VMLAB хорошо подходил бы для решения множества несложных задач. Я воспользуюсь симулятором, входящим в состав Proteus. Для симуляции нам потребуется:
Я не буду приводить здесь подробную инструкцию по этим действиям. Все это прекрасно описано в сопутствующей документации, изучить которую вам все равно придется, поэтому не стоит откладывать этот момент. Приведу лишь видеозапись конечного результата:  Все признаки того, что система работает правильно, налицо. Осталось лишь дождаться прототипа и окончательно все проверить на нем. Так ли страшен C, как его малюют Раз уж мы добрались до реального машинного кода, трудно побороть любопытство и удержаться от искушения взглянуть, как же он устроен. Одна из неиссякаемых тем для холиваров — это битва C против ассемблера. В среде тех, кто использует микроконтроллеры в своих конструкциях, очень популярно мнение, что компиляторы C генерируют чрезмерно тяжеловесный и неэффективный код, поэтому программы для микроконтроллеров следует писать исключительно на ассемблере. Если вас интересует мое личное мнение по этому вопросу, то оно таково. Стремительное снижение цен на микроконтроллеры и одновременный рост (возможно, не столь стремительный) оплаты труда программистов приводит к тому, что стоимость «прошивки» многократно превосходит стоимость кристалла, в который она будет прошита. Сделаем грубую прикидку: пусть микроконтроллер вместе с платой, кварцевым резонатором, разъемами и прочей мелочью обходится в 300 рублей. Программа к нему обошлась в один человеко-месяц программиста с окладом 60.000 рублей. Тогда стоимость оборудования сравняется со стоимостью программы при тираже 200 штук. Конечно, крупносерийным производством такую партию не назовешь, но и штучным тоже. К тому же разработка нетривиальной программы едва ли уложится в человеко-месяц (один лишь тщательный сбор требования с их последующей обработкой отнимет не меньше половины этого срока), а значит, цены на аппаратуру и программу сравняются лишь при многотысячных тиражах. Поскольку далеко не все конструкции расходятся такими тиражами, доля стоимости программного обеспечения зачастую оказывается существенно выше, чем аппаратной части. Отсюда следует первый важный вывод: нужно постараться снизить стоимость программной части проекта. Разумеется, делать это следует цивилизованными средствами, не в ущерб качеству, ибо потребительская стоимость сбойной программы стремится к нулю. Самый очевидный способ удешевить разработку программы без снижения качества кода известен уже более полувека — нужно использовать языки программирования высокого уровня. Чем меньше семантический разрыв между средствами языка и понятиями предметной области, тем проще и, следовательно, дешевле будет написанная на этом языке программа. К сожалению, выбор компиляторов языков высокого уровня, пригодных для программирования микроконтроллеров, невелик, и выбор C, пожалуй, близок к оптимальному. Конечно, уровень C как языка программирования по современным меркам невысок, но в сравнении с ассемблером он все же неизмеримо выше. Поэтому программист, использующий язык C, окажется в итоге существенно (до нескольких раз) продуктивнее, чем его коллега, пишущий на ассемблере, даже при условии равной квалификации. Еще один довод в пользу применения языков программирования высокого уровня — их относительная независимость от архитектуры процессора, для которого они генерируют исполняемый код. Время от времени разработчики меняют аппаратную платформу. Иногда это происходит по доброй воле (стали доступны более подходящие кристаллы), иногда это вынужденный шаг (вспомним ситуацию примерно годовалой давности, когда из-за проблем на фирме Atmel ее продукция исчезла со складов поставщиков, и передо мной замаячила вполне реальная перспектива вынужденного перехода на микроконтроллеры семейства PIC). Те, кто программирует на ассемблере, после такого перехода будут вынуждены отправить все предыдущие наработки в мусорную корзину и начать работу заново. Те же, кто использует ЯВУ, имеют шанс отделаться в основном перекомпиляцией, переписав небольшую аппаратно-зависимую часть кода. Следует также иметь в виду, что арсенал инструментальных средств разработчика не исчерпывается одним лишь транслятором. В случае языка C в распоряжении разработчика оказывается также масса различных утилит, которые помогают ему:
Этот список утилит, конечно же, неполон, продолжать его можно еще долго. Их аналоги для ассемблера если и существуют, то по крайней мере мне не известны. Сторонники использования ассемблера обосновывают свой выбор тем, что при непосредственной работе с микроконтроллером на самом низком уровне (машинных команд, регистров и ячеек памяти) можно более эффективно использовать его ресурсы, создавая более компактные и быстрые программы, чем компилятор ЯВУ. Ресурсов и правда слишком много не бывает, равно как и слишком быстрых программ, а в случае микроконтроллеров это тем более актуально. Поэтому на первый взгляд такой выбор представляется вполне разумным. Но мы не будем ничего принимать на веру, а попробуем проверить лично. Для начала откомпилируем наш проект с оптимизацией. Когда компиляция завершится успешно, посмотрим, какой же код сгенерировал компилятор. Для наглядности сгенерированный код приведу сразу после исходного. Код: (C) Blinker.c #include "Application.h" int main() { Application_init(); for (;;) Application_run(); } Код: 00000090 <main>: Пока не вижу ничего лишнего, только вызов функции, а затем зацикленный вызов другой функции. Код: (C) Application.c #include "Application.h" #include "Led.h" #include "Timer.h" void Application_init(void) { Led_init(); Timer_init(); } void Application_run(void) { Led_on(); Timer_wait(500); Led_off(); Timer_wait(1500); } Код: 0000006c <Application_init>: В функции Application_run мы видим, что компилятор использовал регистры r24 и r25 для передачи параметра в вызываемую функцию Timer_wait. Передача параметров через регистры общего назначения эффективнее, чем через стек, благо микроконтроллер с архитектурой RISC располагает множеством таких регистров. Подобный прием наверняка использовал бы и программист на ассемблере. Пока что подкопаться не к чему. Код: (C) Led.c #include "Led.h" #include <avr/io.h> /* Инициализаци порта светодиода. * Выбран порт C, бит 0, управление инверсное. */ void Led_init(void) { // программируем бит 0 порта C на вывод DDRC |= _BV(PC0); // выключить светодиод Led_off(); } // включить светодиод void Led_on(void) { PORTC &= ~_BV(PC0); } // выключить светодиод void Led_off(void) { PORTC |= _BV(PC0); } Код: 0000009a <Led_on>: В функциях Led_on и Led_off оптимизатор откровенно порадовал, сообразив реализовать битовые операции над регистрами инструкциями установки и сброса отдельных битов. В функции Led_init в принципе можно было бы развернуть вызов Led_off, сэкономив пару байт кода, пару байт стека и несколько тактов на вызове функции и возврате из нее. Впрочем, это легко лечится изменением опции оптимизации с -Os на -O3: Код: 0000009a <Led_init>: Код: (C) Timer.c #include "Timer.h" #include <stddef.h> #include <util/delay_basic.h> void Timer_init(void) { // в версии с программной задержкой инициализация не требуется } // программная задержка 1 ms static void wait1ms(void) { _delay_loop_2(4000); } void Timer_wait(uint16_t ms) { for (unsigned short i = 0; i < ms; ++i) { wait1ms(); } } Код: 000000aa <Timer_init>: В функции Timer_wait оптимизатор догадался раскрыть не только вспомогательную функцию wait1ms(), но и библиотечную _delay_loop_2(). Конечно, использование r18 и r19 выглядит лишним, ведь можно было бы в качестве счетчика использовать r24 и r25. Попытаемся немного помочь оптимизатору: Код: (C) Timer.c void Timer_wait(uint16_t ms) { for (; ms > 0; --ms) { wait1ms(); } } Код: 000000aa <Timer_wait>: Теперь машинный код выглядит ничуть не хуже написанного вручную. Делаем выводы: использование языка C для программирования микроконтроллеров не влечет непременного раздувания программного кода и снижения его эффективности. Зато выигрыш в производительности труда программиста очевиден. Попутно снимается проблема переносимости кода на другие семейства микроконтроллеров. Возможно даже заимствование кода, написанного для других семейств, после небольшой адаптации (а порой и вовсе без нее). Последние шаги И вот, наконец, долгожданный прототип в наших руках:
Прошиваем программу, включаем устройство:  Убеждаемся, что задача решена, причем мы умудрились выдержать сроки за счет того, что приступили к работе сразу, не дожидаясь готовности оборудования. Подводим итоги Пришла пора подвести итоги проделанной работы. Конечно же, этот проект был наполовину шуткой, ведь ни у кого в здравом уме не возникнет потребность в подобном устройстве, тем более на базе микроконтроллера. Однако, хотя результат совершенно бесполезен, о самом процессе этого сказать никак нельзя. В ходе работы над проектом мы приобрели ряд ценных навыков и извлекли несколько уроков.
На этом, пожалуй, можно поставить точку. Мы довели наш учебный проект от идеи до реализации и можем приниматься за более серьезные дела, используя полученные навыки. Желаю успехов в ваших разработках!
|
| начало | почта | статьи | файлы | ссылки | сайты | RSS | о нас | опубликовать | оформление | авторы | друзья | реклама |