[let's see 0]

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

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

 

Спасибо

 

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

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

Пожалуйста укажите процитированный документ иначе...

 

Спасибо

[KnightIgor 2]

Поделитесь пожалуйста, проблемами 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, хорошо скалируя производительность.

 

 

[let's see 0]

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

[Артём__ 0]

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

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

 

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

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

 

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

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

Или у STM ещё хуже?

[let's see 0]

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

 

 

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

 

 

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

Или у STM ещё хуже?

Старый конь борозды не потит: каждый наш продукт содержит несколько AVR8 и продолжаем под него писать!

Мне неважно откуда электрики: их код видно издалека...

<<Индусские "электрики">> не думают, а делают как им сказали.

[jcxz 184]

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

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

 

Если при завершении передачи (нет больше данных для передачи) в 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 2]

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

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

 

[gladov 0]

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

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

[let's see 0]

http://electronix.ru/forum/index.php?showt...p;#entry1104736

Можно и проще, и изящнее, и без мютекса!

А проблема в самом наличии проблемы, где ее вообще не должно было быть!

 

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

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

Изменено 22 октября, 2012 пользователем pitt

[KnightIgor 2]

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

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

 

[Allregia 9]

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

 

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

 

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

 

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

[IgorKossak 0]

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

Модератор.