Есть задача переделать CAN IO модуль и сделать его с АРМом. В существующем модуле питание решено так, что внешних 24V стабилизируется без развязки на 12V, с которого питаются катушки реле, и далее стабилизируется на 5V, с которого питается логика. Сторона CAN питается через DC/DC преобразователь.

Какой опыт, способен АРМ работать в индустриальной среде без гальванической развязки ?

MB90-е, они при своих 16 Мгц в прерывание ввалятся за то же время что и LPC на 64 Мгц.
Причем, MB90 не рисковый МК.

Остальное пропускаю, т.к. контекст наталкивает спросить "С чем знакомы, кроме 51-х ?"

Знакомства имею обширные, включая собственные процессоры. Ни "MB90" ни "51" в круг близко знакомых не входят. Проблемы в этом не вижу. Продолжайте быстро вваливаться в прерывание на 16 MHz и мееедленно там работать.
Причины "быстрого"/"медленного" вваливания были изложены абсолютно безотносительно конкретного контроллера. Перечитайте еще раз на досуге.
Все, что хотел сказать - сказал. Точка.

Легко, но не в В любой момент прерывания L, а в В любой момент обработки логики самого обработчика прерывания L.
Для этого в начало обработчика прерывания L и в его конец добавляется соответствующий код.

Да. Надо с головой писать этот код (варианты не раз опубликованы).
Да. Время реакции (именно действия на прерывания L) увеличится. Но уж если Вы его позволяете прерывать другими прерываниями то это д.б. не критично.


А теперь давайте про конкретности?
Сколько Вам надо прерываний в одном проекте? И сколько уровней их вложенности?
Почему нельзя обойтись без вложенности? Нужна быстрая реакция? Может стОит вынести часть обработчика в основную прогу? Т.е. в прерывании только забирать данные или наоборот запихивать их в периферию и взводить флажки?

Многие ОС-ы вообще имеют абстрактный обработчик, который выполняет подготовительные действия и потом вызывает зарегистрированные реальные обработчики.

ИМХО отсутствие продвинутого контроллера прерываний в LPC в частности основано на архитектуре ARM, а именно не сохранение регистров в стеке, а переключение банка регистров а вместе с ним и стека. При таком подходе для реализации изначальной вложенности в N прерываний надо соответственно N банков регистров для прерываний (которые кстати должны глядеть в N стеков в памяти, что м.б. расточительно по памяти). Фирма ARM остановилась на N=2. FIQ и IRQ.

ЗАДАЧА НЕ РЕШЕНА (т.к. программного решения не имеет). Поэтому и легко.

10
5 Причем 3 под управлением OS, остальные, с более высоким приоритетом, немаскируемые для сервайсав OS.


Это все понятно, но
- даже забор и запихивание занимает время (только не надо заводить речь про "быстрые" МК, быстроту предпочитаю определять в тактах)
- перенос обработчика в основную программу требует дополнительных буферов и служб для их обслуживания - дополнительные расходы памяти и времени.

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

Еще обычно пин P0.31 имеет функциональноть только на вывод и внутренний пулл-ап.

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

Ну почитайте по ссылкам например тут

или вот это keil предлагает




А реальный пример вот этого всего можно?
ИМХО при использовании ОС Вы должны "играть" по её ОС-иным правилам.
С другой стороны в ОС д.б. механизмы управления прерываниями.



Везде надо искать компромисы



Согласен, я тоже люблю когда всё гладко и красиво да ещё есть выбор использовать или нет. Но я уже попытался объяснить, что тут играет роль не нежелание производителей делать крутой контроллер прерываний с кучей их приоритетов, а архитектуру ARM которая не позволяет этого.
Так что спор перетекает в плоскость ARM - не ARM.
К тому же реалии таковы что развитие идёт в сторону повышения тактовой частоты с вредрением длинющих конвееров, кэшов и т.п., при этом ожидать быстрой реакции (в тактах) не приходится. И выход из этой ситуации простой и постепенно реализуемый - более умная перефирия. Т.е. FIFO буферы, DMA и т.д. В моём текущем проекте на LPC2292 мне был бы нужнее SPI c возможностью посылки 8/16/24/32битных слов чем куча прерываний с приоритетами. Кстати это снизило бы кол-во прерываний от SPI в 2 раза минимум, и упростило бы сам обработчик.
Ну а ногодрыгательством и програмной реализацией неких "по праву аппаратных" протоколов може убить любую производительность.

И ИМХО дальше разговор бессмысленен т.к. видимо каждый останется при своем мнении.

LPC213x

Спасибо всем за интересные заметки. Я конечно согласен с тем, что гальваническая развязка решает далеко ен всё. Мой вопрос возник от того, что АРМовский кит, который у меня, кажется быть чувствительнее к помехам, чем например кит с Cygnal-ом. Я не имел в виду развязку CAN, там это считаю необходимым, вопрос касался питания процессора. Эсть у нас и приборы прошедшие цертификацию работающие с +5V и 0V вытащеными иногда на десятки метров. В разницу от остальных гальваническая развязка является относительно дорогостоящим мероприятим . Поэтому хотелось слышать, что на этот счёт говорит практика.

ну вот и замечательно... рад за Вас

з.ы. нервны жалко , пойду-ка я в кофейню

извините, увидел ADu и почему то решил, что сигнальный процессор....

спасибо, обязательно посмотрю, - это интересно



всё так.

просто слегка обидно, что столько надо плясать с бубном и в итоге получить характеристики хуже, чем у 8051 на 2МГц. как буд-то 20 лет прошли мимо разработчиков из ARM

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

другое дело ложные прерывания. но это уже особенность архитектуры ARM7. во всяком случае, я пока победить не смог. в любом случае, не считая эрраты с таймерами, это особенность ARM7, а не LPC2000.

а проц замечательный. кстати, мануалы на 213х и 214х получше будут, на мой взгляд. ну и процы помоему класс. к сожалению там нет CAN

А какие-такие ложные прерывания? Похоже я что-то пропустил. LPC2132 у меня в процессе изучения. Интересно, новый LPC2103 будет меньше детскими болезнями страдать?

И еще вопрос, насколько необходимо использовать супервизор на сброс для LPC? Например мне для AVR он ни разу не понадобился. Как обстоит дело в случае LPC&

Не надо делать безответственных широковещательных заявлений.

moonrock
кратко описано на стр. 106 мануала LPC2119... там же дана ссылка на армовский документ

схема сброса по питанию послабее чем в AVR и Мегах, но работает вполне надёжно. пойдёт для бытовки или если сброс используется в качестве немаскируемого прерывания
я использую и сейчас. причём 8ногий, со встроенным компоратором. контролирую 1.8В, 3.3В и 5В.

всё, боюсь нарваться на предупреждение... не в тему

был проект. на основном узле источник питания подавал 24В. на удалённом (до 500м) поставили DC-DC преобразователь. проблема всплыла во время испытаний на импульсную ЭМ помеху. пришлось поставить ферритовые подавители помех на кабель питания, причём с обоих концов... знаете, такие полуцелиндры в платиковой обойме

всё очень зависит от ТЗ и специфики применения