В этот раз разговор пойдёт про аппаратные интерфейсы STM8S: UART, АЦП и I2C. Каждый их этих интерфейсов поддерживает несколько режимов работы, но сейчас мне хотелось бы сфокусироваться на наиболее типовых, на мой взгляд, примерах их использования: а)организация передатчика на UART, б) режим однократного замера АЦП, в) использование I2C в режиме мастера. Напомню, что вариант использования SPI в режиме мастера я приводил на примере драйвера для 4-x разрядного семисегментного индикатора .
Документация которая понадобится для прочтения статьи: Reference Manual STM8S - RM0016, главы: 22 (UART), 24 (АЦП), 21 (I2C). В качестве целевого микроконтроллера я буду использовать 20-пиновый STM8S103F3P6.
Так же как и в прошлый раз, упор будет делаться на "чистом" программировании на Си и Ассемблере без использования сторонних библиотек. В качестве компилятора используется open-source SDCC версии 3.7. Справедливости ради замечу, что я ввёл макросы для прямого доступа к битовым инструкциям, что бы хоть как-то оптимизировать код.
Скачать полные исходники со сборочными файлам и скомпилированными прошивками, можно по ссылке в конце статьи.
В статье используются формулы в формате MathML который поддерживается браузером Firefox, для браузеров Chrome и Opera потребуется установить одноимённое расширение MathML.
Примечание от 01.09.2022г. В SDCC версии 4.2 поменялся формат передачи аргументов функций. Если раньше все аргументы передавались через стек, то теперь они передаются через регистры. Поэтому для совместимости со старым кодом следует добавлять опцию компиляции "--sdcccall 0".
Если под вашу задачу требуется большее число пинов/портов/мегагерц/памяти, чем имеется в используемом вами микроконтроллере, то в ответ на эту проблему обычно советуют взять микроконтроллер "покрупнее". Ответ не лишенный смысла, однако мне удалось найти задачку, от которой так просто не отмахнешься. Героем сегодняшней статьи будет 4-х разрядный семисегментный индикатор с динамической индикацией.
Я уже упоминал о нем в статье про сдвиговые регистры, но тогда у меня не было на руках самой железки, и соответственно говорил я лишь теоретически. Сами ардуинщики об индикаторе отзываются не очень лестно, т.к. применение этого индикатора ограниченное из-за того, что вследствие динамической индикации его нужно постоянно обновлять, что накладывает серьезное ограничение на основную программу. Теоретически эту задачу можно было бы "скинуть" в прерывание таймера, но решение это спорное.
В модуле меня привлекла его компактность. К примеру, для приборной панели паяльной станции, где место сильно ограничено, это то что надо. После некоторого размышления я решил, что в целом модуль неплох, но... для него требуется отдельный управляющий микроконтроллер, сопроцессор, на котором будет крутиться динамическая индикация.
Индикатор не содержит подтягивающих резисторов(!), возможно здесь используются сдвиговые регистры с подтяжкой? Так или иначе, я замерял потребление модуля через EnargyTrace и получил значение около 23mA при питании 3.3 Вольт, что для такой "гирлянды" вполне нормально.
Китайские ATtiny13a в SO-8 корпусе стоят около 15₽, они имеют пять рабочих выводов, три из которых нужно будет отдать на индикатор, остаются два вывода для организации линии связи, что более чем достаточно, но простенький SPI сюда не посадишь, т.к. тот SPI который будет использоваться для управления индикатором, работает мастером, а для связи с "главным" микроконтроллером нужен будет слейв( запускать слейв на главном микроконтроллере - это не вариант). К сожалению или к счастью(смотря как посмотреть), АTtiny13a не поддерживает аппаратно абсолютно никаких протоколов.
Т.о. перед нами стоит задача на ATtiny13a организовать c использованием не более двух пинов скоростную и надежную линию для приема двухбайтного числа от главного микроконтроллера, и отобразить его на 4-х разрядном семисегментном индикаторе. В идеале было бы использование аппаратного протокола главным микроконтроллером и его программной реализации на ATtiny13a. Также хотелось бы, что чтобы код реализации протоколов занимал минимально возможное место на флеше, чтобы его потом можно было использовать в других более сложных проектах.
Т.к. подразумевается использование индикатора для отображения температуры паяльника, во всех примерах будут задействованы только три разряда индикатора.
Полные исходники вместе со сборочными файлами и скомпилированными прошивками можно скачать по ссылке к конце статьи.
USI модуль в MSP430x2xx описывается как простое устройство основанное на управляемом сдвиговом регистре. Однако простота этого модуля оборачивается сложностью в его использовании. То, что в полноценном I2C модуле будет "спрятано под капотом" в виде незримой автоматики, здесь придется делать вручную.
В официальной библиотеке Texas Instruments для использования USI модуля в I2C режиме: slaa368.zip и документации к ней: slaa368.pdf алгоритм работы с USI представлен как конечный автомат. Мне показалось это интересным и я решил разобрать его работу в этой статье. Сама библиотека написана на ассемблере для IAR компилятора, и в так виде лично для меня она была бесполезна. Поэтому в процессе изучения библиотеки я портировал ее на mspgcc, правда не всю, а только работу в режиме мастера.
Статью условно можно разделить на три части. Вначале идет программная реализация I2C для MSP430, которая в дальнейшем будет использоваться как эталонная, т.е. с ней будут сравниваться остальные варианты. Затем будет рассмотрена аппаратная реализация I2C для USI MSP430, и закончим мы конечным автоматом(Finite-State Machine). В итоге у нас будет три драйвера I2C шины: один программный и два аппаратных.
В качестве микроконтроллера я буду использовать MSP430G2452 который шел в комплекте c MSP-EXP430G2 Launchpad. Данный микроконтроллер имеет два порта GPIO, один "А"-таймер, один USI-модуль, 8Кб флеш-памяти и 128 байт оперативной памяти. Т.е. это что-то вроде ATtiny84 по возможностям. Для обкатки драйверов I2C шины, в качестве целевого устройства я буду использовать RTC DS3231, для которого я портировал на Си свою Arduino-библиотеку DS3231SQW.
Так как программного кода в статье много, полные исходники и скомпилированные прошивки я выложил на gitlab.com https://gitlab.com/flank1er/msp430_usi_i2c
Для простоты будем считать, что вы работаете в Linux или в CYGWIN под Windows, используете компилятор mspgcc из комплекта Energia IDE, а в качестве программатора используется MSP-EXP430G2 Launchpad.
Статья правилась 5-го августа 2022г. Было испрвлено неверное определение: "сдвиговый регистр pcf8574" на правильное: "расширитель портов pcf8574". Добавлено оглавление. Также поправлена битая ссылка на datasheet.
Этот расширитель портов наиболее известен по китайским драйверам дисплея HD44780, которые можно приобрести на али или ибэе. Он довольно подробно был разобран здесь: "Сообщество EasyElectronics.ru: I2C расширитель портов PCF8574". Я в свою очередь, попытаюсь сосредоточиться на программировании микроконтроллера ATmega8 для работы с этим регистром. Впрочем, начну я все же с Arduino и имеющегося у меня зоопарка: ATmega328/MSP430G2553/STM32F103C8.
Расширитель портов PCF8574 может выпускаться разными фирмами, мне попались чипы с суффиксом "T", что обозначает производителя как "NXP Semiconductor". Руководство на pcf8574t можно скачать с официального сайта NXP: "PCF8574; PCF8574A Remote 8-bit I/O expander for I2C-bus with interrupt".
Содержание:
I. Общие сведения
II. Работа PCF8574 + ATmega8
Полтора года назад я уже бегло рассматривал протокол 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:
После UART, реализация TWI модуля на AVR кажется довольно корявой и без понимания I2C протокола будет не просто его освоить. Однако, если разобраться с "софтовой" эмуляцией протокола, то работа с TWI модулем уже не составит труда.
Не последне место в этом списке должно быть у официального аппнота: AVR315: Using the TWI module as I2C master
Если открыть руководство для ATmega8, на странице 156 раздел "Two-Wire Serial Interface", то там даже будет примерный набросок программы для работы с TWI:
bit-banging - это тоже, что
дерганье за ниточки
Используя познания из предыдущего поста: "Введение в Bit-banging: "режимы работы GPIO микроконтроллеров AVR, организация последовательной шины" можно сделать что нибудь полезное. "Софтовая" реализация I2C шины будет не зависеть от модели микроконтроллера, будет работать на тех пинах которые вы зададите, и на мой взгляд, что самое важное, может служить примером протокола для взаимодействия между несколькими различными микроконтроллерами.
Иллюстрация I2C протокола, взятая из AppNoteAVR315: Using the TWI module as I2C master представлена ниже:
pull-up c английского
переводится как подтягивание
Когда речь шла об управлении дисплеем HD44780, то там все было относительно ясно. Напрямую соединялось два устройства, одно работало только на прием, другое только на передачу. Поэтому достаточно было выставить нужный логический уровень на выводах GPIO микроконтроллера, чтобы все работало.
Несколько сложнее обстоят дела, когда нужно организовать обмен данными между несколькими устройствами. Выводы устройств имеют два состояния: логичская единица т.е. +5 или +3 Вольта и логический ноль, когда контакт соединен с "землей". Если начать соединять их напрямую, то произойдет короткое замыкание. Bit-banging это та тема, где нужно четко представлять, что происходит.
На основе этих трех состояний можно постоить последовательную шину вида: