AVR признали !, C переходом в рассуждения о контроллерах Опции

[ozzy]

В общем получили мы новые приборы от Dynisco (кто не знает серъезная контора, занимается датчиками давления и сопутствующей електроникой http://www.dynisco.com/)
открываем и видем :


рис1


рис2


рис3

Коллеги Ваши мнения ?

[fmdost]

Говорят в какой-то ещё чернобелой нокии стояла 8и ногая AVR. Футаба начала свой RC control делать на AVR.

[defunct]

Коллеги Ваши мнения ?

Ну есть и более крупные конторы, которые его давно признали.
Atmel например ;>

У меня мнение сложилось такое - из восьмибиток - это лучший представитель по критериям:
- производительность
- компактность кода
- доступность качественных средств разработки (в т.ч. бесплатных)
- соотношение и количество внутренней памяти flash/RAM/eeprom
- богатая периферия.

[Pyku_He_oTTyda]

В паяльной станции ERSA тоже мега установлена

[Allregia]

Если бы еще они не меняли так часто свои кристаллы....
В смсысле - не снимали с производства старые.

Сообщение отредактировал Allregia - Aug 8 2007, 11:41

[alexander55]

В общем получили мы новые приборы от Dynisco (кто не знает серъезная контора, занимается датчиками давления и сопутствующей електроникой http://www.dynisco.com/)
открываем и видем :

Коллеги Ваши мнения ?

Среди 8 разрядных uC AVR вне конкуренции. PIC и 51 отдыхают.
Среди 32 разрядных uC Atmel слегка погорячился (если бы сделал периферию попроще - SAM7S пошел в лет).

[zltigo]

Среди 8 разрядных uC AVR вне конкуренции. PIC и 51 отдыхают.

Среди массовых общего назначения, несомненно да.
Но не надо про 'отдыхают', поскольку X51 ядро используется во многих специализированных с богатой специализированной периферией чипах, и имеет высокоскоростные реализации.
Ну а если учесть, что по нынешним временам на 8 битовиках свет клином не сошелся, то делить конкурентов по разрядности уже не корректно - среди старших моделей скорее AVR уже "отдыхают" по сравнению с 16-32bit той-же ценовой категории. Вот и остались пока только мелкие AVR вне конкуренции.

[Allregia]

Среди 8 разрядных uC AVR вне конкуренции. PIC и 51 отдыхают.

Это не совсем так. Для массового производства, ПИК дешевле, периферия разнообразнее. Особенно - если производство долгосрочное. Микрочип, в отличие от Атмела, продолжает выпускать старые МК, атмел же - заставляет переходить на более новые. Хорошо если с изменением только софта без изменения железа.
51-е тоже бывают весьма разные, их масса встроенных во что-то (например в USC2COM всякие).

[andrvisht]

У PIC переферия конечно быстрее появляется, а у AVR позже, но зато гораздо удобнее сделана.
А в 8 лапках PIC удобнее, и засунуть в него можно чуть больше. Это если вычисления на уровне битов, без особой математики. А так конечно PIC сложно именовать процессором

[defunct]

Для массового производства, ПИК дешевле, периферия разнообразнее. Микрочип, в отличие от Атмела, продолжает выпускать старые МК

Насчет дешевле - может быть, (хотя в последнее время ценовые пределы очень размыты. Флешевый Atmel часто стоит столько же сколько OTP аналог от MicroChip.)

Насчет "периферия разнообразнее" - однозначно нет. +1 в пользу Atmel.
Насчет лояльности - +1 в пользу MicroChip.

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

Сравнивал я Tiny13 и 12F675.
В Tiny13 влез полноценный программатор PIC'ов (через uart).
А в 12F675 - "мигалка на 6 светодиодов".

12F675 - (как тут выразились ранее) - отдыхает.

[VDLab]

Сравнивал я Tiny13 и 12F675.
В Tiny13 влез полноценный программатор PIC'ов (через uart).
А в 12F675 - "мигалка на 6 светодиодов".

12F675 - (как тут выразились ранее) - отдыхает.

Опять религиозная война начинается...
То, что у вас в ПИК "влезла" только мигалка на 6 светодиодов говорит не о "кривизне" оного, а, скорее о кривизне рук писавшего программу. В тот же 675 прекрасно влазит ADPCM кодер+софтовый UART передатчик, сам видел ...

[SasaVitebsk]

Тоже считаю что в основном это дело личных предпочтений. Скажем мои предпочтения на стороне AVR. Хотя безусловно я не могу претендовать на какой-нибудь авторитет в данном вопросе. Я работал с x48,x51,avr. С PIC ознакамливался. Хотел попробовать поработать. Жутко не понравилась система команд.

С другой стороны если работать на Си, то на систему комманд по сути наплевать. А в дальнейшем данные различия будут ещё более нивелироваться. Таким образом остаются следующие критерии.

1) Производительность. (На тестах написанных на СИ) Реакция на события.
2) Поддержка. (Наличие и доступность различных компиляторов, отладчиков, осей, библиотек, программаторов, JTAG и т.д.)
3) Наличие и обширность переферии. Широта переферии в одном камне. Удобство работы с ней.
4) Развитие номенклатуры и устранение огрехов. Модернизация камней.
5) Доступность самих камней и их стоимость.


Вот любопытная статья на тему что именно берут. То есть не взгляд разработчика, а взгляд продавца, которому по сути совершенно наплевать что именно он продаёт. http://kazus.ru/articles/389.html

[oran-be]

Как по мне АВРы - это как виндоза с точки зрения сравнения ее с полетом на "Кукурузнике" - тошнит, а выйти некуда.
Что по нынешним временам есть в ней хорошее - это то, что их везде, как грязи, и дешево, и халявный С компилятор. ВСЕ.
По производительности PIC18 имеет АВР по полной, несмотря на в 2 раза меньшее значение MIPS. Загрузка-выгрузка все сводит на нет. Уже не говоря про обработку прерываний. АВРы на этом тормозят ваще. PIC18 и 51-е умеют переключать контекст. А 51 по нынешним временам есть Силиконовские - они имеют АВР по MIPS конкретно. И Микрочипсы заваяли новые PIC18, которые по стоимости вставляют АВРы.
Зато АВРы можно считать первым ядром, которое раскрутили не за счет его достоинства, а за счет маркетингово правильно составленных технических возможностей и документации. Одни только виртуальные ассемблерные команды чего стоят, не говоря уже о раздутой донельзя производительности. В итоге на этой маркетинговой раскрутке Атмелы воспитали, можно сказать с пеленок, целое поколение МК программеров, в которых маркетинговые штампы уже записаны на генетическом уровне и которые уже не могут видеть преимущества других ядер.
У АВРов есть еще одна хорошая черта - обилие глюков дает разработчикам повод лишний раз пообщаться(человеческим языком ). АВРы - самая плодотворная тема для общения. "АВР признали!" Удивительно! До появления АТМег8 и 16 среди АВРов вообще не было рабочих контроллеров. Для серьезных применений. Как минимум они имели тенденцию само вытираться.

[VDLab]

Упс.. предлагаю прикрыть тему, пока до личностей не дошло.

[Qwertty]

Как по мне АВРы - это как виндоза с точки зрения сравнения ее с полетом на "Кукурузнике" - тошнит, а выйти некуда.
Что по нынешним временам есть в ней хорошее - это то, что их везде, как грязи, и дешево, и халявный С компилятор. ВСЕ.

Забавно. Что Вы делаете в ветке про AVR? В них ведь нет ничего хорошего...

По производительности PIC18 имеет АВР по полной, несмотря на в 2 раза меньшее значение MIPS. Загрузка-выгрузка все сводит на нет. Уже не говоря про обработку прерываний. АВРы на этом тормозят ваще. PIC18 и 51-е умеют переключать контекст. А 51 по нынешним временам есть Силиконовские - они имеют АВР по MIPS конкретно. И Микрочипсы заваяли новые PIC18, которые по стоимости вставляют АВРы.

Интересно за счет чего PIC18 имеет такую высокую производительность? За счет своей ущербной системы команд? Быстрая реакция на прерывания? Это когда надо ручками выяснять в обработчике, что же собственно произошло? За счет всего двух векторов для прерываний? Для таких заявлений неплохо иметь хоть что-нибудь кроме слов...

Удивительно! До появления АТМег8 и 16 среди АВРов вообще не было рабочих контроллеров. Для серьезных применений. Как минимум они имели тенденцию само вытираться.

Вы не любите кошек.... Мне приходилось работать с микрочиповским 16-м семейством, потом перешел на AVR и ниразу об этом не пожалел. Сейчас потихоньку иду в сторону AT91SAM7S. Тоже Атмел.
По старой памяти просматриваю "достижения" микрочипа. Кроме DsPIC ничего интересного не видел. Включая PIC18.

[Прохожий]

Как по мне АВРы - это как виндоза с точки зрения сравнения ее с полетом на "Кукурузнике" - тошнит, а выйти некуда.
Что по нынешним временам есть в ней хорошее - это то, что их везде, как грязи, и дешево, и халявный С компилятор. ВСЕ.
По производительности PIC18 имеет АВР по полной, несмотря на в 2 раза меньшее значение MIPS. Загрузка-выгрузка все сводит на нет. Уже не говоря про обработку прерываний. АВРы на этом тормозят ваще. PIC18 и 51-е умеют переключать контекст. А 51 по нынешним временам есть Силиконовские - они имеют АВР по MIPS конкретно. И Микрочипсы заваяли новые PIC18, которые по стоимости вставляют АВРы.

Полностью поддерживаю. Сравнивать 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 разрядный АЦП и т.д.).

[singlskv]

По производительности PIC18 имеет АВР по полной, несмотря на в 2 раза меньшее значение MIPS. Загрузка-выгрузка все сводит на нет. Уже не говоря про обработку прерываний. АВРы на этом тормозят ваще.

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

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

[Qwertty]

Полностью поддерживаю. Сравнивать AVR и PIC16 абсолютно некорректно. PIC16 старше AVR как минимум лет на 10. А вот PIC18 действительно, по производительности превосходят AVR за счет прямого обращения ко всей памяти, что технологически более прогрессивно. Я уже не говорю о расширенном наборе команд PIC18, который в корне меняет программную модель в сторону скоростной обработки данных непосредственно в памяти данных.

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

Насчет признали. В изделиях, предназначенных для работы в особо напряженных условиях в непрерывном режиме уже давно стоят исключительно PIC...
Косвенным указателем на отставание разаработчиков микроконтроллеров ATMEL ....

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

[VDLab]

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

[Прохожий]

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

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

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

[singlskv]

.........

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

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

[Прохожий]

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

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

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

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

Про AVR32 Вы видимо не слышали....

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

Дело не в этом, ИМХО, хотя AVR, ИМХО вполне справился бы с вашей
задачкой...

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

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

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

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

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

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

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

[Qwertty]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Прохожий]

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

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

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

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

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

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

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

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

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

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

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

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

[Rst7]

Во-первых, число 300 неудобное, так как не помещается в байт.

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

Можно кстати попробовать - например определить 3 массива байт по 300 и просуммировать первые два, помещая результат в 3-й.

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

[ae_]

Не, то что доктор прописал... Я вот не помню, в 18ом пичке тоже проблема с переносом? Если да, то 300 - самое то! :-D
Предлагаю просуммировать два числа по 300байт каждое в третье... Тоже интересно может получиться ;)

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

[Allregia]

Насчет дешевле - может быть, (хотя в последнее время ценовые пределы очень размыты. Флешевый Atmel часто стоит столько же сколько OTP аналог от MicroChip.)

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

Насчет "периферия разнообразнее" - однозначно нет. +1 в пользу Atmel.
Насчет лояльности - +1 в пользу MicroChip.

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

Сравнивал я Tiny13 и 12F675.
В Tiny13 влез полноценный программатор PIC'ов (через uart).
А в 12F675 - "мигалка на 6 светодиодов".

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

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

12F675 - (как тут выразились ранее) - отдыхает.

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

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

Да так и есть. PIC по сути изначально переферийный контроллер.

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

Ну и мы все тогда сможем убедиться как PIC рвет Atmel

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

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

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

DsPIC тоже не сразу стал доступен

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

[Rst7]

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

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

Код

   \                                 In segment CODE, align 2, keep-with-next
      5          unsigned int CRC16(unsigned int CRC, char c)
   \                     CRC16:
      6          {
      7            char h12;
      8            char h0;
      9            char h1;
     10            char hl5;
     11            char hh5;
     12            
     13            h12=CRC>>8;
     14            h0=CRC;
     15            
     16            h1=h12;                 //F  E  D  C  B  A  9  8
   \   00000000   2E01               MOV     R0, R17
     17            h12=__swap_nibbles(h12);        //B  A  9  8  F  E  D  C
   \   00000002   2FE1               MOV     R30, R17
   \   00000004   95E2               SWAP    R30
     18            hh5=h12;                //B  A  9  8  F  E  D  C
   \   00000006   2F3E               MOV     R19, R30
     19            h12^=h1;                //FB EA D9 C8 BF AE 9D 8C
     20            h12&=0xF0;                //FB EA D9 C8 _  _  _  _
   \   00000008   27E1               EOR     R30, R17
   \   0000000A   7FE0               ANDI    R30, 0xF0
     21            hh5&=0x0F;                //_  _  _  _  F  E  D  C
   \   0000000C   703F               ANDI    R19, 0x0F
     22            h1^=hh5;                //F  E  D  C  FB EA D9 C8
     23            hl5=h12;                //FB EA D9 C8 _  _  _  _
     24            {
     25              unsigned int i=(hh5<<8)|hl5;    //_  _  _  _  F  E  D  C  FB EA D9 C8 _  _  _  _
     26              i<<=1;
   \   0000000E   2F6E               MOV     R22, R30
   \   00000010   2F73               MOV     R23, R19
   \   00000012   0F66               LSL     R22
   \   00000014   1F77               ROL     R23
     27              hh5=i>>8;            //_  _  _  F  E  D  C  FB
     28              hl5=(char)i;            //                        EA D9 C8 _  _  _  _  _
     29            }
     30            h1^=hl5; //crclo        //                                FEA ED9 DC8 C   FB  EA  D9  C8
     31            h12^=hh5; //crchi        //FB  EA  D9  FC8 E   D   C   FB
     32            
     33            h12^=h0;
     34            h0=h1^c;
     35            return((h12<<8)|h0);
   \   00000016   2F47               MOV     R20, R23
   \   00000018   274E               EOR     R20, R30
   \   0000001A   2F10               MOV     R17, R16
   \   0000001C   2714               EOR     R17, R20
   \   0000001E   2530               EOR     R19, R0
   \   00000020   2F06               MOV     R16, R22
   \   00000022   2703               EOR     R16, R19
   \   00000024   2702               EOR     R16, R18
   \   00000026   9508               RET
     36          }

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

[oran-be]

М-да, не думал я, что констатация некоторых фактов вызовет такой резонанс...
Я просто в основном писал о том, что АВР уже имеет место быть. Как и Виндоза. А задачей девелопера является использовать наиболее дешевое и доступное решение. АВРы занимают свою нишу.
А диферамбы АВРам обычно поют те, кому в свое время маркетинговые ходы хакнули голову ( в связи с чем они обычно очень рьяно доказывают их преимущества), т.е. те, кто только начинал работать с МК, либо кто еще не присел на тогда имеющиеся ядра, в основном 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

[mse]

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

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

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

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

[Andreas1]

Дешевле, дешевле. Я использую и АВР и ПИК и другие, так что это не религиозная война.

Постоянно слышу это утверждение и не нахожу его подтверждения в прайсах. Назовите PIC, заменяющий мегу8(берем по $0,98...1,05), по цене менее бакса при тысяче штук в России. А такты считать - это уже вторично.
По разнообразию кристаллов и их упаковке пики впереди, но чаще цена важнее.

[oran-be]

Ну давайте попробуем порвать AVR пичком на простой функции...

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

не нахожу его подтверждения в прайсах

PIC18Jxxxxx новое семейство. И железо подправили, и цена очень впечатляет. Есть, конечно и пару оговорок, не без этого.

[Rst7]

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

Извините, но пока я выдвинул уже два предложения, а в ответ - "Курам на смех"... Видимо, пичек никак не может асилить передачу параметров через отсутствующие регистры общего назначения как вообщем то и любая архитектура с одним аккумулятором

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

[Andreas1]

PIC18Jxxxxx новое семейство. И железо подправили, и цена очень впечатляет. Есть, конечно и пару оговорок, не без этого.

На сайте мин цену имеет PIC18F24J10 - по возможностям примерно мега8, но больше флеша. Но это $1,49 Volume Pricing. Наверняка надо умножить на 1,5. Это дешевле???Впечатляет!!!
P.S. Часто сравнивают пики с атмелами по тактам, мипсам, ..., но не по цене сравнимых кристаллов. Пока для моих применений (без CAN,USB, Eth, <64k) атмель значительно выигрывал по цене.

[bodja74]

А ну брысь на свой форум кнопки топтать ,
пришли тут понимаеш со своим уставом.
Каждая жаба свое болото хвалит

