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

[Karol]

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

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

[spf]

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

Гальваническая развязка не панацея от индустриальных помех.

[Evgeny_CD]

Тут почитайте
http://www.caxapa.ru/faq/emc_immunity.html

[Muxa]

вопрос опторазвязки никогда не стоял по ТЗ. кажется просто опасным, ИМХО. посему могу поделиться опытом
для CAN используем TJA1050 + 6N137 + TMV0505S. приятно, что 1050 имеет выход опорного напряжения для смешения шины
что порадовало в LPC2119/29:
- большие запасы по питанию и тактовой частоте (110МГц легко)
- легко разводится в 2х слоях с 4 блокировочными конденсаторами с обратной стороны. не чувствителен к имп. помехам. смело разводим рядом имп. стабилизатор, если вокруг кварца есть кольцевой полигон
- надёжный и устойчивые PLL (без внешних фильтров)
- качественный АЦП. 8бит без специальных мер фильтрации питания и монтажа. если надо лучше, то всего 2 дросселя по нескольку мкГ
- быстрая работа во флэш, почти как с оперативкой за счёт 128бит шины флэш и конкурентной выборки команд/данных
- мощные и не звонкие ноги ПИО
- что бы сжечь, надо оч. сильно постараться
- будет (мож. уже) сертифицирован для систем жизнеобеспечения

недостатки:
- отвратительный юзермануал и апп. поддержка от филипса (правда есть форум). практически все программные примеры содержат фотальные ош. например, ош. инициализации той самой PLL
- неприятные ерраты, которых много и кремний планируют доработать только к концу 2006, возможно
-- баг фул CAN фильтрации.
-- пропуск прерываний при их конкуренции от таймеров и/или PWM
-- катастрофа с SPI, которую филипс называет фичей. при использовании SPI в мастемоде одну ногу надо завести через R на питание и не использовать
- негибкий ПИО. например выводы i2c только открытый коллектор, даже если i2c не нужен. есть и другие. много ног отведено под отладку. порт 1 всегда с подпоркой, а порт 0 без...
- неочевидная и медленная система прерываний (ARM7)
- невозможно с помощью ПО на ножке получить временнУю диограмму быстрее 3-4МГц (LPC)
- 2 питания и часто нужен супервайзер на сбросе. отсутствуют фьюзы. слабая защита кода (2119/29). нет EEPROM (всё не оч. существенно, т. к. имеет недорогие решения)
- на порядок более дорогие, чем, например, для AVR средства разработки (J-LINK $350). на Виглер + GNU ARM надо положить пол жизни, если Вы не линуксоид (ARM7) и важна лиц. чистота. относительно надёжно работает только их бутлодер, если только перешить загрузчик в котором тоже ошибки. операция сама по себе опасная, а дока имеет ош. приводящую к неправильной частоте UART

резюме: после AT91M4008 + SJA1000 от LPC 2129 полный восторг

[zltigo]

-- баг фул CAN фильтрации.
....
-- пропуск прерываний при их конкуренции от таймеров и/или PWM
....
- негибкий ПИО. например выводы i2c только открытый коллектор, даже если i2c не нужен. есть и другие. много ног отведено под отладку. порт 1 всегда с подпоркой, а порт 0 без...

1. А подробности/ссылки на описание бага в CAN? Это что-то новенькое, или имеется ввиду
errata?
2. Вопрос по прерываниям - аналогичен CAN
3. Имеется ввиду, что на порт 1 _входы_ всегда подтянуты к 1? Забавно. Проверю. А это докуметнировано для какогото LPC2xxx?

[Alex03]

Конечно в первую очередь erratа, притом последний (на LPC2292 v1.9)
Там помимо всего прочего 7 CAN глюков расписано. При этом от errata к errata CAN глюки не только добавлялись, но и исчезали!
По сути половину CAN фич приходится не использовать.
Из них мне лично пришлось:
1. Отказаться от использования 3-х передающих буферов. Хотя вроде как работали.
2. Учесть неприём чужого сообщения которое выйграло arbitration при передаче своего.
Лечится передачей всех сообщений командой SelfReceptionRequest вместо TransmittionRequest.
При этом все передаваемые сообщения принимаются назад. Ладно хоть можно настроить
AcceptanceFilter на неприём передаваемых сообщений (если конечно нет необходимости принимать
такие-же ID что и переавать).

