Полностью поддерживаю. Сравнивать AVR и PIC16 абсолютно некорректно. PIC16 старше AVR как минимум лет на 10. А вот PIC18 действительно, по производительности превосходят AVR за счет прямого обращения ко всей памяти, что технологически более прогрессивно. Я уже не говорю о расширенном наборе команд PIC18, который в корне меняет программную модель в сторону скоростной обработки данных непосредственно в памяти данных.
Насчет признали. В изделиях, предназначенных для работы в особо напряженных условиях в непрерывном режиме уже давно стоят исключительно PICи вполне согласно с расшифровкой их аббревиатуры. Конкретно - модули ввода вывода Wago System, BECKHOFF, замки SCHMERSAL. AVRов я чего-то там не видел совсем.
Косвенным указателем на отставание разаработчиков микроконтроллеров ATMEL относительно MICROCHIP может служить тот факт, что ATMEL выпускает микроконтроллеры с ARM архитектурой, а MICROCHIP потянул достаточно навороченную архитектуру PIC24H/F/dsPIC30/dsPIC33 с очень развитой переферией (CRC модуль, часы+календарь 12 разрядный АЦП и т.д.).

Ээээ... ну давайте Вы предложите задачку для реализации на PIC и AVR,
небольшую, команд на 100-200 на асм.
Ну и мы все тогда сможем убедиться как PIC рвет Atmel

P.S.Кстати я знаю такие задачки, вопрос в том знаете ли их Вы...

То что для Вас является достижением Микрочипа, в АVR реализовано изначально. Посмотрел даташит на PIC18F1320 - как были банки в ОЗУ, так и остались. Где прямое обращение? Расширенный набор команд до AVR опять не дотянул.

Я применяю AVR в любых условиях. На улице, на корабле, в метро (система безопасности) и везде они отлично себя показывают. Надеюсь AT91 будут не хуже...
Про AVR32 Вы видимо не слышали....

Мда. Война таки продолжается. Короче, если вдруг кто еще не видел смотрите бенчмарки
Конечно это еще не показатель, но видно что явного преимущества какой либо из платформ не прослеживается.

Я понимаю, вопрос не ко мне. Но вот задача.
Управляем тремя каналами регулировки мощности сетевого напряжения. Каналы могут синхронизироваться как от разных фаз сети, так и от одной или двух в произвольных сочетаниях.
При этом угол управления для каждого из каналов задается посредством шины MODBUS/RTU на скорости 115200 бод.
Проверка проста и тривиальна. Мастер шины уменьшает время между телеграммами до тех пор, пока не начинается их пропуск или лампы не будут моргать.
Девайс монтируется непосредственно у исполнительных модулей приблизительно на 40...50 Ампер.
Не знаю как AVR, а PIC18F работает достаточно устойчиво вот уже порядка трех лет в нескольких сотнях девайсов.
Да. чуть не забыл, число отсчетов, определяющих угол управления сотавляет не менее 12000. Срабатывание устройства от ложных переходов через ноль, вызванными наличием приводов, пускателей и прочих агрегатов на тех же фазах сети недопустимо.

Дело не в этом, ИМХО, хотя AVR, ИМХО вполне справился бы с вашей
задачкой...
Просто предыдущий оратор утверждал, что пик порвет авр как тузик грелку(типа
производительность у него такая крутая), вот я и предложил ему привести пример
задачки где авр будет заведомо проигрывать чисто в производительности...

А так, каждому контроллеру свое применение.
Вот например пришлось мне тут запрограмировать на днях PIC10xxx,
ну просто по тому что у атмела таких нету для задачек связанных с
питанием...(в корпусе sot-23)

Имелось в виду наличие команд непосредственной работы с памятью данных. Банки здесь абсолютно не причем. У PIC18F1320 он всего один. Так что и проблем осбых нет. У AVR есть ряд преимуществ, но они касаются USARTа.
То что в AVR реализовано изначально - векторная система прерываний, сплошное адресное пространство - это далеко не всегда преимущество. Что же касается расширенного набора, то Вы, вероятно, не обратили внимание на "оконный" подход.


Ну, кроме Вас существует еще и мировой опыт применения МК. Именно о нем я и говорил. PICи уже давно себя зарекомендовали, а у AVR все еще впереди. Это, в частности, и было одной из причин, по которым лично я остановился на PIC-ах.


Вот именно, только слышал. Вещь, говорят, абсолютно недоставаемая.


Нисколько не сомневаюсь. В этом деле главное не конкретный МК, а голова и руки его применяющего.


Однако, согласитесь, что в среде ембеддеров преобладает обратное мнение, основанное чисто на показателе команда/число циклов ее выполнения. На самом деле это далеко не так.
Лично я остановился именно на PIC-ах ввиду их большей относительно AVR применяемости в устройствах промышленной автоматики. Так сказать, повелся на поводу у мирового опыта.


