Извините, вопрос не совсем по теме, но все таки, дайте пожалуйста характеристику МК STM32F107 и LPC1768 (оба М3)- кто и чем именно лучше.

Не думаю что стоит ковыряться в их тех. параметрах они почти одинаковы. Важнее сопроводительный софт.
У ST его очевидно больше и разнообразней.

Конечно для ST "важнее", ибо для разборок с сырым и поверхностно документированным железом годится все, даже традиционно писанные левой ногой "библиотеки" . Версия Cortex ядра у ST тоже старая. Банальные попугаи меньше. У ST Cortex-ов преимущество одно, но очень большое - гамма чипов в нижнем сегменте. Правда Автор конкретный спрашивает.

Раз уж пошла такая пьянка, извините, ответ не совсем по теме, очень рекомендую LM3S (тоже m3, LM3S9B92 как замену приведенным в первом посте), вставляет обоих названных и по поддержке и по функциональным возможностям. Ниже основные на мой взгляд особенности:

- встроенный ethernet MAC + PHY (подключаете чип сразу к UTP разъему и eth готов).
- встроенные в ROM драйвера всей имеющейся периферии
- встроенный AES бутлоадер через любой интерфейс в т.ч. ethernet
- 96KB SRAM
- нижние представители семейства в SOIC корпусе!!!
- делители частоты для периферии (напр UART) - дробные!!!

в общем бомба.

Хорошо, что не в DIP . А в чем радость и бомба-то?

PLL и fractional baud для UART LPC тоже, и давно уже, не обижены.
А так, конечно Luminary, привлекательные вещи делает и кроме того еще и внешнюю шину имеют, что для кортексов редкость.

DIP40 с pin-to-pin совместимостью с C51 пригодился бы в хозяйстве..

Ну а радость и бомба - как для меня в первых трех пунктах. Это как минимум минус 1 корпус и минус туча smd лапши для PHY, минус пару-тройку man/months на написание и тестирование бут тулчейна, +экономия FLASH под application код.


точнее сказать для m3 редкость, кортексы то разные.

Явный перебор . Если интерфейс для работы по любому поднимать, то загрузчик для него это никак не месяцы, а часы. Ну и насчет "экономии" FLASH - забивание флеша всяким мусором для непонятно чего, не есть экономия , ибо в результате этого имеем рекордно малый объем Flash доступого для приложений .

Ну скажем MAC+PHY не так уж и приятно когда хочется PHY сделать на оптике. А еще бывают PHY специально для длинных линий на километры и с прочими особенностями. Так что встроенный PHY не плюс если в "мировом масштабе"

Драйвера в ROM это уж совсем для инвалидов. Вернее это такая хитрая привязка юзеров к этому семейству.

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

96 KB SRAM в принципе аргумент. Но для средней RTOS с GUI, развитым WEB серваком и каким-то скриптовым движком все равно мало.
Правда у NXP и те жалкие 64K разбиты на специальные раздельные области.

UART в принципе сносно переносит разбросы по частоте. А благодаря PLL-ам 115200 можно практически изобразит на любом ARM-е с любым разумным кварцем.


А вот ST сильны количеством таймеров и каналов DMA.
Аппаратные таймера особенно помогают когда нужно реализовать много скоростных протоколов с короткими независимыми таймаутами по SPI и I2C на базе RTOS с большим системным тиком скажем в 10мс.

Как раз таки на STM32F107 это правило нарушается. Нет ни одного примера в исходниках по работе с USB Host. Я такого вообще раньше ни у кого не встречал - идёт development board (stm3210c-eval) и к ней все примеры в виде бинарников...

Мне кажется, что STM делает LPC в другом - в возможности более гибкого конфигурирования периферии за счёт ремапа.

Забыли про внешнюю память.

Один таймер на систему второй на все остальные таймауты.

Делает . Дожили . Не более, чем мелкий приятный, но совершенно не принципиальный штрих.

Конечно, всё, чего нет в lpc - ерунда и мелочи. Вы у них на ставке чтоль?
Если серьёзно, то было очень обидно обнаружить, что хотя Cortex-M3 от NXP имеет всё, что нужно для нескольких проектов, но ни на один из этих проектов полностью не ложится, ибо что-то нельзя использовать одновременно. А "приятный, но совершенно не принципиальный штрих" от STM позволяет замечательно разрулить такие ситуации.

