Золотовский Д.В. Учебный курс для новичков по микроконтроллерам AVR. Часть 1

Подождите немного. Документ загружается.

}

while (!(USISR&(1<<USIOIF))); // повторяем предыдущие

операции до переполнения счетчика

dummyloop(USI_DELAY); // тупим в цикле

tmp_sr=USIDR; // сохраняем принятые данные

USIDR=0xff; // освобождаем линию sda

sbi(sdaportd,sda); //ВАЖНО!!! восстанавливаем

подключение SDA к выходному буферу интерфейса

return (tmp_sr); // Возвращаем принятые данные

}

Данная процедура сдернута мной с апнота и почти без изменений.

Примечательна она тем, что осуществляет как чтение так и передачу данных.

Работает она так:

ВАЖНО!

Данная процедура предполагает, что регистр USIDR уже загружен нужными

данными для передачи!

Мы получаем от программы значение регистра USISR, с предустановленным

счетчиком. Так как наш минимальный пакет данных составляет 8 бит данных

в одну сторону и 1 бит в противоположную (смотрите логику работы TWI-

интерфейса), то мы должны послать ведомому 8 бит и принять один (или же

принять 8 бит послать один если передача идет в другую сторону).

Раз у нас есть аппаратный счетчик, да еще и с флагами, значит не надо

городить кучу переменных в циклах и их проверки. Достаточно

предустановить счетчик и гонять цикл до его переполнения.

Именно для этого мы определили константы USISR_8BIT и USISR_1BIT,

которые задают значения счетчика для обработки 8бит данных и 1 бита

данных, а заодно еще и сбрасывали ненужные и нужные флаги состояния.

Далее мы:

•

Толкаем в бит USITC единичку, линия scl начинает менять свое

состояние из 0 в 1, счетчик тикает увеличиваясь на 1 и приемник

считывает первый переданный нами бит.

•

Проверяем свободна-ли линия — если ведомое ведомое устройство не

успевает — оно прижмет SCL в 0. В принципе это должно работает, но

могут возникнуть вилы. У меня не было возможности расковырять

данный момент досконально, а ведомый вроде всегда успевал.

•

Делаем задержку.

•

Еще раз толкаем в бит USITC единичку. Линия SCL при этом у нас

возвращается в 0, регистр USIDR сдвигается на один бит, выпинывая в

линию SDA новое значение, а счетчик увеличивается еще на 1.

Таким образом, мы на один проход цикла получаем полный такт передачи 1

бита по шине. Счетчик при этом тикает 2 раза на один проход.

•

Повторяем все до переполнения.

•

Делаем задержку.

•

Cохраняем полученные данные.

•

Возвращаем линию sda в нормальное состояние (1), для чего

запинываем в USIDR любое значение с установленным 7мым битом.

•

Восстанавливаем подключение линии SDA к выходному драйверу.

Дело в том, что при передачи данных от мастера к ведомому драйвер у

нас всегда подключен, чтобы линия SDA всегда соответствовала

значению 7го бита USIDR, а если мы принимаем данные от ведомого,

то линия SDA должна быть сконфигурирована как вход. Если этого не

сделать — то у меня мастер не мог получить бит подтверждения и

другие данные от ведомого. За направлением приема-передачи следит

процедура, отвечающая за протокол обмена, а в нашей процедуре мы

просто восстанавливаем подключение, если оно было сброшено.

Это была процедура непосредственно обмена по интерфейсу, а теперь

рассмотрим 2 процедуры более высокого уровня, которые уже реализуют

часть протокола обмена данными:

Передача N-ного количества байт от мастера к ведомому

u08 i2c_master_send(u08 *data, u08 data_size)

{

if (bit_is_set(sclportinp,scl)) return(1); // проверка, если старт

не прошел — выход с состоянием (1)

{

USIDR=(*(data++)); // загружаем

очередной байт данных

usi_i2c_master_transfer(USISR_8BIT); // посылаем 8

бит

cbi(sdaportd,sda); // переклюаемся

на прием

if ((usi_i2c_master_transfer(USISR_1BIT))&0x01) return(2); // если нет

подтверждения - выход (2)

data_size--; //

уменьшаем счетчик данных

}

while (data_size>0);

// и так пока все

не передадим

return(0); // успешная

передача — выход с состоянием (0)

}

Прием N-ного количества байт от ведомого к мастеру

u08 i2c_master_read(u08 *data, u08 data_size)

