let's see 0 21 октября, 2012 Опубликовано 21 октября, 2012 · Жалоба С LPC1xxx не работал, есть опыт с STM32F, SAM3 и EFM32. У них прерывания работают "по уровню": если разрешить прерывание по, например, TX для UART еще ДО передачи, то, обнаружив флаг TX, система вызовет прерывание. Если LPC1xxx действительно ведет себя по-другому, - это большая проблема для... NXP, поскольку лучше выбирать процессоры, которые ведут себя в таком вопросе как большинство. Поделитесь пожалуйста, проблемами SAM3. Про STM32F известно, что I2C кривой Спасибо Ну не знаю, Cortex-M, как и все ... В настоящий момент УТВЕРЖДАЮ, что LPC1768 UART THRE interrupt is edge sensitive, т.е по фронту. На основаниии предыдущего опыта ожидаю аналогичного поведения с CAN. Пожалуйста укажите процитированный документ иначе... Спасибо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 21 октября, 2012 Опубликовано 21 октября, 2012 · Жалоба Поделитесь пожалуйста, проблемами 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 21 октября, 2012 Опубликовано 21 октября, 2012 · Жалоба Принципиальных, кроме начальных проблем с поставками и старыми библиотеками, не вижу. Мне нравится концепция периферии 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 21 октября, 2012 Опубликовано 21 октября, 2012 · Жалоба Атмел знаю по AVR Про АВР мы ту, наверное все знаем. Но АВР уже устарело. а от STM получил discovery board и А мне не прислали...Ну и что? ... примеры кода написаны электриками, а не software professionals и поэтому наши электрики "забраковали". А кто ж тогда писал примеры для LPC11? Индусские "электрики"? Или у STM ещё хуже? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
let's see 0 21 октября, 2012 Опубликовано 21 октября, 2012 · Жалоба Про АВР мы ту, наверное все знаем. Но АВР уже устарело. А мне не прислали...Ну и что? А кто ж тогда писал примеры для LPC11? Индусские "электрики"? Или у STM ещё хуже? Старый конь борозды не потит: каждый наш продукт содержит несколько AVR8 и продолжаем под него писать! Мне неважно откуда электрики: их код видно издалека... <<Индусские "электрики">> не думают, а делают как им сказали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 191 22 октября, 2012 Опубликовано 22 октября, 2012 · Жалоба Должен ли я с сожалением констатировать, что все три мои вопроса остались без ответа? Будет жаль. По-моему - проблема выеденного яйца не стоит. Если при завершении передачи (нет больше данных для передачи) в 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 22 октября, 2012 Опубликовано 22 октября, 2012 · Жалоба По-моему - проблема выеденного яйца не стоит. Если рассуждать феноменологически - есть процессор, который продается, значит написать для него работоспособный код возможно. Наверное, и приведеный алгоритм применим. Однако меня настораживает то (я еще не работал с LPC1xxx), что NXP выпендрился и избрал особый путь в генерации прерываний от флагов периферии для своих Cortex. Из моего опыта я вижу, что по крайней мере тут 1:3 не в пользу NXP в сравнении с другими тремя распространенными Cortex-Mx. А как я понял из контекста автора ветки, речь идет и о выборе, в сторону какого Cortex грабли развернуть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gladov 0 22 октября, 2012 Опубликовано 22 октября, 2012 · Жалоба NXP выпендрился и избрал особый путь в генерации прерываний от флагов периферии для своих Cortex. Из моего опыта я вижу, что по крайней мере тут 1:3 не в пользу NXP в сравнении с другими тремя распространенными Cortex-Mx. Дело в том, что NXP взял за основу UART 16650. Именно эта архитектура в точности повторена в контроллерах NXP, а, как известно, на этой архитектуре десятилетиями работали компьютеры. Так что оба подхода: "классический микроконтроллерный" и от NXP имеют право на жизнь и тут еще можно поспорить какой вариант более классический и распространенный. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
let's see 0 22 октября, 2012 Опубликовано 22 октября, 2012 (изменено) · Жалоба http://electronix.ru/forum/index.php?showt...p;#entry1104736 Можно и проще, и изящнее, и без мютекса! А проблема в самом наличии проблемы, где ее вообще не должно было быть! Дело в том, что NXP взял за основу UART 16650. Именно эта архитектура в точности повторена в контроллерах NXP, а, как известно, на этой архитектуре десятилетиями работали компьютеры. Так что оба подхода: "классический микроконтроллерный" и от NXP имеют право на жизнь и тут еще можно поспорить какой вариант более классический и распространенный. А Вас не затруднит указать хотя бы одно преимущество подхода "от NXP"? Изменено 22 октября, 2012 пользователем pitt Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 23 октября, 2012 Опубликовано 23 октября, 2012 · Жалоба Дело в том, что NXP взял за основу UART 16650... и тут еще можно поспорить какой вариант более классический и распространенный. О фактах не спорят: 1:3 не в пользу NXP. И даже 1:4, если покопать TI (Luminary). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Allregia 9 24 октября, 2012 Опубликовано 24 октября, 2012 · Жалоба Не знаю точно, но предполагаю, что примеры, которые входят в состав eval-kit(а как по-русски?) легче сочетаются с документацией и более прозрачне для ЕЕ(элетронщики?), которые имеют первый голос при выборе микроконтроллера. Насколько я осведомлен, они тестируют эвал-киты инициализируя периферию(по-видимому, NXP оказался самым простым, удобным, понятным...) и на том удовлетворяются. Примеры, которые с eva-kit'ами, пишут не электронщики а индусы, причем самые что ни на есть software professionals, ну которые после "трехмесячных курсов переквалификации из погонщиков слонов в программисты" :) Я embedded SOFTWARE инженер и слово SOFTWARE выделил и повторил не случайо. Электрики пишут и довольствуются кодом, а я разрабатываю программное обеспечение, а не код. Разница существенная и тема для другого отдельного топика, так что, пожалуйста, давайте не будем здесь ее обсуждать. Это уже на манечку похоже... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 24 октября, 2012 Опубликовано 24 октября, 2012 · Жалоба Хватит оффтопа, давайте вернёмся к обсуждению темы (если ещё есть, что сказать). Модератор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться