Изучаем STM32 Cortex M3

[STM32F0]

Угу, а ПЛК не на МК и ПЛК вообще вечное, априори.
Посмеялся.

[eddy]

с директором завода

Начали с концевиков линейных трансляторов и Холлов турелей спектрографа, а закончили заводом =D

Я, кстати, собираюсь-таки один вход (сигнал управления затвором от ПЗС-системы) таки на прерывание повесить, чтобы гарантировать постоянство задержки да и вообще минимизировать ее. Хотя, не спорю, что несколько сот микросекунд ошибки относительно общего времени экспозиции в несколько минут — капля в море. Зато проще обработка: по переднему фронту открыл затвор, по заднему закрыл. А в случае КА нужно вводить переменные состояния... У меня и так этих КА уже черт-те сколько (внешний АЦП, 2 UART'а, USB, 5 шаговых двигателей, затвор на TLE5205, подогреватель на UPS5451, 1-wire термометры), скоро, наверное, утону в своем быдлокоде.

[avtoneru]

Так и не понял, с чем вы согласны?

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

[STM32F0]

с тем, что опрос на прерываниях не айс.

Угу, поллинг рулит, да?
Или HAL настолько тупой, что не справится? А может примеров нет?

Если есть возможность отказа МК - необходимо дублировать защиты.

Каким боком здесь дублирование? Хоть троирование!

А если нужна реакция именно на хардварное прерывание, а оно - одно, то заводим все три защиты через диодную развязку или логику на один вход прерывания, и параллельно - на дополнительные два или три входа GPIO. При обработке прерывания - первым делом проверяем, что его вызвало и реагируем соотв. образом. Количество ног - то же самое, время реакции - больше на опрос причины срабатывания прерывания.

Это и есть универсальное решение на все случаи жизни? Не густо!

[С.М.С]

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

И в чём великий смысл опроса в цикле, а не по прерыванию? Какая разница, откуда передать управление с цикла опроса или из процедуры прерывания? У нас же не много поточность, с много ядреностью. Программа как выполнялась оператор за оператором, так и продолжит выполняться.

[Easyrider83]

Нет смысла использовать прерывания. Опрос пинов - задача не быстрая. Сидит в отдельном потоке в RTOS и с определенным интервалом читает состояние порта.
Прерывания - это вообще такая штука, которой не разбрасываются. Вы перешли на ARM, а в голове еще AVR.

[STM32F0]

Нет смысла использовать прерывания. Опрос пинов - задача не быстрая. Сидит в отдельном потоке в RTOS и с определенным интервалом читает состояние порта.

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

Прерывания - это вообще такая штука, которой не разбрасываются. Вы перешли на ARM, а в голове еще AVR.

Чушь! Это как раз у АВР замшелая организация прерываний, а здесь всё путём! Приоритеты зря придумали? Да и переход из прерывания в прерывание короче по времени.
Или просто ужас от одного прерывания в ПИК16 остался и довлеет?

[omercury]

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

Смотрю, прямо революция в вычислительных системах назревает.
Вы историю этак тридцатилетней давности почитайте, как это всё было организовано и как работало, узнаете много нового.
Когда прерываний было всего 2, одно маскируемое, а второе - немаскируемое, а контоллер прерываний был внешним.
Нынешние МК умеют генерировать прерывания практически по любому чиху.

[pambaru]

Нет смысла использовать прерывания.

Вспомнилось - одну демку видел от NXP. Там основной цикл состоял из while (1);
Все остальное делалось в прерываниях

[eddy]

Там основной цикл состоял из while (1);

Годится только для элементарных задач. Если у вас там штуки 3 конечных автомата + передача данных по всяким разным портам, то вряд ли взлетит.