1 Пока есть РОН - унарные операции отдыхают и по скоростям и по возможностям
2 С периферией для начала нужно научиться работать а потом хаять ,TWI выдаст ошибку в регистре статуса если что не так ,я уже не говорю про ситуации с NACK ,и правильно делает что затыкаеться,нечего инфу тупо гнать.
3 Порты нужно еще постараться спалить ,мне это удалось только один раз ,когда при сборке повесили тонкую соплю на корпус и я тупо подал 1 ,выясняя что не так ,и то не сразу МК сдох ,минут через 10
4 ераты - их куда больше можно найти в своей собственной программе
5 цена - недавно покупал PIC16F84 ,за такие деньги можно 3 меги8 купить ,а ведь он даже тиньке в пупок не дышит.

[Rst7]

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

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

Это ваше?

Код

Для ухода от стековой модели, у всех переменных и параметров функций присутствует квалификатор static. Массивам присваиваем квалификатор rom.

Если да, то я с таким бенчмарком не согласен.

[rx3apf]

На сайте мин цену имеет PIC18F24J10 - по возможностям примерно мега8, но больше флеша. Но это $1,49 Volume Pricing. Наверняка надо умножить на 1,5. Это дешевле???Впечатляет!!!
P.S. Часто сравнивают пики с атмелами по тактам, мипсам, ..., но не по цене сравнимых кристаллов. Пока для моих применений (без CAN,USB, Eth, <64k) атмель значительно выигрывал по цене.

Кстати, сравнение старших мег с новыми PIC24 на мой взгляд явно в пользу последних. Дешевле. А пример с mega8 - да, убийственный (сам хотел его предложить ).

[Allregia]

Постоянно слышу это утверждение и не нахожу его подтверждения в прайсах. Назовите PIC, заменяющий мегу8(берем по $0,98...1,05), по цене менее бакса при тысяче штук в России.

Мега8 - уникальный случай



А подобрать похожий ПИК трудно - все же есть различия в номенклатуре.

Более-менее годится pic16f690 - и по цене примерно такой же.

Но можно взять ST72*, ST7Lite, или Холтек какой - будет еще дешевле



P.S. Во многих местах, слышал мнение что Атмел в России демпингует с ценами.

[pokos]

P.S. Во многих местах, слышал мнение что Атмел в России демпингует с ценами.

Тогда в Китае он демпингует ещё больше. Там Мега8 товарищи берут по $0.8 при тысяче штук.

[zltigo]

А ну брысь на свой форум кнопки топтать ,
пришли тут понимаеш со своим уставом.
Каждая жаба свое болото хвалит

Любое, пусть даже теплое, болото нуждается в переодической встряске. Постарайтесь смотреть на свое 'болото' менее субъективно. И этому процессу как нельзя лучше помогает взгляд со стороны.

[rx3apf]

Мега8 - уникальный случай
А подобрать похожий ПИК трудно - все же есть различия в номенклатуре.
Более-менее годится pic16f690 - и по цене примерно такой же.

Как конкурент mega8 - и близко не лежал. Как, впрочем, и остальные pic16. С килобайтом оперативки поспорить очень трудно.. По периферии - тоже не конкурент. И по цене тоже, кстати - в розницу вдвое дороже (смотрю прайсы Эфо и Тритон).
Я бы скорее назвал 16F876 - но опять же, оперативки кот наплакал. И - опять же, много дороже. Вообще, на мой взгляд (при всей моей привязанности к PIC16), когда речь идет о более-менее существенной работе с массивами - PIC16 сливает AVR вчистую. Вся экономия в объеме кода перекрывается корявой работой с банками памяти. Программную память в качестве памяти данных тоже использовать крайне неудобно.

P.S. Во многих местах, слышал мнение что Атмел в России демпингует с ценами.

И только в Росии ? Хм.. Как рынок, мы такого внимания вряд ли достойны. Но что ценовая политика очень агрессивная - очевидно. Интересно, что новые кристаллы от Microchip существенно дешевле, и новые семейства - тоже. PIC24 - так натурально дешевле старших мег, хотя в архитектурные тонкости я не влезал, но на первый взгляд довольно интересно. Как конкурент MSP430 - тоже.

Сообщение отредактировал rx3apf - Aug 9 2007, 09:57

[Rst7]

Любое, пусть даже теплое, болото нуждается в переодической встряске.

Безусловно, почему бы не встряхнуть болото пичков

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

Да конечно, мы прекрасно знаем недостатки архитектуры AVR (главный из них - нет комманд типа LDR Rx,SP+disp и аналогичный STR, очень бы помогло компилятору сишному)...

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

[Andreas1]

Мега8 - уникальный случай

До нее таким случаем были 90S2313, 89С51(2051). Немного удачных недорогих кристаллов, цена которых позволяет ставить в более простые вещи=>экономия и удобство закупок.

Более-менее годится pic16f690 - и по цене примерно такой же.

efind.ru уверяет, что в 2,5 раза дороже, как и с предыдущими "уникальными случами ". Конечно, китайский 51 или холтек чуть дешевле, но пролететь с поставкой - запросто.
Когда небольшая серия, большое разнообразие уст-в или хитрая фичастость, тогда пик и выигрывает.
Когда оптовая цена вылетает за $5, там атмелю тяжело и конкурентов хоть отбавляй.

[zltigo]

Да и вообще, заметьте, запуск обсуждения был произведен именно фразой "Пик - рулит, авр - кака", так что наше болото только защищается

Исключительно справедливости ради, фраза была с точностью до наоборот :

(alexander55 @ Aug 8 2007, 16:02)
Среди 8 разрядных uC AVR вне конкуренции. PIC и 51 отдыхают.

[Rst7]

Согласен. Как раз эту фразу я пропустил... Ну ладно, нападение - лучшая защита

[alexander55]

Исключительно справедливости ради, фраза была с точностью до наоборот :

51 - это быстрые бегуны на месте (3-4 шагана месте, 1-вперед).
PIC - кривые и косые (но понятно, что можно так использовать кривизну, что она станет достоинством), его придумали инолланетяне.

[defunct]

То, что у вас в ПИК "влезла" только мигалка на 6 светодиодов говорит не о "кривизне" оного, а, скорее о кривизне рук писавшего программу. В тот же 675 прекрасно влазит ADPCM кодер+софтовый UART передатчик, сам видел ...

6 светодиодов это я утрирую.
А по поводу того, что вы видели, давайте больше конкретики. Был ли внешний кварц, какая скорость УАРТа?

Помню когда делал оценку возможной реализации дуплексного UART'а на 12F675 с тактом от внутреннего осциллятора, остановился на цифре 200 бод. Выше он просто не тянет. Поэтому для решения задачки (Modbus свлейв, опрашивающий 8 дискретных входов и 1 канал АЦП + 1 дискретный выход) выбор пал на T13.

В T13 с тактом от внутреннего осциллятора, уложился софтовый дуплексный УАРТ 38400, и осталось ~60% ресурсов проца под задачу (это около 3-4MIPS). Реализацию уарта можете посмотреть в "Исходниках программ и библиотек".

ADPCM закодировать имея в распоряжении 3-4MIPS AVR'овских - без проблем. (если прикинуть частоту на которой PIC может выжать 3-4 AVR'овских MIPS'а, то получите цифру в 30-40Mhz).

[Alex B._]

>> 12F675 с тактом от внутреннего осциллятора,
>> остановился на цифре 200 бод. Выше он просто не тянет

ну это вы точно погорячились =)

12F683 - ADPCM декодер (ADPCM симметричный, поэтому что кодер, что декодер ...) + I2C программный + wavetable синтез - пожарный извещатель (нужен голос и сирена). На Си, без особого напряга и хитростей, 8 МГц внутренний генератор. ШИМ правда аппаратный, но и программный бы туда влез на раз. [поправил] - не, наверное не влез бы

Смысла встряски не понимаю =) Знаю safity-critical устройства и в которых и пики и атмель. Глубоко скрытые комплексы может быть? Типа, я ж не лох какой, с аутсайдером работать... Расслабьтесь, в любой профессии такое есть. Гораздо познавательнее - доходами мерятся =)

[mse]

Это ваше?

Код

Для ухода от стековой модели, у всех переменных и параметров функций присутствует квалификатор static. Массивам присваиваем квалификатор rom.

Если да, то я с таким бенчмарком не согласен.

Не "...квалификатор static...квалификатор rom..." я не мог такое написать. Никогда! ;О) Даже в гшорячечном бреду.

[defunct]

>> 12F675 с тактом от внутреннего осциллятора,
>> остановился на цифре 200 бод. Выше он просто не тянет

ну это вы точно погорячились =)

Нет! Я пробовал на практике и очень хотел применить вначале PIC, но обломался.. т.к:

1MIPS на внутреннем осце.
Прием ~50 инструкций на бод, передача ~50 инструкций на бод.
итого 1000 инструкций на прием и передачу кадра.
10^6 / 10^3 == 1000 бод в пике.
округляем в меньшую сторону до ближайшего стандартного бодрейта - получаем 600bod.
Считаем ошибку для 600bod с тактом 1Mhz, и приходим к выводу что только 200 bod можно работать.

Смысла встряски не понимаю =) Знаю safity-critical устройства и в которых и пики и атмель.

Смысл весьма прост, у разных МК разные преимущества и недостатки. У AVR одни, у PIC'а другие. Когда одному МК приписывают преимущества или недостатки другого - это неправильно. В данном случае у Atmel'а есть явное преимущество над всеми 8-ми битными МК - производительность.

Человек попытался это оспорить, отсюда собственно и встряска ;>

Гораздо познавательнее - доходами мерятся =)

резонно

[Rst7]

Не "...квалификатор static...квалификатор rom..." я не мог такое написать. Никогда! ;О) Даже в гшорячечном бреду.

Дайте тогда ссылку на ваши бенчмарки... Я на сахаре только это нашел

резонно

Своими доходами?

Так даже с Вами мне слабо померяться по причине разной оплаты в Киеве и в Первой Столице... Мои $600 в Харькове ни о чем по киевским меркам...

[defunct]

Своими доходами?

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

[Allregia]

Как конкурент mega8 - и близко не лежал. Как, впрочем, и остальные pic16. С килобайтом оперативки поспорить очень трудно..

Кого это интересует, если программа вмещается и работает :-)

Вот во что я не упирался - так это в недостаток оперативки! В пямять программ - да, бывало. Приходилось оптимизировать алгоритмы и структуры программ.
А вот на 8515 - таки раз уперся именно в оперативку, пришлось часть флеша для епрома для редко используемых данных использовать.

efind.ru уверяет, что в 2,5 раза дороже, как и с предыдущими "уникальными случами ".

Не знаю что утверждает ефайнд, (тем более "ру", нам они в Китае нужны а не в "ру"), а 819е под текущие проекты мы брали по 0.8, сейчас меняем их на 690-й, пока количеств анебольше - берем по 1.20, потом обещают по той же цене что и 819-е.
Но количества не тысяча а существенно больше.

Сообщение отредактировал Allregia - Aug 9 2007, 13:47

[m16]

Дайте тогда ссылку на ваши бенчмарки... Я на сахаре только это нашел

тут они
имхо пора сделать религиозные подфорумы : Микроконтроллерные войны , С vs ASM .... во как )

[mse]

Дайте тогда ссылку на ваши бенчмарки... Я на сахаре только это нашел

Всё не нашол, вот только что. Но там ещё было.
http://caxapa.ru/68211.html?todo=full

А ФИР лежит в разделе Беньччморки. Для унсигнед операндов. Там, правда, его на пару-тройку тактов ускорить можно. Но с арифметикой супротив АВРа ПИКу(16,18, поф) ловить нечего - пролёт в разы. И чем длиннее арифметика, тем разов больше. Особенно, если умножение и операнды знаковые.

[Прохожий]

Всё не нашол, вот только что. Но там ещё было.
http://caxapa.ru/68211.html?todo=full

А ФИР лежит в разделе Беньччморки. Для унсигнед операндов. Там, правда, его на пару-тройку тактов ускорить можно. Но с арифметикой супротив АВРа ПИКу(16,18, поф) ловить нечего - пролёт в разы. И чем длиннее арифметика, тем разов больше. Особенно, если умножение и операнды знаковые.

Дык, свой, согласованный и утвержденный тест будем делать или нет?

[Allregia]

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

[=GM=]

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

Самый простой тест требует переноса содержимого 64-байтного массива A[64] сначала в массив B[64], а затем из массива B[64] в массив C[64]. Решил попробовать написать свой код на ассемблере для нескольких процов, вот что получилось

Код

процессор    частота    сахара-бенчмарк ассемблер
атмега       (20 МГц)     5300 тактов      900
pic18f242    (10 МГц)     3321 такт        650
pic18f242    (10 МГц)     8652 такта       650
tms320f2812 (150 МГц)      762 такта        40

То есть, если писать на ассемблере, то очевидно, что на данном тесте pic18 на 30% быстрее, чем атмега.

Для интересующихся ниже приведены фрагменты программ

;Фрагмент для атмеги

Код

movblk:  ld     temp,x+ ;2
         st     y+,temp ;2
         dec    counter ;1
         brne   movblk  ;2/1

;Пересылка одного байта выполняется за 7 тактов

;Фрагмент для пика

Код

movblk   movf   postinc0;1
         movwf  postinc1;1
         decfsz counter  ;1/2/3
         goto   movblk  ;2

;Пересылка одного байта выполняется за 5 тактов

[Прохожий]

;Фрагмент для пика

Код

movblk   movf   postinc0;1
         movwf  postinc1;1
         decfsz contin  ;1/2/3
         goto   movblk  ;2
contin

;Пересылка одного байта выполняется за 5 тактов

А если вот так:

Код

movblk   movff   postinc0,postinc1;2
         decfsz contin  ;1/2/3
         goto   movblk  ;2
contin

Хотя сути это не меняет, но позволяет исключить рабочий регистр W.

[Rst7]

Чето я не пойму. Этот пост:

А ФИР лежит в разделе Беньччморки. Для унсигнед операндов. Там, правда, его на пару-тройку тактов ускорить можно. Но с арифметикой супротив АВРа ПИКу(16,18, поф) ловить нечего - пролёт в разы. И чем длиннее арифметика, тем разов больше. Особенно, если умножение и операнды знаковые.

и этот:

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

Оба ваши... Как понимать?

атмега (20 МГц) 5300 тактов 900
pic18f242 (10 МГц) 3321 такт 650
pic18f242 (10 МГц) 8652 такта 650

10 МГц у пичка подразумевает 40 (из-за PLL)?

Ну да не суть. Обычно задача копирования массивов не стоит (а если стоит, то имеет смысл пересмотреть алгоритм).

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

[=GM=]

А если вот так:

Код

movblk   movff   postinc0,postinc1;2
         decfsz counter ;1/2/3
         goto   movblk ;2

Хотя сути это не меняет, но позволяет исключить рабочий регистр W.

Так не пойдёт, в этой команде нельзя применять косвенную адресацию. Так, как вы написали, вы просто N раз копируете из адреса postinc0 в ячейку по адресу postinc1.

[defunct]

GM & Прохожий.

Господа, давайте разберемся уж до конца:

Выдержка из даташита на PIC18F4450

All single-word instructions are executed in a single
instruction cycle, unless a conditional test is true or the
program counter is changed as a result of the instruction.
In these cases, the execution takes two instruction
cycles with the additional instruction cycle(s) executed
as a NOP.
The double-word instructions execute in two instruction
cycles.
One instruction cycle consists of four oscillator periods.
Thus, for an oscillator frequency of 4 MHz, the normal
instruction execution time is 1 μs.

Теперь давайте приведем к общему знаменателю машинные циклы, обзовем их CYC.
На одинаковой частоте CYCavr = 1/4 * CYCpic
С учетом, что PIC18 работает на 10-12Mhz, а Mega - 16-20Mhz,

CYCavr = 12/20 * 1/4 CYCpic

12/20/4 = 0.15 - это соотношение одного микрочиповского цикла, к AVR'овскому. (Тобиш коэффициент который показывает насколько "быстрее" выполняется одна инструкция на PIC в сравнении с AVR).

Ну а далее смотрим на результат тестов:

5 машинных циклов на микрочипе делим на коеффициент 0.15

получаем

5/0.15 = 33.33 машинных цикла AVR

33.33 AVRовских такта на PIC, против 7 на AVR.

33.33/7 = ~5
На простеньком тесте, PIC уделали в пять раз.

Вывод - по производительности PIC18 фтопку.
Banchmark'и сахары - туда же (особливо если для тестов там использовался IAR 2.2).

[Proton]

Насчёт противостояния ПИКов и AVRок я заметил следующую закономерность. Когда готовил свой дипломный проект у меня был доступ к дипломам прошлых лет. В старых дипломах львиная доля проектов была выполнена на ПИКах, гораздо меньше MCS-51. В новых работах за последние несколько лет практически сплошняком идут AVRки. О чём это говорит, подрастает новое поколение которое прийдя на предприятия будет закладывать в свои устройства уже AVR. И это уже просходит, просматривая вакансии нередко можно встретить требование опыта работы с AVR, ПИКи практически не встречаются. На предприятии где я работаю, для управления силовыми схемами используются исключительно AVR, они же входят в состав изделий поставляемых на АвтоВАЗ.

[zltigo]

В новых работах за последние несколько лет практически сплошняком идут AVRки. О чём это говорит...

Это говорит о том, что если 8bit AVR в своей массе уже добрались до студенческих "работ", то надо смотреть что нужо использовать в реальной работе вместо них . Шутка, конечно, но с большой долей истины.

[Прохожий]

.....

