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

Спасибо.

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


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


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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо


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

Спасибо

Принципиальных, кроме начальных проблем с поставками и старыми библиотеками, не вижу. Мне нравится концепция периферии 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 и поэтому наши электрики "забраковали".

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


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


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

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

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

Если при завершении передачи (нет больше данных для передачи) в 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. освобождение мьютекса/разрешение прерываний.

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

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

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


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

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

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



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

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