Так это еще одно из преимуществ изделий от MICROCHIP - наличие однотипных девайсов в различных корпусах. Вот уже и PIC24H появились в 28 выводном DIP, что лично для меня очень удобно, поскольку немного подслеповат.



Абсолютно не показатель. Этот тест надо делать на АСМе, чтобы отсечь влияние компиляторов. Сомнение вызывает отставание старших PICов на МСС18, поскольку компилятор вполне пристойный. Проверялся простой проверкой генерируемого кода на Ассемблере. Надо только пользоваться преимуществами, имеющимися у PICа и не отдавать распределение памяти на откуп компилятору и компоновщику.

Каюсь - просмотрел по диагонали... Но способ, например, сложения двух чисел в ОЗУ минуя W так и не увидел.

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

Если ориентироваться на мировой опыт, то следует выбрать 51-е ядро. Система команд там одна из лучших, на рынке представлены широко, выпускают их все кому не лень. Тем более, что есть очень шустрые 51-е. Вот только цена у таких "шустриков" зачастую превышает более мощные ARM.

Ну кто-то их уже в руках подержал, значит через какое-то время они будут в прайсе у большинства поставщиков. DsPIC тоже не сразу стал доступен.

Я бы сказал - "редко, но бывает что это не так". МК все-же не процессор, иногда аппаратные средства значат больше, чем МИПС-ы. Но и помигать светодиодом это одно, а FFT по 512 точкам совсем другое.

Мы от Дипов отказались. Автоматический монтаж не SMD элементов вызывает определенные сложности.
Хотя Атмел Дипы тоже выпускает, для младших моделей.

Абсолютно согласен. Тестируются не компиляторы, значит тест должен быть на ассемблере. Можно кстати попробовать - например определить 3 массива байт по 300 и просуммировать первые два, помещая результат в 3-й. Если у PIC18 все так хорошо при работе с памятью, то в таком тесте он должен быть на высоте...

Да его и нет, к сожалению, как, впрочем и для остальных операций. Вы можете только прибавить 1 и очистить ячейку памяти непосредственно, а так же поместить результат операции с участием W. Здесь явно прослеживается дурное наследие 16-ой серии.


Прерывание. Программное решение диспетчера прерываний может быть более гибким, чем аппаратное, заданное архитектурой. Я использую программное управление "квазиприоритетами" различных прерываний, так как лично мне представляется удобным.
Страничная память. Здесь все просто. К примеру. Одна страница - рабочая память. Вторая страница - приемный буфер. Третья страница - передающий буфер. И никто никуда не залазит.
Кроме этого есть команда MOVFF, которая пересылает байт, используя полные адреса, как источника, так и приемника, причем оба операнда могут быть как с простой косвенной адресацией, так и с пост или с пред индексацией косвенного адреса. И все это за один цикл (четыре колебания кварца).


Да так и есть. PIC по сути изначально переферийный контроллер. Так его и используют. А AVR - это претензия на боьшее. Не мне судить оправдана она или нет...


Боюсь вместе с этим появятся сложности в виде компилятора С, нуждающегося в лечении и прочие препятствия.


А как же ежа спаять пожилому человеку ? Со всеми остальными корпусами неудобно как-то... Это потом еж превратится в изделие на SMD.


Тестовую задачу лучше уточнить. Во-первых, число 300 неудобное, так как не помещается в байт. Во-вторых, AVR в данном случае имеет архитектурное преимущество из-за организации памяти. Предлагаю все-таки массивы по 200 байт. И вопрос. Что делать, если результат вылазит за границы байта? После уточнения можно приступить к тесту.
Предлагаю предварительно выставить тексты программ на публичное обозрение с целью уточнения и конструктивной критики.

Не, то что доктор прописал... Я вот не помню, в 18ом пичке тоже проблема с переносом? Если да, то 300 - самое то! :-D



Предлагаю просуммировать два числа по 300байт каждое в третье... Тоже интересно может получиться

Для AVR, с его тремя 16 битными индексными регистрами, этот пример подходит как нельзя лучше. Код - несколько инструкций. Думаю, именно поэтому, пример неудачный. Я не очень знаком с универсальными бенчмарками, но для сравнения нужно выбирать что-то типа сортировки, архивации, шифрования, ...

Дешевле, дешевле. Я использую и АВР и ПИК и другие, так что это не религиозная война. Но АВР - только во вспомогательных устройствах неболшого тиража. В серии - PIC16, ST7Lite. Несколько раз пытались применить вв серии АВРы, но всегда получалось дороже.







Как кому, а мне "лояльность" пофигу. Периферия - в лучшем случае сопоставимая.







