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

Проц 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 строчек кода.

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

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

Я 100% знал, что кто-нибудь придерётся и написал - "без явной необходимости".



А теперь вопрос - чем ещё заниматься в прерывании кроме как ждать битов статуса, если вот так вот задача поставлена, а? Повторяю - для остальной периферии возможно потребуются вложенные прерывания.

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

Поддерживаю.

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



Ну не стоит обобщать, в самом то деле. В среднестатистическом устройстве (среди моих - 100%) обращение по I2C (запись в EEPROM) связана с определенными действиями по интерфейсу пользователя, сменой состояний основного процесса, а все, что нужно для функционирования прибора, запихано в свои прерывания, вовсе необязательно вложенные.

Кстати, по вложенности прерывания несколько недель назад было обсуждение в группе LPC2000 на YAhoo.

А кто против прерываний? Да ради бога. Всё от задачи зависит. Просто приведу вам пример из свой практики, когда это не нужно. И процу действительно нечем заняться. Flashloader. Надеюсь, там знакомая. Я написал flashloader. В RAM загружается код, который шьёт flash и плюс EEPROM по шине 2IC. Попробуйте теперь меня убедить, зачем мне это делать не в цикле и что я не тот камень выбрал.

Я это не придумал, это реальный код, и вы бы поступили так же (почитали доку framework, где прерывания, мягко говоря, не предусмотрены) - сделали цикл. Если у кого-то не встречалась ситуация, когда этого делать не нужно, - может, просто опыта недостаточно?

Кстати, вложенность прерываний я и сам использую.

Приведу ещё пример. EEPROM - съёмная энергонезависимая память в устройстве. Предположим, инициализация этого устройства при включении питания зависит от содержимого этой памяти. Например, бутлоадер девайса проверяет что воткнули и не нужно ли скопировать новую прошивку во внутреннюю флешь. Если версия новее - копируем, иначе стартуем исполняемый код, обработчик прерываний которого понятия не имеет ни про какие I2C EEPROM. Каким боком тут прерывания? Ещё пример - сохранение контекста работы устройства (по немаскируемому прерыванию!) и восстановление при включении питания. И много чего ещё.



Это точно. Вот бьюсь сейчас - GSM модем делает задержки более секунды при обращениях, а опрашивать MDB шину и поддерживать протокол нужно с периодом этак 0.1 сек... Не то мне дополнительный поток делать с диспетчеризацией, не то обрабатывать весь протокол MDB в прерываниях

Вы вобще в курсе что I2C полностью статическая шина ? Если что будем сидеть в прерывании до конца ?
Поллинг в прерывании это вобще новое слово в программировании... то есть конечно допустим для некоторых интерфейсов(например
SPI в режиме мастера), но для I2C это просто бред...
И не удивительно что при таком подходе "вдруг" становятся нужными вложенные прерывания...



Спасибо конечно за помощь в выборе рода занятий,
но вот согласитесь ли Вы со мной поспорить на конкретном примере(то есть поспорить на конкретной реализации) ?
Задачки разные бывают...
Сможете гарантировать передачу 6-8 байт за 1мс при скорости i2c ~100кбит
и обслуживании обмена в основном цикле ?(обмен между 2 процами)
При том что основной цикл считает плавучку с неадекватными временами реакции...



Это все очень "своевременные" замечания, но топик таки называется "Вложенные прерывания" ....

На конкретном примере - я его привёл. А насчёт темы топика Вы правы. За сим и откланиваюсь, ибо аргументы Ваши слабы, да и спорить в общем-то не о чем.

Извините, спойлер не сработал (?), получилась длинная колбаса. Все исходники пришлось вытереть из этого сообщения.

Не за что.

Ну вот мы и пришли - Ваши задачи против моих задач. И что? Позовем третьего с другими задачами?
Просто не обобщайте, и будет консенсус. По крайней мере я соглашусь

А возвращаясь с теме вложенности. Поразительно, 20-15 лет назад на 8080/8086 вложенность и приоритетность прерываний были естественным свойством системы. Убогость контроллеров, к счастью, уходящих сейчас, сделали это чем-то необычным.

Не так - убогость средств программирования, убогость операционных систем, и в первую очередь убогость программистов делало 20 лет назад вложенность "полезной". Хрен в под тем-же DOS организуешь "многозадачность" и выживешь при дисковых операциях без вложенных прерываний. Лично пользовал в прошлом широко. Однако при сколь-нибудь нормальном подходе к делу, вложенность, как минммум, бесполелезна в абсолютно подавляющем числе случаев. Причины "возрождения" поддержки вложенности на данном этапе развития контроллеростроения очень простые - пусть будет до кучи - ресурсы есть. А уровень программирования, опять, зачастую на уровне плинтуса. Массовость, однако.

