х51 Опции

[Egel]

На каких МК стоит начать учиться, с каким языком работать и в какой среде сейчас осуществляется программирование(я знаю, что для х51 семейства программировали под DOS на TASM например )???
Еще очень интересно есть ли какие-то симмуляторы МК(не аппаратные) и как вообще лучше начать обучение в этой области?
Заранее огромное спасибо

[MrYuran]

Вот это читал?

[Egel]

Вопрос впринципе исчерпан
Спасибо

[Egel]

Здравствуйте
Подскажите пожалуйста адрес хорошего сайта для х51 контроллеров.
Что-то типа http://pic16f84.narod.ru/ (для PIC) - только для х51
Хотелось бы больше практики по схемам, программированию и т.д.(теории и так хватает)
И, если есть симмулятор для них

[lks]

Здравствуйте
Подскажите пожалуйста адрес хорошего сайта для х51 контроллеров.
Что-то типа http://pic16f84.narod.ru/ (для PIC) - только для х51
Хотелось бы больше практики по схемам, программированию и т.д.(теории и так хватает)
И, если есть симмулятор для них

Silabs на сайте efo (если память не потерял).
Atmel делают их - есть сайты поддержки на русском.
8052.com
Книжка хорошая на ftp://ftp.svglabs.ru/ Однокристальные микро ЭВМ Справочник. (1994)
У Analog Devices есть серия на 8052. Есть выложенные даташиты на русском (в Питере фирма).

Компилятор Keil - который тут распространяют не советую - глючный. (Специально диверсанты рассылают.)
Хороший компилятор Franklin (демоверсия www.fsi.com - если не забыл)

[zltigo]

Здравствуйте

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

[lks]

Ваши советы нынче почем?

[Mik174]

Компилятор Keil - который тут распространяют не советую - глючный. (Специально диверсанты рассылают.)
Хороший компилятор Franklin (демоверсия www.fsi.com - если не забыл)

Во-первых, адрес указан неверно - правильный http://www.fsinc.com/devtools/index.htm
Во-вторых, он давно не развивается и естественно, очень многие чипы не поддерживает.

Насчет Keil - за 3 года не заметил в нем каких-то глюков.
Писал на нем программы для кристаллов: AT89C51ED2, ADuC845.
Всякий раз когда думал что в компиляторе нашелся какой-то глюк, при ближайшем рассмотрении оказывалась причина в "кривых ручках"

Есть особенность - надо внимательно читать варнинги, среди них есть такие, которые приведут к нерабочему коду. Например, если есть обращение к функции а ее описания нет, то часто это будет варнинг.
Несколько неудобно, с другой стороны если делать программу так, чтобы варнингов не было, проблем не будет. По крайней мере я не сталкивался.

[zltigo]

Ваши советы нынче почем?

Безвозмездно. По поводу Keil - так уж вышло, что на данный момент он лучший, хотя IAR тоже на достойном уровне.

[Egel]

На чем вообще лучше писать(из этих двоих я уже понял)? И чем они отличаются от Ассемблера?

[zltigo]

..я знаю, что для х51 семейства программировали под DOS на TASM например

Неужели на 3 курсе МИФИ специальности Микроэлектроники! еще довели , что 51 и 86 это не одно и то-же? И чем Ассемблеры от языков высокого уровня отличаюся?

[Egel]

Вы конечно опытнее меня, но вопрос был несколько в другом,так что острить не надо.
Про то что от чего отличается я и без института знаю, а вот с чем лучше начать работать это дело другое + если учесть тот факт, что никто особо ничего вразумительного не говорит.
Есть литература, но на ней сидя дома далеко не уедешь
Хочется взять и сделать реальное устройство и его запрограммировать - а без подсказок здесь не обойтись, не кажется ли????

[zltigo]

Про то что от чего отличается я и без института знаю...

Как совершенно неожиданно выяснилось - нет . Острить и не думал, просто искренне удивился и опечалился уровнем нынешнего российского образования. Честное слово ничего личного!!!

[Egel]

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

[SIA]

Как совершенно неожиданно выяснилось - нет . Острить и не думал, просто искренне удивился и опечалился уровнем нынешнего российского образования. Честное слово ничего личного!!!

Нда... Как просел родной институт....
Я еще ДО института 3 процессора в асме/кодах программировал, 6800, 8048 и 8080/8085. На С под Unix - еще СМ1420 застал.

[Egel]

Я за вас очень рад. Не тем надо было заниматься до института.

[SIA]

Вы конечно опытнее меня, но вопрос был несколько в другом,так что острить не надо.
Про то что от чего отличается я и без института знаю, а вот с чем лучше начать работать это дело другое + если учесть тот факт, что никто особо ничего вразумительного не говорит.
Есть литература, но на ней сидя дома далеко не уедешь
Хочется взять и сделать реальное устройство и его запрограммировать - а без подсказок здесь не обойтись, не кажется ли????

Легче всего начать с 51 от Atmel или Silabs, море документации, все "разжевано", и ассортимент микрух очень большой, некритичны к монтажу - работают на любой макетке. Потом освоить ARM/MSP - вот и готов "джентльменский набор".

Я за вас очень рад. Не тем надо было заниматься до института.

Не беспокойся, это было далеко не единственное занятие, даже в то время

[Egel]

Спасибо за совет

[SIA]

Спасибо за совет

Чтобы не делать "железо" самому, купи конструктор в Терраэлектронике.
51 хороши тем, что их проинициализировать/настроить периферию достаточно просто, и можно начать и на ассемблере, и на С.

[AHTOXA]

..я знаю, что для х51 семейства программировали под DOS на TASM например

Неужели на 3 курсе МИФИ специальности Микроэлектроники! еще довели , что 51 и 86 это не одно и то-же? И чем Ассемблеры от языков высокого уровня отличаюся?

Вообще-то был tasm (table driven assembler) под DOS, компилил в том числе и для 51х контроллеров.

[zltigo]

Вообще-то был tasm (table driven assembler) под DOS, компилил в том числе и для 51х контроллеров.

Вообще-то это называется TDASM - именно Table Driven ASseMbler . Под 51 досовский в советских условиях распространен был от фирмы 2500 AD. Archimedes встречался, но это уже Keil .
Ну а TASM это TurboAssembler от Борлад - исключительно x86.

[AHTOXA]

Вообще-то это называется TDASM - именно Table Driven ASseMbler . Под 51 досовский в советских условиях распространен был от фирмы 2500 AD. Archimedes встречался, но это уже Keil .
Ну а TASM это TurboAssembler от Борлад - исключительно x86.

Специально не поленился, ещё раз прочитал название файла - TASM.EXE
Вот readme:

Код

The Telemark Assembler Copyright Notification

The files on this disk are:
Copyright 1985-1993 by Speech Technology Incorporated, all rights reserved.
Copyright 1998      by Squak Valley Software         , all rights reserved.

Portions of TASM.EXE (C runtime library)  are Copyright 1993 by
Borland International.

The following files on this disk may be freely copied and shared with others:

TASM.EXE          - TASM Assembler, executable
TASM48.TAB        - 8048 Instruction definition table
TASM51.TAB        - 8051 Instruction definition table
TASM65.TAB        - 6502 Instruction definition table
TASM85.TAB        - 8085 Instruction definition table
TASM80.TAB        - Z80  Instruction definition table
TASM05.TAB        - 6805 Instruction definition table
TASM68.TAB        - 6800/6801/68HC11 Instruction definition table
TASM3210.TAB      - TMS32010 Instruction definition table
TASM3225.TAB      - TMS32025 Instruction definition table
TASM70.TAB        - TMS7000 Instruction definition table
TASMMAN.HTM       - TASM Documentation (HTML)
TASMTABS.HTM      - TASM Documentation on individual tables (HTML)
TEST*.ASM         - TASM test cases (one for each table)
TESTTABS.BAT      - Batch script to execute the test cases
8051.H            - Useful register definitions for the 8051
MOTO.H            - Useful directive definitions for Motorola compatibility
README.TXT        - Brief Explanation of Disk contents
COPYRIGH.TXT      - Copyright notice
ORDERFRM.TXT      - Registration Form
ORDERFRM.HTM      - Registration Form (HTML)
RELNOTES.TXT      - Release notes.
MISC.ZOO          - Miscellaneous examples, etc.
BOOZ.EXE          - Archive extracter (ZOO format).

Although you may freely copy the above files,  TASM is not 'free'  or
'public domain'.   It is copyrighted material which can be copied and
evaluated by people without registration,  but those that use it on a
regular basis must register (see the ORDERFRM.TXT or ORDERFRM.HTM files).

The  following  files  are  to  be copied  only  with  the  following
restrictions:  The owner of this software may  make as many copies of
the following as is deemed necessary as long as no possibility exists
for  the software (or derivitive products)  to be in use on more than
one machine  at a time. Or, if a site license has been purchased, the
software can only be used on machines at that site.  

TASM.C            - TASM source code
TASMMAIN.C        - TASM source code
MACRO.C           - TASM source code        
PARSE.C           - TASM source code
STR.C             - TASM source code
LOOKUP.C          - TASM source code
WRTOBJ.C          - TASM source code
FNAME.C           - TASM source code
WRTOBJ.C          - TASM source code
ERRLOG.C          - TASM source code
TASM.H            - Header file defining TASM constants
MAKEFILE          - Make file to build TASM


        Thomas N. Anderson
        Squak Valley Software
        837 Front Street South
        Issaquah, WA  98027

    email:  andersontn@acm.org

Видимо их (table-driven) было больше чем один

ЗЫ. Сомневаюсь, однако, что топикстартер имел в виду какой-либо из этих ассемблеров

[777777]

Легче всего начать с 51 от Atmel или Silabs, море документации, все "разжевано", и ассортимент микрух очень большой, некритичны к монтажу - работают на любой макетке. Потом освоить ARM/MSP - вот и готов "джентльменский набор".

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

Безвозмездно. По поводу Keil - так уж вышло, что на данный момент он лучший, хотя IAR тоже на достойном уровне.

Keil генерирует неплохой код, хотя следить за ним, конечно, надо. Например, выражение *++p транслируется достаточно эффективно, а на *p++ генерит какой-то бред. Но стоит написать *p; ++p и код сокращается на несколько байт.

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

[rv3dll(lex)]

ассемблер рулит

кейл генерирует сильно кривой код - так как не знает что от него хотят

[777777]

кейл генерирует сильно кривой код

Вы просто не умеете его готовить

так как не знает что от него хотят

Значит надо объяснить

[rv3dll(lex)]

Вы просто не умеете его готовить

Значит надо объяснить

ага очень удобно объяснить что при делении многобайтных чисел всё зависит от разрядности результата.---- проходили уже!!!!!

и примерные операции - не законченные это вообще песня

[777777]

ага очень удобно объяснить что при делении многобайтных чисел всё зависит от разрядности результата.---- проходили уже!!!!!

и примерные операции - не законченные это вообще песня

Ээ-э... А подробнее можно? А что такое "примерные операции"?

[rv3dll(lex)]

Ээ-э... А подробнее можно? А что такое "примерные операции"?

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

[ukpyr]

еще есть басплатный SDCC :
http://sdcc.sourceforge.net/

[zltigo]

по прерыванию например все данные уничтожаются - остаётся только результат

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

[rv3dll(lex)]

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

если не понимаешь не комментируй
для тебя умножение это

a <= b * c;

и это вне зависимости от того сколько разрядность чисел
если 2х байтные числа на 51 контроллере их за одну команду ассемблера не перемножишь
и займёт это десятки строк

бывают ситуации, когда неточный расчёт лучше, чем потеря данных

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

вот простой пример
чего бы не написал на си но при делении 32 разрядного числа на 32 разрядное на тексасе с помощью команды subd эта команда запустится 32 раза.

но елли результат не превышает 16 бит её жостаточно запустить 16 раз - ответ будет тот же самый.
проигрышь по производительности 2 раза

как компиллятору объяснить это?

[Egel]

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

[zltigo]

..если не понимаешь не комментируй

За десятилетия, так или иначе связанные с программированием на многих-многих ассеблерах, Fortran, Modula, С, .... Я понимаю очень многое

как компиллятору объяснить это?

Использовать явные преобразования типов, предварительное деление сдвигом для гробления точности, перед делением. Наконец, если критично, то и ASM функцию написать совсем не грех. Только вот кричать по незнанию/не владению инструментом о его непригодности явно глупо.

[rv3dll(lex)]

Использовать явные преобразования типов, предварительное деление сдвигом для гробления точности, перед делением. Наконец, если критично, то и ASM функцию написать совсем не грех. Только вот кричать по незнанию/не владению инструментом о его непригодности явно глупо.

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

то есть Вы УЖЕ согласились что в ответственных местах всёже компиллятор не обеспечивает экономичности ресурсов????

