Читая местные обзоры, уже не раз подумывал о покупке паяльника с жалом T12. Давно хотелось чего-то портативного с одной стороны, достаточно мощного с другой стороны, и, разумеется, нормально поддерживающего температуру.
У меня есть относительно много паяльников, купленных в разные времена и под разные задачи:
Есть совсем древние ЭПСН-40 и «москабель» 90Вт, чуть более новый ЭМП-100 (топорик), совсем новый китайский TLW 500W. Последние два особенно хорошо сохраняют температуру (даже при пайке медных труб), но вот паять ими микросхемы не очень удобно:). Попытка использования ZD-80 (пистолетик с кнопкой) не вышла - ни мощности, ни нормального поддержания температуры. Прочая «электронная» мелочь типа Antex cs18/xs25 годится только для совсем мелочей, да и встроенной регулировки не имеет. Лет 15 назад пользовался den-on"овским ss-8200, но жала там совсем малюсенькие, термодатчик далеко и градиент температуры огромен - несмотря на заявленные 80W, на жале по ощущениям и трети не будет.
В качестве стационарного варианта я уж лет 10 использую Lukey 868 (это практически 702, только нагреватель керамический и еще какие-то мелочи). Но портативности в ней нет никакой, с собой в карман или мелкую сумку никак не взять.
Т.к. на момент покупки я еще не был уверен «а нужно ли мне оно», был взят минимальный бюджетный вариант с K-жалом и ручкой, максимально похожей на привычный паяльник от Lukey. Возможно, что кому-то она кажется не очень удобной, но для меня важнее, что-бы ручки обоих используемых паяльников привычно и одинаково лежали в руке.
Дальнейший обзор можно будет условно разделить на две части - «как из запчастей сделать устройство» и попытка анализа «как это устройство и прошивка контроллера работают».
К сожалению, продавец убрал именно этот SKU, поэтому могу дать только ссылку на снимок товара из журнала заказов. Впрочем, нет никаких проблем найти аналогичный товар.
Часть 1 - конструкция
После макетной проверки работоспособности, встал вопрос о выборе конструкции.
Имелся почти подходящий блок питания (24v 65W), высотой практически 1:1 с платой управления, чуть уже ее и длиной около 100мм. Учитывая, что этот блок питания питал какую-то сдохшую (не по его вине!) связную и не дешевую lucent-овскую железку, а в его выходном выпрямителе стоят две диодные сборки на суммарные 40А, я решил, что он не сильно хуже распространенного здесь китайца на 6A. Заодно и валяться не будет.
Тестовая проверка на проверенном временем эквиваленте нагрузки (ПЭВ-100, выкручен на примерно 8 Ом)
показала, что БП практически не греется - за минут 5 работы ключевой транзистор, несмотря на свой изолированный корпус, нагрелся градусов до 40 (чуть теплый), диоды потеплее (но руку не обжигает, держать вполне комфортно), а напряжение по прежнему 24 вольта с копейками. Выбросы увеличились до сотни милливольт, но для данного напряжения и этого применения сие вполне нормально. Собственно, я остановил опыт из-за нагрузочного резистора - на его меньшей половине выделялось около 50W и температура перевалила за сотню.
В результате минимальные габариты были определены (БП + плата управления), следующим этапом шел корпус.
Поскольку одним из требований была портативность, вплоть до возможность распихать по карманам, вариант с готовыми корпусами отпал. Доступные универсальные пластмассовые корпуса совсем не годились по размерам, китайские алюминиевые корпуса под T12 для карманов куртки тоже великоваты, да и ждать еще месяц не хотелось. Вариант с «напечатанным» корпусом не проходил - ни прочности, ни теплостойкости. Прикинув возможности и вспомнив пионерскую молодость, решил сделать из древнего одностороннего фольгированного стеклотекстолита, валяющегося еще со времён СССP. Толстенная фольга (микрометр на тщательно разглаженном кусочке показал 0.2мм!) все равно не позволяла травить дорожки тоньше миллиметра из-за бокового подтравливания, а для корпуса - самое то.
Но лень вкупе с нежеланием пылить категорически не одобрила распиловку ножовкой или резаком. После прикидки имеющихся технологических возможностей, решил попробовать вариант распиловки текстолита на электрическом плиткорезе. Как оказалось - в высшей степени удобный вариант. Диск режет стеклотекстолит без всяких усилий, кромка получается практически идеальная (с резаком, ножовкой или лобзиком даже не сравнить), ширина по длине реза тоже одинаковая. И, что немаловажно, вся пыль остается в воде. Понятно, что если нужно отпилить один маленький кусочек, то разворачивать плиткорез слишком долго. Но даже на этот маленький корпус нужно было под метр реза.
Далее был спаян корпус с двумя отделениями - одно под блок питания, второе для платы управления. Первоначально, я не планировал разделение. Но, как и при сварке, припаянные в угол пластины при остывании стремятся уменьшить угол и дополнительная перепонка очень полезна.
Передняя панель согнута из алюминия в форме буквы П. В верхнем и нижнем отгибе нарезана резьба для фиксации в корпусе.
В результате получился такое (с устройством я до сих пор «играюсь», поэтому покраска пока очень черновая, из остатков старого балончика и без шлифовки):
Габаритные размеры самого корпуса - 73 (ширина) x 120 (длина) x 29 (высота). Ширину и высоту сделать меньше нельзя, т.к. размеры платы управления 69 x 25, да и найти более короткий блок питания тоже не просто.
Сзади установлен соединитель под стандартный электропровод и выключатель:
К сожалению, черного микровыключателя в хламе не оказалось, надо будет заказать. С другой стороны - белый заметнее. А вот соединитель я специально ставил стандартным - это позволяет в большинстве случаев не брать с собой дополнительный провод. В отличие от варианта с ноутбучной розеткой.
Вид снизу:
Черный изолятор из резиноподобного материала остался от исходного блока питания. Он довольно толстый (чуть меньше миллиметра), теплостойкий и очень плохо режется (отсюда и грубый вырез для пластиковой распорки - чуть-чуть не влезало). По ощущениям - как асбест, пропитанный резиной.
Слева от блока питания - радиатор выпрямителя, справа - ключевого транзистора. В оригинальном БП радиатором была тонкая полоска алюминия. Я решил «усугубить» на всякий случай. Оба радиатора изолированы от электроники, поэтому могут свободно прилегать к медным поверхностям корпуса.
На перепонке смонтирован дополнительный радиатор для платы управления, контакт с d-pak корпусами обеспечивается термопрокладкой. Пользы не много, но все лучше воздуха. Что бы исключить замыкание, пришлось чуть обкусить выступающие контакты «авиационного» разъема.
Для наглядности - паяльник рядом с корпусом:
Результат:
1) Паяльник работает примерно как заявлено и вполне помещается в карманах куртки.
2) В старом хламе утилизированы и более не валяются: блок питания, кусок стеклотекстолита 40-летней давности, балончик с нитроэмалью 1987 года выпуска, микровыключатель и небольшой кусок алюминия.
Разумеется, с точки зрения экономической целесообразности существенно проще купить готовый корпус. Пусть материалы были и практически бесплатны, но «время-деньги». Просто в моем списке задач вообще не фигурировала задача «сделать дешевле».
Часть 2 - заметки о функционировании
Как можно заметить, в первой части я вообще не упомянул о том, как все это работает. Мне показалось целесообразным не смешивать описание своей личной конструкции (довольно «колхозно-самопальной» на мой взгляд) и функционирование контроллера, который идентичен или похож у многих.
В качестве некоторого предварительного предупреждения хочу сказать:
1) Разные контроллеры имеют несколько разную схемотехнику. Даже у внешне одинаковых плат могут быть немножко отличающиеся компоненты. Т.к. у меня имеется только одно мое конкретное устройство, я никак не могу гарантировать совпадение с другими.
2) Прошивка контроллера, которую я анализировал, не единственная имеющаяся. Она распространенная, но у Вас может стоять другая прошивка, функционирующая другим образом.
3) Я нисколько не претендую на лавры первооткрывателя. Многие моменты уже были ранее освещены другими обозревателями.
4) Дальше будет много скучных букв и ни одной веселой картинки. Если внутреннее устройство не интересует - остановитесь здесь.
Обзор конструкции
Дальнейшие выкладки будут во многом связаны со схемотехникой контроллера. Для понимания его работы точная схема не обязательно, вполне достаточно рассмотреть основные компоненты:
1) Микроконтроллер STC15F204EA. Ничем особо не выдающийся чип семейства 8051, заметно более быстрый, чем оригинал (оригинал 35 летней давности, да). Питается от 5В, имеет на борту 10-битный АЦП с коммутатором, 2x512байт nvram, 4KБ программной памяти.
2) Стабилизатор на +5В, состоящий из 7805 и мощного резистора для уменьшения тепловыделения(?) на 7805, сопротивлением 120-330 Ом (на разных платах разное). Решение в высшей степени бюджетное и тепловыделяющее.
3) Силовой транзистор STD10PF06 с обвязкой. Работает в ключевом режиме на низкой частоте. Ничего выдающегося, старый.
4) Усилитель напряжения термопары. Подстроечный резистор регулирует его усиление. Имеет защиту на входе (от 24В) и подключен на один из входов АЦП МК.
5) Источник опорного напряжения на TL431. Подключен на один из входов АЦП МК.
6) Датчик температуры платы. Также подключен к АЦП.
7) Индиктор. Подключен к МК, работает в режиме динамической индикации. Подозреваю, что один из основных потребителей +5В
8) Ручка управления. Вращение регулирует температуру (и другие параметры). Линия кнопки в очень многих моделях не запаяна или разрезана. Если соединить, то позволяет настраивать дополнительные параметры.
Как несложно заметить, все функционирование определяется микроконтроллером. Почему китайцы ставят именно такой - мне неизвестно, он не сильно дешевый (около $1, если брать несколько штук) и впритык по ресурсам. В типовой китайской прошивке остаются свободными буквально десяток байт памяти программ. Сама прошивка написана на С или чем-то аналогичном (там видны явные хвосты библиотеки).
Функционирование прошивки контроллера
Исходных текстов я не имею, но IDA никуда не делась:). Механизм работы довольно простой.
При начальном запуске прошивка:
1) инициализирует устройство
2) загружает параметры из nvram
3) Проверяет нажатость кнопки, если нажата - ждет отжатия и запускает п/п настройки расширенных параметров (Pxx) Там много параметров, если нет понимания, то лучше их не трогать. Могу выложить раскладку, но опасаюсь спровоцировать проблемы.
4) Выводит на экран «SEA», ждет и запускает основной цикл работы
Есть несколько режимов работы:
1) Обычный, нормальное поддержание температуры
2) Частичное энергосбережение, температура 200 градусов
3) Полное отключение
4) Режим настройки P10(шаг настройки температуры) и P4(усиление ОУ термопары)
5) Режим альтернативного управления
После запуска работает режим 1.
При коротком нажатии кнопки производится переход в режим 5. Там можно повернуть регулятор влево и уйти в режим 2 или вправо - увеличить температуру на 10 градусов.
При длительном нажатии производится переход в режим 4.
В предыдущих обзорах было много споров, как правильно устанавливать вибродатчик. По имеющейся у меня прошивке могу сказать однозначно - без разницы. Уход в режим частичного энергосбережения выполняется по отсутствию изменений
состояния вибродатчика, отсутствию существенных изменений температуры жала и отсутствию сигналов от ручки - все это на протяжении 3х минут. Замкнут вибродатчик или разомкнут - совершенно неважно, прошивка анализирует только изменения в состоянии. Вторая часть критерия тоже интересна - если вы паяете, то температура жала неминуемо плавает. И если фиксируется отклонение более чем на 5 градусов от заданной, выхода в режим энергосбережения не будет.
Если режим энергосбережения продлится больше заданного, то паяльник полностью выключится, на индикаторе будут нули.
Выход из энергосберегающих режимов - по вибрации или по ручке управления. Возврата из полного энергосбережения в частичный не бывает.
Поддержанием температуры МК занимается в одном из таймерных прерываний (их задействовано два, второе занимается дисплеем и прочим. Зачем так сделано непонятно - интервал прерывания и другие настройки выбраны одинаковые, вполне можно было обойтись единым прерыванием). Цикл управления состоит из 200 таймерных прерываний. На 200-м прерывании нагрев обязательно отключается (- целые 0.5% мощности!), выполняется задержка, после чего производится измерение напряжений с термопары, термодатчика и опорного напряжения с TL431. Далее все это по формулам и коэффициентам (частично задаваемым в nvram) пересчитывается в температуру.
Здесь я позволю себе маленькое отступление. Зачем в такой конфигурации термодатчик - не вполне понятно. При правильной организации, он должен давать поправку температуры на холодном спае термопары. Но в этой конструкции он измеряет температуру платы, не имеющую никакого отношения к требуемой. Его либо нужно переносить в ручку, как можно ближе к картриджу T12 (и еще вопрос - в каком месте картридже находится холодный спай термопары), либо вовсе выкинуть. Возможно, я чего-то не понимаю, но похоже, что китайские разработчики тупо передрали схему компенсации с какого-то другого устройства, совершенно не понимая принципов работы.
После измерения температуры вычисляется разница между заданной и текущей температурой. В зависимости от того, большая она или маленькая работают две формулы - одна большая, с кучей коэффициентов и накоплением дельты (желающие могут почитать про построение ПИД-регуляторов), вторая проще - при больших отличиях нужно либо греть максимально, либо полностью отключить (в зависимости от знака). Переменная ШИМ может иметь значение от 0 (отключено) до 200 (полностью включено) - по количеству прерываний в цикле управления.
Когда я только включил устройство (и еще не залез в прошивку), меня заинтересовал один момент - не было дрожания на ± градус. Т.е. температура либо держится стабильно, либо дергается сразу на 5-10 градусов. После анализа прошивки выяснилось, что дрожит оно по всей видимости всегда. Но при отклонении от заданной температуры менее чем на 2 градуса прошивка показывает не измеренную, а заданную температуру. Это ни хорошо и не плохо - дрожащий младший разряд тоже сильно раздражает - просто нужно иметь в виду.
Завершая разговор о прошивке хочу отметить еще несколько моментов.
1) С термопарами я не работал уже лет 20. Может за это время они стали линейнее;), но раньше для сколько-нибудь точных измерений и при наличии возможности, всегда вводилась функция корректировки нелинейности - формулой или таблицей. Здесь этого нет от слова совсем. Можно настроить только смещение нуля и угол наклона характеристики. Может во всех картриджах используются высоколинейные термопары. Либо индивидуальный разброс в разных картриджах больше, чем возможная групповая нелинейность. Хотелось бы надеяться на первый вариант, но опыт намекает на второй…
2) По непонятной для меня причине, внутри прошивки температура задается числом с фиксированной точкой и разрешением в 0.1 градус. Совершенно очевидно, что в силу предыдущего замечания, 10-битного АЦП, неверной поправки холодного конца, неэкранированного провода и т.п. реальная точность измерений и 1 градус никак не составит. Т.е. похоже, что опять содрано с какого-то другого устройства. А сложность вычислений чуть выросла (неоднократно приходится делить/умножать на десять 16-разрядные числа).
3) На плате имеются контактные площадки Rx/TX/gnd/+5v. Насколько я понял, у китайцев были специальные
прошивки и специальная китайская программа, позволяющая напрямую получать данные со всех трех каналов АЦП и настраивать параметры ПИД. Но в стандартной прошивке ничего этого нет, выводы предназначены исключительно для заливки прошивки в контроллер. Программа для заливки доступна, работает через простой последовательный порт, только TTL-уровни нужны.
4) Точки на индикаторе имеют свой функционал - левая индицирует режим 5, средняя - наличие вибрации, правая - тип выводимой температуры (выставленная или текущая).
5) Для записи выбранной температуры отведено 512 байт. Сама запись сделана грамотно - каждое изменение пишется в следующую свободную ячейку. Как только достигнут конец - блок полностью стирается, а запись производится в первую ячейку. При включении берется самое дальнее записанное значение. Это позволяет увеличить ресурс в пару сотен раз.
Владелец, помни - вращая ручку настройки температуры, ты тратишь невосполнимый ресурс встроенного nvram!
6) Для остальных настроек используется второй блок nvram
С прошивкой все, если возникнут дополнительные вопросы - задавайте.
Мощность
Одна из важных характеристик паяльника - максимальная мощность нагревателя. Оценить ее можно следующим образом:
1) Имеем напряжение 24В
2) Имеем жало Т12. Измеренное мной сопротивление жала в холодном состоянии составляет чуть более 8 Ом. У меня получилось 8.4, но я не берусь утверждать, что погрешность измерения менее 0.1 Ома. Предположим, что реальное сопротивление никак не менее 8.3 Ома.
3) Сопротивление ключа STD10PF06 в открытом состоянии (по даташиту) - не более 0.2 Ома, типовое - 0.18
4) Дополнительно нужно учесть сопротивление 3х метров провода (2x1.5) и разъема.
Итоговое сопротивление цепи в холодном состоянии составляет не менее 8.7 Ома, что дает предельный ток в 2.76А. С учетом падения на ключе, проводах и разъеме, напряжением на самом нагревателе будет около 23В, что даст мощность порядка 64 Вт. Причем это предельная мощность в холодном состоянии и без учета скважности. Но не стоит особо расстраиваться - 64 Вт это весьма много. А учитывая конструкцию жала - достаточно для большинства случаев. Проверяя работоспособность в режиме постоянного нагрева, я помещал кончик жала в кружку с водой - вода вокруг жала кипела и пАрила весьма бодро.
Но вот попытка экономии с использованием БП от ноутбука имеет очень сомнительную эффективность - внешне незначительное снижение напряжения, приводит к потере трети мощности: вместо 64 Вт останется порядка 40. Стоит ли этого экономия $6?
Если наоборот, попытаться выжать из паяльника заявленные 70Вт, есть два пути:
1) Немного увеличить напряжение БП. Достаточно увеличить всего на 1В.
2) Уменьшить сопротивление цепи.
Почти единственный вариант, как немного уменьшить сопротивление цепи - заменить ключевой транзистор. К сожалению, практически все p-канальные транзисторы в используемом корпусе и на требуемое напряжение (на 30В я не рискнул бы ставить - запас будет минимален) имеют сходные Rdson. А так было бы вдвойне замечательно - заодно меньше бы грелась плата контроллера. Сейчас в режиме максимального разогрева на ключевом транзисторе выделяется около ватта.
Точность/стабильность поддержания температуры
Кроме мощности, не менее важна стабильность поддержания температуры. Причем лично для меня стабильность даже важнее точности, поскольку если значение на индикаторе можно и опытным путем подобрать - обычно я так и делаю (и не очень важно, что при выставке 300 градусов реально на жале - 290), то вот нестабильность таким образом не побороть. Впрочем, по ощущениям, стабильность поддержания температуры на T12 заметно лучше, чем на жалах 900-й серии.
Что имеет смысл переделать в контроллере
1) Контроллер греется. Не фатально, но больше желаемого. Причем главным образом его греет даже не силовая часть, а стабилизатор на 5В. Измерения показали, что ток по 5В составляет порядка 30 мА. 19В падения при 30 мА дает примерно 0.6Вт постоянного нагрева. Из них на резисторе (120Ом) выделяется порядка 0.1Вт и еще 0.5Вт - на самом стабилизаторе. Потребление остальной схемы можно игнорировать - всего 0.15Вт, из которой заметная часть тратится на индикатор. Но плата маленькая и поставить step-down просто некуда - если только на отдельной платке.
2) Силовой ключ с большим (относительно большим!) сопротивлением. Применение ключа с сопротивлением 0.05 Ом сняло бы все проблемы его нагрева и добавило бы около ватта мощности нагревателю картриджа. Но корпус был бы уже не 2х миллиметровый dpak, а минимум на размер больше. Или вообще переделать управление на n-канал.
3) Перенос ntc в ручку. Но тогда имеет смысл перенести туда и микроконтроллер, и силовой ключ и опорное напряжение.
4) Расширение функциональности прошивки (несколько наборов параметров ПИД для разных жал и т.п.). Теоретически возможно, но лично мне проще (и дешевле!) заново слепить на каком-нибудь младшем stm32, чем утаптывать в существующую память.
В результате имеем замечательную ситуацию - переделывать можно много чего, но практически любая переделка требует выкинуть старую плату и сделать новую. Либо не трогать, к чему я и склоняюсь пока.
Заключение
Имеет ли смысл переходить на T12? Не знаю. Пока я работаю только с жалом T12-K. Для меня оно одно из самых универсальных - и полигон хорошо греет, и гребенку выводов эрзац-волной пропаять/отпаять можно, и отдельный вывод острым концом прогреть можно.
C другой стороны, имеющийся контроллер и отсутствие средств автоматической идентификации конкретного типа жала усложняет работу с T12. Ну что мешало Hakko засунуть какой-нибудь идентифицирующий резистор/диод/чип внутрь картриджа? Было бы идеально, если в контроллере имелось несколько слотов под индивидуальные настройки жал (хотя-бы штуки 4) и при смене жала он автоматом загружал нужные. А в существующей системе можно как максимум сделать ручной выбор жала. Прикидывая объем работ понимаешь, что овчинка не стоит выделки. Да и картриджи по стоимости соизмеримы с целой паяльной станцией (если не брать китай по $5). Да, разумеется можно экспериментально вывести таблицу поправок температур и приклеить табличку на крышку. Но с коэффициентами ПИД (от которых напрямую зависит стабильность) так не поступить. От жала к жалу они обязаны отличаться.
Если отбросить мысли-мечты, то выходит следующее:
1) Если паяльной станции нет, но хочется - лучше забыть про 900 и брать T12.
2) Если нужно дешево и точные режимы пайки не сильно нужны - лучше взять простой паяльник с регулировкой мощности.
3) Если паяльная станция на 900х уже есть, то достаточно T12-К - универсальность и портативность получилась на высоте.
Не Keil’ом единым…
Есть такая компания, называется она IAR Systems. Делает много вещей, в том числе и среды разработки и компиляторы для различных архитектур, список которых довольно обширен. Также в числе продуктов компании есть отладчики, наборы разработчиков и т.д. Более подробно со всем этим разнообразием можно ознакомиться на их родном сайте iar.com
Нас же сейчас интересует среда для разработки приложений для архитектуры ARM, в частности Cortex-M3. Есть в их ассортименте и такой продукт и называется он EWARM, что является сокращением от Embedded Workbench for ARM, что в свою очередь, в моем вольном переводе на великий и могучий, звучит примерно как «Среда разработки для встроенных систем на архитектуре ARM», впрочем, за точность я не ручаюсь…
Данная среда поддерживает большое количество микропроцессоров и микроконтроллеров построенных на базе архитектуры ARM разных версий. Полный список можно посмотреть на их сайте Т.к. это серьезная среда разработки, то она поддерживает различные отладочные интерфейсы и средства сопряжения как производства самой IAR так и сторонних компаний, имеет встроенный отладчик, симулятор и т.д.
Но по причине отсутствия у меня какого либо девайса для внутрисхемной отладки рассказать я про все это не могу. А пользоваться симулятором как-то в голову даже не приходило. Я по старинке, пишу, заливаю в контроллер и смотрю что происходит. (Зато их есть у меня. И я вам скоро выдам пример того, какой это рулез. прим. DI HALT)
Есть мнение, что компилятор С/С++ у IAR один из самых лучших, но за это я не ручаюсь, хотя кое какие мои сравнения с Keil uVision v3 показали его превосходство.
В общем, это мощнейшая полноценная среда для разработчика. Кому интересно, изучайте описания на официальном сайте Есть ли версия для линукса я на сайте нигде не углядел, поэтому точно не скажу. (Боюсь, что как всегда;) Впрочем, там есть могучий и универсальный GCC и обязательно есть поддержка ARM. Так что если есть желающие показать старт проекта под линухом — ждем с распростертыми обьятьями. Пишите на [email protected] прим. DI HALT)
На момент написания данной статьи доступна версия 6.10 (я же буду рассказывать на примере версии 5.4).
Сколько стоит данное чудо я, к сожалению, на их официальном сайте найти так и не смог, а лазить по сайтам дилеров как-то недосуг… На наше счастье, данный продукт доступен в демо режиме для ознакомления. (Я тоже полазил, не нашел. Кейл стоит около 3 килобаксов. IAR, думаю, в тех же пределах. Вполне подьемно для коммерческого применения прим. DI HALT)
И здесь есть 2 варианта
- 1. Полнофункциональная версия с ограничением использования в 30 дней.
- 2. Версия без ограничения по времени использования но генерирующая код не более 32Кб. Под наши ковыряния хватит с лихвой.
Обе версии, кроме того имеют следующие ограничения:
- Они не включают исходный код библиотек.
- Они не включают поддержку MISRA C (что это такое, к сожалению не знаю).
- Имеют ограниченную техническую поддержку.
- Версия с ограничением кода в 32Кб не имеет поддержки расширенной отладки (что это такое, к сожалению не знаю)
Ну и как всегда есть вариант найти на просторах сети дистрибутив включающий все, что нужно для снятия этих ограничений.
Итак, выбираем для себя вариант, который подойдет больше всего, скачиваем и устанавливаем. Здесь вопросов возникнуть не должно, все тривиально.
После установки можно приступать к созданию проекта. Запускаем IAR Embedded Workbench и видим следующее окно:
Project->Create New Project
Открывается окошко создания нового проекта.
На данном этапе можно выбрать из шаблонов, что именно мы хотим создать, но выбор там не велик, а все шаблоны содержат пустые заготовки файлов с нужным расширением и заголовками. Поэтому не ломаем голову а выбираем
Создался новый проект содержащий только один файл main.c который содержит только одну пустую функцию main(). А вы хотели большего? Дальше все ручками.
На данном этапе желательно нажать на кнопку с изображением трех дискеток или через меню
| File->Save All. |
File->Save All.
EWARM попросит ввести имя WorkSpace (воркспейс может содержать множество проектов) и не мудрствуя лукаво я назвал его также LEDTest.
В отличие от Keil’a EWARM не попросил указать целевое устройство и все остальное, поэтому лезем в свойства проекта и начинаем его настраивать.
По аналогии с Microsoft Visual Studio EWARM позволяет создавать произвольное число конфигураций и по умолчанию создает в проекте 2 конфигурации Debug и Release, что подразумевает 2 набора параметров, одни для компиляции кода содержащего отладочную информацию и другой для кода без нее. Выбираем наиболее подходящую для себя.
Я, например, сразу выставляю Release и настраиваю только ее, но это дело вкуса и наличия или отсутствия у вас средств отладки.
Итак, идем в меню
ST->ST STM32F10xxY
Где Y соответствует семейству имеющегося у вас микроконтроллера. Я выберу ST STM32F10xxE .
 |