В 16С74 у меня когда-то влезло управление графическим ЖКИ, вместе со знакогенератором, цифровые фильтры, управление внешним накопителей, коммуникация через УАРТ наружу и всякое вспомогательное (типа кнопок).

Правда, тогда еще небыло нормлаьных Си-компиляторов, и все было на асемблере написано.







Да не надо сказки рассказывать, учитесь конструировать

Если и тогда что-то не получается на 675-м - значит неправильно выбран процессор.







Да, так расшифровывается его название. Но справедливо это в основном для самых-самых первых ПИКов, а с тех пор уже больше 30-ти лет прошло (конкретно - 32), и все несколько поменялось.







Понимаете, кто кого "рвет" - это удел споров желторотых пЫонЭров, криячащих "винда - сакс, пингвын - рулезз!". Каждому свое место. Я так Z80 и TMS320 любл больше чем все 51-е, пики и авры вместе взятые.

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

В большинстве же - система команд вообще последнее, на что обращают внимание при выборе МК.







дсПИК - я честно говоря не понимаю, и на семинарах внятного ответа от микрочиповчев ниразу не получил. На сегоднешний день, на мой взгляд они не имеют рынка, поскольку за те же деньги можно купить существенно более навороченный ДСП. Если Микрочип снизит цену на дсПИКи хотя бы вдвое - будет о чем говорить.

Ну давайте попробуем порвать AVR пичком на простой функции - получение следующего значения CRC16 с полиномом 0x11021 (в IAR'е один из стандартных) из текущего значения CRC16 и нового байта данных. Я даже не буду результат компиляции сишного исходника переделывать:


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

М-да, не думал я, что констатация некоторых фактов вызовет такой резонанс...
Я просто в основном писал о том, что АВР уже имеет место быть. Как и Виндоза. А задачей девелопера является использовать наиболее дешевое и доступное решение. АВРы занимают свою нишу.
А диферамбы АВРам обычно поют те, кому в свое время маркетинговые ходы хакнули голову ( в связи с чем они обычно очень рьяно доказывают их преимущества), т.е. те, кто только начинал работать с МК, либо кто еще не присел на тогда имеющиеся ядра, в основном 51 и PIC. На самом деле АВР - средненький проц, сделанный, похоже, путем сильного обрезания ARMа, чуть ли не потери функциональности(АВР32 вообще очень похож на ARM). Атмелы вообще мало своего имеют. 51 и ARM-не ихнее, ПЛИС тоже у Альтер содрали, еле выкрутились в свое время, АВРы - "музыкой навеяные".
На что Атмелы купили молодых и неудовлетворенных другими ядрами:
Производительность - Атмелы на первое место высунули, что все выполняется за 1 такт, кроме переходов. Для RISC это нормально. Но на самом деле это имело место только с 1200, т.е. при условии того, что прога использует 32 байта ОЗУ. При наличии использования внешней памяти, и при наличии длинных джампов, оказывается, что самые нужные и наиболее часто используемые команды выполняются за 2, а то и за 3 такта! Получается, та же мега8 с 16мипс проигрывает пик18 с 10 мипс, у которого самые нужные команды выполняются таки за 1 такт.
78 powerfil instruction - это мне больше всего нравится - виртуальные инсрукции. Я до сих пор путаюсь в ассемблере, поскольку эта дикость меня до сих пор сбивает. Но в отделе маркетинга видать посчитали: больше инструкций - больше объем продаж.
Полезное - это простое программирование и, наверное, первый бесплатный С компилятор, который уже в 2007 более-менее довели до ума.
Вредное - работа с каждым новым узлом добавляет новой кармы за счет упоминаний разработчиков Атмел. Такие глюки... Вот наиболее веселые:
USART - стартует не по спаду, а по уровню. Не признано Атмел. В свое время. когда появилась мега103, мы сначала радостно наметились ее заложить, но, почитап еррата, обломились. А вот одни коллеги таки радостно ее заложили. Бедные, как они потом намучились, пока дотумкали, что же не так. Глядя на них, я не менее двух лет наблюдал, как работают меги8, пока попробовал их в работе.
TWI - самый крутой, по моему мнению - аппаратно зависает, если на шине что-то не так ( например, если не выставили АСК). Хорошо хоть его перезапустить оказалось можно без ресета.
I/O - при сбросе кидают все ноги в 0, после чего переходят в Z. Если об этом не знать и управлять чем то мощным, можно получить сюрприз в виде фейерверка.
PWM - При установке уровня 0 на выходе все равно присутствуют короткие импульсы. Если об этом не знать...

Сообщение отредактировал oran-be - Aug 9 2007, 06:55

Да уже сто раз было. ;О) Я на сахаре ФИР выкладывал, опять на сахаре программный ШИМ на N каналов...В общем рвёт ПИК(16, 18, без разниццы) АВРа, как Тузик сковородку. ;О)

Завязывать тему пора.