[SIA]

еще есть басплатный SDCC :
http://sdcc.sourceforge.net/

Кстати, как показывает практика, вполне неплохой, т.е. не идеален, но работать вполне можно. И легально.

....компиллятор не обеспечивает экономичности ресурсов????

В 99% применений эта самая "экономичность ресурсов" не имеет никакого экономического смысла. Как правило, если реально (а не по причине бездарности алгоритма) не хватает быстродействия/памяти, дешевле поставить более мощный процессор, чем тратить время на асме.
32-битный 70 МГц ARM с кучей периферии стоит всего несколько долларов.

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

Если речь о Xmega, и критерий - "красота архитектуры" - то возможно. Но экономического смысла в их применении сегодня нет - их цена выше, чем у более мощных и экономичных 32 и 16-разрядных. Только для любителей ностальгии по AVR.
Ни ассортимент, ни качество АЦП/ЦАП в AVR (и большинстве других микроконтроллеров от Atmel) не выдерживают никакой конкуренции с Cygnal, преимуществ по скорости/экономичности - тоже никаких. Тогда нафиг ?

[MrYuran]

то есть Вы УЖЕ согласились что в ответственных местах всёже компиллятор не обеспечивает экономичности ресурсов????

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

[zltigo]

то есть Вы УЖЕ согласились что в ответственных местах всёже компиллятор не обеспечивает экономичности ресурсов????

При умелом использовании от современных компиляторов получаем хорошо оптимизированный код.
Естествено, соревнование в ручной оптимизации, тем более на более чем старенькой 51 платформе, на уровне десятка-другого команд выграть у компилятора достаточно легко, хотя о сколь-нибудь впечатляющем выигрыше можно обычно говорить только на специально подобранных тестах
Глобально, при сколь-нибудь разумных затратах времении говорить об эффективности программирования на ASM уже не приходится. За последние годы, если не считать сопровождения одного безмерно древнего проекта на ASM размером под 200K кода, "ответсвенных мест" в которых я прибегал к использованию нескольких десятков строчек на ASM, пожалуй наберется штук 5-6.

Более того, где-то прошлой осенью пришлось столкнуться со старым изделием на 51. Разработчик тянул его много лет, вроде все работало, выпускалось, но как водится после его ухода полезли очередные проблемы Разбираться в 40K ASM кода совсем не хотелось, посему была просто портирована простенькая операционочка со 186 контроллера, поддержка однотипного железа, типовые протоколы и... уложившись в 30K получилося рабочий девайс не захлебываюшийся под нагрузкой, да и еще спокойно гонящий при этом в RS232 отладочную информацию. Честно говоря, предварительно морально был готов пару отработчиков прерываний на ASM писать, но не пришлось. Все стало работоспособным за счет более сложного построения системы а не тупого ускорения "ответственных мест".
По весне знакомый просил помочь с Тинькой - псевдонаучная поделка генерящая "волшебные" импульсы, впрочем к делу это отношения не имеет. Писали в ней софт вполне опытные ASM писатели, только вот результат получился странноватый - по верхней частоте/длительности чего-то не лотягивала до желаемого заказчиком, да и на анализаторе спектра что-то выглядило подозрительно очень - чего-то в алгоритме ошиблись явно. Переписывали сие уже много раз, писатели и заказчик находились в конфронтации.... Пришлось за несколько вечеров переписать на C. Тоже думал просто попробую (например на меге), а потом вылизывать придется - уж больно 2K флеша не впечатлили (отвык от малых форм ), да и по скорости достаточно сурово все по началу смотрелось. И ничего - 1.6K кода вместо 1.8K у ассемблерописателей при большем функционале и красотулечках (приблуда для продаже через TV Shop - важно) и двойной запас по девиации частоты вверх . И вообще ни одной сторочки (ну кроме штатного cstatrup) на ASM.

[SIA]

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

[zltigo]

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

А алгоритмы, естественно, хорошо и эффективно пишутся, и при этом глобально (с глобальностью в ASM напряг ) оптимизируются на алгоритмических языках.

[rv3dll(lex)]

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

как подстилка

Все стало работоспособным за счет более сложного построения системы а не тупого ускорения "ответственных мест".

уже гдето писал
проц2406 от тексаса
обработка нескольких каналов
на каждый канал в реальном времени чуть больше 100 машинных цыклов.
так вот в комментариях эти машинные цыклы были написаны 1 2 3 5

