Хочу немного поделиться негативным опытом использования микроконтроллеров Atmel в промышленной разработке.
Atmel как целевую платформу выбрал заказчик, хотя мы его и отговаривали (еще даже не зная, что нам предстоит — интуиция, что ли?). Ну что же, «заказчик всегда прав».
В продукте было два контроллера — 32-битный UC3A3 и 8-битный ATMega164. В качестве дебаггера выбрали AVR One!, в качестве среды разработки — AVR Studio 5.0 (последняя версия на момент старта).
И началось!
У двух из трех купленных AVR One! в течении первого же месяца отвалились JTAG-коннекторы. У одного из них пропадал контакт питания. Каждый дебаггер, к слову, стоит около 600 евро!
При первом подключении дебаггера к компу с установленной AVR Studio 5.0 последняя захотела обновить ему прошивку. И не просто захотела, а отказывалась работать без этого. Процедура обновления прошивки благополучно зациклилась в «обновление — ожидание готовности устройства — обновление завершено неуспешно — обновление...», произвести ее удалось только после долгих танцев с бубнами.
На начальной стадии работа ведется на Evaluation платах. Были такие и у Атмела. Вот только на «готовых» эвалкитах к большинству пинов процессора банально не было доступа! А универсальный пакет STK600, позволяющий «воткнуть» в него практически любой контроллер при помощи переходника (решение реально супер, если бы не одно но), имел маленький недостаток — его схема была недоступна ни в открытом доступе, ни за деньги! Блин, вот реально — тулкит, предназначенный для экспериментов с платформой, поставлялся без схемы! И схема его охранялась очень и очень тщательно, судя по многочисленным веткам на AVR freaks. Поскольку мы не могли представить себе, как же можно работать без наличия схемы, мы разумно отказались от покупки этого тулкита (который ни разу не дешевый, к слову!).
Еще веселее стало, когда приступили собственно к написанию и отладке кода.
Самым веселым оказалось то, что пошаговая отладка оказалась в принципе невозможной. Дело в том, что поставив где-нибудь в коде брейкпоинт, дождавшись остановки программы в этом месте и выполнив «шаг вперед», ты оказывался… в обработчике прерывания! (Естественно, в прерывании при этом никаких брейкпоинтов не было!). А поскольку прерывания в системе были всегда (таймеры и т.п.), процесс отладки выглядел следующим образом: приходилось ставить следующий брейкпоинт на следующей строке и нажимать Run вместо Step Over. Особенно весело это было, когда надо было отследить if или switch. Или же выполнить Step Into, а не Step Over…
Вторым радостным моментом оказалось то, что когда ты останавливался в прерывании, ты не видел стека вызовов. Особенно радовало, когда этим прерыванием было исключение процессора. На предыдущем проекте на контроллере от Freescale в аналогичной ситуации ты отлично видел весь стек вызовов — в каком месте произошло исключение процессора и что к нему привело. Здесь же все, что ты видел — это то, что исключение произошло. А где и почему — оставалось только догадываться.
Третьим радостным моментом оказалось, например, вот что: код
int a[4];
a[0] = 1;
a[1] = 2;
a[2] = 3;
a[3] = 4;
категорически отказывался работать на ATMega! Элемент a[1] после этого кода оставался равным 0!
И особенно порадовал ответ техподдержки Atmel «Да, данный процессор имеет указанную проблему, попробуйте заменить его на другой!». Ага, а ничего, что уже как бы плата с ним произведена? Следующим ответом техподдержки было «Попробуйте заменить в AVR Studio родной AVR toolchain на open source WinAVR. Это, как ни странно, помогло, массив стал инициализироваться как надо. Правда, заголовочные файлы этого toolchain представляли из себя местами кашу, и часть заголовков пришлось брать от „родного“…
Плюс вся система работала крайне нестабильно. Дебаггер мог просто перестать видеть контроллер. Студия могла перестать видеть дебаггер. Или перестать запускать код на выполнение.
К счастью, на AVR freaks часть проблем была описана и решения найдены. Например, вместо 600-евровых AVR One! были куплены 50-евровые AVR Dragon, работающие гораздо стабильнее — с ними разработка стала в принципе возможной. (Из серии „Зачем, блин, платить больше?“).
И пришлось перейти с AVR Studio 5.0 на более старую AVRStudio32, поскольку первая была настолько глючно-сырой, что работать в ней было невозможно. Интерфейс, конечно, у пятой студии был удобным, ничего не скажешь, но когда удобная в использовании среда банально не работает — удобство оказывается бессмысленным, увы.
AVRStudio32 c точки зрения интерфейса оказалась очень специфической штукой. То ли Eclipse-based сыграло свою роль, то ли Atmel внес свою лепту… Приведу лишь один пример.
Нам понадобилось изменить точку запуска, которая по умолчанию выставлена в среде разработки на начало flash контроллера. В AVRStudio32 за это отвечает так называемая „конфигурация запуска“ (найти которую, кстати, отнюдь не очевидная задача). Так мало того, что параметры конфигурации запуска не сохраняются в проекте (а это означает, что изменения должен был вносить каждый разработчик „ручками“ и их нельзя было коммитить в репозиторий), так кроме этого студия могла в какой-то из моментов по своему желанию создать новую конфигурацию, с параметрами по умолчанию, сделав ее текущей. Нет, когда это все уже знаешь, то исправить это не вопрос. Но вот когда не знаешь, а выглядит все так, что после очередного изменения вдруг все перестало работать, то становится очень даже невесело…
То, что примерно за год разработки дебаггеры банально три или четыра раза выходили из строя, уже было просто досадной мелочью.
Еще одной такой досадной мелочью был прикол с тем, что Atmel называет Fuses — специальные биты, управляющие поведением микроконтроллера, доступные при помощи специальных команд. Неосторожное движение или ошибка — и процессор оказывался непригодным к дальнейшему использованию без очень сложных телодвижений. Можно было, например, переключить его с использования внутренней тактовой частоты на внешнюю. Поскольку внешней, конечно же, в наличии не было, процессор переставал работать. Вернуть этот бит без подачи внешней синхронизации было невозможно в принципе. А еще можно было, например, „выключить“ JTAG — после чего к контроллеру невозможно было подключиться дебаггером.
Вполне естественно, что во время разработки возникают ошибки. Но когда такая ошибка приводит к остановке процесса на непонятно сколько времени — мягко говоря, совсем невесело.
Одна из последних проблем оказалась не менее веселой — по какой-то из причин микроконтроллеры один за одним переставали работать, и дебаггеры тоже переставали их видеть. Времени на анализ было потрачено прилично, оказалось же вот что.
Немного доп. информации: каждый контроллер от Atmel имеет так называемый Device Code, однозначно идентифицирующий семейство. Есть спец. команда, чтобы этот код прочитать. Дебаггер и студия как раз его и используют для идентификации того, что подключено. По идее, значение это read only, и нигде в спецификации не указано обратное. Оказалось, что это не так.
Цитата из Errata:
Signature may be Erased in Serial Programming Mode
If the signature bytes are read before a chiperase command is completed, the signature may be erased causing the device ID and calibration bytes to disappear. This is critical, especially, if the part is running on internal RC oscillator.
Особенно же впечатлило решение проблемы:
Problem Fix / Workaround:
Ensure that the chiperase command has exceeded before applying the next command.
То есть, если Device ID уже оказался стертым, записать его назад возможности не предоставляется. Хуже всего то, что вместе с ним стирается еще и калибровка внутренней частоты, которая также невосстановима, насколько я понял из доступной информации.
Должен сказать, что после команды Chip Erase в коде стояла задержка в два раза больше, чем того требовала спецификация. Однако Device ID волшебным образом стирался по непонятной причине…
Что же, негативный опыт — тоже опыт. Вряд ли я по доброй воле выберу теперь Atmel для чего-либо.
А что касается Arduino — понятно, конечно, что те, кто решает с ней поиграться, с большинством проблем банально не столкнутся, но — после всего описанного выше я все же не понимаю столь высокой ее популярности.
И кстати, выбор заказчиком платформы, похоже, как раз и был обусловлен популярностью Ардуино…
Автор: olekl
