прерывания по фронту(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

[_Артём_]

К своему ужасу обнаружил, что UART(перевод?) генерирует прерывания по фронту: если "Пустои передающий буфер", например, было замаскировано, то после снятия маски прерывание потеряно, даже если условие - буфер, по прежнему, пустой сохранилось. Сильно подозреваю, что то же ждет меня с другой переферией. Хочу услышать ваши советы.
1. Зачем Phillips так делает? В чем преимущества? Чем просто маски недостаточно?

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

3. Другой М3, например, Atmel SAM3... или что-то подобное.

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

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

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

[pitt]

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

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

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

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

[_Артём_]

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

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

• Each port pin can be programmed to generate an interrupt on a rising edge, a falling
edge, or both.
• Edge detection is asynchronous, so it may operate when clocks are not present, such
as during Power-down mode. With this feature, level triggered interrupts are not
needed.

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

Прерывание по фронту, в том виде как оно есть, вызывает у меня серьезную изжогу, и потому, пока не поздно, ищу возможную альтернативу, а по сему, так как "все Cortex-ы имеют ошибки-недостатки" стараюсь не наступить на грабли, обтоптанные кем-то до меня.

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

[pitt]

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

[AHTOXA]

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

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

[ar__systems]

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

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

[pitt]

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

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

[_Артём_]

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

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

[pitt]

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

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

[_Артём_]

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

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

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

[pitt]

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

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

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

[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

[KnightIgor]

Прошу прощения за терминологию: русскую или забыл или не знал.
Работаю с LPC1768. Пишу HAL- hardware abstraction laye
...
Другой М3, например, Atmel SAM3... или что-то подобное.

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

[_Артём_]

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

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

34.4.2.9 Level-sensitive and pulse interrupts
The processor supports both level-sensitive and pulse interrupts. Pulse interrupts are also
described as edge-triggered interrupts.

[pitt]

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

Поделитесь пожалуйста, проблемами SAM3. Про STM32F известно, что I2C кривой

Спасибо

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

В настоящий момент УТВЕРЖДАЮ, что LPC1768 UART THRE interrupt is edge sensitive, т.е по фронту. На основаниии предыдущего опыта ожидаю аналогичного поведения с CAN.
Пожалуйста укажите процитированный документ иначе...

Спасибо

[KnightIgor]

Поделитесь пожалуйста, проблемами SAM3.

Принципиальных, кроме начальных проблем с поставками и старыми библиотеками, не вижу. Мне нравится концепция периферии SAM3, особенно PDA. А I2C там вообще делает все сам; SPI|I2S очень гибкий. SAM3U - пока единственный Cortex-M3 с High-Speed USB PHY.

Про STM32F известно, что I2C кривой

Верно лишь частично: интерфейс стабилен и работоспособен, если разобраться, на что нужно время. Он не кривой, он по-просту перемудренный (из-за двойной буферизации и особых случаев выдачи ACK/NACK) и не очень быстрый (1MHz появился лишь у F2xx|F4xx). STM еще не успел выдать "на гора" свою кривую синхронную библиотеку, как I2C уже летал у меня с использованием прерываний и DMA.

В STM подкупает отличный "drop in replacement" по всей семье Cortex-Mx, доступность и цены: на правильно разведеную плату можно поставить как 1xx, так и вплоть до 4xx, хорошо скалируя производительность.

[pitt]

Принципиальных, кроме начальных проблем с поставками и старыми библиотеками, не вижу. Мне нравится концепция периферии SAM3, особенно PDA. А I2C там вообще делает все сам; SPI|I2S очень гибкий. SAM3U - пока единственный Cortex-M3 с High-Speed USB PHY.

Верно лишь частично: интерфейс стабилен и работоспособен, если разобраться, на что нужно время. Он не кривой, он по-просту перемудренный (из-за двойной буферизации и особых случаев выдачи ACK/NACK) и не очень быстрый (1MHz появился лишь у F2xx|F4xx). STM еще не успел выдать "на гора" свою кривую синхронную библиотеку, как I2C уже летал у меня с использованием прерываний и DMA.

В STM подкупает отличный "drop in replacement" по всей семье Cortex-Mx, доступность и цены: на правильно разведеную плату можно поставить как 1xx, так и вплоть до 4xx, хорошо скалируя производительность.

Спасибо. Атмел знаю по AVR а от STM получил discovery board и ... примеры кода написаны электриками, а не software professionals и поэтому наши электрики "забраковали".

[_Артём_]

Атмел знаю по AVR

Про АВР мы ту, наверное все знаем. Но АВР уже устарело.

а от STM получил discovery board и

А мне не прислали...Ну и что?

... примеры кода написаны электриками, а не software professionals и поэтому наши электрики "забраковали".

А кто ж тогда писал примеры для LPC11? Индусские "электрики"?
Или у STM ещё хуже?

[pitt]

Про АВР мы ту, наверное все знаем. Но АВР уже устарело.


А мне не прислали...Ну и что?


А кто ж тогда писал примеры для LPC11? Индусские "электрики"?
Или у STM ещё хуже?

Старый конь борозды не потит: каждый наш продукт содержит несколько AVR8 и продолжаем под него писать!
Мне неважно откуда электрики: их код видно издалека...
<<Индусские "электрики">> не думают, а делают как им сказали.

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

[pitt]

http://electronix.ru/forum/index.php?showt...p;#entry1104736
Можно и проще, и изящнее, и без мютекса!
А проблема в самом наличии проблемы, где ее вообще не должно было быть!

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

А Вас не затруднит указать хотя бы одно преимущество подхода "от NXP"?

Сообщение отредактировал pitt - Oct 22 2012, 23:48

[KnightIgor]

Дело в том, что NXP взял за основу UART 16650... и тут еще можно поспорить какой вариант более классический и распространенный.

О фактах не спорят: 1:3 не в пользу NXP. И даже 1:4, если покопать TI (Luminary).

[Allregia]

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

Примеры, которые с eva-kit'ами, пишут не электронщики а индусы, причем самые что ни на есть software professionals, ну которые после "трехмесячных курсов переквалификации из погонщиков слонов в программисты"

Я embedded SOFTWARE инженер и слово SOFTWARE выделил и повторил не случайо. Электрики пишут и довольствуются кодом, а я разрабатываю программное обеспечение, а не код. Разница существенная и тема для другого отдельного топика, так что, пожалуйста, давайте не будем здесь ее обсуждать.

Это уже на манечку похоже...

[IgorKossak]

Хватит оффтопа, давайте вернёмся к обсуждению темы (если ещё есть, что сказать).
Модератор.