Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: как выбрать кристал?...
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
d71
как кто проц выбирает?
вот к примеру, я определился с переферией памятью и портами, понял что на 2313 невлазию...
----
гляжу на список процев - на выбор много получается
мега8-16-8515... и на чем остановиться?...
GxOST
Прикидываешь количество портов/памяти/периферии, память умножаешь на два (минимум!) - вот тебе и минимальные требования. Потом смотришь сюда.
Георгий
1. Объем памяти
2. Кол-во выводов
3. Габариты
4. Наличие нужного интерфейса
5. Цена
6. Рабочая частота
7. Диапазон температур

У меня примерно в таком порядке идут критерии подбора.
BVU
Цитата(d71 @ Jan 25 2006, 10:52) *
как кто проц выбирает?
вот к примеру, я определился с переферией памятью и портами, понял что на 2313 невлазию...
----
гляжу на список процев - на выбор много получается
мега8-16-8515... и на чем остановиться?...

Критериев довольно много. На эту тему в инете много различных статей.
Все конечно зависит от задачи под которую собираетесь применить МК.
1. Архитектура кристалла (объем памяти ПЗУ, ОЗУ; периферия/интерфейсы, встроенные узлы).
2. Быстродействие.
3. Потребляемая мощность.
4. Система команд/система прерываний.
5. Инструментарий поддержки кристалла (компиляторы, программатор, отладочные средства ...)
6. Конструктив (немаловажно - подойдет ли для макетирования).
и т.д.
IgorKossak
Одними из первых пунктов поставил бы:
1. Наличие и удобство среды программирования.
2. Наличие отладочных средств.
defunct
Цитата(d71 @ Jan 25 2006, 09:52) *
как кто проц выбирает?
вот к примеру, я определился с переферией памятью и портами, понял что на 2313 невлазию...
----
гляжу на список процев - на выбор много получается
мега8-16-8515... и на чем остановиться?...


на mega16, она поддерживает JTAG.. После отладки прошивки, сможете перенести код на другой более дешевый камень.
ROC
Цитата(IgorKossak @ Jan 25 2006, 11:25) *
Одними из первых пунктов поставил бы:
1. Наличие и удобство среды программирования.
2. Наличие отладочных средств.

Ну ИМХО мы вроде в AVR'овской ветке форума находимся... smile.gif

Цену и доставабельность камня никто всерьез не учитывает?
Если изделие штучное, таки можно и вообще не учитывать, это все "размажется" по стоимости собственно разработки, а если объемы будут 10-100-1К-10К...???
Можно ведь и пролететь...
У Atmel, например, был момент с безумными сроками поставок
BVU
Цитата(ROC @ Jan 25 2006, 16:23) *
Цитата(IgorKossak @ Jan 25 2006, 11:25) *

Одними из первых пунктов поставил бы:
1. Наличие и удобство среды программирования.
2. Наличие отладочных средств.

Ну ИМХО мы вроде в AVR'овской ветке форума находимся... smile.gif

Цену и доставабельность камня никто всерьез не учитывает?
Если изделие штучное, таки можно и вообще не учитывать, это все "размажется" по стоимости собственно разработки, а если объемы будут 10-100-1К-10К...???
Можно ведь и пролететь...
У Atmel, например, был момент с безумными сроками поставок

Да сей факт немаловажный, а по всей видимости изначално главный для промышленной разработки идущая в серийное производство. Но инженер прикидывает в начале элементную базу исходя из своих профессиональных навыков работы. Сперва проект в какойто мере создается на бумаге, а уже потом в силу экономической оптимальности начинается 'подстройка' под реальность бытия. Все в конечном итоге сходиться к одному: какие деньги отпущены на разработку и возможно ли на них создать то устройство, которое оговорено в тех. задании.
Stanislav
Цитата(GxOST @ Jan 25 2006, 11:17) *
Прикидываешь количество портов/памяти/периферии, память умножаешь на два (минимум!) - вот тебе и минимальные требования. Потом смотришь сюда.
В принципе, верно. Однако есть еще более правильный путь, если проект серьезный и нужно делать серию - отладить все на макете со старшим чипом линейки (напр., Меге 128), а после утрамбовать в подходящий по стоимости чип, не забывая о необходимом запасе ресурса на всякий пожарный случай.
d71
т.е. подитожу:
--------------
первый подход:
берем максимум (мега128) и ни в чем себе не отказываем,
полет мысли и всё такое, затем реально оцениваем во что это получилось по ногам\интерфейсам\памяти и переносим на соответ. проц.
--------------
второй:
сразу и серьезно на бумаге(кад) проектируем конечное устройство и пихаем кристал из наиболее доставабельных\малоценных\ограниченных
--------------
при цене меги128 - 400 руб. имеет смысл сварганить макетку с разьемами на портах для экспериментов и парой кварцев (3-9 мГц и часовой)
мммм.... мысль.... а т.к. панелько у меги большая, то и под 2313 можна внутри разместить панель и развести питалово, кварц и существующие порты, а УАРТ можно с мах232 сразу на макетке разместить, ограничив джамперами, на i2c сразу панельку под память 24с например.... однако сажусь за рисование, очень мысль мне эта нравится, но поправьте если чего...
asen
Ведение макетирования на старших кристаллах приводит к тому что при переходе на более слабые некоторой периферии может просто не быть и имена у регистров могут поменяется !
Из этого выход
1) Так как в настоящем серийном производстве цена отнюдь не последний фактор следует изначально проводить анализ необходимых системных ресурсов. Так например если у старших семейств присутствует какой то аппаратный интерфейс и он вам необходим в конструкции то отнюдь не значит что нужно выбирать этот кристалл при достаточном запасе производительности всегда возможна его программная реализация
2) Применение больших кристаллов невольно приводит к раздуванию кода и ОЗУ обусловленное психологическим отсутствием границы нежели когда вы пишите и знаете если вы будите ставить несколько операций типа
a[1] = 1;
a[2] = 2;
a[2] = 3;
и тд
Вместо
for (i=1;i<N;i++)
a[i]=1;
вам придется менять кристал и все остальное
defunct
Цитата(d71 @ Jan 26 2006, 04:52) *
т.е. подитожу:
--------------
первый подход:
берем максимум (мега128) и ни в чем себе не отказываем,
полет мысли и всё такое, затем реально оцениваем во что это получилось по ногам\интерфейсам\памяти и переносим на соответ. проц.


Подход хорош, но imho макетку на m128 не имеет смысла делать, потому что ресурс флеша очень ограничен всего 10K циклов записи, после чего чип запирается (сигнатура перестает читаться). Уже натыкался на такие грабли. Поэтому лучше собирать макетку не на старшем чипе который идеть только в TQFP и MLF корпусах, а на "средних" чипах, которые имеются в DIP исполнении - m32, m162, m16.
Panych
Цитата(defunct @ Jan 26 2006, 13:19) *
Подход хорош, но imho макетку на m128 не имеет смысла делать, потому что ресурс флеша очень ограничен всего 10K циклов записи, после чего чип запирается (сигнатура перестает читаться).

а этого слишком мало, чтоб потом перепаять контроллер? каков же алгоритм разработки? насколько по времени при интенсивной работе (чистое время) хватает 10к???
defunct
Цитата(Panych @ Jan 26 2006, 13:26) *
Цитата(defunct @ Jan 26 2006, 13:19) *

Подход хорош, но imho макетку на m128 не имеет смысла делать, потому что ресурс флеша очень ограничен всего 10K циклов записи, после чего чип запирается (сигнатура перестает читаться).

а этого слишком мало, чтоб потом перепаять контроллер? каков же алгоритм разработки? насколько по времени при интенсивной работе (чистое время) хватает 10к???


С учетом, что при использовании OCD за день может производиться до 200-300 перезаписей, а иногда и больше. Итого 10k хватает примерно на 1 месяц. Перепаивать раз в месяц TQFP-64 как-то лениво, да и чип жалко.. Я обычно использую макетку с DIP панелькой или с сокетом, и через 15-20 дней работы - чип просто вынимаю из панельки и ставлю другой.. Так и чип экономится и время на запаивание/выпаивание..
shans
Цитата(defunct @ Jan 26 2006, 15:46) *
Цитата(Panych @ Jan 26 2006, 13:26) *

Цитата(defunct @ Jan 26 2006, 13:19) *

Подход хорош, но imho макетку на m128 не имеет смысла делать, потому что ресурс флеша очень ограничен всего 10K циклов записи, после чего чип запирается (сигнатура перестает читаться).

а этого слишком мало, чтоб потом перепаять контроллер? каков же алгоритм разработки? насколько по времени при интенсивной работе (чистое время) хватает 10к???


С учетом, что при использовании OCD за день может производиться до 200-300 перезаписей, а иногда и больше. Итого 10k хватает примерно на 1 месяц. Перепаивать раз в месяц TQFP-64 как-то лениво, да и чип жалко.. Я обычно использую макетку с DIP панелькой или с сокетом, и через 15-20 дней работы - чип просто вынимаю из панельки и ставлю другой.. Так и чип экономится и время на запаивание/выпаивание..


Под TQFP-64 тоже есть ZIF-сокеты, крупноваты по размерам, но штука удобная. У меня на макетке такой стоит - не нарадуюсь smile.gif Описание есть здесь: http://www.micronica.ru/suppliers/panels/panels.pdf
d71
да, я признаю что ошибся, конечно я имел в виду pdip корпус, пока остановился на m16 , в ней же будет панель под tiny2313, два кварца (один для красивого uart) через джампер. max232 с обвеской, опять таки через джампер. на twi dip8 под 24c и dip20 под ацапы/расширения
все порты на разьемы, как будет готово макетно - запостю, мож кому интересно будет
Stanislav
Цитата(d71 @ Jan 27 2006, 07:27) *
да, я признаю что ошибся, конечно я имел в виду pdip корпус, пока остановился на m16 , в ней же будет панель под tiny2313, два кварца (один для красивого uart) через джампер. max232 с обвеской, опять таки через джампер. на twi dip8 под 24c и dip20 под ацапы/расширения
все порты на разьемы, как будет готово макетно - запостю, мож кому интересно будет
А не то линейку ATmega168 - 88 - 48 выберите. Они вообще пин-пин совместимые и в дипе все имеются. ATmega48 меньше доллара стоит в ЭФО...
defunct
Цитата(Stanislav @ Jan 27 2006, 09:07) *
А не то линейку ATmega168 - 88 - 48 выберите. Они вообще пин-пин совместимые и в дипе все имеются. ATmega48 меньше доллара стоит в ЭФО...


В DIP'е то они все имеются только к нам в основном AI доходят.. Да и для отладки JTAGICE MKII дороговат.
alniko
Цитата(IgorKossak @ Jan 25 2006, 14:25) *
Одними из первых пунктов поставил бы:
1. Наличие и удобство среды программирования.
2. Наличие отладочных средств.

и еще чего-то т.к. нравятся мне AVR, а еденичные образцы я
собираю на PIC
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.