FullCAN мне к счастью не нужен. Я 29-ти битные ID пользую.
А вот AcceptanceFilter радует. Правда я не понимаю как это у них реализовано. Эт с какой скоростью эти 2к шерстить надо. Впрочем требование по упорядоченности приводит к мысли что там кокойнить алгоритм типа половинного деления реализован.

Да и вообще первый опыт пользования CAN радует. У нас в одной сети было 4 девайса работало пару месяцев без проблем. При подсоединении пятого девайса ничего не работает. Сначала разбирались с этим пятым, а в результате разборок выяснилось что в разъёме подключенном к одному из 4-х девайсов были перепутанны 2 провода - GND и сигнальный CAN- . Как работало ваще не понятно - бронебойная шина.

С недостатками от Muxa почти полностью согласен, но местами не так категорично.
Про подтяжки пинов и открытые коллекторы/стоки у них в принципе расписано, но чтобы это всё найти и понять надо 3 дня потерять. Очень не прозрачно и не просто и однозначно.
Ну а SPI в мастермоде - ДАааа, сам дома 25-ти ваттным старющим паяльником паяльником резюк к лапе паял, была свободная. Кстати в последнем errata они ещё баг SPI опубликовали в slave mode.
Ещё отмечу очень "стильное" распределение ПИНов в 144-пиновых корпусах. Уверен на 99.9% что например LPC2194 на самом деле LPC2294 в меньшем корпусе.


У нас связка такая
LPC2292 - ADuM1201 - TJA1050 ну и DC-DC 0505S не помню чей.

[zltigo]

Про подтяжки пинов и открытые коллекторы/стоки у них в принципе расписано, но чтобы это всё найти и понять надо 3 дня потерять. Очень не прозрачно и не просто и однозначно.

Достаточно внимательно и более трех дней изучал все, что авторы сочли нужным изложить
относительно LPC2x24. Не заметил. Можете пальцем показать в любой документ
по LPC2xxx? Экспериментально проверить не проблема, конечно....

[Muxa]

zltigo

1. А подробности/ссылки на описание бага в CAN? Это что-то новенькое, или имеется ввиду
errata?
2. Вопрос по прерываниям - аналогичен CAN
3. Имеется ввиду, что на порт 1 _входы_ всегда подтянуты к 1? Забавно. Проверю. А это докуметнировано для какогото LPC2xxx?