{

if (bit_is_set(sclportinp,scl)) return(1); // проверка, если старт

не прошел — выход с состоянием (1)

{

cbi(sdaportd,sda); // переклюаемся на прием

*(data++)=usi_i2c_master_transfer(USISR_8BIT); // принимаем 8

бит

if (data_size==1)

{

USIDR

=0xFF; //если последний байт —

передаем NACK

}

else

{

USIDR=0x00; // если не последний —

передаем подтверждение ACK

}

usi_i2c_master_transfer(USISR_1BIT); // собственно передача

ACK/NACK

data_size--; // уменьшаем счетчик

данных

}

while (data_size>0); // и так пока все не

примем

return(0); // успешный прием

данных, выход с состоянием (0)

}

Процедуры простые и особых пояснений вроде не требуют.

Вот собственно и вся база для организации обмена по USI в режиме мастера.

Дальше уже реализация самого верхнего уровня протокола, зависящего от

устройства с которым мы будем общаться.

К статье приложено несколько файлов

Они в архиве usi.zip

•

usi_i2c.c Исходники рассмотренные здесь

•

i2c_memory.c , в котором набор процедур для работы с eeprom.

Процедуры очень простые, но если возникнут вопросы — пишите.

Расписывать их подробно — еще такая же статья получится. За раз

сложно для понимания. Но если ногами не запинают, напишу в виде

продолжения…

AVR. Учебный Курс. Использование AVR TWI для работы с

шиной IIC (i2c)

Про шину IIC я писал уже неоднократно. Вначале было описание протокола, потом

пример работы в лоб, а недавно камрад Ultrin выложил пример работы с i

c на базе блока

USI. Да и в интернете полно статей по использованию этой шины в своих целях. Одно

плохо — все они какие то однобокие. В подавляющем большинстве случаев используется

конфигурация “Контроллер-Master & EEPROM-Slave”. Да еще и на программном мастере.

И ни разу я не встречал материала, чтобы кто то сделал Контроллер-Slave или описал

многомастерную систему, когда несколько контроллеров сидят на шине и решают

арбитражем конфликты передачи. Пустоту пора заполнять, решил я и завязал узелок на

память… Да только веревочку пролюбил :)

Обещаного три года ждут, вот я таки пересилил лень, выкроил время и сообразил

полноценную библиотеку для работы с аппаратным модулем TWI, встроенным во все

контроллеры серии MegaAVR. Давно грозился.

Кошмар на крыльях ночи

Во-первых, я сразу же отказался от концепции тупого последовательного кода. Когда у

нас есть некоторая функция SendByte(Address,Byte) которая шлет данные по шине, а

потом возвращает 1 или 0 в зависимости от успешности или неуспешности операции.

Метод прост, дубов, но медленный. Т.е. пока мы байт не пошлем мы не узнаем ушло ли

оно, а значит будем вынуждены тупить и ждать. Да, шина i2c может быть очень быстрой.

До 100кбит ЕМНИП, но даже это время, а я все же за высокоскоростное выполнение кода,

без тормозных выдержек. Наш выбор — диспетчеризация и работа на прерываниях.

Суть в том, что мы подготавливаем данные которые нужно отослать. Дальше запускаем

аппаратуру передачи и возвращаемся к своим делам. А зверский конечный автомат, что

висит на прерывании TWI передатчика сам передает данные, отвлекая основную

программу только тогда, когда нужен какой-либо экшн (например сунуть очередной байт

в буфер передачи). Когда же все будет передано, то он генерит событие, которое

оповещает головную программу, что мол задание выполнено.

Как? Ну это уже от конкретной реализации событий программы зависит. Может флажок

выставить или байт состояния конечного автомата подправить, а может и задачу на

конвейер диспетчера набросить или Event в почтовый ящик задачи скинуть. Если юзается

RTOS.

Что у нас есть?

А у TWI всего один вектор прерываний (в отличии от USART, где на каждое событие по

прерыванию). Впрочем, это не страшно. Т.к. к нему в нагрузку идет регистр TWSR в

котором записывается код причины по которой мы оказались в прерывании. Т.е. у нас, без

лишних проблем, образуется конечный автомат.

Вот перечень кодов выдаваемых этим регистром

Коды состояний для режима Master

•

0×00 Bus Fail Автобус сломался… эээ в смысле аппаратная ошибка шины. Например,

внезапный старт посреди передачи бита.

•

0×08 Start Был сделан старт. Теперь мы решаем что делать дальше, например послать

адрес ведомого

•

0×10 ReStart Был обнаружен повторный старт. Можно переключиться с записи на чтение

или наоборот. От логики зависит.

•

0×18 SLA+W+ACK Мы отправили адрес с битом записи, а в ответ получили ACK от

