Помехоустойчивость LPC2xxx, Способны ли работать без гальвпанической развязки Опции

[Karol]

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

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

[Alex03]

2 zltigo

> 3. Открываем,читаем,закрываем... А где? в отцитированном подтверждение
> Вашего утверждения:
>> порт 1 всегда с подпоркой, а порт 0 без...

Глава PIN CONFIGURATION из юзер мануала.
Таблица Pin description for нужный чип.
Далее читаем Note-сы для каждого порта. Например у меня для LPC2292/2294

Note: All Port 0 pins excluding those that can be used as A/D inputs (P0.27, P0.28, P0.29
and P0.30) are functionally 5V tolerant. If the A/D converter is not used at all, pins
associated with A/D inputs can be used as 5V tolerant digital IO pins. See "A/D Converter"
chapter for A/D input pin voltage considerations.

Note: All Port 1 pins are 5V tolerant with built-in pull-up resistor that sets input level to high
when corresponding pin is used as input.

Note: All Port 2 pins excluding those that can be used as A/D inputs (P2.30 and P2.31)
are functionally 5V tolerant. Port 2 pin configured to perform an input function will use builtin
pull-up resistor to set the default input level to high. If the A/D converter is not used at all,
pins associated with A/D inputs can be used as 5V tolerant digital IO pins. See "A/D
Converter" chapter for A/D input pin voltage considerations.

Note: All Port 3 pins excluding those that can be used as A/D inputs (P3.28 and P3.29)
are functionally 5V tolerant. Port 3 pin configured to perform an input function will use builtin
pull-up resistor to set the default input level to high. If the A/D converter is not used at all,
pins associated with A/D inputs can be used as 5V tolerant digital IO pins. See "A/D
Converter" chapter for A/D input pin voltage considerations.

Далее включаем дедуктивный метод Шерлока Холмса насчёт P0.

А вот про I2C в этой же таблице:

P0.2 SCL I2C clock input/output. Open drain output (for I2C compliance).
CAP0.0 Capture input for TIMER0, channel 0.

P0.3 SDA I2C data input/output. Open drain output (for I2C compliance).
MAT0.0 Match output for TIMER0, channel 0.
EINT1 External interrupt 1 input.

Читая это любой читатель поймёт что Open drain только для I2C, ан нет!

У атмела подход к конфигурянию портов поприятней ИМХО.

2 Muxa
> Alex03, я не вполе доволен 6N137. ограничивает скорость. интересно, какую опторазвязку
> Вы используете?

Я же написал ADuM1201, тока эт уже не опто-, но гальвано-. Работает нормально и габариты клёвые. Мы ими и SPI на ~5MHz развязывали.


2 All

Про прерывания.
Да нормальная система. Любая логика приоритетов програмно реализуется ежели надо.
Скорость реакции? А оно надо? Ну что такого вы делаете чтобы на прерывание за 1 такт реагировать надо было? Оправдывает ли это отказ от команд типа LDM произвольного числа регистров и т.д.?
Хорошо конечно когда сразу, но в большинстве случаев не критично. А там где критично надо изначально подходить к выбору чипов в системе с учётом этого.
Вот потеря прерываний, даже расписанная в еррата-х меня печалит больше!
ИМХО.

[spf]

Любая логика приоритетов програмно реализуется ежели надо.

И нафига тогда контроллеры прерываний делают?

Про вложенные прерывания слыхали?

Реализуйте:
В любой момент обработки прерывания L с приоритетом LOW, если формируется запрос прерывания HIGH то перейти к обработчику H.

[Alex03]

Любая логика приоритетов програмно реализуется ежели надо.

И нафига тогда контроллеры прерываний делают?

Про вложенные прерывания слыхали?

Реализуйте:
В любой момент обработки прерывания L с приоритетом LOW, если формируется запрос прерывания HIGH то перейти к обработчику H.

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

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


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

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

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

[spf]

Реализуйте:
В любой момент обработки прерывания L с приоритетом LOW, если формируется запрос прерывания HIGH то перейти к обработчику H.

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

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

Сколько Вам надо прерываний в одном проекте?

10

И сколько уровней их вложенности?

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

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

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

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

[Alex03]

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

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

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

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

// Macros for Interrupt Nesting
#define IENABLE /* Nested Interrupts Entry */ \
__asm { MRS LR, SPSR } /* Copy SPSR_irq to LR */ \
__asm { STMFD SP!, {LR} } /* Save SPSR_irq */ \
__asm { MSR CPSR_c, #0x1F } /* Enable IRQ (Sys Mode) */ \
__asm { STMFD SP!, {LR} } /* Save LR */ \

#define IDISABLE /* Nested Interrupts Exit */ \
__asm { LDMFD SP!, {LR} } /* Restore LR */ \
__asm { MSR CPSR_c, #0x92 } /* Disable IRQ (IRQ Mode) */ \
__asm { LDMFD SP!, {LR} } /* Restore SPSR_irq to LR */ \
__asm { MSR SPSR_cxsf, LR } /* Copy LR to SPSR_irq */ \

Сколько Вам надо прерываний в одном проекте?

10

И сколько уровней их вложенности?

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

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

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

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

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

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

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

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