прерывания по фронту(edge sensitive) Опции

[pitt]

Прошу прощения за терминологию: русскую или забыл или не знал.
Работаю с 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

[pitt]

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

Спасибо.

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

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

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

[jcxz]

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

По-моему - проблема выеденного яйца не стоит.

Если при завершении передачи (нет больше данных для передачи) в ISR вы маскируете THRE, то потом, когда фоновая задача хочет записать новые даные для передачи, она делает следующее:
1. мьютекс/запрет прерываний.
2. проверка - THRE замаскировано(запрещено)? нет - переход к 5.
3. размаскируем THRE
4. заполняем TX fifo.
5. освобождение мьютекса/разрешение прерываний.

Если при завершении передачи (нет больше данных для передачи) в ISR вы не маскируете THRE, а просто выходите из ISR (предварительно сбросив программный флаг "TX в процессе"), то потом, когда фоновая задача хочет записать новые даные для передачи, она делает следующее:
1. мьютекс/запрет прерываний.
2. проверяете флаг "TX в процессе". Если стоит - переход к 5.
3. уставливаем флаг "TX в процессе"
4. заполняем TX fifo.
5. освобождение мьютекса/разрешение прерываний.

[KnightIgor]

По-моему - проблема выеденного яйца не стоит.

Если рассуждать феноменологически - есть процессор, который продается, значит написать для него работоспособный код возможно. Наверное, и приведеный алгоритм применим. Однако меня настораживает то (я еще не работал с LPC1xxx), что NXP выпендрился и избрал особый путь в генерации прерываний от флагов периферии для своих Cortex. Из моего опыта я вижу, что по крайней мере тут 1:3 не в пользу NXP в сравнении с другими тремя распространенными Cortex-Mx. А как я понял из контекста автора ветки, речь идет и о выборе, в сторону какого Cortex грабли развернуть.

[gladov]

NXP выпендрился и избрал особый путь в генерации прерываний от флагов периферии для своих Cortex. Из моего опыта я вижу, что по крайней мере тут 1:3 не в пользу NXP в сравнении с другими тремя распространенными Cortex-Mx.

Дело в том, что NXP взял за основу UART 16650. Именно эта архитектура в точности повторена в контроллерах NXP, а, как известно, на этой архитектуре десятилетиями работали компьютеры. Так что оба подхода: "классический микроконтроллерный" и от NXP имеют право на жизнь и тут еще можно поспорить какой вариант более классический и распространенный.