Как читать техническое описание на микроконтроллер: введение и первые шаги
Технические описания (datasheet, «даташит») на микроконтроллеры иногда представляют собой огромное количество фактов, цифр и спецификаций. Это практическое пошаговое руководство поможет вам определить и извлечь необходимую вам информацию.
Поскольку микроконтроллеры становятся всё более сложными и мощными, их технические описания (datasheet, «даташит») становятся всё длиннее и сложнее. Это неудивительно, и я, конечно, не хочу критиковать производителей за попытку представить подробную и исчерпывающую информацию об их компонентах. Дело в том, что эти длинные и иногда пугающие технические описания создают некоторые проблемы.
Сложности технических описаний
Прежде всего, они могут стать препятствием для студентов и инженеров, которые не имеют опыта разработки на микроконтроллерах. Для базовых приложений, которые опираются на примеры кода и библиотечные функции, бывает возможно выполнить работу, даже не заглядывая в техническое описание. Однако в большинстве случаев важно проконсультироваться и даже изучить технические характеристики микроконтроллера, а для тех, кто еще не знаком с реализацией микроконтроллера и разработкой программного обеспечения, может быть трудно подойти к документу, в котором в десять или даже в сто раз больше информации, чем та, что нужна для проекта. Данная статья написана в первую очередь для читателей, которые попадают в эту категорию людей.
Тем не менее, даже опытные разработчики устройств на микроконтроллерах могут испытывать небольшое «давление» от технического описания при переходе на более сложное устройство или на нового производителя. Я надеюсь, что эта статья также будет полезна людям, которые попадают в эту вторую категорию.
Некоторые характеристики технических описаний
Я хочу кратко рассказать о масштабах проблемы, описав документацию, прилагаемую к нескольким микроконтроллерам от производителей, которых я рекомендовал в статье о выборе микроконтроллера.
- MSP430FR5994 – микроконтроллер с ультранизким энергопотреблением от Texas Instruments:
- техническое описание – 171 страница;
- руководство пользователя – 1021 страница;
- список опечаток – 15 страниц;
- EFM8UB20F32G – 8-разрядный USB микроконтроллер от Silicon Labs:
- техническое описание –57 страниц;
- справочное руководство – 308 страниц;
- список опечаток – 6 страниц;
- STM32G0x0 – 32-разрядный микроконтроллер Arm Cortex-M0 от STMicroelectronics:
- спецификация на продукт – 96 страниц;
- справочное руководство – 913 страниц;
- руководство по программированию – 110 страниц;
- список опечаток – 11 страниц.
Шаг 1: Оценка характера документов
Несмотря на (упрощенное) название этой статьи, многие микроконтроллеры не имеют «технических описаний». Различные типы информации могут быть распределены по нескольким документам, и вам необходимо кратко изучить эти документы, чтобы определить, какие из них имеют спецификации, описания и рекомендации, которые вам действительно нужны на определенном этапе процесса разработки.
Например, устройства EFM8 от Silicon Labs имеют и техническое описание, и справочное руководство. Техническое описание содержит список функциональных возможностей, электрические характеристики, некоторые базовые примеры аппаратной реализации, описание выводов и размеры посадочных мест.
Таким образом, я буду использовать техническое описание, когда исследую устройство, проверяю некоторые характеристики производительности (потребление тока, точность генератора, нелинейность АЦП и так далее), создаю компонент в САПР и разрабатываю схему.
Справочное руководство, напротив, содержит подробную информацию о внутренней памяти, прерываниях, источниках тактовых сигналов, ядре процессора и всех периферийных устройствах.
Разделы периферийных устройств содержат описания регистров, которые представляют всю информацию, необходимую для настройки и реализации функциональных возможностей периферии. Таким образом, справочное руководство относится в первую очередь к разработке встроенного программного обеспечения (прошивки), хотя оно, безусловно, включает в себя информацию, которая должна учитываться в схеме.
Шаг 2: Игнорирование ядра
Хотя я упорно настаиваю на важности языка ассемблера, я признаю, что в целом это уже не практичный подход к разработке прошивки. И у меня нет сомнений, что почти каждый человек, читающий эту статью, будет писать код для микроконтроллера на C/C++. Это означает, что компилятор будет автоматически управлять многочисленными деталями, относящимися к внутренней работе вашего микроконтроллера, и, следовательно, вы можете спокойно игнорировать подавляющее большинство этих деталей (по крайней мере, на начальном этапе).
Например, руководство пользователя MSP430FR59xx посвящает около 40 страниц центральному процессору. Во многих приложениях вся эта информация будет ненужной.
Суть здесь в том, чтобы подумать обо всех деталях, связанных с процессором, о которых вам не нужно беспокоиться при написании кода на C/C++, а затем попытаться определить соответствующие разделы технического описания, которые вы могли бы пропустить.
Шаг 3: Не зацикливайтесь на электрических характеристиках
Производители полупроводниковых устройств, как правило, отлично справляются со своей работой, полностью описывая характеристики своих устройств. Однако в своей реальной инженерной работе (с моего первого рабочего дня до настоящего момента) я обнаружил, что только небольшая часть электрических характеристик устройства имеет значение для конкретного проекта.
Таким образом, не пугайтесь длинного раздела технического описания, заполненного таблицами характеристик, посадочными местами, графиками и временными диаграммами. Если есть несколько характеристик, которые особенно важны для вашего приложения, обязательно проверьте их, но также помните, что эмпирические данные, собранные с использованием вашей системы в соответствии с вашими эксплуатационными параметрами, будут более ценными, чем числа в техническом описании.
Подведем итоги
Мы увидели, что документация для современных микроконтроллеров может быть объемной до такой степени, что она может стать препятствием, особенно для новичков в этой области и, возможно, даже для опытных инженеров. В данной статье представлены мои первые три предложения по преодолению перегрузки документацией, и мы продолжим это обсуждение в следующей статье.