Давайте называйте конкретно, что нельзя использовать одновременно у LPC17xx списком периферии Вашего проекта.



Нет, просто никогда не сталкивался с такой проблемой в реальности. Практически на их ARM7 есть подобные проблемы при использовании "тяжелой" периферии, типа LCD контроллеров.
Давайте опишите Вашу проблему.

Я сейчас всего уже не вспомню, но вот один пример моих страданий.
Как видите, никакой тяжёлой периферии. Хотя наверное статистически это не самый частый вариант.

USB Host и не надо делать на Cortex-M3. А кто делает тот явно выжимает копейки, т.е. работает на огромные объемы.
Для хостов есть ARM9 и выше с полным набором классов хоста на базе Win CE и без всяких урезаний.

ST забазировался на USB хосте от Micrium. Исходники конечно продают, но за хорошие деньги и в открытом доступе их еще долго не видать.

С другой стороны на фтп лежат исходники примитивного USB хоста для доступа к FAT на базе операционки Микриума.
Там драйвера на пару килобайт, и переделать их под STM32 займет не больше пары дней.

Давайте не будем рассматривать дикие случаи для девайсов ценой до 100$.
Когда хочется подключиться по оптике, думаю разумнее просто купить свитч с одним оптовходом и кучей ethernet'ов, какой смысл к каждому девайсу ценой за $50 оптику тянуть, где разъем будет дороже. Дальнобойные PHY на километры лично меня как-то тоже мало интересуют, есть ethernet стандарт 802.3u который меня полностью устраивает и в его рамках LM3S предлагает самое выгодное решение.


А Вы посмотрите как используется ROM у других конкурентов делающих МК с Flash. ROM в них - это мертвый груз, который вообще никак не используется устройством в life-time. Вопрос - зачем за него платить?


Идея непонятна. Другие производители дают вам бутлоадер (если дают) априори без шифрования вообще, ну там для знакомства с МК может в таком и есть толк, но в life-time это полнейший непотреб. В то время как бутлоадер LM3S может использоваться конечными пользователями устройства, для обновления прошивки например по eth.


Спорить не буду, однако замечу, что китайцы потратят одно и тоже число времени и средств - ломая конкретно ваш бутлоадер с конкретным тулчейном на который потрачено вами n месяцев, и LM3S'ный на который я не потрачу ни минуты.

А почему вы только периферию сравниваете? А почему акселераторы FLASH-памяти никто не сравнил? Вот например, кто-то из местных делал. Может он и LM3S уже затестил...

Из ДШ на LM3S:

At system clock speeds of 50 MHz and below, the Flash memory is read in a single cycle.
....

The Flash memory controller has a prefetch buffer that is automatically used when the CPU frequency
is greater than 50 MHz. In this mode, the Flash memory operates at half of the system clock. The
prefetch buffer fetches two 32-bit words per clock allowing instructions to be fetched with no wait
states while code is executing linearly.

Думаю NXPшный MAM делает то же самое.

Чуть-чуть прокоментирую приведенную Вами ссылку. Первая, отчетливо заметная, ступенька для NXP на приведенном графике находится где-то в районе ~40Mhz, и повторяется с шагом в 20Mhz. Это свидетельствует о включении дополнительных wait-state'ов через каждые 20Mhz. И наталкивает на мысль, что флеш у NXP всего лишь 20Mhz'овый... Но стоит отметить, что работа MAM выглядит великолепно.

У LM3S теоретически должна быть только одна ступенька после 50Mhz, - когда включается prefetch буфер, и на мой взгляд суммарная производительность должна быть выше чем у NXP, за счет более быстрого флеша.

Ваша тяга к мощным процессорам всем хорошо известна Неужели для того, чтобы пользователь мог воткнуть в устройство флешку, непременно нужен ARM9 с Win CE?



Что-то я не нашёл такого, скажите поточнее, где оно?

Разумеется не на ставке. 5 мая получаю от TI (у которого я тоже не на ставке ) несколько демобордов на LM3S6965. На них будет прототипироваться распределенная система передача данных. Причины выбора для этого прототипа Luminary:
- попытка минимизировать потребление энергии и уровень излучаемых помех за счет встроенного PHY;
- достаточно большой объем RAM, ибо придется буферизироваить трансляцию между весьма разноскоростными интерфейсами;
- в устройстве будут и другие, причем ключевые, компоненты от TI - незачем плодить поставщиков.