Уважаемые, подскажите, пожалуйста.

Проц LPC2214. Есть задача по прерыванию таймера сразу же производить чтение по I2C с девайса. Алгоритм работы по I2C сделан тоже на прерываниях. Необходима синхронность чтения данных с таймером. Следует ли в данном случае использовать вложенные прерывания или можно каким-то образом обойти? Переделать работу с I2C без прерываний? Объём записывемых/считываемых данных из девайса не более 20Байт.

ИМХО, шина I2C вообще не предполагает работу с жесткими привязками ко времени.

И зачем вложенные прерывания? Нельзя просто запустить передачу по прерыванию от таймера и продолжить на прерываниях I2C?

Шина - да, а вот получаемые/принимаемые данные очень сильно привязаны


Как вариант - можно. Тогда в моём случае надо будет передать алгоритму старта работы с I2C указатель на функцию, которую следует вызвать по окончании цикла обмена с девайсом. Подумаю, может, так и сделаю.

Так отвяжите. Банально добавьте в I2C пакет метку времени.

Собственно, эту метку времени и нужно считать из девайса для синхронизации времени на мастере с точностью до 2-5мс

Ответ таков: если вы не планируете выйти из обработчика таймера, пока не закончите обмен по шине I2C, то вам действительно будут нужны вложенные прерывания, но как раз не для I2C, а для остальной периферии. Что касается I2C, то я бы прерывания делать не стал без явной необходимости - архитектурно программный модуль I2C получается проще, надёжнее и портабельнее (т.е. этот модуль можно удобно использовать для других проектов), когда регистры опрашиваются в цикле. Но это при условии, что ядру в этот момент совсем делать нечего.

Я бы применил следующий ход
0. Организовал бы системные часы на каком-либо таймере с тиком 200 - 500 мкс.
1. При приеме пакета I2C брал бы временнУю метку этого события Ti2c.
2. При входе в процедуру синхронизации также брал бы временнУю метку Tsynchro.
3. Имея метки Ti2c и Tsynchro, а также время time, пришедшее в пакете I2C подстраивал бы часы (local_time) так: local_time = time + (Tsyncro - Ti2c). Естественно предполагается, что синхронизация локальных часов происходить после приема данных о времени по i2c.

Да, тоже думал об этом. Как ближайший вариант реализации учту. Спасибо.

Почитайте про RTCP. реализовывать весь нет смысла конечно, но вот оценка inter-arrival jitter'a и transit delay'я оттуда вам пригодится.

Ерунду Вы пишете полную...
Если Вашему процу делать нечего настолько что Вы готовы сидеть в цикле и опрашивать - Вы выбрали не тот проц...
I2C это самый типичный пример для interrupt driven transfer...

А зачем такиие сложности с вложенным прерыванем?
Таймерное прерывание делает свое грязное дело - инкрементирует/декрементирует счетчики, а после этого выставляет флажки для функций вызываемых по этому прерыванию.
В главном цикле проверяется эти флажки, и по их наличию запускается I2C и/или любая другая interrupt driven передача.
Таким образом таймерное прерыване удлинняется на пару тройку машиинных команд, а не на ожданиие окончание цикла обмена по шине.

Вот здесь про такой подод подробнее http://tldp.org/LDP/lkmpg/2.4/html/x1210.html

Это как это не планируете выйти из обработчика прерывания????
Зашел в прерывание таймера и сидишь там пока И2С ковыряет там байтики?
Странно как-то.



Чего-то как-то туманно :-)
Нельзя ли поподробнее?

Всем спасибо за предложения. Всё сделал, проверил, работает как надо.
Необходимо было с внешнего девайса получать периодически синхронизацию времени (сек и мс) с точностью +-2..5мс.
Сделал просто: по прерыванию 1мс таймера инкрементировал локальный счётчик мс, при равенстве его 1000, сбрасывал и вызывал процедуру чтения/синхронизации времени и коррекции этого мс счётчика. Процедуру чтения по I2C из внешнего девайса сделал по поллингу I2CONSET_SI. Ещё одна особенность - синхронизация времени должна была проходить ВНУТРИ прерывания, чтобы ни одна из процедур основного кода не получила расходящиеся значения времени. В готовый код потребовалось добавить всего 8 строчек кода.

Хрень какая-то...
Может объясните, что Вы хотели сказать этой фразой.

Да темнит что-то человече... Сам себя перемудрил.