Вывод неверный, потому как внутренняя частота внутри PIC18F может быть умножена на 4 за счет внутреннего PLL. PICи с USB (типа 18F4550) брать в расчет не будем. Итого 10 Мгц *4(это PLL)/4(число циклов в команде)=10мгц. Т.е. минимальное время выполнения команды в PIC18 составляет 100 нс против 50 нс в AVR. Далее, подсчитав число циклов в варианте для AVR получаем 7*50=350 нс. Для варианта с PIC имеем 100*5=500 нс. Берем соотношение 500/350=1.43. Вывод: для этого конкретного примера AVR оказался быстрее PIC в 1.43 раза.
Преимущество незначительное, ели учесть все неудобства, связанные с эксплуатацией AVRов.

[=GM=]

GM & Прохожий.
Теперь давайте приведем к общему знаменателю машинные циклы, обзовем их CYC.
На одинаковой частоте CYCavr = 1/4 * CYCpic
С учетом, что PIC18 работает на 10-12Mhz, а Mega - 16-20Mhz,

CYCavr = 12/20 * 1/4 CYCpic

12/20/4 = 0.15 - это соотношение одного микрочиповского цикла, к AVR'овскому. (Тобиш коэффициент который показывает насколько "быстрее" выполняется одна инструкция на PIC в сравнении с AVR).

Ну а далее смотрим на результат тестов:

5 машинных циклов на микрочипе делим на коэффициент 0.15

получаем 5/0.15 = 33.33 машинных цикла AVR

33.33 AVRовских такта на PIC, против 7 на AVR.

33.33/7 = ~5
На простеньком тесте, PIC уделали в пять раз.

Вывод - по производительности PIC18 фтопку.
Banchmark'и сахары - туда же (особливо если для тестов там использовался IAR 2.2).

Не, так плохо. Под рукой описание на PIC18F2240, буду опираться на него, думаю в PIC18F4450 похожее положение дел. Давайте положим свои предпочтения в карман и рассмотрим по справедливости. (Сам я предпочитаю иметь дело с авр, мне нравится система команд, хотя и не без недостатков).

1) Потреблениие прямо пропорционально тактовой частоте, на которой работает ядро (системная частота процессора). Так что лучше сравнивать в машинных циклах (МЦ). Ну посудите сами, вы на МК PIC18F2240 подаёте 10 МГц, а они там умножаются на 4, получается 40, но одна команда выполняется за 4 периода частоты 40, т.е. системная частота равна 10. Вывод - сравнение только МЦ.

2) По производительности. Для атмеловского фрагмента время исполнения 900/20=45мкс, для пика - 650/10=65 мкс. Времена выполнения одного порядка, никакого выигрыша по производительности в 5 раз нету и в помине.

3) Давайте скажем по справедливости, что на данном тесте пик обходит авр по машинным циклам. Представьте себе, что завтра микрочипы сделают системную частоту 20 Мгц. Ну и кто будет в проигрыше?

4) Вот тут предлагали посчитать crc на одном и другом проце, давайте посмотрим, кто там будет впереди?

[Прохожий]

Это говорит о том, что если 8bit AVR в своей массе уже добрались до студенческих "работ", то надо смотреть что нужо использовать в реальной работе вместо них . Шутка, конечно, но с большой долей истины.

Я лично склоняюсь все к тем же 24-м PICам, потому как 18-е уже надоели. Слишком много неудобств. AVR - не вариант.
Хотя почти все японские фирмы (OMRON, например) в своих промышленных покидухах применяют в основном NEC в различных вариантах в зависимости от назначания покидухи.
Хотелось бы узнать мнение уважаемого коллектива. Если не PIC18 и не AVR, то что?

[defunct]

Итого 10 Мгц *4(это PLL)/4(число циклов в команде)=10мгц.

Ок прощу прощения что не учел PLL.

Берем соотношение 500/350=1.43. Вывод: для этого конкретного примера AVR оказался быстрее PIC в 1.43 раза.

Преимущество довольно значительное, если взять во внимание простоту теста.

Еще, помоему код получился неравнозначным.
Халтурка-с

Код

movblk:  ld     temp,x+;2
         st     y+,temp;2
         dec    counter;1
         brne   movblk;2/1
;Пересылка одного байта выполняется за 7 тактов

этот код копирует counter байт из x в y

Код

;Фрагмент для пика
movblk   movf   postinc0;1
         movwf  postinc1;1
         decfsz counter;1/2/3
         goto   movblk;2

А этот что делает?

postinc0, postinc1 - адреса намертво вшиваемые в тело команд.

3) Давайте скажем по справедливости, что на данном тесте пик обходит авр по машинным циклам.

Безусловно, ведь PIC в данном тесте не выполняет того функционала который делает AVR. Результат кода (который выиграл по маш. циклам) будет отличаться от того, который проиграл.
Давайте вначале подправим тест?

Представьте себе, что завтра микрочипы сделают системную частоту 20 Мгц. Ну и кто будет в проигрыше?

Что будет завтра - это уже другой вопрос..
Завтра может Atmel PLL засунет и запустит ядро на 40Mhz или 80..

По остальным пунктам, думаю ответил выше.

[rx3apf]

Я лично склоняюсь все к тем же 24-м PICам, потому как 18-е уже надоели. Слишком много неудобств. AVR - не вариант.
Хотя почти все японские фирмы (OMRON, например) в своих промышленных покидухах применяют в основном NEC в различных вариантах в зависимости от назначания покидухи.
Хотелось бы узнать мнение уважаемого коллектива. Если не PIC18 и не AVR, то что?

Найдутся и "фанаты" MSP430. Я, например, его использовал довольно много, но как-то "душа не лежит". PIC24 по первому впечатлению на него похож... Думаю, не надо делать из конкретного микроконтроллера (или семейства) культа. Фанатичная привязанность ограничивает кругозор в ущерб результату. Подбирать надо по задаче, а не задачу под контроллер...

[=GM=]

Ок прощу прощения что не учел PLL.
Преимущество довольно значительное, если взять во внимание простоту теста.

Как раз преимущества по машинным циклам нет, наоборот. У меня на вход TMS320F2808 подаётся 20 МГц, но внутри они умножаются на 10 и делятся на 2, какую частоту мне брать для определения производительности? 20, 100 или 200 МГц?

Еще, помоему код получился неравнозначным. Халтурка-с

Код

;Фрагмент для пика
movblk   movf   postinc0;1
         movwf  postinc1;1
         decfsz counter;1/2/3
         goto   movblk;2

А этот что делает? postinc0, postinc1 - адреса намертво вшиваемые в тело команд.

Не, это вы халтурно относитесь к пику(:-). Регистр POSTINCn это аналог регистра INDFn, только с постинкрементом.

На си примерно так будет *(postinc1)++ =*(postinc0)++

[defunct]

Я лично склоняюсь все к тем же 24-м PICам, потому как 18-е уже надоели. Слишком много неудобств. AVR - не вариант.

А почему тогда не ARM?

Не, это вы халтурно относитесь к пику(:-).

Понял ;>

Как раз преимущества по машинным циклам нет, наоборот. У меня на вход TMS320F2808 подаётся 20 МГц, но внутри они умножаются на 10 и делятся на 2, какую частоту мне брать для определения производительности? 20, 100 или 200 МГц?

Частоту ядра конечно. В вашем случае - 100.
Для PIC'а если с 4xPLL'ом - 40Mhz, но приводить к какому-то эталону все равно надо. Приводят к MIPS'aм, и в ДШ на PIC должно быть написано - ядро PIC на 40Mhz имеет производительность 10MIPS.

[Прохожий]

Код

;Фрагмент для пика
movblk   movf   postinc0;1
         movwf  postinc1;1
         decfsz counter;1/2/3
         goto   movblk;2

А этот что делает?

postinc0, postinc1 - адреса намертво вшиваемые в тело команд.

Опять же неправда Ваша. PostincХ - это ссылка на виртуальный системный регистр с аналогичным именем, означающая что исполнительный адрес берется из пары FSRXH:FSRXL и после выполнения команды к этому делу будет прибавлена 1. Следовательно в указанном случае пересылка осуществляется следующим образом:
Байт данных, расположенный по адресу FSR0H:FSR0L перешлется в ячейку по адресу FSR1H:FSR1L, затем регистровые пары FSR0H:FSR0L и FSR1H:FSR1L будут инкрементированы. И все это дело повторится изначальное (при входе в цикл) counter раз.

[=GM=]

Хотелось бы узнать мнение уважаемого коллектива. Если не PIC18 и не AVR, то что?

Сильно зависит от задачи. Я долго работал с TMS320C5402, клял эти проклятые пайплайновые конфликты, потом перешёл на TMS320F2808..12. Ну, скажу я вам, небо и земля. И управление легко делать, подрыгать ногами, и ДПФ быстро, 16*16 умножает за такт, 32*32 за два такта, и периферии до чёрта: CAN, SPI, I2C, ADC 12.5 Мвыборок/с. Почти мечта(:-). Сейчас новые представители семейства появились, так там есть модуль плавающей точки...

