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

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

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

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

вопрос опторазвязки никогда не стоял по ТЗ. кажется просто опасным, ИМХО. посему могу поделиться опытом
для 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 полный восторг

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

Конечно в первую очередь 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 не помню чей.

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

zltigo

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

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

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

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

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



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

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

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

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

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

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


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

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

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

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

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

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

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