Подскажите камень с интересующими характеристиками

1) CAN контроллер
2) flash от 16к
3) ram от 4к
4) таймер 1 на 16 лучше 2
5) Ног на вывод не менее 32 лучше мощный выход
6) ADC 4 канала х 10 бит
7) Подешевле

Ну и желательно корпус не большой. Хорошо бы на 64 ноги. А то at91sam7x128 - 100 ног.

Честно говоря PIC использовать не хочу. Что-то меня от него воротит. Хотелось бы на ядре ARM.

да тот же SAM7S256 к примеру...

PS а тут прямо и просится 18f458(258) ))

А разве SAM7S256 имеет CAN?

Вот такие рассматривал

PIC18F448 - 5.36/12$ (16K/0.8/33/1/4) - много поставщиков
PIC18F458 - 5.6/12$ (32K/1.5/33/1/4) - много поставщиков
PIC18F648 - 15.5/21$ (16K/1.5/52) - 1 поставщик
AT90CAN32/64 - нет поставщиков
AT90CAN128 - 8.9/11.9$ (128K/4/52/1/6) много
AT91SAM7A3 - 6.5/11$ - (256K/32/62/2/8) - много поставщиков
AT91SAM7X128 - 6.5/11$ - (256K/32/60/1/4) - много поставщиков
LPC2194 - 9/12$ -(256K/16/32/4/6) 4 канала АЦП - много поставщиков

В скобках указаны (Флэш/ОЗУ/ноги/CAN каналы/ШИМ каналы)

К PIC придётся покупать отладочные средства. Кстати есть не очень хорошие отзывы. У PIC самый маленький объём Озу. Хватит ли я не знаю. Придётся писать на Си, а там озу само распределяется.

Объём программы пока неясен. Точно знаю что очень много таблиц будет.

Тогда начинайте с LPC236x - потом минимизируетесь или наоборот пойдете в сторну внешней RAM.
С RAM в ARM конечно тяжеловато - 32 битовость провоцирует тяготение к расходу порциями по 32 bit.

Отнюдь - все поддается контролю при необходимости.

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

Сам же я немного боюсь, в связи с тем, что не работал ещё с ARM. Там же можно прогу в озу размещать. И я пока не готов отметить сколько его понадобится. Плюс программа ещё неясна в плане CAN. Также с ним не приходилось работать. В общем то думаю что килобайта 4 за глаза будет, но 1.5 как в 18f458 - это что-то маловато будет.

Ставить внешнее озу - ни-ни. Всё это будет в автомобильном приборе работать размером с CD диск и плотность электроники там велика. Аналогичный я уже сделал на AVR. Сейчас в серии. Вот добавили CAN. Чтоб к немецкому двигателю напрямую.


Наверное всётаки подамся в сторону SAM7X. Вроде JTAG к нему ~150$ на ЭФО. Ну блин 100 ног! Я это уже кушал. Хреново наши их запаивают пока. Шаг 0.5.

Вот нашёл ещё один LPC 2119 от 6$. Класс!

вроде не упоминались STR9

http://mcu.st.com/mcu/inchtml.php?fdir=pages&fnam=str9

Если прибор автомобильный, то стОит взглянуть на TMS470
http://focus.ti.com/paramsearch/docs/param...&family=mcu

Это разные килобайты Даже если принимать меры по экономии памяти сопровождающиеся потерями производиельности 4K на 32bit в где-то дотянут до тех-же 1.5K 8bit-овике. Первым будет хавать память по четыре байта зараз стек. Любая 'хорошая' переменая это тоже четыре байта.... При прямом переносе небольших малонуждающихся в 32 битных операциях программ с 8 на 32 битные контроллеры смело можете делить оставшуюся от байтовых буферов RAM на 4.....




Практически этого не надо. Для LPC c его 128 битным кэшиком при включенном MAM производительность при работе из FLASH падает немного. Критические участки вполне достаточно слегка подрихтовать на ASMе. Тем более если речь идет о переходе с менее мощнях контроллеров - ARMовские мегагерцы то тоже сказываются

