Софтварный I2C для MPL115A2 и AVR.

AVR
Почитав статью «Цифровой измеритель абсолютного давления (барометр) MPL115A2» решил запустить оный на AVR. С аппаратным I2C связываться не стал, т.к. барометр поддерживает очень высокие скорости обмена и получается выгоднее читать его софтварно, не мешая остальным прерываниям, чем долго и мучительно разгребать регистр TWR ради четырёх паршивых байт. Ну и отсутствие привязки к выводам радует.
Итак, в архиве Си файл со всеми необходимыми функциями, который надо просто прицепить к своему проекту. Написан под IAR, но из специфичного там только функция __delay_cycles(); Как следует из названия, она выполняет задержку в тактах контроллера. Просто заменяем её принятой в своём компиляторе для обеспечения необходимых выдержек между сменой состояния лапок. Задержки (скорость) подобрать по вкусу.

Настойка софтварного I2C сводится к изменению всего 5 дефайнов.
DS_I2C_PIN, DS_I2C_DDR, DS_I2C_PORT — регистры порта, к которому подключён барометр.
DS_SDA_LN, DS_SCL_LN — биты порта для соответствующих линий.
И всё, больше ничего трогать не надо.

Ну, ещё DS_I2C_T отвечает за задержку вкупе с параметром F_CLK, который обычно задаётся в основном коде. DS_I2C_T == 1000 достаточно для работы барометра при кварце 16 МГц (задержка получается 16000 тактов или 1 мс).

На выходе имеем три функции и два буфера:

void read_coef_soft(void); // считать коэффициенты и положить их в буфер MPL115A2_coef.
void start_conv_soft(void); // запустить преобразование температуры и давления.
void read_result_soft(void); // считать температуру и давление и сунуть в MPL115A2_result.

unsigned char MPL115A2_coef[8];   // буфер коэффициентов
unsigned char MPL115A2_result[4]; // буфер результата


Выполнив функции можно пользовать результаты в соответстующих буферах.

Разумеется, функции I2C можно использовать и в других разработках.
  • +3
  • 03 сентября 2012, 18:50
  • Dikoy
  • 1
Файлы в топике: MPL115A2_2.zip

Комментарии (19)

RSS свернуть / развернуть
Пригодится, спасибо.
0
ПС. Не забыть про лапки ресет и шутдаун. Управлять ими особого смысла нет, но состояние задать нужно правильное.
0
  • avatar
  • Dikoy
  • 03 сентября 2012, 22:28
дубль темы можно не просто запретить на редактирование, а убить вовсе.
0
Не знаю как.
0
Утащить в личный блог и нажать «удалить». Хотя он скорее всего не удалится.
0
  • avatar
  • Vga
  • 04 сентября 2012, 20:55
Таки не понял в чем выгода чтения данных софтово?? (Я к тому, что по Вашим словам барометр поддерживает большие скорости обмена… Тогда какое отношение к медленному софт-и2ц?)
0
Ну, допустим теоретическое ограничение на чтение софтварно, это Fclk/2. На практике это невозможно, есно, но вот мегагерц == мегабит получить можно элементарно. А то и три. Вычитать барометр дёргая лапками занимает столько же времени, как ветвиться по свичу в прерывании, но при этом мы не мешаем другим прерываниям.
У АВР очень громоздкое прерывание обслуги TWR. Если чип нагружен прерываниями, уводить его на 100500 тактов в TWR не то чтоб глупо, а часто опасно, тем более что оно там возникает на каждый чих. Даже если разрешить вложенность.
Когда мы работаем софтварно, нас в любой момент может прервать прерывание и мы не помешаем ни ему, ни самому чтению.
В общем, поигравшись с барометром я понял, что прерывание там нафиг не нужно. Вообще. Если только не ставить 10 кБит скорость обмена.
Конечно, можно и штатный регистр в мейнлупе поллить, дело вкуса, но тут привязка к конкретным лапам.