[mse]

Чето я не пойму. Этот пост:
и этот:
Оба ваши... Как понимать?

Буквально. Как Тузик порвёт сковородку, так ПИК порвёт АВРа в арифметике. ;О)

Прохожему: На сахаре, в беньчморках лежит ФИР, писаный мной на АСМе. С тактами. Можете написать аналогичное на ПИКе и посчитать. Во сколько раз медленнее оно будет. Да и здесь, в АВРовой ветке, есть то-же самое, только знаковая арифметика.

По поводу пересылок: пересылка массива памяти, сама по себе, никому не нужна. Нахрен пересылать массив из одного места в другое, если работать можно сразу в том месте? Ну да ланна, это на любителя. ;О)

Сильно зависит от задачи. Я долго работал с TMS320C5402, клял эти проклятые пайплайновые конфликты, потом перешёл на TMS320F2808..12...

Ну согласитесь, сравниватьТМС320 с ПИКо-АВРами некорректно. И не только из-за ТМСовой крутизны. ПИКо-АВРы требуют вокруг себя меньше обвязки, меньше жрут, меньше занимают места. Стоят дешевле. Из этого и исходить. Лёгкое ядро, оно всегда себе дырочку найдёт. ;О)

[_artem_]

Вот одна страничка в которой утверждается что начинка ericsson а1018 на базе авр :
http://www.hackcanada.com/blackcrawl/cell/texts/charger.pdf

правда чип вроде бы кастом.

[rx3apf]

Вот одна страничка в которой утверждается что начинка ericsson а1018 на базе авр :
http://www.hackcanada.com/blackcrawl/cell/texts/charger.pdf

правда чип вроде бы кастом.

Известный выводок T39/R520 и остальные из того ряда - тоже AVR (в смысле, ядро AVR, периферия другая).

[singlskv]

Самый простой тест требует переноса содержимого 64-байтного массива A[64] сначала в массив B[64], а затем из массива B[64] в массив C[64].

GM, давайте чуть чуть усложним задачку.
Пусть есть два 64 байтных массива A[64] и B[64],
а в массив С[64] будем писать типа С[i] = A[i] (&, | или ^) B[i];
И оценим скорость на пике и авр как в машинных циклах, так и реальное время
выполнение на максимальной частоте кристала.

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

P.S. Кстати, эта задачка также хороша для религиозной
войны IAR vs WinAVR

[Прохожий]

А почему тогда не ARM?

Здесь вопрос достаточно сложный. Из первого знакомства с ARM вынес следующее:
1. Дорогая среда разработки (EWARM от IAR).
2. Отсутствие хорошего бесплатного компилятора С (сам не пробовал, но отзывы о GCC не очень лестные).
3. Дорогостоящее оборудование для отладки.
4. Излишне сложная система команд (привычка начинать знакомство с Ассемблера).
Прошу учесть, что это мое личное мнение, не претендующее на абсолютную истинность.

[zltigo]

1. Дорогая среда разработки (EWARM от IAR).

Лукавите

2. Отсутствие хорошего бесплатного компилятора С (сам не пробовал, но отзывы о GCC не очень лестные).

Одного поля ягода с так называемым WinAVR, который, как я понимаю, 'устраивает'.

3. Дорогостоящее оборудование для отладки.

-Для любительско/халявных вариантов Wiggler дорогостоящ ?
-клоны профессиональных стоят одинаково - в пределах десятков долларов.
-оригинальные - несколько сотен для любого из контроллеров.

4. Излишне сложная система команд (привычка начинать знакомство с Ассемблера).

Привычка на данном историческом этапе 'дурная' - ARM контроллер при сопоставимых ценах с AVR девайс другой весовой категории. С ASM начинать не надо. Бегло просматривать результат компиляции, изредка писать пару десятков команд безусловно надо, но плотно изучать и начинать писать вполне достаточно в процессе работы и постфактум.

[SasaVitebsk]

Всё что я пишу ниже, мой взгляд на данную тему.

Что по нынешним временам есть в ней хорошее - это то, что их везде, как грязи, и дешево, и халявный С компилятор. ВСЕ.

Так это "ВСЁ", уважаемый, два из моих 5 пунктов. А третий (производительность на СИ) вы переврали, в чём вас тут же и уличили.

По производительности PIC18 имеет АВР по полной, несмотря на в 2 раза меньшее значение MIPS. Загрузка-выгрузка все сводит на нет.

Это совершенно неверный вывод. Видимо вы не работали по другому. Либо не интересовались исследованиями в данной области. Для 90% вычислений будет достаточно регистров РОН имеющихся у AVR. Загрузка и выгрузка применяется крайне редко. Если не верите, то проанализируйте любую программу на AVR. Причём компилятор Си от IAR прекрасно этим пользуется.

Уже не говоря про обработку прерываний. АВРы на этом тормозят ваще. PIC18 и 51-е умеют переключать контекст.

За Pic говорить не буду, но контекст x51 это всего 8 регистров.А рабочих - 8. Никто не мешает в AVR распределить регистры тем же способом. Вообще переключение контекста не понадобится!!! То есть данный постулат - откровенный бред. (по x51)

А 51 по нынешним временам есть Силиконовские - они имеют АВР по MIPS конкретно. И Микрочипсы заваяли новые PIC18, которые по стоимости вставляют АВРы.

По стоимости и доставабельности AVR и вообще Atmel в России и СНГ - вне конкуренции. Здесь они просто молодцы. В других странах судя по отчётам motorolla лидирует.

Зато АВРы можно считать первым ядром, которое раскрутили не за счет его достоинства, а за счет маркетингово правильно составленных технических возможностей и документации. Одни только виртуальные ассемблерные команды чего стоят, не говоря уже о раздутой донельзя производительности. В итоге на этой маркетинговой раскрутке Атмелы воспитали, можно сказать с пеленок, целое поколение МК программеров, в которых маркетинговые штампы уже записаны на генетическом уровне и которые уже не могут видеть преимущества других ядер.

На момент перехода на AVR, я лично, не читал ни одной рекламной статьи. Более того существовало не более 10 кристаллов. За минусом 1200(12МГц) все остальные работали до 8МГц. На сайте Atmel - писали "повышения тактовой частоты в будущем не планируется". Я перешёл только из-за того, что писал на АСМе и даже слепому, вопреки вашему утверждению, видно что архитектура на голову выше. Выбрал я их поиском. Оценивал очень разные (К примеру PIC и Scenic). Читал сразу даташит. Что касается "виртуальных комманд", то это широко распространнённая практика ещё с исторических времён. И впервые её использовали сами программисты. На 8080 вместо CLR A использовали xor a,a. Не вижу здесь злого умысла. Очень удобно. Не каждый знает эти "фокусы", но если есть соответствующая мнемоника, то лучше использовать tst a, чем or a,a , как мы это делали на 8080.

У АВРов есть еще одна хорошая черта - обилие глюков дает разработчикам повод лишний раз пообщаться(человеческим языком ). АВРы - самая плодотворная тема для общения. "АВР признали!" Удивительно! До появления АТМег8 и 16 среди АВРов вообще не было рабочих контроллеров. Для серьезных применений. Как минимум они имели тенденцию само вытираться.

По поводу серьёзных применений с вами бессмысленно спорить. Безусловно применение МК вами - серьёзно, а мной - несерьёзно.

Девайс монтируется непосредственно у исполнительных модулей приблизительно на 40...50 Ампер.
Не знаю как AVR, а PIC18F работает достаточно устойчиво вот уже порядка трех лет в нескольких сотнях девайсов.

На форуме Точки опоры один человек утверждал, что его мега128 управляет станком искрорезки. Установлена в 20см от самой искры и работает прекрасно. Ни единого сбоя. И тоже год или что-то возле этого. Я могу привести пример, подтверждённый документально, что мои изделия в количестве 40 штук поставили на замену днепропетровским. По причине, что мои за неделю тестирования не зависли ни разу, а днепропетровские за два дня повисали практически все. Мои на меге днепропетровские на пике. (Причина - помехи) Но это не повод ругать пики. Это повод ругать программеров и схемотехников.

12F683 - ADPCM декодер (ADPCM симметричный, поэтому что кодер, что декодер ...) + I2C программный + wavetable синтез - пожарный извещатель (нужен голос и сирена). На Си, без особого напряга и хитростей, 8 МГц внутренний генератор. ШИМ правда аппаратный, но и программный бы туда влез на раз. [поправил] - не, наверное не влез бы

На меге 8 на 16МГц я вводил/выводил сигнал битовый поток на 32кГц и вводил/выводил байтовый поток на 8кГц. Фактически транскодер ИКМ в АДИКМ и обратно. Попутно делал 12 цифровых фильтров. Естественно "внутри" сигнал был 16-ти битный. Конкуренты на PICе так и не смогли повторить. Их изделие использовало 2 PIC 16 + дополнительную микруху с фильтрами.


