Прошу прощения за терминологию: русскую или забыл или не знал.
Работаю с LPC1768. Пишу HAL- hardware abstraction layer (не знаю перевод). К своему ужасу обнаружил, что UART(перевод?) генерирует прерывания по фронту: если "Пустои передающий буфер", например, было замаскировано, то после снятия маски прерывание потеряно, даже если условие - буфер, по прежнему, пустой сохранилось. Сильно подозреваю, что то же ждет меня с другой переферией. Хочу услышать ваши советы.
1. Зачем Phillips так делает? В чем преимущества? Чем просто маски недостаточно?
2. Способы борьбы. Вдруг узнаю что-то, чего еще не знаю. Учтите, у меня за плечами более 30 лет опыта работы в СССР и США
3. Другой М3, например, Atmel SAM3... или что-то подобное. Предварительный обзор, сделаный до меня, рекомендавал NXP за лучший интерфейс с периферией. Кстати, на М3 мы переключились после провала использовать NIOS-II в среде ALTIUM TASKING. Их порт ни в какие ворота не лезит: все дырявое и корявое, хотя на бумаге все прекрасно...

Спасибо.

Сообщение отредактировал pitt - Oct 20 2012, 13:54

Из вашего поста непонятно, что вас интересует. UART или edge sensitive?


Наверное все Cortex-ы имеют ошибки-недостатки. Зачем переходить на другой?


Интересно, чем это интерфейс от NXP лучше, чем другие?

Меня UART НЕ интересует. Это просто удобный и понятный объект для обсуждения. Мой первый вопрос - попытка понять зачем и почему используется фронт, а не уровень. Не вижу никаких преимуществ, кроме недостатков. Может кто-то знает то, что я пока не знаю?

Прерывание по фронту, в том виде как оно есть, вызывает у меня серьезную изжогу, и потому, пока не поздно, ищу возможную альтернативу, а по сему, так как "все Cortex-ы имеют ошибки-недостатки" стараюсь не наступить на грабли, обтоптанные кем-то до меня. Например, STM32 имеет корявый I2C, а вот LPC в этом отношении нареканий не имеет. У меня несколько I2C devices, так что это серьезный довод. Мне нужен простой и надежный CAN и Ethernet., остальная перефирия не столь болезненна.

Не знаю точно, но предполагаю, что примеры, которые входят в состав eval-kit(а как по-русски?) легче сочетаются с документацией и более прозрачне для ЕЕ(элетронщики?), которые имеют первый голос при выборе микроконтроллера. Насколько я осведомлен, они тестируют эвал-киты инициализируя периферию(по-видимому, NXP оказался самым простым, удобным, понятным...) и на том удовлетворяются. Я embedded SOFTWARE инженер и слово SOFTWARE выделил и повторил не случайо. Электрики пишут и довольствуются кодом, а я разрабатываю программное обеспечение, а не код. Разница существенная и тема для другого отдельного топика, так что, пожалуйста, давайте не будем здесь ее обсуждать.

Сообщение отредактировал pitt - Oct 20 2012, 15:52

В NXP считают иначе:


Прерывания по уровню на входе нет, только по фронтам.


Почему "Прерывание по фронту, в том виде как оно есть, вызывает у меня серьезную изжогу"? Что с ними не так?

Если речь идет о внешнем прерывании, то я двумя руками "ЗА". Я могу сам определить что именно является событием: уровень или фронт, а если фронт, то какой и сам себе барин! А если, как в примере с UART то, извините, изжога.
Вот пример.
Есть обработчик ТХ interrupt. Есть несколько приложений, которые хотят им воспользоваться. Если мы имеем прерывание по уровню, то если буфер пустой и прерывание разрешено(размаскировано), то все, что должно сделать приложение - разрешить прерывание(убрать маску). Если маска уже убрана т.е. посылка идет, то это дело обработчика завершить посылку одного буфера, найти следущий и т.д., а если больше данных для пересылки - нет, замаскировать прерывание. Интерфейс просой и надежный. Если мы имеем дело с прерыванием по фронту, то маскировать прерывание нельзя - оно может быть потеряно, так как если в момент, когда буфер освободился(ФРОНТ) была маска, а когда маска была снята, то несмотря на то, что буфер-то пустой у нас нет фронта! Вот вам и изжога! Теперь приложение должно найти способ как инициировать прерывания. Тут сразу нужны mutexы и прочие накладные расходы, а вот зачем, когда можно все так просто...
Я не хочу долго распространяться о деталях. Если Вы подумаете, то разберетесь сами, а если нет, то поверьте мне и извиняйте дядьку...
Кстати, представьте себе что контролеер прерываний работал бы по фронту!!! Какая бы это была трагедия.

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

А зачем его вообще маскировать? Нету данных, буфер пустой, так и прерывание возникнуть не можеть. Чего вы маскированием добиваетесь. Вообще проблемы не вижу, что вас так напрягает?

Ответ посмотрите выше! Если прерывание по фронту, то Вы совершенно правы, но когда данные есть, а фронта нет, что тогда(суть проблемы!!!)? Если по уровню, то из прерывания невозможно выйти если не замаскировать.

Да, понял.
Нелегко увидеть проблему, если её нет.

Особенно если смотреть в другую сторону...

Ну, звыняй нас , дядка, непонятливых....

P.S. Привели бы пример кода, что ли, где приходится делать криво или как оно должно было быть по прямому.

http://bibliotekar.ru/encSlov/17/160.htm

Должен ли я с сожалением констатировать, что все три мои вопроса остались без ответа? Будет жаль.

Кстати, вот более подробное описание проблемы http://electronix.ru/forum/index.php?showtopic=106139

Сообщение отредактировал pitt - Oct 21 2012, 16:15

С LPC1xxx не работал, есть опыт с STM32F, SAM3 и EFM32. У них прерывания работают "по уровню": если разрешить прерывание по, например, TX для UART еще ДО передачи, то, обнаружив флаг TX, система вызовет прерывание. Если LPC1xxx действительно ведет себя по-другому, - это большая проблема для... NXP, поскольку лучше выбирать процессоры, которые ведут себя в таком вопросе как большинство.

Ну не знаю, Cortex-M, как и все ...