до кучи формирование нескольких последовательностей импульсов на портах которые в явном виде прям отсчитывая по циклам выводились в порт

[blackfin]

уже где-то писал

Ага.. Вся ветка - de ja vue..

[zltigo]

Ага.. Вся ветка - de ja vue..

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

[777777]

Если речь о Xmega, и критерий - "красота архитектуры" - то возможно. Но экономического смысла в их применении сегодня нет - их цена выше, чем у более мощных и экономичных 32 и 16-разрядных.

Несколько странно сравнивать AVR с ARM.
Цена ATtiny13 или 2313 существенно ниже чем 32-разрядных контроллеров, не говоря уж о размере микросхемы.

Ни ассортимент, ни качество АЦП/ЦАП в AVR (и большинстве других микроконтроллеров от Atmel) не выдерживают никакой конкуренции с Cygnal, преимуществ по скорости/экономичности - тоже никаких. Тогда нафиг ?

А вы во все проекты ставите 16-разрядные АЦП с 1-МГц быстродействием?
Ни ассортимент, ни качество Дэу не идет ни в какое сравнение с Мерседесами, не говоря уж Роллс-Ройсах, однако их почему-то выпускают. (Про Лады, так и быть, не стану говорить чтобы не вызывать ненужных споров, хотя их объемы выпуска тоже не падают)

[rv3dll(lex)]

(Про Лады, так и быть, не стану говорить чтобы не вызывать ненужных споров, хотя их объемы выпуска тоже не падают)

жигули при повседневной эксплуатации в течении первых 3-5 лет самая практичная и дешёвая машина.

насчёт производительности
на задачах обработки сигналов дохлый сигнальник натянет любой арм

[SIA]

Несколько странно сравнивать AVR с ARM.
Цена ATtiny13 или 2313 существенно ниже чем 32-разрядных контроллеров, не говоря уж о размере микросхемы

Если нужен простенький предельно дешевый, но надежный контроллер - это тогда к Microchip или Freescale (а-ля 68705). Мелкие AVR в этом отношении ничем не выделяются - ни ценой, ни функциями.

[lks]

Во-первых, адрес указан неверно

Да, конечно - Franklin Software Inc.
Но я сразу указал, что писал по памяти - поэтому странно, что это уточнение вы адресуете ко мне.

Во-вторых, он давно не развивается и естественно, очень многие чипы не поддерживает.

Это вы просто плохо разбираетесь в программировании. У меня ДОСовские компиляторы замечательно работают для самых современных чипов. Что касается Franklin'а - у него есть все что положено иметь современному компилятору.

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

Не надо по себе судить других.

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

И чем же AVR лучше будет?
Может по быстродействию больше бывают?
Или память может иметь такую же как у 8052?
Совместимость программного кода может тогда лучше чем у 8052?
Чем же тогда лучше?

[Herz]

Я вам так скажу. Компилятор - сложный программный продукт, намного сложнее, чем большинству из здесь присутствующих приходилось создавать. И вполне естественно, что возможные баги в нём вылавливаются не сразу. Однако что характерно: опытный программист гораздо реже пеняет на компилятор, хоть и знает его значительно лучше. О чём это говорит? Это к вопросу о "глюках" компиляторов. А уж религиозные войны под девизами типа ASM рулит - С must die! и наоборот - и вовсе, ИМХО, детский лепет, как и споры о том, какой контроллер лучше. Ибо взрослому человеку понятен смысл слова целесообразность.

[777777]

И чем же AVR лучше будет?
Может по быстродействию больше бывают?
Или память может иметь такую же как у 8052?
Совместимость программного кода может тогда лучше чем у 8052?
Чем же тогда лучше?

Архитектурой.
По быстродействию - да, 16 МГц при выполнении команды за 1 такт это несомненно лучше, чем 20 МГц за 12 тактов, а нынешние 1-тактовые 8052 не работают на таких частотах.
Память у него не такая же, а лучше чем у 8052 - к любой ячейке можно обратиться непосредственно, а у 8052 - только к первым 127 байтам, к 256 - только косвенно, а уж об обращении к XRAM я вообще молчу.
Совместимость программного кода с чем? Если "совмещать" на уровне С-программ, то AVR-овский компилятор намного эффективнее, чем 8052 именно благодая своей архитектуре. Архитеркура же 8052 совершенно не приспособлена для компиляторов, собственно, в то время вряд ли кто предполагал, что для него можно написать компилятор языка высокого уровня.

