Вот задался я этим вопросои, господа...
И не нашел ответа.
В самом деле, название всем известной серии микроконтроллеров--это аббревиатура или просто так.

А не все ли равно? АЦТОЙ ведь полный!

Интересно... Винды тоже АЦТОЙ...и тоже очень :) популярны.
А может, PIC--инициалы создателя чипов ?
А может--Программируемые Интеллектуальные Чипы ?

А может что то типа перефирийный интегральный контроллер?

А может что то типа перефирийный интегральный контроллер?

Вот именно так и правильно. Но, конечно, более говенные микроконтроллеры придумать сложно. Правда для тупых кодовых замков и автосигнализаций подходят. А в других областях - как и было сказано выше - АЦТОЙ !

Угу..... Товарищи, если вас занесло в микроконтроллерные дебри, не беритесь за ПИКи. Оно АЦТОЙ!

Есть замечательные UBICOM (ip2022 не считаеться =) тоже суксь), которые до 100мипс. AVR вообще супер - асм с оптимизацией под С компиляторы. Z86 перпективные...

НО НЕ ПИКИ!!!!

Еще раз повторюсь. Я жалею что потерял те два года, которые я работал с ПИКами. Слава богу, что мелкочипы облажались и закрыли розничную продажу у себя в офисе, что собственно и заставило меня искать новый "народный МК" (tiny2313 =) )

Конечно PIC не верх совершенства.
Но утверждать что он не на что неспособен
не правильно.У меня в одном устройстве
он (877)осуществляет сложную цифровую
оброботку сигнала,и ещё успевает одновременно
кучу других задач.На MSP это можно сделать
более эфектно.Но его не так просто освоить.

Какой проц лучше - спор давний и давно же получен ответ: в случаях когда не требуется использовать особые особенности железа (как, например микропотребление у ТI, или какую либо специфическую встроенную периферию), то лучший проц тот на котором умеешь работать. Но все равно АВР рулит! :-)

Dimik
Есть замечательные UBICOM (ip2022 не считаеться =) тоже суксь), которые до 100мипс.
ВАУ!!! И сколько это чудо стоит?

AVR вообще супер - асм с оптимизацией под С компиляторы.
IMHO писать на HLL под микроконтроллер - изврат. В AVRовском асме лично мне не хватает таких команд 80x86 как "xor reg,val", "add reg,val". Ладно хоть, "andi reg,val" и т.п. сделали.
Но главное - MIPS!

Слава богу, что мелкочипы облажались и закрыли розничную продажу у себя в офисе
В Штатах или здесь?
что собственно и заставило меня искать новый "народный МК" (tiny2313 =) )
А где Вы их покупаете? Пытался летом найти - нет нигде. Взял АTMega. Ещё в Tiny нет ADC.

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

AVR вообще супер - асм с оптимизацией под С

С чего вы взяли, что Атмеловский АСМ "оптимизирован под С" ?? Это вам производитель сказал, что его АСМ оптимизирован под С ??
Ткните пальцем в "оптимизацию под С" !! - RISC-архитектура (если речь идет об ATmega и AT90S), соответствующая система команд, минимальная и обладающая функциональной полнотой, не более того.
Но, надо отдать должное, Атмеловские контроллеры, безусловно, хороши.

IMHO писать на HLL под микроконтроллер - изврат.

Ничего не изврат. Когда нет проблемм с объемом памяти программ и не требуется "сверхбыстродействие" то писательство на HLL - вполне нормальный процесс.

Эх, Лоренц, Лоренц....


Уж сколько раз... ;) ;)

Не знаю уж кто, когда и кому, но (при) мне производитель сказал, что архитектура АВРа, влючая систему команд, оптимизирована под разработку на Ц.

Это было на семинаре Атмела в Москве, в Бауманском институте, если ничего не путаю, в 2000 году.

Вообще, чтобы понять, в какой степени оптимизирован под Ц тот или иной проц, надо написать какую-нибудь тестовую программку, откомпилировать и посмотреть, что получится.

По-моему, на АВРе циклы типа while() получаются несколько короче, чем на 51.

Вообще, чтобы понять, в какой степени оптимизирован под Ц тот или иной проц, надо написать какую-нибудь тестовую программку, откомпилировать и посмотреть, что получится.

Компиляторы тоже разные бывают, и компилят они тоже по-разному...

По моему мнению
PIC = Programmable Interface Controller

По крайней мере, такая расшифровка встречается в интернете.

Если мне не изменяет память, то под RISC писать компиляторы проще. ;) Хотя наверное не будет хватать того богатства способов адресации, которое есть у х86.

Если мне не изменяет память, то под RISC писать компиляторы проще. ;)

Честно говоря, никогда не писал компиляторы, но, если это утверждение верно, то тогда любая RISC-платформа обладает свойствами AVR-а, в плане "оптимизированности под Ц".

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

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

Это для RISC, в целом. Так что, фраза "оптимизация под Ц" - это, скорее, реклама, нежели реальность.

Кстати, поскольку под АВР я никогда на асме не писал, то вопрос к тем, кто писал.

Есть ли проблема с дальностью перехода при условных джампах?

Помню, на 51 приходилось делать промежуточные точки с лонгджампами

Есть ли проблема с дальностью перехода при условных джампах?

Есть такая проблема, к сожалению...

По моему PIC = Programmable In Circuit = Внутрисхемно программируемый.
А еще в AtTiny есть АЦП - в tiny13 и tiny15 точно есть, а то кажется BlackCat спрашивал.

В последних PICах, (rfPIC...) в одной микросхеме
микроконтроллер, радиопередачик,АЦП. Возможно передача как в аналоге так и в цифре (+прыгающая частота в ближайшей переспективе).
Весьма любопытное изделие!!!

Ну да, а вы уверены что все это работает ?

Пока что по интегрированности микроконтроллеров широкого применения всякой переферией бесспорные лидеры Atmel и Cygnal.

По моему PIC = Programmable In Circuit = Внутрисхемно программируемый.
Это по-другому называют "In system programmable", сокращенно ISP.
Опять же по возможностям ISP все эти PIC'и рядом не стояли с AVR.



Кстати, поскольку под АВР я никогда на асме не писал, то вопрос к тем, кто писал.

Есть ли проблема с дальностью перехода при условных джампах?

Помню, на 51 приходилось делать промежуточные точки с лонгджампами

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

Неприятности с джампом у меня были только на 48 проце. На 51 при глюках с переходами, если память не жалко и лень возиться, можно было все SJMP заменить на LJMP - без ущерба программе. А условный ждамп там действительно только короткий.
Вопрос такой - есть ли реальная альтернатива AtMega128 (по числу ножек, и UARTов, чтоб был SPI, АЦП, можно I2C) но с большей внутренней программной памятью ?

Если нужно именно AVR ядро, то мне кажется 128К - это максимум. Кстати, ATMega128 имеет внешнюю шину адреса/данных. Это тоже можно как-то использовать. Если надо хранить одну большую исполняемую программу, то за объем больше чем 128 К вы не выйдите. Если надо иметь возможность выполнять какие-то фрагменты большой программы крайне редко, то их можно разместить где-нибудь в Datafash, типа AT45DBxxx, подключенной к SPI-порту и загружать при необходимости в EEPROM основной памяти программ, используя технологию bootloader'a. Но это все конечно геморрой еще тот и если ваша программа не на ассемблере написана, а на Си то проще перейти на один из микроконтроллеров семейства AT91 с ядром ARM. Вот там есть настоящие монстры по объему внутренней памяти программ.
AT91FR40162 - 2M флэша, правда нет АЦП встроенного
AT91M55800A - все есть, но память - цепляется к внешней шине. Может адресовать до 128M.
А более подробно здесь смотреть :
http://www.atmel.com/dyn/products/devices.asp?family_id=605

Арм штука хорошая, но ему нужна внешняя память. А у AT91M55800 геморройный PLL, как заливать прогу в чистую ПЗУ macraigor`ом не понятно.
пока используем 63200, но его снимают с производства.
У AtMega128 есть внешняя шина данных-адреса, но не для программы.
Интересное наблюдение для AtMega128 - если софт не использует внешнюю шину, а на ней что-нибуть "закорочено" это может привести к странному поведению программы, хотя в теории не должно. Может быть у AtMega128 есть недокументированные возможности работы с внешней программной памятью ?

Вы правильно заметили, что у ATMega128 внешняя шина данных и адреса не предназначена для подключения программной памяти. Я говорил о другом - о загрузке с устройства, подключенного к ней программы во внутреннюю программную память используя возможности реализации bootloader'a. Этот вариант работает если исполняемый программный код разбит на загружаемые модули, работающие независимо друг от друга и нужно сменять исполняемые модули программы в основной памяти крайне редко, в противном случае "заездите" Flash, да и процесс загрузки занимает прилично времени.
Метод такой "догрузки" стар как мир.

А у AT91M55800 геморройный PLL

Какие проблемы были с PLL ?
Вроде у большинства атмеловсеих ARMов эти схемы похожи.

Спасибо за совет с bootloader'ом, но это долго и ресурс флеши ограничен такой метод - негодится. А насчет AT91M55800 и PLL : Используется Greenhils для отладки через wiggler и macroigor flash programmer для заливки флеши тоже через JTAG.
При первом включении системы с чистой флешью средства отладки и заливки не стартуют - слишком медленно работает проц на часовом кварце, и не хочет тактироватся большей частотой :(` Для запуска приходится вначале записывать во флеш прогу, стартующую PLL, а флешь мелкая, планарная и запаянная или ставить большую-большую панельку под boot ПЗУ (27с212 в дипе, чтоб удобнее прошивать-втаскивать-вытаскивать). Может есть другой способ но я не разобрался, и сейчас используем AT91M63200, там нет PLL и нет проблем с отладкой.

Какие достоинства и недостатки
у микроконтроллеров