Output (вывод)
Здесь указываем что мы хотим получить навыходе, исполняемую программу или библиотеку. Оставляем без изменения – Executable. Также здесь можно прописать пути куда ложить откомпилированную программу/библиотеку, объектные файлы и файлы листингов. Меняем, если душа того просит.
Library Configuration (конфигурация runtime библиотеки языка С). Это тема отдельной телепередачи:-) но сейчас можно смело поставить None и пройти дальше.
Library options (опции стандартной библиотеки языка С)
Здесь настраивается работа функций printf и scanf. Вернее поддержка различных ключей строки форматирования. Ниже кратко расписано какая опция что поддерживает, а более подробно можно прочитать в документации идущей в комплекте с EWARM. Поддержка более сложных ключей форматирования увеличивает размер кода т.к. обработчики строки форматирования разные по сложности реализации. В данном проекте нам это не важно т.к. данными функциями мы пользоваться не будем. А в последущием я освещу данный вопрос подробнее.
MISRA-C: 2004 и MISRA-C: 1998. Настройки расширений MISRA-C. Что это такое, я честно не знаю. :-)
C/C++ Compiler (настройки компилятора С/С++)
Здесь настраивается поддержка расширений языков С/С++, режимы оптимизации компилятора, генерация отладочной информации, пути к инклудам и т.д. Здесь пока можно ничего не трогать.
Assembler
Соответственно настройки языка ассемблера. Здесь пока можно ничего не трогать.
Output Converter (конвертация вывода)
Вот это нам нужно. Дело в том, что по умолчанию EWARM генерирует исполняемый файл в формате ELF, что какбы намекает, что Unix и прочие линуксы IAR’у не чужды.
Но нам то они ни к чему, поэтому смело тыкаем галку Generate additional output (генерировать дополнительный выходной файл) и в списке Output format (формат выходного файла) выбираем подходящий для себя, вернее для используемого вами программатора, формат.
Выбор особо не велик и реально для большинства будет состоять из двух вариантов: Intel extended, в простонародье именуемый HEX или binary. Я лично пользуюсь вариантом binary. Здесь же, если того требуют ваши религиозные убеждения, можно задать имя выходного файла отличающееся от дефолтного.
 |
Custom build (пользовательская сборка)
Здесь можно задать дополнительные утилиты и их параметры которые будут использоваться при сборке проекта, но нам это ни к чему — пропускаем.
Build Actions (действия при сборке)
Здесь можно указать команды которые нужно выполнить перед сборкой или после. Поступаем аналогично предыдущему пункту.
Категория Linker (линковщик)
Вот и добрались до второго, после указания целевого устройства, важного момента! Ибо от линковщика, вернее его настроек, очень сильно зависит запуститься ваш проект в микроконтроллере или нет т.к. именно линковщик располагает код и различные таблицы (например векторов прерываний) по нужным адресам.
Вкладка Config (конфигурация). Здесь содержится ссылка на используемый файл конфигурации линковщика. Это очень важный файл т.к. именно в нем прописана конфигурация нашего микропроцессора в части памяти (ее наличия или отсутствия, адресации и размера), размещения таблицы векторов прерываний, размеры стека и кучи. По умолчанию проставлена ссылка на файл конфигурации идущий в комплекте с EWARM’ом и едином для всех устройств на базе ядра Cortex, что не есть хорошо, т.к. устройства все разные, объемы флеша и ОЗУ у них разные и т.д. К счастью, есть возможность отредактировать этот файл самостоятельно, что дает широчайший простор творчеству, либо с использованием кнопки Edit… находящейся здесь же.
 |
Самостоятельная конфигурация файла настроек линковщика, занятие бесспорно увлекательное и плодотворное, но оно выходит далеко за рамки данной статьи т.к. только об этом можно написать не одну статью. Подробно все описано в руководстве пользователя, идущем в комплекте с EWARM. Скажу лишь, что там можно создавать сегменты памяти, указывать их тип, размер, размещение и еще много чего. Иногда это очень нужно, но это уже в более серьезных проектах.
Поэтому ограничимся нажатием кнопочки Edit… Правда перед этим нужно решить один концептуальный вопрос.
Дело в том, что как я уже сказал выше, данный файл является заготовкой для всей архитектуры Cortex, поэтому если вы его измените, а потом захотите создать проект для другого контроллера, того-же NXP LPC17XX, то его опять придется редактировать уже под этот процессор. Тут есть 3 варианта решения:
- Сказать себе, что кроме STM32F меня ничего не интересует и отредактировать данный файл.
- Скопировать данный файл в той-же папочке где он лежит (а лежит он, как можно догадаться, в папке диск:путь куда установили EWARM\arm\CONFIG\) во что-то типа STM32F10XXX.icf и редактировать его.
- Скопировать его в папочку с проектом переименовав во что-то типа STM32F10XXX.icf и редактировать его.
Итак, выбираем вариант себе по душе (я лично пользуюсь 3-им вариантом а путь прописываю так:
| $PROJ_DIR$\stm32f103re.icf |
$PROJ_DIR$\stm32f103re.icf
Переменная $PROJ_DIR$ разворачивается в путь до папки с проектом автоматически, т.е. путь получается относительным. Таким образом можно папку с проектами копировать потом куда угодно и файл не «потеряется» в отличие от использования жесткого пути), выбираем свой файл отредактировав путь или нажав кнопку выбора файла (кнопка с «…» справа от едита) и нажимаем кнопку Edit…
В появившемся окошке в первой вкладке Vector Table задаем адрес таблицы векторов прерываний. Что это такое, для тех кто не в курсе, я не буду раскрывать. (Я тоже не скажу:), т.к. все уже сказано в разделе про . Тут все точно также, только векторов больше. прим DI HALT)
Адрес может быть либо 0х00000000 либо 0х08000000. Я предпочитаю ставить 0х08000000 т.к. он указывает на начало внутренней флеш памяти, а адрес 0х00000000 может мэпиться на флешку а может и нет, в зависимости от состояния входов BOOT в момент инициализации контроллера, но это нужно уже курить даташит на устройство.
 |
