Изучение модуля USI MSP430 странным образом(на самом деле закономерным) вывела меня на такую штуку, как сдвиговый регистр. Имея о них лишь общее представление, мне пришлось срочно разбираться c этой, довольно обширной темой. Итак.
Сдвиговый регистр, он же расширитель портов, он же шинный преобразователь, преобразует сигнал последовательной шины в параллельный или/и обратно.
В рамках этой статью я рассмотрю работу с популярным 8-и битовыми сдвиговым регистром на SPI интерфейсе 74HC595.
В качестве практических примеров, я рассмотрю подключение светодиодной гирлянды, семисегментных индикаторов и дисплея с параллельной шиной HD44780.
В качестве микроконтроллера я буду использовать ATmega8, а в качестве среды моделирования Proteus 8.5.
Кроме этого, я затрону организацию SPI интерфейса у ATmega8.
В завершении прошлой статьи я приводил ссылку для проверки I2C модуля RTC DS3231. Для этого не надо устанавливать никакие библиотеки, достаточно скопировать текст программы в Arduino IDE и кликнуть на загрузку скетча в микроконтроллер. Это одинаково работает как в Arduino IDE, так и в MSP430 Energia и STM32duino.
Однако, больше чем для проверки этот пример не годится, и рано или поздно перед каждым встает вопрос написания своей библиотеки для полноценной работы с RTC. Отчет времени, с календарем или без, довольно распространенная штука, и этот код вы скорее всего будете тащить из проекта в проект. Т.е. это вещь которую проще один раз хорошо сделать, что бы потом к этому не возвращаться.
Сам я уже прошел по этому пути, но т.к. написанный код уже не умещался под спойлерами, поэтому пришлось написать полноценную Arduino - библиотеку. В заключение будет несколько примеров с использованием этой библиотеки, с тем, как на мой взгляд нужно правильно работать с DS1307/DS3231.
Но прежде чем "городить огород", предлагаю взглянуть на готовые решения, одобренные "патриархами" arduino.cc, а именно: библиотеки Time, DS1307RTC, а также DS3232RTC которая работает совместно с библиотекой Time.
Вроде бы немного, и вроде бы несложно.
Весь код я буду тестировать на Arduino Nano, MSP430 Launchpad - Energia и на STM32duino - Blue Pill.
Общая концепция библиотек для работы со временем такая. Имеется базовая библиотека TIME которая ведет через функцию millis() расчет времени при запросе такого через функции библиотеки hour(), minute(), second() и т.д. Библиотека абстрагируется от аппаратной части того или иного хронометра. Она рассчитана на ведение календаря и отчет времени средствами самого микроконтроллера, без подключения RTC. Соответственно библиотеки DS3232RTC и DS1307RTC добавляют функции синхронизации микроконтроллера с RTC.
Содержание:
Я все-таки не удержался, и приобрел MSP430 LaunchPad. Это может показаться довольно странным решением, учитывая, что для прошивки чипов я активно использовал BSL, и вроде как LaunchPad был не очень-то необходим.
Кроме того, LaunchPad уже лет пять стоит в несколько раз больше чем 4.3USD да и цена за доставку может неприятно удивить.
Ok, мои аргументы:
Несмотря на то, что далее речь пойдет преимущественно о работе в среде Linux, к Windows все описанное тоже будет применимо, при условии использования Energia в версии для Windows и чего-то вроде CYGWIN. Для программирования MSP430 в Windows имеются следующие IDE: 1) Code Composer Studio aka CCStudio; 2) IAR Workbench for MSP430. На первый я даже смотреть не стал, т.к. это Eclipse который все ненавидят, а второй отказался работать с LaunchPad'ом. Нет там поддержки MSP430UIF оказывается.
Часто можно встретить комментарии, что MSP430 чипы бедны на периферию. Мощные чипы конечно у TI конечно же есть, но здесь в цене начинает сильно выигрывать продукция фирмы STM. Однако STM не делает чипы в DIP корпусе, и STM8 не имеет поддержки в Linux, поэтому "младшие" MPS430 для замены ATtiny13/ATtiny2313 мне кажутся наиболее интересными. Кроме того они более "прокачены" чем ATtiny. Например MSP430F2002 имеет на борту аппаратный SPI и I2C, а MSP430F2003 имеет 16-битный сигма-дельта АЦП(!). Такого вообще нет ни у AVR ни у STM.
Ок, пора за дело.
Содержание:
Полтора года назад я уже бегло рассматривал протокол I2C, теперь же настало время изучить его более подробно.
Попробуем написать программную реализацию протокола, рассмотрим "подводные камни" такой реализации, а также способы отладки шины I2C. Для обкатки алгоритма попробуем подключить следующие устройства на шине I2C: RTC DS1307/DS3231 и EEPROM AT24C512/AT24C32.
Для проектирования будет использована CAD Proteus_8.5. Для проверки на реальном железе будет использован чип MSP430G2453.
Итак, тренироваться будем на RTC DS1307, но здесь должен заметить, что данный чип относиться к 5-вольтовой логике поэтому с 3.3-вольтовым MSP430 он работать не будет. Заставить работать данную связку можно только в Proteus. Для тестирования на реальном железе я буду использовать DS3231 модуль. Однако для того чтобы понять I2C не нужен готовый модуль, он будет только мешать.
Когда не очень опытный радиолюбитель берет устройство на I2C, ему надо его как-то проверить, убедиться что оно хотя бы в принципе работает. Как это сделать? Обычно делается это на Arduino (я по крайней мере так делаю). Находится какой-нибудь скетч для проверки, и на нем проверяется.
Однако, при наличии проблем, как узнать в чем кроется загвоздка: в "косячной" библиотеке или в железке? Например, если мы загрузим этот скетч для работы с DS1307, и запустим его БЕЗ всякого модуля, то получим такую картинку:
Как видно, мы получили какие-то непонятные значения и если бы сбойная микросхема RTC была бы подключена, нам оставалось бы только гадать, где скрывается проблема: в коде или в железке.
И здесь проблема здесь не в низком качестве кода скетча. Если посмотрим API References:
Немного максималистическая попытка сделать статью в стиле "все-в-одном", а именно: разобрать базовую периферию MSP430 и заодно использовать эту тему как ознакомительную для Proteus.
К сожалению, как выяснилось, в Proteus симуляция MSP430 не совсем полная, поэтому реального микроконтроллера Proteus заменить конечно не сможет. Однако, с некоторыми оговорками это все-таки замечательная платформа для отладки схем и различных алгоритмов. Ниже будет наглядно показано как отладить работу программного UART передатчика с помощью Proteus.
Я начинал статью с Proteus_8.3, а заканчивал ее под Proteus_8.5. И там и там имеются неточности если сравнивать с работой реального чипа, не следует забывать, что это всего лишь модель. И все-таки я бы посоветовал использовать версию 8.5 по той причине что там более-менее корректно работает таймер. У меня были сложности большими частотами, но возможно сказалось ограничение по производительности виртуальной машины.
Честно говоря, я не слишком расписывал темы: что такое Proteus, зачем он нужен, как его устанавливать и что значат все эти кнопочки. Подобных руководств достаточное количество на YouTube.
В качестве примера рассматривается чип MSP430G2453 в 28-пиновом корпусе. Но весь материал можно экстраполировать на всю линейку MSP430x2xx.
Как всем известно, с марта этого года компилятор COSMIC for STM8 стал полностью бесплатен и без ограничений на размер генерируемого кода. Он имеет полную поддержку SPL(Standard Peripheral Library) и фирменой среды разработки - STVD(ST Visual develop IDE).
К сожалению, Cosmic работает только под операционными системами Windows, и для активации требует лецензионный ключ который можно прождать несколько дней. С другой стороны, stm8flash в Linux не умеет прошивать STM8L151C8, а с COSMIC через виртуалку вполне можно работать, да из под Wine он тоже запускается.
Ок, для начала нам потребуется скачать SPL и STVD c сайта https://my.st.com, а с сайта http://www.cosmic-software.com/download.php сам компилятор COSMIC. Как скачать SPL я рассматривал год назад в Введение в STM8: программирование и прошивка с помощью клона ST-Link v2, версия для Linux, а связку STVP+STVD весной в STM8 + IAR + ST-LINK2: программирование, прошивка и отладка из под Windows. Однако с тех многие ссылки побились, поэтому предлагаю пройти квест заново. Потому что поиск чего-то на st.com, действительно напоминает дурной квест.
В качестве целевого чипа я буду использовать STM8S103F3P6, изредка переключаясь на STM8L051/STM8L151 там, где есть необходимость.
Чип MSP430g2453IPW28 распаяный на адаптере TSSOP28-DIP28
Чипы AVR заслужили хорошую репутацию отчасти тем, что содержат АЦП даже в самых младших моделях микроконтроллеров. Аббревиатура MSP430 не случайно ассоциируется с DSP, данные чипы при вполне разумной стоимости могут нести в себе 16-битные или даже 24-битные сигма-дельта АЦП, а также есть целая линейка CC430 микроконтроллеров c радиомодулем(!) на борту. MSP430 (расшифровывается как Mixed Signal Processor) имеет 16-битную архитектуру что позволяет обрабатывать данные с АЦП за один прием, не обрезая их до 8-бит как на AVR. Данные микроконтроллеры изначально разрабатывались как малопотребляющие. Причем настолько малопотребляющие, что ввелась новая концепция устройств с одной батарей для всего жизненного цикла устройства. Семейства MSP430x5xx и MSP430x6xx включают в себя модуль DMA. Одним словом, это еще одна достойная замена устаревающим AVR.
Сейчас, когда у меня скопилось несколько микроконтроллеров различного типа, настало время разобраться с их энергопотреблением, чтобы не полагаясь на рекламные лозунги различных компаний, понять, что есть что в мире автономного питания.
Первым делом мой взгляд упал на ATtiny13A. Небольшая микросхема, если логически подумать, должна потреблять минимум энергии. На практике однако, это зависит от используемого техпроцесса при изготовлении этой микросхемы.
Справедливости ради стоит заметить, что ATtiny13 с пониженным энергопотреблением имеют индекс V. А чипы с технологией picoPower, снабжаются индексом P. Что же до ATtiny13A, согласно документации, его потребление в обычном режиме, при питании 1.8V и частоте 1МГц - 160 микро ампер. В Idle режиме при тех же условиях - 24 микро ампер. Питание 1.8В я не собираюсь использовать, меня больше интересует потребление при 3.3В.
Мой мультиметр фирмы Mastech, модель: M830BZ. Это не весть что, но если измерять потребление различных чипов одним прибором, выводы сделать можно будет.
Для работы с режимами энергосбережения в avr-gcc есть библиотека avr/sleep.h. Переводной мануал по данной библиотеке можно почитать здесь. Я же пойду по традиционному пути ковыряния регистров.
В качестве исходного примера возьмем blink из старого поста:
Симулятор роботов позволит проверить математическую модель и алгоритм перед тем как приступать к изготовлению робота. V-REP компании Coppelia Robotics - один из самых совершенных симуляторов в настоящее время. Программный комплекс является кроссплатформенным и бесплатным для использования в образовательных целях. Симулятор состоит из физического и графического движка, что позволяет достаточно комфортно работать с программой.
На скорую руку я отметил важнейшие элементы в интерфейсе V-REP:
Обычно, чем больше размер программы, тем чаще приходится пользоваться отладчиком. В AVR Studio встроен замечательный эмулятор микроконтроллеров, на котором можно проверить работоспособность прошивки, и можно порадоваться за Windows пользователей, но что делать пользователям Linux?
В Linux в качестве эмулятора может выступить SimulAVR, а отладчиком avr-gdb. Собственно, работе с этим отладчиком и посвящен этот пост, потому-что им же производится отладка по JTAG. Но, пока я JTAG не разжился, придется пользоваться эмулятором. SimulAVR поддерживает небольшой набор микроконтроллеров и к том уже не всю периферию он эмулирует, но таймеры и порты преимущественно работают.
Supported devices: at90can128 at90can32 at90can64 at90s4433 at90s8515 atmega128 atmega1284 atmega1284a atmega16 atmega164 atmega164a atmega168 atmega32 atmega324 atmega324a atmega328 atmega48 atmega644 atmega644a atmega8 atmega88 attiny2313 attiny25 attiny45 attiny85
К сожалению XMega не поддерживается ;) поэтому тренироваться будем на ATmega8. Для работы с отладчиком нужно будет скомпилировать прошивку с опцией -ggdb и убрать оптимизацию кода опцией -O0.
SimulAVR и AVR-GDB работают по клиент-серверной архитектуре. Первый выступает в роли сервера, второй в роли клиента.
Для отладки возьмем такой пример: