Вёл проект на LPC3264, потом предложили STM32 (Cortex-M3), ресурсов в последнем ровно столько сколько нужно и, всвязи с тем, что это довольно новый продукт, решил поделиться впечатлениями. Схемы и программы у обоих проектов идентичные.

Сравнительные плюсы:
Ток потребления меньше чем у лпц (35-40 мА, соответственно и источник питания проще и дешевле)
Не так чувствителен к скачкам напряжения питания (2-3.6 В, тут ещё будем тестировать, но лпц сбрасывался в определённых условиях)
Багов не замечено (в лпц2364 критичная проблема с МАМ)

Сравнительные минусы:
Дебагить не слишком удобно (если интересно смогу пояснить подробнее)
Флэш меньше

Буду признателен если кто-нибудь пополнит список или расскажет с чем ещё нехорошим могу тут столкнуться.

Сообщение отредактировал OVladimir - Jan 12 2008, 08:13

Наверное таки LPC2364. 128k флэша, так и у F103 есть вариант с таким-же размером, вот SRAM да, только до 20k... и ethernet нету...
Я тоже на нее переползаю, только на F101. Особенно радует F/2 при работе c SPI. Делиться пока нечем

В корпусах <=64 - нет возможности REF с наружи завести , а внутренних 1.5в не хватает.

1. Уже в прошлом
2. У STM - вообще мамообразных вещей нет.

Да уж лучше без голословия

Естественно интересно. Я не особый поклонник внутрисхемной отладки, но попробовал с RLink в Ride7 ничего особо неудобного не заметил.



У LPC тоже типа есть, но с проблемами на прием

STM хвалятся своими самыми быстрыми в мире флэш, но конечно же, они не такие быстрые как надо для того чтобы оправдать частоту ядра в 72 MHz, думаю, влепят рано или поздно. Суть не в том. Для определённых задач скорости более чем предостаточно.

"Да уж лучше без голословия " куда уж тут, не дома сидим, и вещи для людей делаем, как им потом в глаза смотреть.

Про дебаг: Практически во всех случаях приходится это делать в реальной схеме, так сразу видно почти все огрехи (как программы, так и самой схемы). А с STM при дебаге если после точки останова необходимо сделать шаг (step over, например), попадаешь в процедуры обработки какого-нибудь прерывания, поэтому приходится расставлять доп. брейкпоинты чтобы просто пройти по процедуре основного цикла, тут я не знаю, может есть другой какой-нить способ, но в лпц такого не наблюдалось.

Ну 13ns FLASH это будет уже скорее поздно , а в NXP стиле 128bit 50ns FLASH - легко. Вскоре LPC1000 должны выкатить - будет еще и выбор....

Дело в том, что LPC - ARM7 и его ICE не поддерживает single step, он реализуется отладчиком (разными способами можно посмотреть например исходники GDB). А у Cortex-M3 уже есть аппаратный single step и поэтому вы попадаете в прерывания - здесь опять же хороший отладчик, если не требуется отлаживать прерывания должен их обходить.

Вот, спасибо, есть объяснение.

и, не в тему вопрос, у кейла хороший отладчик? и где у него это настраивается?

Особенно он хорош в связке с STR912. Ваааще убийца становится.
http://aly.ogmis.lt/OpenProjects/ARMDominator4/ARMD4.htm

А про отладку говорить мало смысла не сказав в какой среде отлаживаете.

RealView Microcontroller Development Kit
Version 3.11
это всё

Ну извините, на дворе уже 3.15b
Cortex значительно лучше отлаживается в Keil-е чем ARM7TDMI.
Таже скорость пошагового прохода гораздо выше.

По поводу NXP. Здесь на московской конференции NXP пообещали много вкусного в LPC1000

Не знаю, как на Моссковской, но если, как на остальных, то собствено семейство было только обозначено и соответственно в документе по ссылке о нем практически ничего нет.

Там немного описана переферия (стр 28) и место, которое он должен занимать на рынке (словом информация для продавцов). Флеши и RAM обещается явно по-больше, чем сейчас у ST. Модуль Ethernet MAC наверняка будет от LPC23xx/24xx с DMA. Я был на этой конференции. Представитель NXP утверждал, что эта серия ориентирована на замену 8 и 16 битных МК при той же стоимости, производительности, привосходящей ARM7 и низком энергопотреблении. Больше всего "хвалили" эту архитектуру STMicroelectronix. Посмотрим, что получится у NXP

Сообщение отредактировал Vitaliy_ARM - Jan 12 2008, 22:44

это может потому что частота JTAG в 1 MHz вместо 200 kHz в лпц

Вопрос в другом, реально ли в кейле сделать обход обработчиков прерываний, о котором упоминал KRS, и начиная с какой версии это возможно сделать?