Вкладка Memory Regions (регионы памяти).
Здесь задается 2 важных для работы контроллера вида памяти ROM (ПЗУ) и RAM (ОЗУ) вернее их адреса начала и окончания. ROM — это наша внутренняя флеш память. Начинается она с адреса 0х08000000, это заложено в архитектуре контроллера. А вот заканчивается у каждого по разному. Зависит от объема который есть в вашем контроллере.
У меня ее 512Кб, а у вас может быть 32, 64, 128, 256. Т.е. адрес окончания этой области памяти вычисляете сами. Для меня он будет равен 0x0807FFFF (адрес начала 0x08000000 + размер флеша (512*1024) – 1 в шестнадцатеричном формате). Для вас это может быть 0x08007FFF, 0x0800FFFF, 0x0801FFFF и т.д. Желательно указывать точный размер чтобы полученная прошивка не превысила этот размер, а так линковщик ругнется в случае чего. Но нам это не грозит пока. Аналогично заполняем поля для RAM, зная из чтения даташита, что она начинается с адреса 0x20000000 и посчитав где она закончится.
 |
Если ошибетесь в этих адресах, особенно начальных, например нолик пропустите или лишний напишите, то программа просто не будет работать.
Вкладка Stack/Heap Sizes (размеры стека и кучи)
Параметры говорящие сами за себя.
Стек нужен для передачи параметров функциям, сохранения точек возврата из них и т.д. Сильно большим его делать не имеет смысла т.к. зря будет расходоваться ОЗУ, а если сделать сильно маленьким, то может не хватить (особенно если будет использоваться много вложенных функций). Поставим его равным 0x200 т.е. 512 байт. В нашем проекте этого более чем достаточно.
Куча – это часть ОЗУ выделенная для функций работы с памятью языка С/С++ таких как malloc, оператор new и т.д. В данном проекте мы их использовать не планируем, поэтому ставим 0.
 |
