MicroCHIP.RU
Главная Документация Отладочные средства Справочник Поиск Ссылки
 Новости   Конференция   Контакты 
 

PIC или Atmel

 Нoвaя темa  |  Наверх  |  Перейти к теме  |  Поиск  |  Правила  |  Вход 

ВНИМАНИЕ!
Вы просматриваете архив форума.

Этот форум работает только в режиме просмотра и поиска.

Действующий форум переведен на новый движок и
находится по адресу www.microchip.su

 PIC или Atmel
Автор: alex367 ()
Дата:   03/03/2004 13:37

Добрый день!
Я все время программировал промышленные контроллеры, решил попробовать сделать одну
задачу на микроконтроллерах (система управления подъемником).Помогите определиться
с выбором, на чем все же лучше делать на PICах или Atmel?




 
 а кстати
Автор: patton ()
Дата:   03/03/2004 13:44

всё хотел узнать что такое промышленные контроллеры


 
 Re: PIC или Atmel
Автор: GRR ()
Дата:   03/03/2004 13:45

Может тебе самому выбрать. Тут сейчас такое начнется! В Питере уже черт знает что...
http://www.microchip.ru/phorum/read.php?f=2&i=42843&t=42701


 
 Re: а кстати
Автор: next ()
Дата:   03/03/2004 14:08

http://simatic.nm.ru/Simatic/simatic_main.htm


 
 А в чем проблема то?
Автор: Bill ()
Дата:   03/03/2004 14:15

Хоть тот, хоть другой можно взять.


 
 спасибо
Автор: patton ()
Дата:   03/03/2004 14:18

я что-то типо этого и думал, то есть создавать бы это я согласился, а "программировать" нет, тк
я сам умею такие штуки делать, которые другие потом "программируют"


 
 Кстати, как управляется кран?
Автор: Sam ()
Дата:   03/03/2004 22:35

Я читал (очень давно, когда еще умел), что козловой кран можно более-менее
нормально управлять только нечеткой логикой (fuzzy-logic). Что раскачка груза,
боковой ветер, неравномерная просадка платформы и еще куча факторов делают
невозможным создания программы управления которая просто выдавала бы "на гора"
команды исполнительным механизмам и все. Что нужно постоянно учитывать огромную
кучу факторов и для этого применяют системы нечеткой логики.
Кто-нибудь сталкивался с такими?


 
 Re: Кстати, как управляется кран?
Автор: alex367 ()
Дата:   04/03/2004 09:54

данными системами я не занимался, в подъемнике все гораздо проще. Но применительно
к кранам нечеткая логика IMHO может применяться только как неосновной элемент, все
остальное должно быть однозначно, иначе может не пройти по ГОСГОРТЕХНАДЗОРу.


 
 Re: А в чем проблема то?
Автор: alex367 ()
Дата:   04/03/2004 09:56

особой проблемы нет, просто надо быстро выполнить задачу, а самое главное, чтобы
все стабильно работало. По этому и решил посоветоваться у более опытных людей.


 
 Re: Кстати, как управляется кран?
Автор: Gremlin ()
Дата:   04/03/2004 10:54

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


 
 Скажи лучше, что за задача.
Автор: Vladimir ()
Дата:   04/03/2004 11:33

Тогда и оптимальный контроллер порекомендуем. PIC и AVR это все же не конкретные
контроллеры :).


 
 Re: Скажи лучше, что за задача.
Автор: alex367 ()
Дата:   04/03/2004 12:01

Задача простая. Есть грузовой подъемник, несколько этажей остановок, пульты
управления, 2-х скоростной привод и система блокировки дверей. Входов с различных
датчиков и постов управления - 30, выходов - 16. Аналоговых сигналов нет. Надо
сделать соответствующую систему управления с возможностью ее дальнейшего развития (
вывод информации на ЖК, подключение дополнительных входов/выходов).




 
 мат. теория под Fuzzy есть
Автор: LEXA ()
Дата:   04/03/2004 12:45

и придумана она как раз математиком Л. Заде более четверти века назад - математическая теория
нечетких множеств (если мне не изменяет память :)

единственное НО: для синтеза (да и анализа, пожалуй) регуляторов на основе нечеткой логики теория
как раз не особенно поможет - оптимизация параметров регулятора ведется численными методами
(подозреваю, что путем банального перебора)

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


 
 Re: Скажи лучше, что за задача.
Автор: Яков ()
Дата:   04/03/2004 13:14

По моему мнению как раз задача для промышленного контролера-тянуть все провода в одну точку а
там городить из пика пром контролер -будет еще дороже.
Вот если ты хочешь избавиться от проводов во всех точках поставить интелектуальные датчики (те
же пики)а затем управлять по двум проводам это может быть интересным но не уверен что
дешевле:)))
Кстати для пика есть спец язык (не помню как называется было упоминание сдесь на конфе)похожий
на язык промышленных контроллеров.




 
 Re: Скажи лучше, что за задача.
Автор: alex367 ()
Дата:   04/03/2004 13:36

Дороже не должно быть, т.к. промконтроллер в такой конфигурации стоит чуть больше
200 евро.
Интеллектуальные датчики уже давно придуманы и называется все это AS интерфейс.
Примять только их можно не всегда, а в данном случае это будет еще дороже.


 
 Re: Скажи лучше, что за задача.
Автор: Яков ()
Дата:   04/03/2004 14:17

Да я не против :)твори это интересно но я думаю ты если будешь работать один -разработать
развести изготовить плату потом корпус и т.д все это займет более месяца - и сравни с 200
евро а промышленный контролер можно подготовить к работе за несколько дней -причем даже инженер
не нужен хватит электрика.Только не обижайтесь это расуждения скорее для себя




 
 Re: Скажи лучше, что за задача.
Автор: alex367 ()
Дата:   04/03/2004 14:20

все верно, по этому мы и применяем пром.контроллеры, но они не очень подходят для
серийной продукции. По этому я потрачу месяц, но зато в дальнейшем все окупится,
т.к. подъемники мы делаем постоянно.


 
 Re: PIC или Atmel
Автор: Dimka ()
Дата:   04/03/2004 14:26

Я бы посоветовал PIC. Только из следующего соображения. У меня был горький опыт с Atmel.
Контроллер хороший, ничего не скажешь. Но вот в промышленной среде себя ведёт не стабильно. Он
управлял у меня пускателями и всякой мощной нагрузкой. Имело место периодическое сбрасывание
контроллера. Ставил всевозможные фильтры по питанию, даже в экранированный корпус засунул. Все
равно он периодически сбрасывался, а иногода вис. Даже WDT не помог. Как только поставил PIC
обо всём об этом забыл и всё работает бес всяких сбоев вот уже год, с учётои того, что система
работает круглосуточно.


 
 Re: PIC или Atmel
Автор: alex367 ()
Дата:   04/03/2004 14:39

Вот, то что нужно! Как раз необходимый опыт эксплуатации в промышленности. Большое
спасибо! Я тоже склоняюсь к PIC, тем более, что портов у PICов больше.


 
 это что-то новое
Автор: patton ()
Дата:   04/03/2004 14:49

про то что портов больше


 
 Ставь пик(+)
Автор: abivan ()
Дата:   04/03/2004 15:41

Задача не вычислительная, а ногами дрыгать. Я думаю что никто не скажет, что пик менее
помехоустойчив чем авр. А вот об обратном идет дискуссия.


 
 без сомнения
Автор: patton ()
Дата:   04/03/2004 16:10

а всё же нету данных по авру( я пытался на телесисе узнать и ничего определенного ), я на пике
ацп запускаю с масимально возможной скоростью преобразования = 1.6мкс на один бит, а в авре
такие скорости достижимы? А то устал уже dsPIC ждать. В смысле счас надо делать выбор или
большой пик или мега, а если большой пик то тогда хочется dsPIC, а если большой пик 6720 или
8720 то тк задачи больше вычислительные, то как-то на мегу тянет. Внешнее АЦП никакой охоты нет
ставить тк пиковское счас справляется.


 
 Re: это что-то новое
Автор: alex367 ()
Дата:   04/03/2004 16:27

сравни http://www.atmel.ru/AVR/Mega.htm
и http://www.microchip.ru/lit/pic/pic18fxx2/pic18f8620


 
 да я в курсе
Автор: patton ()
Дата:   04/03/2004 16:38

исторически пик догоняет мегу( по этим параметрам ), вот и мегапики появились, это новый и
самый большой контроллер, если сравнивать в среднем, так сказать по весовым категориям, то это
неправильно, хотя по IO больше у 8720


 
 PIC18F452 или PIC18F442 (-)
Автор: patton ()
Дата:   04/03/2004 16:44

-


 
 Не, ну постой...(+)
Автор: abivan ()
Дата:   04/03/2004 17:13

Если тянет на мегу, так и пользуй.
Вопрос то вот в чем. С чем раньше работал и с тем и с другим? Если да, то и разницы нет.
Если АЦП пика устраивает атмега зачем?
Ну и в плане общеобразовательности
LVD + BOR в атмеге есть?


 
 Re: Не, ну постой...(+)
Автор: patton ()
Дата:   04/03/2004 17:36

abivan писал(а):

> Если тянет на мегу, так и пользуй.
> Вопрос то вот в чем. С чем раньше работал и с тем и с другим?
> Если да, то и разницы нет.
с мегой последний раз работал уж с 2 года как, а на С никогда, а впихнуть туда по памяти
вычислиловки всё же больше можно если сравнивать одинаковые объёмы памяти
> Если АЦП пика устраивает атмега зачем?
ну вот из-за памяти, задачи такие маячат, что я в сторону ARM-ов поглядываю
> Ну и в плане общеобразовательности
> LVD + BOR в атмеге есть?
то что там с этим проблемы и надо внешний супервизор это да


 
 Чего ждать?
Автор: Илья ()
Дата:   04/03/2004 18:12

Если очень хочется, то заказывайте образцы dsPIC с 21-й страницы Product Selector
Guide кроме 50хх и работайте.


 
 Вы про 16С92х забыли
Автор: undefined ()
Дата:   04/03/2004 18:33

У них давно более 50 портов було. Правда, половина только на ввод.


 
 Ну-ка, ну-ка (+)
Автор: Ecole ()
Дата:   04/03/2004 18:35

Разве мелкочиповцы шлют образцы во все страны? Из их белого списка Россия и Украина
давненько уже исключены. Или образцы можно как-то иначе заказать?


 
 Re: Скажи лучше, что за задача.
Автор: Vladimir ()
Дата:   05/03/2004 01:03

Я бы делал на ATmega162 или ATmega169, если алгоритм не слишком громоздкий. Если
нужно больше памяти - то ATmega32, 64, 128.
Требование к количесвту портов (46) и возможность предусмотреть их дальнейшее
наращивание фактически подразумевают необходимость ставить внешние расширители
портов, например типа 74HC595 и т.п., что, ИМХО, намного дешевле и "раширябельнее",
чем ставить сразу дорогущий многоножечный таракан. Тем более что данные на входах
вроде бы не меняются с сумасшедшей скоростью т вполне можно обойтись периодическим
програмным опросом.
Требование к выводу на ЖКИ означает необходимость сразу предусмотреть канал вывода
на ЖКИ. Если ЖКИ малоразрядный, то, может быть, удастся снизить цену девайса путем
использования встроенного в ATmega169 контроллера ЖКИ. Если же нет, то от этого
чипа лучше сразу отказаться.
Насчет якобы хреновой помехоустойчивости AVR, периодического слетания флэша, порчи
информации в EEPROM и т.п. - все это ерунда. При просто ГРАМОТНОЙ разработке
девайса ничего подобного нет. Хотя это только мое ИМХО. Опыт работы с AVR у меня не
очень большой, работал я только с новыми мегами (ATmega8...ATmega128) и тиньками
(ATtiny12...ATtiny26). Возможно в старых приборах (90S) какие-то траблы и были,
новые же ведут себя вполне пристойно, хотя, конечно, не и не без казусов (хотя бы в
ATtiny26).
BOR в мегах есть и он вполне надежен. Я лично, кроме самой первой разработки,
никогда внешнний супервизор не ставлю (если, конечно, нет особых требований к
потреблению) и пока встроенный BOR не подводил.
Такого LVD как у PICов в AVR нет и это, на мой взгляд, безусловный минус. Хотя,
пользуются же PICами и без LVD. Если не знать, что такая фича существует, то и
особого дискомфорта не ощущаешь ;-)
Еще большой "+" ATmega162, ATmega64, ATmega128 - наличие 2-х UARTов. Если вы будете
делать расширение функций через RS-485 или работать от удаленного пульта
управления, то два UARTа очень даже могут пригодиться.

PS. А в целом ваша задача, ИМХО, очень некритична в выбору чипа. Без проблем будет
работать даже PIC16, если, конечно, программа в него влезет. Может быть даже
посмотреть в сторону слабеньких Renesas (ранее Hitachi) типа H8. У них вроде бы
есть очень недорогие многоножечные (до 100 и более) тараканы. Вам ведь все равно с
чего начинать, а среда разработки IAR EWB для H8 (v1.53G) практически такая же как
и для AVR (v3.10a) и PIC18 (v2.12a).




 
 Re: без сомнения
Автор: Vladimir ()
Дата:   05/03/2004 01:56

АЦП у "мег" очень даже неплохое по точности и функциональности, но помедленнее, чем
у PIC. Минимальное время преобразования = 5 мкс на 1 бит. Но есть еще нюансы. Перед
первым измерением по каналу идет настройка АЦП и она забирает 12 тактов. Так что
если вы сканируете каналы, то 1 измерение займет у вас 25 тактов или минимум
125мкс. Если каналы не переключать, то время 1 измерения в 2 раза меньше (13 тактов
или минимум 65мкс).
Особняком стоит ATmega169. Там вроде бы разрешено устанавливать длительность такта
преобразования 1мкс (вместо 5мкс как во всех остальных мегах). Т.е. по DS время 10-
битного преобразования в режиме free running = 13мкс. Насколько справедливо это
утверждение я не знаю. Только на днях начал щупать Atmega169 и до АЦП еще не
добрался.
Внешний супервизор, как по мне, в схемах с мегами далеко не всегда обязателен.
Встроенный BOR отлично справляется со сбросами при включении/выключении питания, а
если нужно заблаговременно подготовиться к выключению при снижении питания, то
можно использовать встроенный компаратор. Конечно, не такая роскошь, как LVD в
PICах, но часто и одного уровня срабатывания достаточно.


 
 Re: мат. теория под Fuzzy есть
Автор: Gremlin ()
Дата:   05/03/2004 10:45

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


 
 и чего мне даст образец, если через несколько месяцев я хочу делать серию
Автор: patton ()
Дата:   05/03/2004 10:55

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


 
 Если в Москве(+)
Автор: abivan ()
Дата:   05/03/2004 11:03

То можно попробовать через Тритон.
Да и в любом случае напишите письмо. Если Вы не частное лицо, а организация, то думаю Вам
помогут.
"Maxim S. Eremenko"
maxim.eremenko
на(@)
microchip.com.ru


 
 Re: Скажи лучше, что за задача.
Автор: alex367 ()
Дата:   05/03/2004 11:08

Большое спасибо за столь подробный ответ!
Но для меня очень критична стабильность работы. Если AVR надо как то по хитрому
программировать для того, чтобы добиться стабильности, то это увы не подходит.
Кроме того, зачем делать расширители, когда можно взять просто PIC побольше. В
данном случае разница в цене большая только в процентном отношении, а по деньгам
непринипиально, все равно гораздо дешевле будет, чем на промконтроллере.


 
 А говорят с апреля серийные поставки...(-)
Автор: Alex B._ ()
Дата:   05/03/2004 11:29

,


 
 А я так вообще зарекся(+)
Автор: abivan ()
Дата:   05/03/2004 11:29

связываться с новыми изделиями, пока пару ревизий не выйдет.
На 18F252 нагрелся с его глюком tblread. Кристаллы то они поправили, а POD для эмулятора так
глючный у меня и остался.


 
 Я всё же попрошу прощения
Автор: patton ()
Дата:   05/03/2004 11:43

за такие провокационные вопросы, наверное можно было как-то "по-честному" твоего совета
спросить, но как-то по пути наименьшего сопротивления всегда получается


 
 Re: Скажи лучше, что за задача.
Автор: Vladimir ()
Дата:   06/03/2004 17:12

Что значит хитро программировать? И при чем здесь именно AVR?
PLC потому и стоят дороже, чем МК, что в них программные функции поддержки как вы
выразились "стабильности" уже реализованы разработчиками PLC. Вы программируете
только необходимые вам пользовательские функции, не заботясь о правильном старте
после включения питания, отработки дребезга контактов, правильной организации
таймеров, восстановлении работоспособности после сбоев и т.д. и т.п.
Используя МК (все равно какого PIC, AVR, H8...) вы всю предварительную работу
разработчиков PLC берете на себя. Преимущество в переходе к МК в том, что вы не
делаете ЛИШНЕГО и экономите на СЕРИИ. А "хитрого" и достаточно трудоемкого
программирования вам все равно не избежать.