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

Поделитесь пожалуйста, проблемами 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"?

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

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

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



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

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