1. Лист эррат можно взять на сайте филипса
http://www.semiconductors.philips.com/acro...sheets/2119.pdf
http://www.semiconductors.philips.com/acro...sheets/2129.pdf
2. По прерываниям от таймеров и PWM там же. про пропуск и ложные прерывания они отсылали к доке на ARM, но в последнюю ревизию мануала добавлена отделная секция. после 8051 или ATMega система прерываний в ARM7 настоящий ночной кошмар... кто только такое придумал и зачем?
3. открываем мануал (http://www.semiconductors.philips.com/acrobat/usermanuals/UM_LPC21XX_LPC22XX_2.pdf) и на странице 111 читаем:
"Port 0: Port 0 is a 32-bit bi-directional I/O port with individual direction controls for each bit. The operation of port 0 pins depends upon the pin function selected via the Pin Connect Block."
ниже про выводы I2C:
"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."
естественно подумать, что OD только для I2C режима. а вот и нет!

тоже самое про SPI SS. в последней редакции появилось римечание:
"Note: LPC2119/2129/2194/2292/2294 configured to operate as SPI master MUST select SSEL functionality on an apropriate pin and have HIGH level on this pin in order to act as a master"
даже прочитав это, трудно поверить, что если на SS проскочит помеха с низким уровнем, то SPI, невзирая на запрограммированный режим, преключится в слейв моду. а вот переключится!!

Alex03

FullCAN мне к счастью не нужен. Я 29-ти битные ID пользую.
А вот AcceptanceFilter радует

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

... но местами не так категорично

так уж получилось
а вообще проц оч. радует. и шины замечательная. была мысль перейти на связку SAM7S + (например) MCP2510, но отказались в основном из соображений надёжности
Alex03, я не вполе доволен 6N137. ограничивает скорость. интересно, какую опторазвязку Вы используете?

[zltigo]

zltigo
1. Лист эррат можно взять на сайте филипса
....
после 8051 или ATMega система прерываний в ARM7 настоящий ночной кошмар... кто только такое придумал и зачем?
....
3. открываем мануал ....

1...2. Где берут errata и что в них пишут, я в курсе. А вот ответов на вопросы я не получил.
Точнее опосредовано Вас следует понимать так - багов, кроме описанных в erratа не замечено,
кроме I2C портов c открытым колектором в любом режиме.

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

порт 1 всегда с подпоркой, а порт 0 без...

По "жуткой" системе прерываний, извините, очень смахивает на песни со слов "человека, который у нас пишет CAN "(AKA программист) не разобравшегося в вопросе. Cложнось и 'непривычность' устройства не всегда признак дурости его создателей. Мне, повидавшему многое, нравится очень. Баги от филипса не нравятся а система прерываний для встаиваемого железа хороша.

[spf]

Баги от филипса не нравятся а система прерываний для встаиваемого железа хороша.

Чем же хороша, если не секрет?
Судя по теме http://electronix.ru/forum/index.php?showtopic=9336 нет ничего хорошего, тем более для встраиваемых систем.
- Приоритетов можно сказать нет.
- Время реакции как трамвайная остановка.

[zltigo]

- Время реакции как трамвайная остановка.

Ну во первых, не надо делать окончательных выводов из отрывка статьи. Для этого как минимум надо иметь:
- всю статью
- знать а как оно удругих-то в предлагаемых услових реализовано и можно-ли вообще ЛУЧШЕ
сделать? И намного лучше? И какой ценой?

Попробую чуть-чуть подтолкнуть к самостоятельному мышлению:
- У всех систем процессор+контроллер прерываний имеется задержка в единицы тактов для
того, что в отрывке статьи называется "синхронизатором". Это неизбежность. Возможно у кого-то
тактом больше-тактом меньше;
- Все процессоры вынуждены завершить после этого еще и выполняемую команду. Если эта команда длинная, то естественно время реакции растет. Хотите быстрее - НЕ ИСПОЛЬЗУЙТЕ ИХ, только
примитивные за один-пару тактов. будет ДАЖЕ лучше, чем с поминаемым здесь рефренсным 51 контроллером с его 12 тактами на команду;
- Время исполнения команды очень разное и зависит от удачи по вычитыванию из флэша? Да
разное. А кто-то придумал уже предсказатель наступающего прерывания? :-) НЕТ! Хотите избавиться
от этого - отключите - получите опять рефренсный 51 работающий на 20MHz c 50ns флэшем.
- далее в отрывке статьи начинается приплетание ко времени реакции еще и программ - типа
а вот если весь контекст сохранять тогда еще временииии.... А если с умом, то помеееенньше...
А, что в других контроллерах программы обработчики не нужны? Да я понимаю, что в идеале
иметь не только стек аппаратно переключенный но и свой набор регистров. Давайте назовите кто такое имеет.
- Далее вообще потрясающий факт :-))) типа если обрабатывается высокоприоритетное, то низкоприоритетное ждет. А, что на одноядерных чипах ДРУГАЯ реализация возможна? НЕТ.

В общем Вы прочитав статью с перечислением фактов и только фактов восприняли ее КАК ПЕРЕЧЕНЬ ФАТАЛЬНЫХ НЕДОСТАТКОВ исключительно LPC, что и явилось Вашей ошибкой.

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

- Приоритетов можно сказать нет.