ведомого. Значит можно продолжать.

•

0×20 SLA+W+NACK Мы отправили адрес с битом записи, а нас послали NACK. Обидно,

сгенерим ошибку или повторим еще раз.

•

0×28 Byte+ACK Мы послали байт и получили подтверждение, что ведомый его принял.

Продолжаем.

•

0×30 Byte+NACK Мы послали байт, но подтверждение не получили. Видимо ведомый уже

сыт по горло нашими подачками или он захлебнулся в данных. Либо его ВНЕЗАПНО

посреди передачи данных украли инопланетяне.

•

0×38 Collision А у нас тут клановые разборки — пришел другой мастер, по хамски нас

перебил, да так, что мы от возмущения аж заткнулись. Ничего I’l be back! До встречи через

n тактов!

•

0×40 SLA+R+ACK Послали адрес с битом на чтение, а ведомый отозвался. Хорошо! Будем

читать.

•

0×48 SLA+R+NACK Крикнули в шину “Эй ты, с адресом ХХХ, почитай нам сказки” А в ответ

“Иди NACK!” В смысле на запрос адреса с битом чтения никто не откликнулся. Видимо не

хотят или заняты. Также может быть никого нет дома.

•

0×50 Receive Byte Мы приняли байт. И думаем что бы ответить ведомому. ACK или NACK.

•

0×58 Receive Byte+NACK Мы приняли байт от ведомого и сказали ему “иди NACK!” И он

обиженый ушел, освободив шину.

Коды состояний для режима Slave:

•

0×68 Receive SLA+W LP Мы были мастером, трепались с подчиненными по шине. И тут

появляется на шине другой, более равный, мастер, перебивает нас и молвит “Уважаемый

ХХ, а не возьмете ли вы вот эти байтики…” Чтож, он круче. Придется бросать передачу и

брать его байты себе.

•

0×78 Receive SLA+W LP Broadcast Были мы, как нам казалось, самыми крутыми мастерами

на шине. Пока не появился другой мастер и перебив нас прогундосил на всю шину “Эй,

слышь тыыы. Слушай сюда” Девайсы-лохи, с неотключенными широковещательными

запросами подчиняются. Остальные отмораживаются и всякое Broadcast-быдло

игнорируют.

•

0×60 Receive SLA+W Сидим на шине, никого не трогаем, ни с кем не общаемся. А тут нас по

имени… Конечно отзовемся :)

•

0×70 Receive SLA+W Broadcast Ситуация повторяется, но на этот раз слышим уже знакомое

нам “Слышь, тыыыы”. Кто? К кому? Игнорируем Broadcast запросы? Или нет? Зависит от

моральных качеств программы.

•

0×80 Receive Byte & 0×90 Receive Byte Broadcast Принимаем байты. От кого и в каком виде

не важно. Решаем что сказать Давай еще (ACK) или “Иди NACK”. Тут уже по

обстоятельствам.

•

0×88 Receive Last Byte & 0×98 Receive Last Byte Broadcast Приняли последний байт и

распихиваем по карманам.

•

0xA0 Receive ReStart Ой у нас Повторный старт. Видимо то что пришло в первый раз был

таки адрес страницы. А сейчас пойдут данные…

•

0xB0 Receive SLA+R LP Слали мы что то слали, а тут нас перебивает другой мастер,

обращается по имени и говорит “А ну ХХ зачитай нам что нибудь из Пушкина” Что делать,

приходится читать.

•

0xA8 Receive SLA+R Либо просто к нам какой то другой мастер по имени обращается и

просить ему передать байтиков.

•

0xB8 Send Byte Receive ACK Ну дали мы ему байт. Он нам ACK. А мы тем временем думаем

слать ему еще один (последний) и говорить “иди NACK”. Или же у нас дофига их и можно

еще пообщаться.

•

0xC0 Send Last Byte Receive NACK Дали мастеру последний имеющийся байт, а он нам “иди

NACK”. Хамло. Ну и хрен с ним. Уходим с шины.

•

0xC8 Send Last Byte Receive ACK Дали мастеру последний имеющийся байт, а он требует

еще. Но у нас нету, так что разворачиваемся и уходим с шины. А он пусть карманы

воздухом наполняет (в этот момент мастер начнет получать якобы от slave 0xFF байты, на

самом деле это просто чтение висящей шины).

Из каждого состояния можно выйти по фиксированному для каждого состояния пути. Как

и куда выходить зависит от того, что нам нужно сделать. Какие данные послать.

Путь определяется битами регистра TWCR и управляется он только вручную!

