Цитата(Andrew O. Shadoura @ Jul 5 2008, 16:49)
Как ни странно, в аврах приоритетов гораздо больше, чем 2…
Прошу прощения, а Вы хоть поняли, о чём я? Мой ответ ArtemKAD выше читали? Как вообще устроена система прерываний хотя бы у MCS51 знаете?
Ещё раз медленно:
Да, у AVR все запросы прерываний выстроены в цепочку, запрос от того устройства, которое расположено дальше от ядра, маскируется тем, которое стоит ближе. Ну без такой цепочки в той или иной форме просто нельзя, надо же как-то выбрать того, кто сейчас будет обслуживаться.
В некотором смысле это можно называть "приоритетами". Но работают такие "приоритеты" только в случае одновремённого анализа этих прерываний, т.е. при строго одновремённом их возникновении либо при их возникновении в любом порядке во время запрещённых прерываний. Если же уже начал работать обработчик, к примеру, SPI, то не имеет никакого значения факт "наиприоритетности" INT0 - оно не прервёт "менее приоритетный" обработчик SPI до тех пор, пока в том не будет выполнена команда SEI. Но сразу после неё резко так обработчик EE_RDY тоже сможет прервать обработчик SPI - т.е. коту под хвост пошло теперь уже то, что обработчик SPI
якобы приоритетнее EE_RDY.
Конечно, можно поизвращаться и при входе в обработчик SPI сохранить состояние разрешения прерывания EE_RDY, запретить его, потом сделать SEI, порабтать, (по вкусу - выполнить CLI) и восстановить состояние разрешения EE_RDY. Именно о таком спочобе эмуляции приоритетной системы прерываний писал ArtemKAD. Но это только
программная эмуляция того, что у других бывает аппаратно.
В том же MCS51 имеется
две или четыре таких цепочки, которая у AVR
одна. И битиками можно перемещать запросы между цепочками, не меняя порядка. У цепочек есть свои приоритеты. Запрос из более приоритетной цепочки может прервать уже работающий обработчик из всех менее приоритетных цепочек. Запрос из менее приоритетной цепочки будет ждать, пока не закончатся все обработчики из его и более приоритетных цепочек.
В этом случае, например, можно прерывание от аналогового компаратора переместить в самую приоритетную цепочку и сработка компаратора сразу же вызовет его обработчик - без ожидания, пока
работающий уже в данный момент обработчик какого-нибудь таймера расщедрится на сохранение контекста, для прерываний от UART да ADC сохранит состояния и запретит их, разрешит глобальные прерывания.
В ещё более продвинутом случае у процессора в статусе может быть несколько битов, задающих "приоритет процессора". Только запросы из более приоритетных цепочек могут прервать данный участок кода, остальные подождут.
Да, без этого можно жить. Можно стараться обработчики прерываний делать покороче, чторбы задержка в них не была существенной, можно, как это часто обсуждается, в нужных обработчиках запрещать "менее приоритетные" и после этого разрешать прерывания - но сама частота подобных обсуждений говорит о том, что систему прерываний AVR можно было бы поправить хотя бы в духе MCS51 - это не так дорого стоит,
гораздо дешевле умножителя. Без которого тоже можно жить
Цитата(Andrew O. Shadoura @ Jul 5 2008, 16:49)
Для EEPROM и ADC битовость наоборот более удобна, ибо позволяет производить проверку завершения операции одной командой.
Товарищ А.Накойхер интересуется - зачем для "проверки завершения операции одной командой" в битово-адресуемой области находятся регистры EEARH, EEARL, EEDR, ADCH, ADCL ? И за компанию с ними UBRR, UDR, SPDR, TWDR, TWAR ?
Господин К.А.Кого-Фига также интересуется - а не лучше ли было бы вместо них в битово-адресуемую область опустить регистры TIFR, TIMSK, GICR, GIFR, а у кого и тот же TWCR (это вообще 5 баллов - у меги8 TWDR "внизу", TWCR "вверху" !!!).
Я где-то выше сказал хоть слово про то, надо было переместить "вверх" регистры EECR, ADCSR ?
Да, в свежих AVR это дело потихоньку поправили, но изначально был такой ляп...
ATMEL рекомендует ATmega32A и ATmega16A
Jul 1 2008, 16:49
