#include - оптимальное использование директивы

[Исбанни]

Я сбросил флаг в самом начале. Это означает выход из прерывания разве?? Я ж написал, что выход из прерывания подразумевает некоторые аппаратные действия. И происходит он там, где закрывается последняя сишная скобка }

Обработчик прерывания при использовании API функций RTOS занимает гооооораздо больше, чем 10-20 тактов. Но работает все норм.
Ну а в тех МК, где нет векторов, или же когда под одним вектором находятся несколько запросов на прерывание, и требуется сначала проверить источник прерывания - вот там попробуйте-ка уложиться в эти ваши 10-20

[eddy]

сделай на СТМ8 обслугу полухардварного софтового ЮАРТа и ИР-датчика одновременно

Делал. И все работало.
STM32F0, и каким местом ты будешь хардварно засекать время срабатывания внешнего прерывания? Допустим, микросекунды отмеряются таймером, а все остальное — структура (дата, часы, минуты, секунды).
И???

[AR_Favorit]

Вот как сбросили флаг прерывания, так считай и вышли.

Шо, правда? И приоритет (в МК с приоритетной системой прерываний) выполняемого кода изменился, и менее приоритетное прерывание может выполниться?

[eddy]

AR_Favorit, как только флаг сбросишь, это же самое прерывание опять может вызвать обработчик, хоть он до конца и не дошел! и насрать!!!

[Исбанни]

eddy, в приоритетном STM32 такого нет - повторно войти без выхода не даст одинаковые приоритет и номер активного и отложенного прерывания. В ПИКах с одним вектором тоже не будет повторного входа - аппаратно запрещаются прерывания во время нахождения в режиме прерываний, и повторный вход без выхода из прерывания или без программного разрешения, находясь в прерывании - невозможен. Про АВР-ы не помню, я с ними почти не работал.
Да и вообще, флаг прерывания работает немного по-другому. Вспомните, что бывает, если флаг не сбросить до выхода из обработчка?

[parovoZZ]

Вы хоть свой пример покажите, на чем пишете, какой микропроцессор, что хотите изобразить.

МК без приоритетных прерываний.
По прерыванию от nRF мне надо быстро считать её буфер и обработать эти данные. Если данные не для меня, то их либо удалить, либо отправить дальше.Но есть ещё одно прерывание, которое более приоритетное для данной задачи. Поэтому обработку принятых данных могу отложить на потом. Главное - считать буфер nRF, потому как следом может ещё прилететь радио-пакет. Решение в лоб через флаг мне не нравится - этот флаг надо постоянно опрашивать. Но раз так, то проще опрашивать регистр nRF, чем делать замуты с прерываниями. А есть ли решение, чтобы после обработчика прерывания сразу перейти в функцию обработчика данных? Это было б идеально.

[AR_Favorit]

AR_Favorit, как только флаг сбросишь, это же самое прерывание опять может вызвать обработчик, хоть он до конца и не дошел! и насрать!!!

Мда.

Специально же подчеркнул: для МК с приоритетной системой прерываний.
Флаг запросто и автоматически сбрасывается в некоторых прерываниях (по чтению регистра данных, например), но при этом это же прерывание "из него самого" тут же опять вызваться не может. Как и любое другое с тем же или более низким приоритетом.

А у неприоритетных типа АВР вход в прерывание тупо автоматически запрещает прерывания, и пока обработчик не закончится каким-нить RETI в машинном коде, тоже никто никого не прервет и не вызовет.

[Исбанни]

По прерыванию от nRF мне надо быстро считать её ... Если данные не для меня, то их либо удалить, либо отправить дальше

nRF24L01, да? Используйте её собственные возможности. У нее есть 5-байтный адрес, автоматически обрабатывающий ситуацию "свой/чужой". И еще есть 6 потоков (pipe) со своими адресами, в сумме одна nRF может принимать и автоматически распознавать ("свой/чужой") до 6 передатчиков.
Когда по адресу будут распознаны данные именно для вашей nRF, она опустит в 0 свою линию прерывания IRQ и вы можете совершенно спокойно прочитать данные с нее.
Но читать данные конечно лучше не в прерывании, поскольку, когда вы читаете, у вас либо идет ожидание принятого по SPI очередного байта, либо если используете прерывание по получении байта SPI, то это прерывание не сможет быть обработано из-за неприоритетного контроллера прерываний.
То есть, вам в прерывании от IRQ можно запустить передачу по SPI первой команды для чтения nRF (команда R_RX_PAYLOAD), и выйти из текущего прерывания. А в прерывании по приему байта SPI вы уже будете как-то разруливать остальное.
Второй момент: радиопакеты слать слишком часто не следует, когда у вас целая сеть развернута, иначе эфир будет сильно забит. Арбитража там не предусмотрено, лишь только подтверждение приема, приходящее по радио обратно передатчику. И то - если этот режим включен (ShockBurst).

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

[eddy]

AR_Favorit, ЯХЗ, как должно быть, но когда-то, быдлокодя 1-wire для STM32F103 столкнулся с тем, что пока в процессе отладки весь код пхал в обработчик прерывания от таймера, происходило зависание. Как только код укоротил (только флаги выставлял), все пошло нормально. Воткнуть в прерывание вывод данных на USART я не могу, а читать кроме RM&datasheet на МК еще и документацию на ARM лень, поэтому остается лишь гадать на кофейной гуще, как оно на самом-то деле!

[parovoZZ]

nRF24L01, да? Используйте её собственные возможности. У нее есть 5-байтный адрес, автоматически обрабатывающий ситуацию "свой/чужой". И еще есть 6 потоков (pipe) со своими адресами, в сумме одна nRF может принимать и автоматически распознавать ("свой/чужой") до 6 передатчиков.
Когда по адресу будут распознаны данные именно для вашей nRF, она опустит в 0 свою линию прерывания IRQ и вы можете совершенно спокойно прочитать данные с нее.

Это я всё в курсах. Но мне не подходит - когда устройств штук 30-50 пайпами не отделаешься. Да и адрес в 5 байт - это дофига. Мне и трех должно хватить=)

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

Это тоже не подходит, но придётся включить ради динамической длины пакета и слать NO_ACK в сообщении. Об успешной доставке будет квитировать центральный контроллер.

Но читать данные конечно лучше не в прерывании, поскольку, когда вы читаете, у вас либо идет ожидание принятого по SPI очередного байта, либо если используете прерывание по получении байта SPI, то это прерывание не сможет быть обработано из-за неприоритетного контроллера прерываний.
То есть, вам в прерывании от IRQ можно запустить передачу по SPI первой команды для чтения nRF (команда R_RX_PAYLOAD), и выйти из текущего прерывания. А в прерывании по приему байта SPI вы уже будете как-то разруливать остальное.

А вот это хорошая идея. Я буду думать в этом направлении.