TWINT

TWEA

TWSTA

TWSTO

TWWC

TWEN

—

TWIE

•

TWINT — флаг прерывания. Сброс его означает что конечный автомат провернется дальше,

а прерывание будет снова уловлено.

•

TWEA — Enable ACK. Разрешение ответа ACK. Если его включить, то автомат TWI будет

отзываться на свой адрес, а также давать ACK во всех случаях когда этого требует

протокол. Скажем, после прием байта. Если нам надо послать NACK то бит не ставим.

•

TWSTA — Сформировать старт. Причем не факт, что прямо сейчас. От текущего состояния

зависит. Например, если этот бит поставить в 0х38 состоянии, то старт будет сформирован

когда шина освободится. Контроллер TWI умный и сам все хорошо знает.

•

TWSTO — сделать Stop. Опять же аналогично. После записи в этот бит модуль отваливается

от сессии передачи. МК становится неадресованным ведомым.

•

TWWC — конфликт записи. Сигнализирует о том, что кто то из прикладной программы

записал в TWDR данные. Тогда как в TWDR полагается писать только при поднятом TWINT

(в нашем случае это будет толкьо в обработчике прерывания).

•

TWEN — блок TWI включен. Только и всего.

•

TWIE — прерывания от TWI разрешены.

Простой пример — оптправка данных в EEPROM. По правилам шины i2c она должна

выглядеть так:

Master

Start

SLA+W

Byte

Stop

Slave

ACK

Какова последовательность действий? Ну первым делом мы все подготовим, запишем в нужные

места данные, чтобы контроллер знал потом откуда все хватать. Считаем что это уже сделано.

Start

В прикладной программе инициируем обмен по шине. Для этого всего то надо установить

в TWCR биты:

•

TWSTA — сказав, что мы формируем старт.

•

TWINT — иначе ничего не завертится.

•

TWEN — понятно зачем. Включить обязательно

•

TWIE — прерывания тоже нам нужны.

0×08

А дальше, как только блок TWI родит на шине Start, мы окажемся в прерывании TWI с

кодом 0х08 и тут смотрим что надо сделать дальше. А дальше нам надо отправить

SLA+W. SLA+W мы записываем в TWDR и даем приказ заслать это в шину, поставив

биты

TWEN, TWIE, TWINT остальные не нужны. Т.к. это не старт, не стоп, и, для простоты,

ведомым мы не являемся в принципе, а значит нам ACK никому слать не надо.

Запуливаем эту комбинацию в TWCR и выходим из прерывания.

0×18

Спустя какое то время, когда блок TWI срыгнет адрес на шину, мы вновь окажемся в

прерывании. Но уже с кодом 0х18 (или 0х20 если нам никто не ответил). Теперь надо

решать что дальше делать. Надо послать байт данных. Суем данные в TWDR из

условленного места. И снова проворачиваем механизм, выставив флаги. На этот раз нужен

тоже только TWEN, TWIE и TWINT.

Блок TWI начнет отправлять данные по шине. Как закончит опять сгенерит прерывание,

но уже с кодом 0х28

0х28

Мы послали байт и попали сюда. Код 0х28 (или код 0х20 если ведомый послал нас

NACK). Теперь надо решать что делать дальше. У нас там по плану еще один байт

послать. Суем его в TWDR и шлем (TWEN, TWIE и TWINT).

0х28

Опять в прерывании, опять с кодом 0х28. А байты то кончились. Больше ничего слать не

надо. Значит пошлем СТОП и прекратим обмен. Не проблема (TWEN, TWIE, TWINT и,

главное, TWSTO). Теперь где нибудь выставим флажок или пошлем событие о том, что

передача успешно завершена, а затем, с чистой совестью, выйдем из прерывания в

фоновую программу.

Сложно? Вот и я думаю, что не очень. Особенно когда все по полочкам разложишь.

А вот я рисовал когда то диаграмму движения по автомату с кодами ошибок и событий.

Правда это не полный автомат, а только лишь режим Master и без арбитража

Покрупней

Синии линии - косяки и сбои. Красные — спокойная работа когда все говоря ACK и не

перечат.

А сам обработчик прерывания TWI пишется очень просто. Берешь и делаешь CASE в

который забиваешь все возможные коды входа и варианты реакции на них. Получается

чертовски много кода, но кусочки сами по себе простые. И за раз выполняется всего одна

ветвь, а значит работает это ОЧЕНЬ быстро.

Причем не обязательно реализовывать все-все-все коды. Например, если у нас только

Master то вся группа кодов для Slave не имеет смысла. Если мастер один, то вариантов