И сравнивать производительность надо всётаки именно на СИ. Причина проста. На СИ пишут большенство программистов. Таким образом "кривизна" компилятора как раз имеет значение в конечном устройстве. Так почему я не должен её учитывать при выборе? Отсутствие хорошего компилятора - это серьёзный минус. Отсутствие бесплатного - ещё один. Невозможность использования библиотек, написанных под GNU - третий. Отсутствие портов для популярных ОСей - для некоторых (например zltigo ) - просто смерть данного семейства.

GM, давайте чуть чуть усложним задачку.
Пусть есть два 64 байтных массива A[64] и B[64],
а в массив С[64] будем писать типа С[i] = A[i] (&, | или ^) B[i];
И оценим скорость на пике и авр как в машинных циклах, так и реальное время
выполнение на максимальной частоте кристала.

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

P.S. Кстати, эта задачка также хороша для религиозной
войны IAR vs WinAVR

Всётаки задачка высосана из пальца, потому что правильнее всётаки минимум два массива (B и С) формировать одновременно во время приёма B. И лишних пересылок, при этом не будет.

[Прохожий]

GM, давайте чуть чуть усложним задачку.
Пусть есть два 64 байтных массива A[64] и B[64],
а в массив С[64] будем писать типа С[i] = A[i] (&, | или ^) B[i];
И оценим скорость на пике и авр как в машинных циклах, так и реальное время
выполнение на максимальной частоте кристала.

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

P.S. Кстати, эта задачка также хороша для религиозной
войны IAR vs WinAVR

К стати, скажу по секрету, что для обслуживания любой шины, связанной с USART, AVR подходит несколько лучше, чем PIC. Это связано с тем, что в AVR реализован аппаратный контроль четности, а в PIC - нет.
Скажите (действительно интересно), а где при обслуживании MODBUS требуются такие действия?
Что же касается теста, то для PIC будет приблизительно следующее:

Код

Loop     movf   postinc0,w,0; 1
         andwf  postinc1,w,0; 1
         movwf postinc2,0  ; 1
         decf    counter,f,0  ; 1
         bnz    Loop           ; 2

Получилось 6 МЦ или 600 нс при частоте кварца 10 МГц и включенном PLL.

[zltigo]

Отсутствие портов для популярных ОСей - для некоторых (например zltigo ) - просто смерть данного семейства.

Лично я способен и сам оси оптимальные с точки зрения нужной мне функциональности писать, что и проделывал неоднократно . И использовать и модифицировать 'непопулярные' тоже могу. И портировать 'популярные' могу. И без осей могу, но уже последние лет 15-17 это крайне редко делаю - опыт, однако.
Так-что поминать меня всуе не надо

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

Ну заметно плохих компиляторов уже пожалуй нет - вымерли, динозавры
А бесплатность - пусть лучше будет уверенность с развитии и соответственно в том, что компилятор не станет аутсайдером.
Ибо плата даже за 'дорогой' компилятор вполне сопоставима c месячной зарплатой программиста, даже уже в Российских условиях.

[=GM=]

Ну согласитесь, сравниватьТМС320 с ПИКо-АВРами некорректно. И не только из-за ТМСовой крутизны. ПИКо-АВРы требуют вокруг себя меньше обвязки, меньше жрут, меньше занимают места. Стоят дешевле. Из этого и исходить. Лёгкое ядро, оно всегда себе дырочку найдёт. ;О)

Так я и не сравнивал! Я отвечал г.Прохожему

Хотелось бы узнать мнение уважаемого коллектива. Если не PIC18 и не AVR, то что?

[Прохожий]

Лукавите

Нисколько.

Одного поля ягода с так называемым WinAVR, который, как я понимаю, 'устраивает'.

Ну Вам виднее. Я лично не пользовался ни тем, ни другим.

-Для любительско/халявных вариантов Wiggler дорогостоящ ?
-клоны профессиональных стоят одинаково - в пределах десятков долларов.
-оригинальные - несколько сотен для любого из контроллеров.

Дело в том, что я как бы любитель, поэтому в данном случае речь идет о моих личных материальных средствах. С PIC все ясно. Купил ICD2 за 6000 руб и, в принципе, можешь заниматься любым контроллером от 18-го до 24-го. Можно даже позволить себе и REAL ICE за 16 000 руб.
Это, практически, все затраты, поскольку все остальное официально халявное.

Привычка на данном историческом этапе 'дурная' - ARM контроллер при сопоставимых ценах с AVR девайс другой весовой категории. С ASM начинать не надо. Бегло просматривать результат компиляции, изредка писать пару десятков команд безусловно надо, но плотно изучать и начинать писать вполне достаточно в процессе работы и постфактум.

Боязно как-то отдавать все на откуп дядям, написавшим компилятор и компоновщик. Хотя может быть я и не прав.

[singlskv]

Всётаки задачка высосана из пальца, потому что правильнее всё таки минимум два массива (B и С) формировать одновременно во время приёма B. И лишних пересылок, при этом не будет.

Неа, не прокатит, если в массиве есть многобайтовые значения, то сначала прием всего
пакета, а только потом операции над данными.
Для многобайтовых значений, в А[] часть байтов многобайтового значения может
поменяться между приемами в B[], соответственно в С[] получим полный бардак.
Но вобще то это совсем другая тема,
я просто предложил чуть усложнить задачку

P.S. Вот интересно, Вы предпочитаете AVR и я то же.
Это что, начало спора IAR vs WinAVR ?

[defunct]

1. Дорогая среда разработки (EWARM от IAR).

Есть также Keil, RealView, CrossWorks..
Keil и CrossWorks дружат с gcc тулчейном.

2. Отсутствие хорошего бесплатного компилятора С (сам не пробовал, но отзывы о GCC не очень лестные).

Для PIC'ов насколько я осведомлен тоже не густо в этом плане.
Общепризнанный лучший компилятор от HT и он небесплатный..

3. Дорогостоящее оборудование для отладки.

Wiggler $10-$15
J-Link клон - сопоставим по цене с ICD2

4. Излишне сложная система команд (привычка начинать знакомство с Ассемблера).

~40 мнемоник.
даже меньше чем у новых PIC.

Прошу учесть, что это мое личное мнение, не претендующее на абсолютную истинность.

нет проблем, просто может быть вас просто дезинформировали.
Загляните в АРМы

[=GM=]

Не сообразил ответить сразу, отвечу здесь.

По поводу пересылок: пересылка массива памяти, сама по себе, никому не нужна. Нахрен пересылать массив из одного места в другое, если работать можно сразу в том месте? Ну да ланна, это на любителя. ;О)

Сергей, я тащусь от вашей рассудительности(:-). Объясните тогда, за каким шутом разместили этот тест в бенчмарках на сахаре? Похоже там одни любители собрались и вы в том числе, э?(:-).

GM, давайте чуть чуть усложним задачку. Пусть есть два 64 байтных массива A[64] и B[64], а в массив С[64] будем писать типа С[i] = A[i] (&, | или ^) B[i]; И оценим скорость на пике и авр как в машинных циклах, так и реальное время
выполнение на максимальной частоте кристала. Кстати задачка не высосана из пальца а вполне реально необходимая при обслуживании Modbus.
P.S. Кстати, эта задачка также хороша для религиозной войны IAR vs WinAVR