Обратите внимание, что большинство периферии отъедает ноги, поэтому 32 или 33 ноги в вашей выборке явно маловато чтобы иметь "Ног на вывод не менее 32". В этом смысле LPC смотрятся веселее. Возможно неплохим решением будет использование внешнего сдвигового регистра для получения некоторых из выходных сигналов?

Из переферии только 32 ноги выход, 4 ноги аналоговый вход и CAN. Так что на 2119 укладываюсь.
Кстати на lpc2119 указано for automotiv применений.

Спасибо всем за консультации.
Пока этого достаточно для старта.

Если заказчик платит - не важно, если свои - МТ-Линк в 2 раза дешевле. Я брал в Минске в Альфасофте.

Так я с ними дружу. Как и с Премьер-Электриком.

Да конечно наверное проще купить будет.

ИМХО лучшего решения чем PIC24 для этой задчи не вижу. 40MIPS,ОЗУ 8-16кБ,FLASH от 64 кБ, таймеров куча,АЦП(10-12 бит),DMA,CAN, корпуса 64 и 100 TQFP, цена 4-8$.

Действительно мне подходит по х-кам. Нашёл два камня pic24hj64gp506/hj128gp506.

Согласно einfo цена 9/10$ соответственно. Предложений пока мало.

А чем он лучше lpc2119?

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

Цена на 2119 - 6$ по тому же einfo.

Дело в том, что я не работал не с ARM не с PIC (Точнее с PIC один раз на заказ). Поэтому отладочных средств нет. Надо покупать. Но ARM - явно более перспективный камень. Выпускается множеством контор. Семейство очень обширное. А прибор заказан с перспективой. Если я присобачу его на CAN, то потом по накатанному значительно легче будет.

Это, так сказать размышления вслух.

Отладочное средство под названием 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 и/или необходимость в проведении быстрых вычислений.

Блин действительно в уголке там что-то затерялось, признаюсь я в этот дистрофичный раздел про спи не вчитывался, потому и хрень эту пропустил. Все, Мартина - ф топку. Гуся лапчатого! Вместе с Нильсом.

Откуда такое утверждение?
Помимо IOxCLR/IOxSET есть ещё и IOхPIN доступный на запись. В новых LPC ещё и fast IO появился.

LPC2119/2129/2194/2292/2294 User Manual
"IOPIN: ... The current state of the GPIO configured port pins can always be read from this
register, regardless of pin direction and mode. Access: Read only."

Насчёт fast IO, признаться, я не в курсе. Наверное решили заткнуть эту дыру.
ARM изначально предназначен для быстрого выполнения вычислительных операций, а быстрым шевелением ногами видимо решили пожертвовать.

Там же чуть ниже:
Что говорит о невнимательности составителей доки. Проверяли, так оно и работает и кто-то тут на форуме получал от филипса подтверждение что "так делать можно и таки он не read-only"

Спасибо за живое участие.

Есть как бы 2-3 проекта. Первый с CAN. Быстро ногами там особо перебирать не придётся. Там надо CAN и програмный ШИМ 12 каналов с незначительным количеством ступеней (32-64). АЦП 4 канала с минимальной математикой. Да и ещё флэши побольше - таблицы очень крупные хочу применить. Ну и цена поменьше, а то сейчас изделия тысячами делаются. Вариант с LPC - пока самый дешёвый получается.

Во второй задаче - максимально быстрая математика. Работа с графикой с портом 485, I2C, SPI*2, много памяти, работа с объектами. Много прерываний. Это сейчас работает под Mega640 на 14.7. Но хотелось бы быстрее хотябы раза в 3. Там чем быстрее тем лучше. По переферии - LPC2114 намного красивее ложится и всё что нужно есть.

Как бы изучение меня не пугает. Всё равно придётся рано или поздно. Так зачем оттягивать? Сразу в бой.

>> LPC2114
смотрите в сторону относительно новых LPC213x, LPC214x, не трогайте это барахло с двумя питаниями.

