Подбираю контроллер по задаче. До этого работал только с Atmel, но начал сомневаться с новой задачей.
Задача:
USB 2.0 в режиме эммуляции RS232, FlashDisk, возможно еще одного устройства
RS232 - 2 штуки
SPI - 2 штуки, но можно обойтись и одной
I2C или встроенные часы CMOS
Небольшое количество дополнительных портов в/в
АЦП - 2 канала (10 бит за глаза, контроль питания)
Тактовая от 32МГц и выше
Разрядности хватило бы и 8 бит, но не нашел подходящего (все операции байтовые)
ОЗУ - 32 и 64(лучше) кБайт
Flash для программы 256К
Программа, скорее всего, будет на основе FreeRTOS

На данный момент смотрел варианты AT91SAM7S256 и LPC2146. По второму вопрос: Real-time clock у них - настоящие cmos часы работающие при полном выключении питания и подключенной батарейке или же это не будет аналогом а ля PCF8583? Снижение цены решения очень приветствуется.

STM32!

Есть юсб, для уарт и масс сторадж уже всё написано в примерах
СПИ до 3 штук
втроенные RTC
АЦП - явно больше 2 каналов, заявлено 12 бит, но думаю 10 честных там можно наскрести
тактовая до 72
озу до 64к (в том числе в корпусе 64tqfp)
порт FreeRTOS есть

К тому же либа чтобы не изучать имена регистров, сэмплы на всю переферию и внятная документация

А вот именно помянутое выше и есть бочка дегтя ибо документация ПРОСТО НИКАКАЯ, багов много, а вместо документации и внятного описания багов предлагаются ПРИМИТИВНЫЕ либы. Если функционал
либ устаивает хоть как-то, то тогда можно пользовать. В противном случае это будет непрерывная лабораторная работа по изучению.
Со скоростью исполнения из Flash - традиционно тормозное.... Они, конечно в первых рядах выступили (по этой причине есть баги и в ядре Cortex) и цена разумна. Но на этом достоинства кончаются.
Лучше начинать с LPC21/2300 c перспективой перехода на более дешевые LPC1700

Да. Только errata гляньте.

Для at91 эт к сожалению не так. Часов там нет,есть только дебильный RTT, непригодный вообще ни для чего.

Да вполне нормальные там либы. Не супер, но у STM32 они уже выглядят чуть "прямоугольнее", чем были раньше у STR91. И багов не так уж много, в основном это опечатки, которые к тому же достаточно быстро исправляются. Типа у филипса их нет Хотя я сам непосредственно с филипсами не работаю, но коллеги пользуют и филипсы, и адуки. Не скажу, чтобы мне сильно хотелось на них переходить Документация на адуки - это вообще ж...

Со скоростью выполнения у STM32 и правда что-то немного не то, сейчас вот разбираюсь - может я чего-то не так понял.

Присоединяюсь к рекомендации (если, конечно, USB Full Speed устраивает). Документация - на уровне, позволяет освоить без обращения в техподдержку. Примеров и софта - сколько хочете. Еррата - неторопливо, но уменьшается.

Не могу не высказать своего мнения библиотекам от ST для их кортексов. Чрезмерная избыточность кода! Разве что посмотреть и сделать по своему. И быстрее будет работать и вдвое компактнее окажется. На двух проектах уже в этом убедился. Кстати, в ИАРе и в С++ с этой библиотекой были проблемы.
Это моё личное мнение, спорить ни с кем не буду.

А что там конкретнее не то? Большие тормоза? На какой частоте?

Только начинаю щупать этот МК (раньше из ST пользовался STR91)
На частотах 48-72МГц нужно ставить 2 цикла задержку на память, так вот, на глаз (простые действия типа цикла и дергания ножками) имеем примерно 62% производительности от той, которая должна быть при нулевой задержке. Размещение в ОЗУ почему-то на результат не повлияло, может ошибся где-то. Отключение предвыборки производительность ещё больше снижает. Пока этот вопрос отложил, доделаю другую работу - вернусь к исследованиям.


Да, это есть. Зато по этим исходникам библиотек легко можно разобраться что к чему, отдельные части при желании можно и переписать.
Пользуюсь кейлом, проблем с подключением нет.

STM32 - почитаю, спасибо!


