Отладочное средство под названием ICD2(programer/debuger) собирается на коленке за пару часов, схем в сети валом. Микрочип свободно распостраняе полнофунциональну версию компилятора С30(студенческая 60 дней - потом урезает оптимизацию, но это легко лечится). В некоторых тестах будет работать пошустрее АРМа на 60МГц.

P.S. если не изучали ни АРМ ни PIC то освоение PIC24 ,будет заметно проще.
P.P.S. PIC24-латентность прерываний в 5 тактов(ни больше ни меньше) мне так нравицаааа.....

Безусловно PIC прожили долгую и славную жизнь, безусловно Microchip будет до последнего бороться за завоеваный ранее пласт пользователей, безусловно будет стараться держаться на уровне конкурентов, безусловно это ему это вполне удается... Но подсаживаться новым пользователям без какой либо на то надобности (типа многостотысячных тиражей с экономией бакса на изделии из-за униикального сочетания конкретных возможностей) не имеет смысла. Да и найти точно подходящий чип потенциально проще среди многочисленных производителей 'открытых' платформ типа ARM или даже стареньких 51, нежели Микрочиповцев и Атмеловцев, даже если они вдруг стали все из себя 16-32битными и DSPшными.....

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

Об этом собственно я и писал.

Всё таки много камней, много подходов, единые принципы. В сторону развития - тоже далеко грести.

Ну и цены вполне приемлемые. Одни только LPC чего стоят. А там и at91 не за горами.

Ну и освоюсь с камнями, потом легче будет.

А из-за одного проекта залезать в PIC чёто не хочется.

>> Я обнаружил только АЦП 12 бит (мне не надо)
>> и ПДП( Тоже постольку-поскольку).

DMA как раз вам нужно. Он может работать с ECAN в PIC24H в режиме формирования адреса буфера для пакетов с разным ID, что очень удобно.
С CAN-ом то вообще работали? Если нет, и не представляете пока объем задачи - все равно что брать. В противном случае смотрите описания модулей и решайте, что вам интереснее - ядро или нормальный контроллер CAN.

В любом случае спасибо за ответы и информацию к размышлению. Я её анализирую, а не отбрасываю.

С CAN-ом я не работал. С DMA приходилось. Поэтому и задаю вопросы. Но достаточно плотно перечитал литературу. В том числе по модулю CAN для LPC. С учётом таблицы идентификаторов, для упрощения обработки запросов я пока не вижу куда мне ПДП присобачить. То есть по CAN-у у меня будут передаваться очень небольшие объёмы данных. То есть будут передаваться данные на два прибора с датчиков двигателя. В плане ПДП существует также at91sam7x - который имеет этот модуль и стоимость всё равно сравнима с PIC24.

Не очень хороший момент ещё один для PIC24 это переход на 3.3V. В том плане что раньше я мог бы использовать мощные выходы напрямую. Для PIC24, как я понял придётся ставить те же буфера как и для LPC.

Я пока только выбираю - поймите. Оцениваю с разных сторон. Есть у меня ещё один или два проекта, где-то в перспективе. И вот хотелось бы их на единой базе сделать. Всё таки изучать и работать с разными ядрами одновременно - не очень хочется. Возраст. Голова забита информацией. Нужной и не нужной. Последнее время работал с AVR. Есть необходимые отладочные средства. Так что если уж выбирать м/у PIC и AVR, то я лучше склоняюсь к AVR. Например at90can128. Хотя производительность и поменьше зато буфера не требуются.

Вот ещё пара вопросов.
Сравниваю мк от филипс (типа 2114-2119) и атмел (типа at91sam7). Поправьте если что не так или подтвердите.

1) Для LPC не требуется доп. аппаратных цепей PLL. Для AT91sam7 - требуется.
2) Для LPC требуется внешний BOD, для ATMEL - нет.
3) Для LPC требуется внешний стабилизатор 1.8V, для ATMEL - нет.

Непонятен ещё один момент. Согласно книге по LPC указано что максимальная частота SCK для SPI не может превышать 400кГц.
И делитель не может быть меньше 8. (Даже в режиме мастера).
С другой стороны я планирую поставить кварц 14745600 и *4 = ~59. А частоту переферии выбрать /4 = 14745600. Таким
образом максимальная частота SPI может равнятся 14745600/8 = 1843200, что явно больше 400кГц. Вообще по честному не понимаю
данного ограничения.
Согласно даташиту на at91sam7 указана максимальная частота SPI как Pclk, то есть в моём случае может составлять
14.7456 MHz.

А где Вы про 400кГц нашли? С I2C не путаете?

Вот отсюда и пляшите.