В LPC213x LPC214x CAN к сожалению отсутствует..

http://www.nxp.com/products/microcontrolle...2bit/index.html

Servo?


Ну с математикой быстрее получится конечно, а вот прерывания... Дело в том что латентность прерываний на армах оставляет желать лучшего. У меня атмеловский камень на частоте 48Мгц входил в прерывание за время порядка 1usec (замерялось цифровым осциллографом), на филипсах не смотрел, но думаю время будет такого же порядка.

Что касается камня из филипсов, то для обоих задач лучше наверно 23xx серия.

Опечатался LPC23xx, LPC24xx....

Загнули, батенька. 1us это уже Ваша программа обрабработчика "помогла" от момента реального входа до того, как Вы добрались до махания пином за которым следили "цифровым осциллографом" + задержка периферийной шины при управлении пином. Вообще для критичных по времени реакции
FIQ существует там кроме скромной, но не лишней, экономии тактов еще можно съэкономить на разборках с источником прерывания, да и IRQ обработчики прерывать, при грамотном программировании.

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

fiq конечно штука хорошая но только одна, пару переферийных блоков на него не посадишь .

Но вообще не все так плохо, жить можно, если захотеть.

>> В LPC213x LPC214x CAN к сожалению отсутствует..
дык у него про CAN для второй задачи ничего не было написано, а так конечно LPC2119 и 2129

>> Опечатался LPC23xx, LPC24xx....
LPC23xx и LPC24xx CAN как раз имеют

Я не совсем в курсе возможных превнесенных Atmel ограчичений в исходный ARMовский контроллер
(у STR он вообще самодельный - полное дерьмо ), но LPC c его полностью лицензированным контроллером прерываний может и векторизироваться, естествено ценой лишнего обращения к контроллеру.

Насчёт прерываний - это я оценивал. Мне достаточно одного быстрого. Тем более я посмотрел, что у UART буфер. А то на AVR из-за его 2-ух байт не справляюсь с частотой свыше 57600. Все остальные вообще не срочные.

Да ещё один момент. Мне бы надо по обработке N- прерываний от таймера запустить одно софтовое. На AVR я изголяюсь - разрешаю от таймера лишнего, а там уже флаг стоит к тому моменту. А здесь есть софтовые прерывания? Пока что-то пропустил данный момент.

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

В этом изделии она стопудово лишняя. Там совершенно классическая однозадачная программа. Всё что необходимо паралелить, - паралелится за счёт прерываний. Вот там где CAN там хорошо бы, но пока ещё не готов.

Надеюсь, что когда дойдете до CAN, придете к осознанию того, что круг "классических однозадачных" весьма узок. А уж те в которых "паралелится за счёт прерываний." уж явно не
относятся к ним и, напротив, являются "совершенно классическими" многозадачками.

Готовьтесь! Удачи!

На простых (да и не очень) задачах зачастую вполне хватает машины состояний (для каждой задачи).
Т.е. можно добиться некоего подобия невытесняющей многозадачности.

ЗЫ. Не спора ради.

Аналогично!

Безусловно. И совершенно с Вами соглашусь. В том плане, что ТРУДНО ОЦЕНИТЬ ВОЗМОЖНОСТИ ТОГО С ЧЕМ НЕ РАБОТАЛ ПЛОТНО.

Более того конечно там можно применить ОС. При этом возможно она будет вполне эффективна. Но необходимо будет ПОЛНОСТЬЮ переписать, ориентируясь на СОВЕРШЕННО ДРУГИЕ ПРИНЦИПЫ.

С другой стороны, я являлся пассивным участником спора на форуме AVR. По поводу полезности и нужности TinyOS. И, думаю, там прозвучала одна совершенно корректная фраза. Что ОС не повышает производительность, а уменьшает. Она повышает наглядность, читаемость, повторяемость, удобнее наработки использовать и прочее, что приводит к уменьшению времени создания и отладки проектов (тем кто регулярно с этим работает).

Поэтому задачу на основе ОС необходимо проектировать и писать с нуля. А ни как не переносить.