Если нужен простенький предельно дешевый, но надежный контроллер - это тогда к Microchip или Freescale (а-ля 68705). Мелкие AVR в этом отношении ничем не выделяются - ни ценой, ни функциями.

Может я действительно чего-то не понимаю, но как раз PIC-и это совершенно отстойные контроллеры, по всем параметрам хуже любого имеющегося. Ну объясните, чем урезанная система команд лучше полноценной? Чем 20 МГц при выполнении на 4 такта лучше, чем 16 МГц - за один такт? Назовите хотя бы один параметр, по которому PIC лучше хотя бы какого-нибудь другого контроллера?

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

[rv3dll(lex)]

Архитектурой.
По быстродействию - да, 16 МГц при выполнении команды за 1 такт это несомненно лучше, чем 20 МГц за 12 тактов, а нынешние 1-тактовые 8052 не работают на таких частотах.

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

Назовите хотя бы один параметр, по которому PIC лучше [i]хотя бы какого-нибудь другого

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

насчёт того, что 51 архитектура не для компилляторов это точно.
этот контроллер (ядро) разработан в 76 по моему году и как и х86 - 640 килобайт хватит всем стало со временем мало

года 4 назад сравнивал пики с аврками так вот за цену в 3-5 раз меньше 12 пики превосходили по набору функионала авр 90 серии
про доки на русском и официальную поддержку в москве это очень большой плюс.

насчёт урезанной системы команд не такая она и урезанная.

насчёт выполнения за 12 тактов ну есть за 6 за 4 это без конвейера

1 такт полноценный возможен только с конвейером - зато при большом количестве переходов это не работает - и получаем теже 4 цикла

[Herz]

Может я действительно чего-то не понимаю, но как раз PIC-и это совершенно отстойные контроллеры, по всем параметрам хуже любого имеющегося. Ну объясните, чем урезанная система команд лучше полноценной? Чем 20 МГц при выполнении на 4 такта лучше, чем 16 МГц - за один такт? Назовите хотя бы один параметр, по которому PIC лучше хотя бы какого-нибудь другого контроллера?

Наверное, чего-то и не понимаете... И я чего-то не понимаю. У каждой архитектуры есть свои плюсы, свои минусы. А что такое урезанная система команд? Все RISC контроллеры имеют "урезанную" систему команд. Кстати, 18-е ПИКи имеют набор из 75 и более инструкций - это мало? Насчёт "самых отстойных" зайдите на этот форум и скажите там об этом. Для себя отметил высокую надёжность ПИКов и замечательную документацию.

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

Не преувеличивайте. Да и популярны они не только в России.

[rv3dll(lex)]

пики в частности стоят почти во всех сигнализациях

[MrYuran]

И вообще: сводить выбор 8-битного контроллера, даже х51, к дилеме "PIC vs AVR" это тоже самое, что ограничить выбор религии между православием и католичеством а кому-то может мусульманство больше подходит, там много жён иметь можно... Причём одновременно!

[SIA]

По быстродействию - да, 16 МГц при выполнении команды за 1 такт это несомненно лучше, чем 20 МГц за 12 тактов, а нынешние 1-тактовые 8052 не работают на таких частотах.

Это не так. Сейчас полно однотактных 8051, у самой Atmel есть 20 МГц, у Silabs - до 100МГц.
Кстати, разница в качестве архитектуры AVR и х51 далеко не столь велика, как это кажется на первый взгляд - число команд для реализации большинства алгоритмов на x51 отличается от AVR всего в 1.3-1.6 раза безо всякой оптимизации. На однотактных х51 это элементарно перекрывается повышением тактовой (16 МГц AVR - это как раз 20...25 МГц "однотактного" х51). При этом х51, как более простой, при равных топонормах, потребляет меньше микроампер на мегагерц, чем AVR. Выбор же вариантов контроллеров х51 гораздо больше, их не делает только ленивый. И готовых библиотек/функций к ним накоплено больше всего. Все это - чисто практические соображения, безо всяких "теорий о всеобщем счастье и неуклонном прогрессе". Т.е. работая с х51, можно решать более широкий круг задач, чем ограничиваясь AVR. Быстрые х51 на контроллерных задачах не сильно отстают от ARM. По деньгам решения на х51 тоже, как правило, выходят дешевле AVR и по железу, и - что более важно в мелких сериях - по софту.