Все, нажимаем кнопочку Save.
В остальных вкладках категории Linker настраиваются подключаемые внешние библиотеки, пути к ним, настройка имени выходного файла, настройки генерации листингов, расчета контрольных сумм и т.д. Нам в данном проекте ничего из этого не понадобиться, а объяснять все слишком долго. Будут конкретные вопросы — спрашивайте в комментах.
Категория Debuger (отладчик)
Здесь настраиваются аппаратные средства внутрисхемной отладки либо отладка в симуляторе. Как я уже говорил, аппаратных средств у меня нет, а симулятором я не пользуюсь. Поэтому рассказать тут особо ничего не могу.
С облегчением жмем кнопку Ок справа-внизу окошка, и применяем выбранные параметры.
Теперь можно смело нажать кнопку F7 или в меню
| Project->Make |
Project->Make
и откомпилировать наш проект.
В папочке которую вы указали для выходных файлов программы (если ничего не меняли, то это будет, в зависимости от выбранной конфигурации, папка Debug/exe либо Release/exe в папке с проектом) увидим 2 файла. Один с раширением.out и второй.bin или.hex, в зависимости от того, что вы указали в качестве дополнительного выходного файла.
Все, наша первая программа готова! Можно прошивать ее в контроллер и она заработает! Не верите? А вы попробуйте.
На этом позвольте закончить мою первую статью т.к. она и так получилась не маленькой. А к написанию более функционально насыщенной программы мы перейдем на следующем нашем шаге.
PS:
Хочу еще пару слов сказать о прошивке контроллера. Как я написал в эпиграфе, если ничего нет, но очень хочется… Если у вас нет аппаратного прошивальщика и/или отладчика, то это не большая проблема. Дело в том, что прошить контроллер STM32F можно с использованием обычного интерфейса USART, в простонародье это называется через COM порт. В идеале, если на плате с микроконтроллером распаян преобразователь уровней USART в TTL и заведен на порт USART1 контроллера (ножки PA.8 PA.9). Если нет, то тоже не большая беда. Можно немного распотрошить любой кабель-переходник USBCOM (в крайнем случае покупается в магазине), там внутри стоит микросхема с TTL уровнями, и пользоваться им подключаясь напрямую к ножкам контроллера. Про выставление уровней BOOT0/1 и как входить в режим бутлоадера можно узнать из даташита. А прошивать можно программой Flash Loader Demo производства самой ST Microelectronics. Я пользуюсь именно ей. Правда почему-то найти ее на сайте ST невозможно, поэтому прикладываю ее к своей статье, спасибо за нее нашим китайским братьям!
До того, как ARM купила компанию Keil , лучшими практически по всем показателям были компиляторы от IAR Systems . Сейчас ситуация выровнялась и по некоторым тестам компилятор от Keil даже превосходит компилятор от IAR. Но тем, кто привык работать в IAR нет большого смысла осваивать новую среду.
Миландр предоставляет файлы поддержки своих микроконтроллеров для среды IAR, но подключение этих библиотек не так очевидно, как в случае PACK для Keil. Эта статья будет посвящена тому, как начать работать с микроконтроллерами Миландр в среде IAR. Напишем обычный "HelloWorld", то есть помигаем светодиодами.
Создастся проект с пустой реализацией функции main. Откроем опции проекта и настроим его под конкретный микроконтроллер, выбираем пункт меню или жмем Alt+F7. Далее приведу только те опции, которые необходимо поменять, все остальное остается по умолчанию. По вкладкам:
General Options
Выбираем наш микроконтроллер, 1986ВЕ92У относится к группе 1986ВЕ9х.
Output Converter
Если будет необходим hex файл прошивки, то включить его создание можно в этой вкладке.
Linker
Здесь необходимо выбрать файл задающий раскладку памяти для МК. Этот файл MDR32F1.icf мы копировали ранее при установке SPL. Определение $TOOLKIT_DIR$ как раз содержит путь к директории установки, в которую мы копировали папки Milandr.
C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\arm\config\flashloader\Milandr\MDR1986VE9х\MDR32F1.icf
Области памяти можно скорректировать, нажав Edit, но тогда лучше сохранить измененную версию под новым именем, чтобы оставить рабочим исходный вариант.
Debugger
В закладке Setup необходимо выбрать наш отладчик, J-link уже присутствует в списке, выбираем его. Отладчика Ulink2 нет в списке, видимо необходимо ставить дополнительно. Кроме этого необходимо выбрать приведенные на картинке ниже файлы FlashMDR32F1x.mac и jbr_1986BE9x.ddf , которые мы так же копировали при установке SPL.
C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\arm\config\flashloader\Milandr\MDR1986VE9х\FlashMDR32F1x.mac
C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\arm\config\debugger\Milandr\MDR1986VE9х\jbr_1986BE9x.ddf
В следующей закладке Download выставляем опции "Verify download" и выбираем файл загрузчика FlashMDR32F1x.board , который загружает нашу программу в микроконтроллер. Это аналог flm файла в среде Keil.
C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\arm\config\flashloader\Milandr\MDR1986VE9x\FlashMDR32F1x.board
J-Link/J-Trace
В данном окне выставим опции аналогичные тем, что мы выставляем для данного отладчика в среде Keil. Укажем стартовую частоту микроконтроллера 8МГц и выставим Reset Pin. Далее можно выбрать использование Jtag или SWD, а так же увеличить скорость подключения, но мне сейчас это не критично, поэтому оставил по умолчанию.
После внесения изменений, да и вообще периодически, полезно нажимать кнопку Save All. При первом сохранении IAR предложит сохранить Workspace текущего проекта, сохраняем под таким же "HelloWord"-ом. При следующих запусках среды выбираем File - Recent Workspaces и IDE открывается в состоянии в котором мы ее оставили.
Организация папок проекта и SPL
При организации проекта я руководствовался данной статьей IAR EWARM. Создание проекта часть 2. CMSIS и Standard Peripherals Library.
Полагаясь на рекомендации статьи раскладывать исходники по папочкам, я завел группы аналогично тем, что создает Keil по умолчанию - Startup и Driver. Приведу сразу конечный вид дерева проекта и выпадающее меню, показывающее как создавать группу.
Согласно статье, я так же создал отдельную папку src и положил туда файл main.c. Для такого маленького и простого примера это не столь важно, но будем вырабатывать правильный стиль.
Теперь необходимо подключить сами библиотеки SPL позволяющие работать с периферией микроконтроллера. Во многих статьях в интернет необходимые файлы библиотек копируются в папку проекта на диске и затем подключаются в IAR. Мне такое решение не показалось удобным, поэтому я решил разместить библиотеку по стационарному адресу и подключать во всех проектах файлы из единого источника. Плюс данного решения в том, что при исправлении ошибки в общих исходниках, изменение проявится во всех связанных с библиотекой проектах. Потребуется только перекомпиляция. Если же в каждый проект копировать подборку необходимых исходников, то придется в каждый проект вносить исправления. Но тут каждый решает для себя как ему удобнее организовывать код. Зачастую изменение в общем коде, может затронуть уже старый, готовый и работающий проект. В таком случае, проект "ушедший в продакшн" лучше "заморозить" в текущем состоянии, собрав для него все исходники отдельно.
В итоге директории на диске я организовал следующим образом, есть одна общая папка IAR_CODE в которой лежит папка SPL и по папке для каждого микроконтроллера, внутри которых создаются отдельные проекты. Проекты используют исходники SPL, которые подключаются относительными путями от папки проекта. Использование абсолютных путей сделает проект непереносимым в другое место, поэтому пути лучше использовать относительные. При переносе или копировании проекта куда-то, необходимо будет скопировать проект и папку SPL, сохраняя их относительное расположение. Тогда проект будет успешно собираться из другого места.
Здесь приведены директории и файлы которые будут использоваться в нашем проекте.
IAR_CODE\ - Общая папка с проектами в IAR 1986VE9x\ - папка проектов под 1986VE9x MDR32F9Qx_board.h - файл выбора МК и ревизии HelloWorld - папка проекта SPL\ - папка SPL MDR32F9Qx_config.h - файл прочих настроек CMSIS\ CM3\ CoreSupport - поддержка ядра DeviceSupport\MDR32F9Qx\ - startup файлы inc startup\iar MDR32F9Qx_StdPeriph_Driver\ - driver файлы inc src
Чтобы получилась такая раскладка, вот что нужно скопировать из архива SPL:
В папку IAR_CODE\SPL: Исходные файлы SPL lib\MDR32F9_1986ВЕ4_2015\Libraries\все содержимое Файлы с настройкой SPL под конкретный микроконтроллер lib\MDR32F9_1986ВЕ4_2015\Config\MDR32F9Qx_config.h в папку IAR_CODE\1986BE9x: lib\MDR32F9_1986ВЕ4_2015\Examples\MDR1986VE9x\MDR32F9Q3_EVAL\MDR32F9Qx_board.h
В файле MDR32F9Qx_board.h осуществляется выбор микроконтроллера с помощью макроопределений, поэтому он лежит в папке с проектами под конкретный МК.
Файл MDR32F9Qx_config.h в архиве настроен для микроконтроллера 1986ВЕ4, необходимо открыть этот файл в Notepad и внести небольшую правку. Должно получиться так:
// !!! Раскомментировать блок: /* Seleсt the header file for target microcontroller */ #if defined (USE_MDR1986VE9x) #include "MDR32Fx.h" #elif defined (USE_MDR1986VE1T) #include "MDR1986VE1T.h" #elif defined (USE_MDR1986VE3) #include "MDR1986VE3.h" #elif defined (USE_MDR1986BE4) #include "MDR1986BE4.h" #endif //#include "MDR1986BE4.h" - ! Закомментировать строку, либо удалить.
Теперь чтобы среда IAR могла находить файлы SPL в нашей раскладке необходимо указать ей пути для поиска при сборке. В дереве проекта выбираем самый верхний пункт "HelloWorld - Debug" - просто кликаем на нем левой мышкой, чтобы он был активен и открываем опции проекта (Alt+F7). Если не выбрать верхний пункт проекта, а будет активен какой-то файл из групп в дереве проекта, то при нажатии Alt+F7 откроются опции для этой группы. Нам же необходимо указать пути для всех групп в проекте, поэтому выбираем самый верхний узел в дереве.
Заходим в категорию "С/С++ Compiler ", выбираем закладку Preprocessor . Здесь в поле "Additional include directories" необходимо добавить пути которые мы сформировали. Вот эти пути, добавляем их по одному c помощью диалога, вызываемого кнопкой с многоточием, либо можно скопировать пути прямо отсюда:
$PROJ_DIR$\..\..\SPL\CMSIS\CM3\CoreSupport $PROJ_DIR$\..\..\SPL\CMSIS\CM3\DeviceSupport\MDR32F9Qx\inc $PROJ_DIR$\..\..\SPL\CMSIS\CM3\DeviceSupport\MDR32F9Qx\startup\iar $PROJ_DIR$\..\..\SPL\MDR32F9Qx_StdPeriph_Driver\inc $PROJ_DIR$\..\..\SPL\MDR32F9Qx_StdPeriph_Driver\src $PROJ_DIR$\.. $PROJ_DIR$\..\..\SPL
Это и есть наши пути относительно папки проекта. При расположении прочих проектов по данной раскладке, эти пути останутся валидны.
При добавлении путей через диалоговое окно необходимо следующее, по картинке:
Пути хорошо бы добавить с относительным путем
При добавлении пути через диалоговое окно,
Видно, что пути получаются абсолютными.
Кликаем на кнопку с треугольником.
Выбираем вариант с путем относительно проекта.
Собираем пустой проект
Для компиляции минимального проекта к уже существующему файлу main.c необходимо подключить startup-файлы с таблицей векторов прерываний и т.д.
Перед подключением файлов в проект давайте заведем переменную в среде IAR, которая будет задавать путь к нашей папке с кодом IAR_CODE. В главном меню выбираем Tools - Configure Custom Argument Variables .
В открывшемся окне создаем группу MDR_Lib и переменную MDR_CODE, которая будет задавать путь к нашей головной папке.
Если проект не был сохранен, а при первом сохранении сохраняется Workspace, то кнопки в данной форме будут неактивны. В этом случае необходимо перед заходом в данную форму нажать Save All.
Теперь подключая файлы из нашей директории IAR_CODE, пути в проекте будут указываться относительно переменной $MDR_CODE$, следовательно при переносе проекта в другое место достаточно будет переназначить новый путь в переменной MDR_CODE.
Давайте теперь подключим файлы необходимые для компиляции пустого проекта. Для подключения файлов кликаем правой клавишей мыши на созданной нами группе Startup, выбираем Add - Add Files, и подключаем следующие файлы:
Добавляем файлы: IAR_CODE\SPL\CMSIS\CM3\DeviceSupport\MDR32F9Qx\startup\iar\ startup_MDR32F9Qx.s system_MDR32F9Qx.c system_MDR32F9Qx.h
Удобно выделить все файлы и добавить за один раз.
После этого проект должен собираться - меню Project - Rebuild All . Наблюдаем ошибок 0, на ворнинги не обращаем внимания. Библиотека не сильно подчищена для среды IAR.
Для проверки того, что файлы подключились через переменную $MDR_CODE$ кликнем правой клавишей мыши на заголовок в дереве проекта "HelloWorld - Debug" и выберем в выпадающем меню Open Containing Folder . Откроется окно проводника в Windows с выделенным файлом HelloWorld.ewp. Открываем его notepad-ом и листаем в самый низ, где находим как подключены наши, только что добавленные файлы:
....
Видно, что пути указаны через переменную $MDR_CODE$. Надеюсь данный подход поможет при необходимости перенести весь репозитарий с проектами, то-есть папку IAR_CODE, в новое расположение или на другой компьютер с минимальными усилиями.
Собираем "HelloWorld"
Скопируем в наш файл main.c код из проекта Hello World - светодиод . В этом коде используются библиотечные файлы управления портами и тактовой частотой. Давайте их так же добавим в проект.
Добавляем файлы: IAR_CODE\SPL\MDR32F9Qx_StdPeriph_Driver\src\ MDR32F9Qx_port.c MDR32F9Qx_rst_clk.c
Подключать *.h файлы не будем, пути у нас прописаны и они найдутся сами. Компилируем проект через кнопку в меню или F7. Проект должен успешно скомпилироваться.
Для того, чтобы прошить получившуюся программу в микроконтроллер выбираем в меню Project - Download - Download active application . В Debug Log окне выскакивают некоторые "ворнинги", но прошивка заканчивается успешно и микроконтроллер приветствует Мир!
В случае использования программаторов Segger, при загрузке в устройство подключенное впервые, драйвера Segger запрашивают какое ядро Cortex подключено.
Выбор должен быть таким:
1986ВЕ9х - "Unspecified Cortex-M3" .
1986ВЕ1Т, 1986ВЕ3Т - "Unspecified Cortex-M1" ,
1986ВЕ4У - "Unspecified Cortex-M0"
SPL и пример на GitHUB
Данный пример мигания светодиодом можно скачать с GitHub - IAR_CODE , так же как и аналогичные реализации для 1986ВЕ1Т и 1986ВЕ3Т. В репозитории содержится библиотека SPL на которой реализованы примеры. Эта библиотека собрана из официальной версии, были лишь вырезаны файлы не относящиеся к IAR и исправлены некоторые ошибки.
Запускаем IAR AVR. Откроется окно Embedded Workbench Startup, можно создать проект ипользуя его, но мы пойдем другим путем, поэтому жмем Cancel. Окно закроется и перед нами во всей своей невзрачной красе предстанет IAR.
Выбираем в верхнем меню Project > Create New Project…
IAR предложит выбрать тип шаблона проекта (Project templates). Выбираем C > main и кликаем Ок.
В стандартном Save As диалоге находим или создаем папку и сохраняем проект. Проект готов. Приглядимся к IARу.
Верхняя строка – почти стандартный menu bar. Ниже - tool bar с кнопками.
С правой стороны находится редактор кода. Сейчас там открыт файл main.c, но в нем только пустая функция main().
С левой стороны расположено окно рабочего пространства (workspace), в котором отображается структура проекта. Любой IARовский проект должн находиться по-крайней мере в одном рабочем пространстве.
В верхней части рабочего пространства находится выпадающее меню. Это так называемые конфигурации проекта. По умолчанию их две – Debug и Release. Они отличаются между собой настройками проекта. Можно создавать свои конфигурации.
Сохраним рабочее пространство. Если не сделаем сейчас, придется делать это на этапе компиляции. Выбираем в меню File > Save Workspace
Зададим настройки проекта для конфигурации Debug. Выбираем в меню Project > Options
Или кликаем правой кнопкой мышки по галочке напротив названия проекта.
Откроется диалоговое окно с множеством настроек.
Выбираем тип микроконтроллера
General Options > Target > Processor configuration
У меня это ATmega8535.
В General Options > System ставим галочку Enable bit definitions in I/O-Include files
Хоть нам и не понадобится сейчас эта настройка, полезно знать где она находится.
Включаем генерацию ассемблерного листинга
. Необязательная опция, но я обычно включаю, чтобы посмотреть что натворил компилер.
С/С++ Compiler > List > галочка Output List File
Linker > Output.
B поле Output file cтавим галочку Override default и заменяем расширение d90 на hex
В поле Format выбираем Other и в выпадающем меню Output format выбираем тип файла intel-standart
Жмем ОК.
Теперь копируем и вставляем текст нашей программы в main.c
#include
#include
int
main(void
)
{
unsigned char
led = 1;
DDRC = 255;
while
(1)
{
PORTC = ~led;
__delay_cycles
(400000);
led = led<<1;
if
(led == 0)
led = 1;
}
return
0;
}
Кликаем кнопку Make.
Если все сделано правильно, IAR откомпилирует и соберет проект, а внизу откроется окно Messages.
На днях произошла ужасная вещь - на клавиатуру ноутбука вылилось небольшое, но достаточное для глюков количество воды. Хорошо, что вода оказалось чистой, и особенно то, что в Красноярске вода содержит мало примесей (за несколько лет в чайнике нет ни капли накипи). Что нужно делать, если что-то подобное случилось с Вами: Быстро перевернуть ноутбук, позволить жидкости вытечь из клавиатуры (при этом стоит следить, чтобы жидкость в этот момент не стекала на матрицу.Вытереть тряпкой остатки воды(спорный пункт!) Я взял баллон со сжатым воздухом и продул под всеми клавишами, при этом вылетело много жидкости. Возможно, таким образом можно лишь усугубить ситуацию, загнав жидкость потоком воздуха куда не следует.Теперь нужно разобрать ноутбук и просушить клавиатуру. Других вариантов нет. Имейте ввиду, что если Вы конкретно залили клавиатуру, то можете попрощаться с ноутбуком и вот почему: Клавиатур пока нет ни в России, ни в Китае! Я обзвонил много сервисных центров, и даже общался с л…
Мало кто знает, а в особенности те, кто только начинает изучать микроконтроллеры STM32, что их можно запрограммировать не имея специального программатора. Необходимо лишь выбрать режим загрузки контроллера через встроенный загрузчик, подключитьcя через UART и записать необходимый код. Теперь обо всем подробнее. Большая часть контроллеров STM32 имеет встроенный (нестираемый) загрузчик в специальной области памяти, который работает по протоколам UART, SPI, I2C и CAN. Конечно же проще всего работать через UART, т.к. он есть почти у каждого, кто имеет дела с электроникой, поэтому его и будем рассматривать. Выбор области памяти, из которой осуществляется загрузка контроллера осуществляется подачей низкого или высокого уровня на ножки BOOTx (может быть как одна, так и несколько). Подробнее о том, как выбрать загрузчик на конкретном контроллере указано в AN2606. Так же в AN2606 указано, какой интерфейс контроллера можно использовать для программирования. Еще, чтобы записать код в к…
У контроллеров STM32, в большинстве своем, отсутствует как таковой буфер приемника UART. Исходя из этой особенности, приходится создавать кольцевой буфер и использовать прерывания. При низкой тактовой частоте ядра и высоких скоростях UART это оказывается очень накладно как по производительности, так и по энергопотреблению.
Всего этого можно избежать при помощи DMA, но как? Ведь при настройке DMA указывается фиксированный размер буфера, в который копируются принятые данные. К тому же у DMA есть прерывания только при полном и половинном заполнении буфера. Фактически, если вы уверены, что длина принимаемых данных не превысит длину буфера, прерывания от DMA можно не использовать вовсе. А обойтись только прерыванием IDLE от UART.
Флаг прерывания IDLE в интерфейсе UART выставляется в случае, если после стоп-бита последнего переданного символа на линии RX нет данных в течении времени приема одного символа. Флаг IDLE сбрасывается программно.
