Перейти к содержанию
    

Нужны ли вложенные прерывания?

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Я бы применил следующий ход

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, то я бы прерывания делать не стал без явной необходимости - архитектурно программный модуль I2C получается проще, надёжнее и портабельнее (т.е. этот модуль можно удобно использовать для других проектов), когда регистры опрашиваются в цикле. Но это при условии, что ядру в этот момент совсем делать нечего.
Ерунду Вы пишете полную...

Если Вашему процу делать нечего настолько что Вы готовы сидеть в цикле и опрашивать - Вы выбрали не тот проц...

I2C это самый типичный пример для interrupt driven transfer...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А зачем такиие сложности с вложенным прерыванем?

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Это как это не планируете выйти из обработчика прерывания????

Зашел в прерывание таймера и сидишь там пока И2С ковыряет там байтики?

Странно как-то.

 

 

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

 

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

Чего-то как-то туманно :-)

Нельзя ли поподробнее?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Всем спасибо за предложения. Всё сделал, проверил, работает как надо.

Необходимо было с внешнего девайса получать периодически синхронизацию времени (сек и мс) с точностью +-2..5мс.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ещё одна особенность - синхронизация времени должна была проходить ВНУТРИ прерывания, чтобы ни одна из процедур основного кода не получила расходящиеся значения времени. В готовый код потребовалось добавить всего 8 строчек кода.

Хрень какая-то...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хрень какая-то...

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...