Три уровня глобальных FIQ VecIRQ IRQ и 16 векторных слотов для произвольного назначения приоритетов.. Может мы о разных контролерах разговариваем? Вроде нет :-(

[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 произвольного числа регистров и т.д.?
Хорошо конечно когда сразу, но в большинстве случаев не критично. А там где критично надо изначально подходить к выбору чипов в системе с учётом этого.
Вот потеря прерываний, даже расписанная в еррата-х меня печалит больше!
ИМХО.

[zltigo]

2 zltigo
Таблица Pin description for нужный чип.
Далее читаем Note-сы для каждого порта. Например у меня для LPC2292/2294
.....
Вот потеря прерываний, даже расписанная в еррата-х меня печалит больше!
ИМХО.

1.Спасибо. Увидел и в своем LPC2114/24 примечание. Успокоился.
2.Если имеется ввиду описанная потеря от Timer и PWM, то ситуация такого использования
мне в голову особо не приходит. Ибо прерывания в подобных случаях это только попытка
заменить отсутсствующие начисто (жаль :-( )встроенные аппаратные средства для взаимосвязки всего этого богатства заготовок таймеров и ШИМов. Предполагаю, что нужный результат почти всегда можно получить при небольшом довеске внешней логики без использования множественных источников прерываний.

[Alex03]

2 zltigo
Вот потеря прерываний, даже расписанная в еррата-х меня печалит больше!
ИМХО.

2.Если имеется ввиду описанная потеря от Timer и PWM, то ситуация такого использования
мне в голову особо не приходит.

Там ещё в регистры SPI писать нельзя чтоб от него не потерять прерывание. Что в принципе тоже не страшно.
А печалит меня то что такие баги вообще есть, и не обнаружены сразу.
Видимо филипс очень сильно торопился, и сделал из пользователей тестеров.
Подозреваю что и сейчас часть глюков не выявлена.
Ну а EXTINT и VPBDIV - эт вообще откуда взялось? Никак не связанные вещи. Похоже что 2 сигнала одним именем обозвали и т.д.

[spf]

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

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

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

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

[spf]

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

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

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

[zltigo]

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

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

[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.

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

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

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

[Andy Mozzhevilov]

3. Имеется ввиду, что на порт 1 _входы_ всегда подтянуты к 1? Забавно. Проверю. А это докуметнировано для какогото LPC2xxx?

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

[zltigo]

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

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

[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 раза минимум, и упростило бы сам обработчик.
Ну а ногодрыгательством и програмной реализацией неких "по праву аппаратных" протоколов може убить любую производительность.

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

[Andy Mozzhevilov]

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

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

LPC213x

[Karol]

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

[Muxa]

zltigo
1. Лист эррат можно взять на сайте филипса
....
после 8051 или ATMega система прерываний в ARM7 настоящий ночной кошмар... кто только такое придумал и зачем?
....
3. открываем мануал ....

1...2. Где берут errata и что в них пишут, я в курсе...

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

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

[Muxa]

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

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

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

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

2 All

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

всё так.

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

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

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

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

[moonrock]

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

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

[zltigo]

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

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

[Muxa]

moonrock

А какие-такие ложные прерывания?

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

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

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

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

[Muxa]

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

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

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

[Andy Mozzhevilov]

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

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

Какую конкретно, МИП, НИП? Какая степень жетскости испытаний? Если МИП, то по какой схеме? Провод-провод, провод земля?

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

Наверное, можно было бы просто применить кабель в экране.

[Dimmix]

какой максимальный кварц можно поставить в lpc2292 чтоб он работал без глюков и где можно найти даташит или апнот по разводке кварца

Сообщение отредактировал Dimmix - Jan 25 2012, 20:59

Причина редактирования: Научитесь грамотно писать

[GetSmart]

У меня 2294 работал с кварцем 14,7456 и внутри умноженным на 4 без глюков.

[Dimmix]

есть плата на 2292 она тоже работала с кварцем на 20 с чем то, и вдруг заглючила, корпус кварца принудительно запаян на граунд, т .е. видимо были проблемы с запуском.
В общем плата поработала и встала. Может емкости на 20пф накрылись конечно.

[GetSmart]

Так можно и кварц обвинять.
Естественно нужно выпаять кварц (это проще чем проц), заменить кварц на 100% рабочий и проверять. Кондёры тоже.

[Dimmix]

Может лучше поставить генератор что то в плане VCTCXO, только по шиту не ясно куда его заводить

[GetSmart]

XTAL1 - вход для внешнего генератора 142 пин в LQFP

[Dimmix]

Похоже кварц паяли чем то активным, плата вроде запустилась после промывки, но все равно виснет программа.
Почемуто невозможно найти шит как его шить через ИСП, и флеш маджик тоже что то ругается.