Ну и как быструю проверку работоспособности данный код можно использовать. Таки корпус там такой, что никогда не знаешь, припаялся или нет :)
-1
>>У АВР очень громоздкое прерывание обслуги TWR
У NXP, как мне показалось, оно ещё более громозкое, что логично — не SPI и не UART — мудрёней.

>>Если чип нагружен прерываниями
__enable_interrupt не поможет разве? (Естественно с запретом повторного прерывания от TWI во время работы его самого).
Тем более, I2C весьма терпима к медленным устройствам — любой slave может тормозить, как хочет, подгоняя шину под себя. Мастер — тем более.
>>Когда мы работаем софтварно, нас в любой момент может прервать прерывание и мы не помешаем ни ему, ни самому чтению.
Когда мы работаем аппаратно — аналогично, если master это не тина без ОЗУ, конечно. Но это не ваш случай — памяти хватает в большинстве случаев. Или нет?
0
У NXP, как мне показалось, оно ещё более громозкое, что логично — не SPI и не UART — мудрёней.
У армов NXP-шных — может и так; а у 51 ихних же обработчик очень стройный получается. Сишный «case» компилится в таблицу переходов, примерно так:
i2c_irq:		
			push    acc
      		  	push    b
      		  	push    dph
      		  	push    dpl
      		  	push    PSW
       		 	mov     PSW,#008H; переключаю банк регистров
				mov a, I2STAT
				rr a
				rr a
				mov dptr, #I2Cvectortable
				jmp @a+dptr
I2Cvectortable:	
		;00h->00h
				ajmp i2c_error
		;08h->02h - передан start
				ajmp i2c_putaddress
				;10h->04h - передан повторный старт
				ajmp i2c_putaddress
; и так далее...
0
Самый замороченный I2C из встречавшихся — у STM8 и STM32. У силабсов чуть полегче, хотя тоже не подарок.
0
Угу, еще и с жесткими ограничениями на время реакции на некоторые события, иначе I2C-модуль виснет.
0
  • avatar
  • Vga
  • 06 сентября 2012, 10:51
А можно подробнее, чем плох силабовский SMBus модуль? У меня с ним никогда проблем не было. Правда, я не все его режимы использовал, поэтому и интересно где стелить солому на будущее.
0
Нет выгоды, я думаю. Конечно, TWI AVR выше 400кГц не может, но затраты на аппаратный TWI меньше программного TWI. На вкус и цвет — кому что нравится.

Разве что будешь лучше представлять как TWI работает, если программно реализуешь — тоже выгода.
0
Если регистр опрашивается поллингом, то меньше. Единственный минус — привязка к конкретным ногам. А там, как правило, сидят INTы, которые бывают нужны.
А если прерывание, то отжирает ресурсов больше, чем софтовая раскрутка.

Ясно что речь идёт про мастера. Со слейвом такое уже не прокатит.
0
При аппаратном TWI ноги никуда не заремапишь, это да.
>>А если прерывание, то отжирает ресурсов больше, чем софтовая раскрутка.
Почему? И о каких ресурсах речь? Как-то слабо верится, что аппаратный блок более медленный, чем программная реализация. Вы сравнивали?
Может программная более 'sstrnbdyf из-за игнорирования каких-то состояний шины?
0
Мне интересно ознакомится, но почему то архив скачивается битый.
0
Перезалил
0
Спасибо! Теперь порядок.
0
Понимаю, что статья скорее про реализацию интерфейса, а не про датчик. Однако, если Вас интересует измерение давления, посмотрите на версию этого датчика MPL115A1 с интерфейсом SPI. Я недавно работал с ним и остался доволен. Я к тому, что если есть проблемы с аппаратным I2C модулем в Ваших МК, то может их будет меньше с аппаратным SPI модулем.
0
  • avatar
  • Ser60
  • 10 сентября 2012, 02:42
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.