А CAN Вы на каких частотах гонять хотите? На стандартных? А как Вы их получите с таким кварцем?

В серии at91sam7 максимальная частота SPI = MCK, то есть мастерклоку, источником которого является PMC. Мастерклок это собственно частота ядра, которая в атмеле по даташиту не может превышать 55Мгц. Делитель для SPI может выбиратся от 1 до 255.

>> То есть по CAN-у у меня будут передаваться
>> очень небольшие объёмы данных.
ну дак в чем вопрос, берите тогда какой понравицо, аппаратные фильтры и маски вам не нужны

Всё понял. Спасибо.

Аппаратный фильтр не помешает. По CAN то будет много сообщений ходить. Это для меня инфа незначительная. Но в LPC это предусмотрено.

SPI и CAN у меня в разных проектах это я объединил, чтобы темы не плодить. А упоминание про 400кГц я несколько раз перечитал. Оно именно в книжке по LPC для SPI было указано. Наверное описались. Смысла то нет. Не тот интерфейс.

Стремительно сцапал с полки книжку тревора мартина, про спи там 1.5 листа, про 400 кГц на тех листах ни слова. Книжка, конечно, того, своеобразная, но так уж обижать автора не стоит.

Кстати тут соседняя веточка про CAN в lpc довольно забавная
http://electronix.ru/forum/index.php?showtopic=9069

1.8 стабилизатор действительно в лпц нужен в отличии от атмела. SPI максимально наверное 7-8 MHZ. Бода в лпц встроенного нет, но я бы и для атмела внешний ставил. Неплохой вариант FM3104 - RTC + супервизор + вачдог. В истекшем году я познакомился с армом лпц и авр в качестве цпу и сопроцессора. Лпц мне показался намного дружественней в освоении. Я писал в кейле. В основном все отладил в симуляторе включая и2с и связь с хостом.

Не может быть такого! 100% с I2C Вы перепутали, хотя и там ограничения в 400KHz со строны контроллера нет - 400 это обычное ограничение периферии.
На "старых" LPC Master SPI до 7,5MHz (1/8 от тактовой процессора). На "новых" 30, но из-за бага в большинстве случаев 15, поскольку на 30 по своей тактовой он нормально не принимает , но его передачу другие (хотя работаю на 30 только со своими FPGA) скорее всего без проблем поймут.


Причем только для старых представителей семейства. Может не стоит себя ограничивать и смотреть в сторну LPC213x LPC23xx ???

Именно данная книга. Кстати мне она понравилась по изложению
Стремительно возьми её с полки ещё раз.

стр. 117 сразу под рис. 4.29. Правда 400 килобит в секунду, но как говорится - не легче

А веточку забавную я читал.

1. Действительно, есть там такой ляп про 400 kbit/s. У меня в электронном виде английский оригинал книги, там это написано на стр. 99. Это явная ошибка. Для LPC2xxx максимальная частота SPI равна pclk/8. Цитата из user manual:

SPI Clock Counter Register... The register indicates the number of pclk cycles that make up an SPI
clock... The value of the register must also always be greater than or equal to 8. Violations of this can result in unpredictable behavior.

2.


Да, всё так и есть. Хотя в автомобиль действительно и для SAM BOD будет нелишним.

3. В общем насчет выбора МК для данной задачи:
Для LPC прийдется ставить буфера на вывод для преобразования 3в->5в, да и по трем вольтам у них выходной ток максимум 4 мА. Особенно хочу обратить внимание: у ARM, и LPC в частности, медленно работает битовый вывод. Нельзя просто вывести требуемое значение в порт, требуются манипуляции с регистрами SET/CLEAR. LPC разогнанный до 60 МГц, будет сопоставим с тем же AVR на 16 МГц. Быстрая работа с периферией - только по внешней шине, но у мелких LPC в 64-выводном корпусе её нет.

Если есть опыт работы с AVR, то я бы советовал его и использовать. Учитывая, что объем передаваемых данных небольшой, можно поставить внешний CAN контроллер типа например MCP2510 со связью по SPI, фильтрация сообщений у него настраивается. Или тот же AT90CAN128. Это всё равно будет занимать меньше места, чем LPC+буфера+ещё обвязка к нему. Кстати, нормальной EEPROM в LPC тоже нет.
Имею опыт работы с CAN в LPC, и считаю, что реализация CAN на LPC "с нуля" займет намного больше времени, чем прикручивание внешнего контроллера к AVR.
По-моему, две основных причины, которые могут повлиять на выбор в сторону ARM со встроенным CAN, это большой объем данных по CAN и/или необходимость в проведении быстрых вычислений.