развития с перехватом шины другим мастером тоже не будет. Или если проц работает

только Slave то оставляем лишь Slave функции. Которые тоже можно почикать, убрав,

например, прием байта если нам байты только отсылать. В общем, кромсай@отрезай.

Главное затерминировать через Break или через Default остальные пути развития

сценария. На всякий пожарный.

Я же, выполнил полностью весь автомат. С возможностями как Slave, так и Master. C

возможностью перехвата обмена другим мастером. Не заморачивался только с

широковещательными пакетами и повторным стартом для Slave режима.

Процесс

Итак, как происходит обмен. Так как у меня в проекте поднят диспетчер, то вся обработка

начальных/конечных событий сделана через него.

Обмен для мастера состоит из пунктов:

•

1. Подготовка данных и формирование первичного старта. Т.е. все данные загружаются в

нужные буферы, все индексы буферов выставляются на нули, записываются нужные

адреса Slave и, если нужно, адреса страниц памяти, число передаваемых байт, число байт

в адресе страницы. Требуемый режим обмена и тыды. В общем всю необходимую инфу

для передачи данных. А также задаю адрес точки выхода из автомата. И запускаю

конечный автомат.

•

2. Конечный автомат отрабатывает в соответстветствии с выбранным режимом передачи и

на излете запускает выходную задачу.

•

3. Выходная задача (мы еще в прерывании TWI, поэтому действуем быстро-быстро, не

тупим), считывая коды ошибок, проверяет успешность передачи, если что не так делает

перезапуск посредством заброса функции первичного старта через службу таймеров на

повторное исполнение. Скажем через 50мс. Если все хорошо, то ставим на конвейер

диспетчера задачу следующую по алгоритму работы всей проги.

Обмен для слейва попроще:

•

1. Инициализируем Slave, заполняем мастер-адреса. Заполняем буфера выходными

данными (если такие могут быть). Включаем ACK, включаем прерывания TWI, включаем

сам TWI. Задаем точку выхода из конечного автомата. Ждем когда к нам соизвоят

постучаться.

•

2. Если обращение произошло, то автомат его обрабатывает, заливает/сливает данные с

выходных буферов. А по окончании обмена выполняет выходную задачу.

•

3. Выходная задача (мы еще в прерывании TWI, поэтому действуем быстро-быстро, не

тупим) обрабатывает сгребает данные из входящих буферов, сигнализирует фоновой

программе или запускает через диспетчер задачу исходя из пришедших данных.

Причем во время работы мастера может произойти вызов его как слейва и тогда возникнет

переход от одного обмена к другому. Туда и обратно. С повторной попыткой обмена.

Крутилки, ручки и кнопочки

Опишу вначале все барахло что у меня там есть. Тут кратко. Подробней в исходниках, в

комментариях.

Опции

•

i2c_PORT & i2c_DDR — Порт где сидит нога TWI

•

i2c_SCL & i2c_SDA — Биты соответствующих выводов

•

i2c_MasterAddress — Адрес на который будем отзываться в роли Slave

•

i2c_i_am_slave — Если мы еще и слейвом работаем то 1. Если только мастером то 0.

•

i2c_MasterBytesRX – Величина принимающего буфера режима Slave, т.е. сколько байт

жрем.

•

i2c_MasterBytesTX – Величина Передающего буфера режима Slave , т.е. сколько байт

отдаем за сессию.

•

i2c_MaxBuffer — Величина буфера Master режима RX-TX. Зависит от того какой длины

строки мы будем гонять

•

i2c_MaxPageAddrLgth — Максимальная величина адреса страницы. Обычно адрес

страницы это один или два байта. Зависит от типа ЕЕПРОМ или другой микросхемы.

Стартовые данные

•

i2c_Do — основная переменная состояния. Она флаговая. В нее вписываем флаги режима

работы, из нее берем коды ошибок

•

i2c_InBuff — буфер приема в режиме Slave. Т.е. если мы работаем как ведомыми и нас

вызвал мастер, то он впишет свои байтики сюда. Причем впишет не больше чем указано.

Т.к. на последнем байте мы его пошлем NACK и откажемся принимать мастерские

подачки.

•

i2c_OutBuff — а это выходной буфер ведомого. Когда мастер нас позовет и скажет “Есть

чо?”, то мы ему выгрузим данные отсюда. Таким образом, общение в качестве ведомого

ведется через эти буфера. Например, в мультироцессорной робо системе, где есть голова,

а есть ведомое шасси, то контроллер шасси может хранить в InBuff значения требуемой