За пик г.Прохожий уже ответил, 6 МЦ. У авра, увы, будет 10 МЦ. Так что разрыв увеличивается(:-(.

Так глядишь, с вашей лёгкой руки я стану экспертом по пикам, а я в них не особо петрю, плаваю короче(:-)...

[zltigo]

Всётаки задачка высосана из пальца, потому что правильнее всётаки минимум два массива (B и С) формировать одновременно во время приёма B. И лишних пересылок, при этом не будет.

В тестовой программе пересылки быть должны. Естественно, массовые пересылки массивов это зачастую неудачое решение задачи, но и сводить решаемые контроллерами задачи к обработке чисто синхронных потоков явно неправильно - это вообще отмирающаяя область применения контроллеров
общего назначения, ибо с этим много легче справляются дешевеющие FPGA или на худой конец не отстающие от них по динамике цен DSP. То, что для меня является привычно/обычной задачей для небольшого перефирийного контроллера - можете, хотя-бы мельком, глянуть, что из себя представляют телекоммуникационные протоколы. Ну для конкретности пусть будут протоколы 2 уровня семиуровневой модели OSI - LAPD/LAPV5/MTP2/...) Без буферизации и пересылок там никуда. Как впрочем и без 'осей' с их задачами и очередями сообщений и таймерам все это писать чистое извращенное и ненадежное решение.

[singlskv]

Скажите (действительно интересно), а где при обслуживании MODBUS требуются такие действия?

Вобще-то по стандарту, над любыми данными должны быть реализованы четыре
варианта действий: REP, OR, AND и XOR.
Конечно мало кто это реализует в своих контроллерах, но по стандарту нужно, особенно
если присутствуют железки или софт сторонних производителей.

Что же касается теста, то для PIC будет приблизительно следующее:

Код

Loop     movf   postinc0,w,0; 1
         andwf  postinc1,w,0; 1
         movwf postinc2,0 ; 1
         decf    counter,f,0 ; 1
         bnz    Loop          ; 2

Получилось 6 МЦ или 600 нс при частоте кварца 10 МГц и включенном PLL.

Не знал что там есть 3 "виртуальных" счетчика.
Тогда да, разницы почти нет, по машинным циклам выигрывает пик, по реальной
скорости авр.
А какой пик ? Интересно глянуть.

[zltigo]

Дело в том, что я как бы любитель, поэтому в данном случае речь идет о моих личных материальных средствах. С PIC все ясно. Купил ICD2 за 6000 руб и, в принципе, можешь заниматься любым контроллером от 18-го до 24-го. Можно даже позволить себе и REAL ICE за 16 000 руб.

Для конкретности - затраты, например J-Link за примерно те-же 250USD или вообще его клон, баксов за 70 и можно заниматься любыми ARMx любых производителей.
Можно, конечно, покруче и подороже - J-Trace. Только зачем? Ядро отлаживать? Я вообще совсем не представляю, каким местом отладчика я буду отлаживать, например, поминаемый ранее LAPD. Я вообще не представляю для чего внутрисхемный отладчик для подавляющего большинства случаев отладки хоть сколь-нибудь сложных задач.

[=GM=]

Тогда да, разницы почти нет, по машинным циклам выигрывает пик, по реальной скорости авр. А какой пик ? Интересно глянуть

Например, pic18f2220.

Там ещё есть "страшная" команда movff var1,var2. Напрямую пересылает значение из переменной var1 в переменную var2, требует ДВА машинных цикла. У авр аналогом будет пара команд lds/sts, ЧЕТЫРЕ машинных цикла плюс использование РОН.

[singlskv]

Так глядишь, с вашей лёгкой руки я стану экспертом по пикам, а я в них не особо петрю, плаваю короче(:-)...

Дык и я плаваю, мое знакомство с пиками ограничилось знакомством, в
свое время, с каким-то(уже не помню каким) представителем 16 семейства, ну
и вот тут недавно пришлось на PIC10 малюсенькую задачку набросать.

А вот это из даташита на PIC:
All single-word instructions are executed in a single instruction cycle.
........
One instruction cycle consists of four oscillator periods.

в свое время меня отвратило от подробного изучения пик(и был выбран авр).
Чуйствую, в чем-то дурят

Там ещё есть "страшная" команда movff var1,var2. Напрямую пересылает значение из переменной var1 в переменную var2, требует ДВА машинных цикла. У авр аналогом будет пара команд lds/sts, ЧЕТЫРЕ машинных цикла плюс использование РОН.

Дык все равно паритет по реальной скорости выполнения...
А использование РОН, ну ведь принципиально разные модели процов...

[Прохожий]

Есть также Keil, RealView, CrossWorks..
Keil и CrossWorks дружат с gcc тулчейном.

Я тоже нашел RIDE по ссылке от ST. Даже приделал туда GCC. Попробовал тестовую программку. Вроде на вскидку все хорошо. Но, все равно, как-то боязно.

Для PIC'ов насколько я осведомлен тоже не густо в этом плане.
Общепризнанный лучший компилятор от HT и он небесплатный..

Зато MCC18 бесплатный. Меня лично он полностью устраивает. Код проверялся по ассемблерному листингу. Ничего особо криминального обнаружено не было. А все глюки выгребаются правильным размещением данных. По большому счету, оптимизация кода там и нафиг не нужна.

Wiggler $10-$15
J-Link клон - сопоставим по цене с ICD2

А корпуса? У большинства ноги через 0.65 мм. Если руки кривые, то прототип изготовить практически невозможно.

~40 мнемоник.
даже меньше чем у новых PIC.

Дык, у i 486 тоже как бы 40 мнемоник, зато вариантов... ARM из той же оперы, поскольку создавался как альтернатива.

нет проблем, просто может быть вас просто дезинформировали.
Загляните в АРМы

Может быть Вы и правы. Надо будет поплотнее заняться ARMами. Но лично мне кажется, что и в 24 PICах что-то есть позитивное.

Для конкретности - затраты, например J-Link за примерно те-же 250USD или вообще его клон, баксов за 70 и можно заниматься любыми ARMx любых производителей.

Спасибо за информацию. Вполне вероятно, что придется разориться на обозначенную сумму. Хотя ICD2 у меня уже есть.

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

А посмотреть, чего там в реальности напринималось в буфер? Или что творится с АЦП?

[Qwertty]

Тема оказывается актуальная, судя по быстрому росту.
Все же тестирование нужно провести. Полученные результаты будут гораздо объективнее, чем заявления "порвет как тузик". Задача должна быть простая, но все же не в три команды.
Предлагаю такую - вычисляем сумму байт и среднее арифметическое 300 байтного массива. размерность в 300 байт заставит применить честное деление, а не ограничиться сдвигами. Ну и результат суммирования будет иметь возможность превысить 16бит. Т.е. будут и работа с памятью и арифметика.
Итак, в одном углу ринга разминается Мега8. Найдется ли у нее соперник...
Взвешивание (цена ) будет проведено после боя

Сообщение отредактировал Qwertty - Aug 10 2007, 00:02

[_artem_]

Без буферизации и пересылок там никуда.

А для чего организовывать пересылки массивов в мтп2?

[oran-be]

Я заметил одну вещь. Никакое МК ядро не имеет столь фанатично преданных поклонников, как ядро АВР. Причем, повторюсь, в основном это те, кто сразу с него начал, либо те, кто еще не успел присесть на другие ядра. Остальные же, кто реально работает с несколькими типами МК, обычно не испытывают особого восторга от АВР. Что-то хорошо, что-то плохо. То же самое они обычно и говорят про другие типы МК, даже про те, с которых начинали. В чем же причина фанатизма?
Есть идея. Всем приверженцам АВРов собраться и пойти в ветку PICов, или 51-х, или сразу в обе и устроить там, открыв парочку горячих тем. А то там что-то скучновато.

Сообщение отредактировал oran-be - Aug 10 2007, 05:20

[mse]

...размерность в 300 байт заставит применить честное деление, а не ограничиться сдвигами...

А если честное умножнеме? :О)

[gormih]

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

Тема на самом деле ниочем. То, что авры ставят куда не лень - известно давно.
Что касается достоинств и недостатков - можно спорить бесконечно, но на самом деле все упирается в то, какая перед вами стоит задача. Я вот например программировал 5 ядер мк - Pic, z80, 8051, avr и arm у всех есть свои области применения, свои плюсы и минусы... но без привязки к конкретной задаче все споры будут спорами ни о чем. Если вы хотите получить самый дешевый микроконтроллер например - то берите вообще holtek - от 37 центов... вот только с его программированием возникнут сложности у неопытного программиста. Если хотите сократить сроки разработки - берите avr - в сети масса готовых решений, взяв из которых куски кода и добавив немного своего можно решить любую задачу (если конечно она вообще реализуема на данном ядре)

[pokos]

Ну, не хочу развивать религиозного фанатизьма, однако, в моём списке PIC отсутсвует.
Присутствуют COP, 48, 51, AVR. Когда-то передо мной стоял выбор между PIC и AVR, решён был в сторону AVR, поскольку в то время за сравнимые деньги можно было купить AVR с FLASH, а PIC только OTP, такой же кристалл PIC с FLASH был на порядок дороже. А поскольку к тому времени я уже изрядно наелся внутрисхемных эмуляторов и эмуляторов ПЗУ, PIC как-то сам собой отвалился.
С тех пор я просто не вижу надобности вводить себе в мозг ещё одну архитектуру.

Что касается пресловутого теста с FIR. Непонятно, почему там PIC24 DSPIC и AVR. Почему нету ARM? Ведь его тоже Atmel делает.

[IEC]

Тема действительно ни о чем! Для каждой задачи можно выбрать свой МК. Не важно какай марки и фирмы изготовителя, главное чтобы он оптимально справлялся с поставленной задачей и программист знал как это реализовать.
А кто с чем работает наверное в большей степени зависит от того, что выбрано в начале. Переход на другой тип МК обусловлен старением архитектуры.
Я, например, начинал с 51 и перешел на AVR из-за цены и объема предоставляемой памяти и переферии. И сейчас перешел на ARM. На PIC переходить не вижу смысла, т.к. для решения текущих задач этой базы вполне достаточно.