Понятно. Я и сам на них обратил внимание.

Про Атмел я и сам знаю. А вот в Флипсе часы настоящие? Если да, то экономия корпуса, да и гемора меньше с обращением.

С Адуками как-то связывался, но там нужен был очень быстрый АЦП. Так и отложилось в пмяти, что АД - это для оцифровки.

А когда можно будет пощупать LPC1700?
И какие самые маленькие корпуса у них будут?

Оттуда => http://www.nxp.com/news/content/file_1478.html


См. сами на сайте производителя http://www.standardics.nxp.com/products/lpc1000/lpc17xx/

Щупать можно в 1 квартале, а вот с корпусов они начали с больщих практически это конкуренты, в том числе есть pin-to-pin совместимые их-же LPC2300

Посмотрел STM и новые NXP.
Понравились (подошли) контроллеры LPC1756 и STM32F103VC. Филипсовская даже интереснее меньшим корпусом (80). Вот только ее еще нету в природе. А есть ли еще какие сображения по их выбору?

Тогда берите пока LPC23xx

А почему не LPC2146, ведь у нее и пинов меньше и МАС-а нет, дешевле будет? Может есть другие соображения?

Нормально, просто Вы как-то перевели речь на свежие 80pin . LPC213x/4x у меня на данный момент самые массовые в применении. звестные баги на данный момент пофиксены практически все. Уточните только о SPI - они имееют ограниченя по скорости разные по функционалу.

На один канал SPI ,будут подключены две флешки AT45DB, а на второй периферийное slave устрйство с потоком до 1мб. В прототипе устройства они вешались все на один канал AT91SAM7X, но от сети отказались и она более не нужна. Встал вопрос, спускаться на SAM7S или брать нечто другое.

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

По поводу функционала - относитесь к этой либе просто как к врапперу регистров. Производительность вполне разумная, а баги в ядре кортекса будут у всех производителей.

Те, кого не смущает наличие неразумно большое количество документированых и не документированных багов и, повторяю, устраивает минималистичное использование ресурсов через "библиотеки" могут пользовать. Остальным рекомендую крепко подумать, даже если формально есть в нем нечно очень привлекательное. Я например, в свое время из-за HDLC возился с их-же STR711. В результате количество хоть и несмертельных багов, неудобств, кривостей для меня перевесило все прочее. Традичия такая у ST нехорошая продолжилась и на STR9 (в конце концов плюнул на производительность и ужался на ARM7 от NXP), и на STM , хотя от STM еще не отказался окончательно

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

Проблем с ИАРом у меня нету, а если вы используете в С++ библиотеки наисанные на Си и у вас возникают проблемы, то вы скорее всего не умеете работать с кодом содержащим и С и С++ код.

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

с этим у меня нет проблем уже как лет двадцать с гаком

Насчет библиотеки абсолютно верно.
По стилю тех библиотек видно, что писались они зелеными студентами.
Либы совершенно в диссонансе с такими культовыми вещами как ARTX и FS у Keil-а, uCOS , FreeRTOS и т.д. и по стилю именований и по стилю передачи параметров.
В либах совершенно обходятся стороной реализации асинхронных обменов с периферией через буферы , очереди и прерывания.
А такой стиль обменов только и возможен в RTOS.
Например в STM32 сделать мультимастера по I2C эти либы нисколько не помогают.
Такая же фигня с UART-ами.
Та же история с USB. Там вообще дикий гемор. Ребята решили сделать добрую часть либы такой абстрактной чтоб она без изменений шла и под STR91 и под STM32 и под STR7.
Поэтому где обычно хватает одного файла у них нужно десять и концов не найдешь в бесконечных косвенных вызовах. А это уже прямые убытки на отладку.

Ну ладно. Тема пройденная.
Меня волнует другое.
Какого х. внутренний термометр в STM32 никогда не показывает температуру ниже 70 C?
Все считаю по формуле. Все остальные напруги его ADC измеряет достаточно прецизионно, правда кроме референсного напряжения которое тоже оказывается завышено.

Что интересно в предыдущей партии температура тоже была завышена, но не выше 30 С
Или реально там кристал такой горячий?

Если действительно кристалл нагрет до 70, то это легко должно чувствоваться на ощупь - как очень горячий!