[Duplex]

А уж религиозные войны под девизами типа ASM рулит - С must die! и наоборот - и вовсе, ИМХО, детский лепет, как и споры о том, какой контроллер лучше. Ибо взрослому человеку понятен смысл слова целесообразность.

Может быть обсуждалась некорректная работа крякнутой демоверсии компилятора Keila?
Это явно не одно и то же, что лицензионный компилятор?
К фирменной версии компилятора Keil претензий не прозвучало. ИМХО.

Архитектурой.
По быстродействию - да, 16 МГц при выполнении команды за 1 такт это несомненно лучше, чем 20 МГц за 12 тактов, а нынешние 1-тактовые 8052 не работают на таких частотах.
Память у него не такая же, а лучше чем у 8052 - к любой ячейке можно обратиться непосредственно, а у 8052 - только к первым 127 байтам, к 256 - только косвенно, а уж об обращении к XRAM я вообще молчу.
Совместимость программного кода с чем? Если "совмещать" на уровне С-программ, то AVR-овский компилятор намного эффективнее, чем 8052 именно благодая своей архитектуре. Архитеркура же 8052 совершенно не приспособлена для компиляторов, собственно, в то время вряд ли кто предполагал, что для него можно написать компилятор языка высокого уровня.
Может я действительно чего-то не понимаю, но как раз PIC-и это совершенно отстойные контроллеры, по всем параметрам хуже любого имеющегося. Ну объясните, чем урезанная система команд лучше полноценной? Чем 20 МГц при выполнении на 4 такта лучше, чем 16 МГц - за один такт? Назовите хотя бы один параметр, по которому PIC лучше хотя бы какого-нибудь другого контроллера?

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

Есть контроллер с ядром 8052, с USB портом и с тактовой частотой 400 МГц.
В 8052 вся память разбита по типам, может со стороны это кажется сложным - у меня проблем небыло с адресацией. На самом деле такая организация памяти дает очень много преимуществ.


PIC контроллеры обрели такую популярность только лишь благодаря тому, что их "проталкивают".
Первый из них PIC16F84 имел флэш память и простой программатор и практически бесплатный программатор. В одном небольшом корпусе все что нужно для работы, возможность многократно переписывать код и невысокая цена - это было привлекательным для начинающих.
Затем, многие перешли от PIC к AVR и далее к ARM - а кое кто, как работали на 8052 так и продолжают.
Возможности контроллеров 8052 растут, а совместимость сохраняется.

(16 МГц AVR - это как раз 20...25 МГц "однотактного" х51).

Однотактный 8051 (одноцикловый) - это когда команда регистр-регистр выполняется за один такт генератора синхронизации.
Если тактовая частота 20 МГц - то это означает, что за одну секунду выполнено будет 20 млн. комманд типа регистр-регистр.
AVR получается работатет быстрее, чем выполняется синхронизация?
Побойтесь бога, это невозможно...

[skripach]

Есть контроллер с ядром 8052, с USB портом и с тактовой частотой 400 МГц.

Что за он?

[Огурцов]

Первый из них PIC16F84 имел флэш память и простой программатор и практически бесплатный программатор. В одном небольшом корпусе все что нужно для работы, возможность многократно переписывать код и невысокая цена - это было привлекательным для начинающих.
Затем, многие перешли от PIC к AVR

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

[Egel]

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

[sergey sva]

Много схем собирал на контроллерах MSC51, проблем не возникало,
Их еще продолжаю выпускать и даже появляются новые как например AT89C51RE2*.
http://www.atmel.ru/Production/tables/c51.htm
тем более есть неплохие бесплатные компиляторы. Впрочем бесплатные компиляторы
сейчас для многих микроконтроллеров есть.
Кстати вот собрал девайс на днях смс простенькая сигналка с сотиком , на 51
смски отправляет еще наверно сделаю что бы дозванивалась и говорила, пока не знаю что поназамутить



видео с девайсом и звуком 5мгб
http://slil.ru/26027289

характеристики :
микроконтроллер at89c51ed2
звук астота диск 8кгц
флаш память 512мгб
частота кварца 40мгц можно поставить 60
дисплей 128х64

Сообщение отредактировал sergey sva - Aug 1 2008, 20:59