А я согласен с Dog Pawlowa, - не надо обобщать. И не надо переносить свойства контроллеров общего назначения на МК для встроенных приложений.

И для I2C тоже самое.
Представим, что у нас поступает какая-то инфа по I2C и от этого крутится голова. Ну и какая разница, буду ли я ждать пока "буфер приёма не пуст" или я буду прямо сидеть на приёме? Если это попутный фоновый процесс, то тогда реализация "по прерываниям" - предпочтительней.

Я совсем не против работы по i2c без прерываний, более того, в моих проектах часто бывает что один проц(главный)
работает с i2c по прерываниям(по другому никак из-за большого числа разных задач),
а другой(переферийный) проц работает по опросу(опять же по другому никак из-за необходимости иметь только 1 прерывание
в системме для предсказуемого джиттера).
Я против попыток ожидания флагов i2c в прерываниях....(и вложенных прерываниях как костыль...) как предлагал один из авторов...

Возможно.
Из проектов последних пяти лет она мне понадобилась для реализации программного IrDA SIR.
Теоретически ее можно рассматривать как некоторую альтернативу RTOS.

Весь этот вопрос о вложенных прерываниях яйца выеденного не стоит. :-) Тем более , что человек уже как-то решил свою тайную проблему.
Кто как хочет, тот так и двигает левой рукой(вариант -- правой)?

Но Ваша фраза об уровне меня заинтересовала. Как можно оценить уровень программирования?
Массовость??? Откуда она взялась???? У нас так много ВУЗов, которые готовят специалистов по программированию (в частности МК)????
Большинство из тех , кто здесь бывает и не бывает сами осваивали эту область.

Понятно. Подход "радиогубителя" - слепил что-то и "у меня работает".

Спросить оценки у других.

Хлоп, штампик поставил... Точно старый усталый программер.
Как всегда -- я Д"Артаньян , а Вы все ...
Я-то хотел той фразой сказать ,что путей решения очень много.

А если я хочу оценить кого-то при приеме на работу?
Я не настолько велик, чтобы кому-то давать оценку, а таких "гигантов " как Вы рядом нет. Как быть? Критерии все же нужны...

Все очень просто, ИМХО: грамотный специалист всегда может аргументировать, почему было применено то или иное решение. В отличие от любителя, код пишет лаконичный, без лишних действий и затычек - это заметно даже при беглом просмотре.

Вы говорите о технике программирования. Но ведь если человек не понимает ЧТО писать или неправильно ставит задачу, то никакая техника не спасет.
У меня один знакомый был -- уехал к шведам. Он прекрасный математик. Но в программировании не силен. Однако это не помешало ему заключить неплохой контракт за границей именно как прграммеру. Хочу сказать , что техника приходит с опытом, а умишко заложен генетически -- кому больше, кому меньше. Мне вот совсем ничего не отмерили, в отличие от zltigo :-)

Так пусть это будут любые, НО ВАШИ критерии, а не какие-то "чужие", пусть и рекламируемые, как умные.



Заграница, она такая , а программирование давно уже участь домохозяек. Знакомая учительница жимии, предпенсионого возраста, повторно выщла замуж за иландского пенсионера, работы, соответственно, там не нашла. На курсах безработных освоила новую специальность "программиста" - работает. Погагаю, что с Российской колокольни, порядка 20 тысяч евро в год это уже "неплохой контракт". Практически аналогичная история в Штатах. Подбросить могу и примеры из жизни прогаммистов на Бейсике а Англии.

Наверное Вы правы... Но... Есть тут у меня человек один. Пишет для всего, что угодно. Как-то даже ключ для протокола обмена с блоком управления двигателем взломал за пару часов. А вот элементарный сигма-дельта АЦП на компараторе месяц ковырял пока нормально измерил. Как так? По моим критериям не есть хорошо, но ведь ключикто как-то получил...

Интернет он большой, вот и появляются "юные хакеры" скачавшие что-то и нажавшие кнопку мышкой и получившие "результат". Что-то вроде "мартышек" с гранатами - уделают любого морпеха за счет найденой гранаты. Вопрос только мастерство-ли это?

Не тот случай -- в интернете это не найдешь...

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