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



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

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

Сообщение отредактировал IgorMarx - Aug 7 2009, 17:12

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

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



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

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

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

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

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

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



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

Сообщение отредактировал IgorMarx - Aug 7 2009, 20:04

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



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



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

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

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

Сообщение отредактировал IgorMarx - Aug 8 2009, 04:42

Не за что.

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

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

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

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

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

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

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

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

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

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

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

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

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

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