Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: х51
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему
Страницы: 1, 2
Egel
На каких МК стоит начать учиться, с каким языком работать и в какой среде сейчас осуществляется программирование(я знаю, что для х51 семейства программировали под DOS на TASM например )???
Еще очень интересно есть ли какие-то симмуляторы МК(не аппаратные) и как вообще лучше начать обучение в этой области?
Заранее огромное спасибо
MrYuran
Вот это читал?
Egel
Вопрос впринципе исчерпан
Спасибо smile.gif
Egel
Здравствуйте
Подскажите пожалуйста адрес хорошего сайта для х51 контроллеров.
Что-то типа http://pic16f84.narod.ru/ (для PIC) - только для х51
Хотелось бы больше практики по схемам, программированию и т.д.(теории и так хватает)
И, если есть симмулятор для них
lks
Цитата(Egel @ Jul 29 2008, 20:25) *
Здравствуйте
Подскажите пожалуйста адрес хорошего сайта для х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 - если не забыл)

smile.gif
zltigo
Цитата(Egel @ Jul 29 2008, 18:25) *
Здравствуйте

Совет - как только из чьих-то уст услышите словосочетание "глючный компилятор", причем вне всякой зависимости от того, какой конкретный компилятор поминается всуе, начинайте более предвзято относится к даваемым Вам советам по программированию smile.gif.
lks
Цитата(zltigo @ Jul 29 2008, 21:07) *


Ваши советы нынче почем? cranky.gif
Mik174
Цитата(lks @ Jul 29 2008, 20:52) *
Компилятор Keil - который тут распространяют не советую - глючный. (Специально диверсанты рассылают.)
Хороший компилятор Franklin (демоверсия www.fsi.com - если не забыл)


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

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

Есть особенность - надо внимательно читать варнинги, среди них есть такие, которые приведут к нерабочему коду. Например, если есть обращение к функции а ее описания нет, то часто это будет варнинг.
Несколько неудобно, с другой стороны если делать программу так, чтобы варнингов не было, проблем не будет. По крайней мере я не сталкивался.
zltigo
Цитата(lks @ Jul 29 2008, 20:20) *
Ваши советы нынче почем? cranky.gif

Безвозмездно. По поводу Keil - так уж вышло, что на данный момент он лучший, хотя IAR тоже на достойном уровне.
Egel
На чем вообще лучше писать(из этих двоих я уже понял)? И чем они отличаются от Ассемблера?
zltigo
Цитата(Egel @ Jul 29 2008, 11:21) *
..я знаю, что для х51 семейства программировали под DOS на TASM например

Неужели на 3 курсе МИФИ специальности Микроэлектроники! еще довели sad.gif, что 51 и 86 это не одно и то-же? И чем Ассемблеры от языков высокого уровня отличаюся?
Egel
Вы конечно опытнее меня, но вопрос был несколько в другом,так что острить не надо.
Про то что от чего отличается я и без института знаю, а вот с чем лучше начать работать это дело другое + если учесть тот факт, что никто особо ничего вразумительного не говорит.
Есть литература, но на ней сидя дома далеко не уедешь
Хочется взять и сделать реальное устройство и его запрограммировать - а без подсказок здесь не обойтись, не кажется ли????
zltigo
Цитата(Egel @ Jul 29 2008, 22:48) *
Про то что от чего отличается я и без института знаю...

Как совершенно неожиданно выяснилось - нет sad.gif. Острить и не думал, просто искренне удивился и опечалился уровнем нынешнего российского образования. Честное слово ничего личного!!!
Egel
Образование прекрасное, кстати, а спрашивал то я совсем про другое. Вы бы лучше чего-нибудь дельное сказали
SIA
Цитата(zltigo @ Jul 30 2008, 00:52) *
Как совершенно неожиданно выяснилось - нет sad.gif. Острить и не думал, просто искренне удивился и опечалился уровнем нынешнего российского образования. Честное слово ничего личного!!!

Нда... Как просел родной институт....
Я еще ДО института 3 процессора в асме/кодах программировал, 6800, 8048 и 8080/8085. На С под Unix - еще СМ1420 застал.
Egel
Я за вас очень рад. Не тем надо было заниматься до института.
SIA
Цитата(Egel @ Jul 30 2008, 00:48) *
Вы конечно опытнее меня, но вопрос был несколько в другом,так что острить не надо.
Про то что от чего отличается я и без института знаю, а вот с чем лучше начать работать это дело другое + если учесть тот факт, что никто особо ничего вразумительного не говорит.
Есть литература, но на ней сидя дома далеко не уедешь
Хочется взять и сделать реальное устройство и его запрограммировать - а без подсказок здесь не обойтись, не кажется ли????

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

Цитата(Egel @ Jul 30 2008, 01:09) *
Я за вас очень рад. Не тем надо было заниматься до института.

Не беспокойся, это было далеко не единственное занятие, даже в то время smile.gif
Egel
Спасибо за совет
SIA
Цитата(Egel @ Jul 30 2008, 01:13) *
Спасибо за совет

Чтобы не делать "железо" самому, купи конструктор в Терраэлектронике.
51 хороши тем, что их проинициализировать/настроить периферию достаточно просто, и можно начать и на ассемблере, и на С.
AHTOXA
Цитата(zltigo @ Jul 30 2008, 02:37) *
Цитата(Egel @ Jul 29 2008, 11:21) *

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

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


Вообще-то был tasm (table driven assembler) под DOS, компилил в том числе и для 51х контроллеров.
zltigo
Цитата(AHTOXA @ Jul 29 2008, 23:35) *
Вообще-то был tasm (table driven assembler) под DOS, компилил в том числе и для 51х контроллеров.

Вообще-то это называется TDASM - именно Table Driven ASseMbler . Под 51 досовский в советских условиях распространен был от фирмы 2500 AD. Archimedes встречался, но это уже Keil smile.gif.
Ну а TASM это TurboAssembler smile.gif от Борлад - исключительно x86.
AHTOXA
Цитата(zltigo @ Jul 30 2008, 04:23) *
Вообще-то это называется TDASM - именно Table Driven ASseMbler . Под 51 досовский в советских условиях распространен был от фирмы 2500 AD. Archimedes встречался, но это уже Keil smile.gif.
Ну а TASM это TurboAssembler smile.gif от Борлад - исключительно x86.


Специально не поленился, ещё раз прочитал название файла - TASM.EXE smile.gif
Вот 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) было больше чем одинsmile.gif

ЗЫ. Сомневаюсь, однако, что топикстартер имел в виду какой-либо из этих ассемблеровsmile.gif
777777
Цитата(SIA @ Jul 30 2008, 01:11) *
Легче всего начать с 51 от Atmel или Silabs, море документации, все "разжевано", и ассортимент микрух очень большой, некритичны к монтажу - работают на любой макетке. Потом освоить ARM/MSP - вот и готов "джентльменский набор".


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

Цитата(zltigo @ Jul 30 2008, 00:13) *
Безвозмездно. По поводу Keil - так уж вышло, что на данный момент он лучший, хотя IAR тоже на достойном уровне.


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

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

кейл генерирует сильно кривой код - так как не знает что от него хотят
777777
Цитата(rv3dll(lex) @ Jul 30 2008, 08:15) *
кейл генерирует сильно кривой код

Вы просто не умеете его готовить smile.gif
Цитата(rv3dll(lex) @ Jul 30 2008, 08:15) *
так как не знает что от него хотят

Значит надо объяснить smile.gif
rv3dll(lex)
Цитата(777777 @ Jul 30 2008, 08:31) *
Вы просто не умеете его готовить smile.gif

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


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

и примерные операции - не законченные это вообще песня a14.gif
777777
Цитата(rv3dll(lex) @ Jul 30 2008, 08:48) *
ага очень удобно объяснить что при делении многобайтных чисел всё зависит от разрядности результата.---- проходили уже!!!!!

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


Ээ-э... А подробнее можно? А что такое "примерные операции"?
rv3dll(lex)
Цитата(777777 @ Jul 30 2008, 08:50) *
Ээ-э... А подробнее можно? А что такое "примерные операции"?


это когда точность расчёта зависит от оставшегося времени
по прерыванию например все данные уничтожаются - остаётся только результат
ukpyr
еще есть басплатный SDCC :
http://sdcc.sourceforge.net/
zltigo
Цитата(rv3dll(lex) @ Jul 30 2008, 07:02) *
по прерыванию например все данные уничтожаются - остаётся только результат

Честно говоря даже комментировать не хочется ахинею sad.gif. Нет, я конечно понимаю, что через заднепроходное отверстие не прикладая ума можно получить любой "эффект", только вот зачем при этом пенять на компиляторы?
rv3dll(lex)
Цитата(zltigo @ Jul 30 2008, 11:11) *
Честно говоря даже комментировать не хочется ахинею sad.gif. Нет, я конечно понимаю, что через заднепроходное отверстие не прикладая ума можно получить любой "эффект", только вот зачем при этом пенять на компиляторы?


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

a <= b * c;

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

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

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

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

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

как компиллятору объяснить это?
Egel
Да вы не обращайте внимания, у него стиль такой
zltigo
Цитата(rv3dll(lex) @ Jul 30 2008, 09:28) *
..если не понимаешь не комментируй

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

Использовать явные преобразования типов, предварительное деление сдвигом для гробления точности, перед делением. Наконец, если критично, то и ASM функцию написать совсем не грех. Только вот кричать по незнанию/не владению инструментом о его непригодности явно глупо.
rv3dll(lex)
Цитата(zltigo @ Jul 30 2008, 12:02) *
Использовать явные преобразования типов, предварительное деление сдвигом для гробления точности, перед делением. Наконец, если критично, то и ASM функцию написать совсем не грех. Только вот кричать по незнанию/не владению инструментом о его непригодности явно глупо.


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

то есть Вы УЖЕ согласились что в ответственных местах всёже компиллятор не обеспечивает экономичности ресурсов????
SIA
Цитата(ukpyr @ Jul 30 2008, 10:29) *
еще есть басплатный SDCC :
http://sdcc.sourceforge.net/

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

Цитата(rv3dll(lex) @ Jul 30 2008, 12:16) *
....компиллятор не обеспечивает экономичности ресурсов????

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

Цитата(777777 @ Jul 30 2008, 08:08) *
Без AVR этот набор далеко не полон, ибо именно он на сегодняшний день является лучшим из 8-разрядных контроллеров.

Если речь о Xmega, и критерий - "красота архитектуры" - то возможно. Но экономического смысла в их применении сегодня нет - их цена выше, чем у более мощных и экономичных 32 и 16-разрядных. Только для любителей ностальгии по AVR.
Ни ассортимент, ни качество АЦП/ЦАП в AVR (и большинстве других микроконтроллеров от Atmel) не выдерживают никакой конкуренции с Cygnal, преимуществ по скорости/экономичности - тоже никаких. Тогда нафиг ?
MrYuran
Цитата(rv3dll(lex) @ Jul 30 2008, 12:16) *
то есть Вы УЖЕ согласились что в ответственных местах всёже компиллятор не обеспечивает экономичности ресурсов????

Компилятор - это же не искусственный разум, это просто инструмент.
Такой же, как и к примеру, автотрассировщик плат. Понятно, что опытная тётенька-конструктор (или дяденька, не суть) может намного лучше развести, чем компьютер. Но по временным затратам эти процессы несопоставимы. Если что-то надо передвинуть или поменять - опять же, разница налицо (по времени и трудозатратам). Но если правильно пользоваться инструментом (писать DO-файлы для трассера или make-файлы для компилятора), вручную обходя узкие места, то выигрыш автоматизированного подхода налицо. Есть, конечно, маньяки, которые клоны виндов пишут на асме, но это скорее похоже на искусство ради искусства и к коммерческой разработке отношения не имеет
zltigo
Цитата(rv3dll(lex) @ Jul 30 2008, 10:16) *
то есть Вы УЖЕ согласились что в ответственных местах всёже компиллятор не обеспечивает экономичности ресурсов????

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

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

А алгоритмы, естественно, хорошо и эффективно пишутся, и при этом глобально (с глобальностью в ASM напряг ) оптимизируются на алгоритмических языках.
rv3dll(lex)
Цитата(MrYuran @ Jul 30 2008, 12:42) *
Компилятор - это же не искусственный разум, это просто инструмент.

как подстилка lol.gif


Цитата(zltigo @ Jul 30 2008, 13:07) *
Все стало работоспособным за счет более сложного построения системы а не тупого ускорения "ответственных мест".


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

до кучи формирование нескольких последовательностей импульсов на портах которые в явном виде прям отсчитывая по циклам выводились в порт
blackfin
Цитата(rv3dll(lex) @ Jul 30 2008, 13:49) *
уже где-то писал
Ага.. Вся ветка - de ja vue.. laughing.gif
zltigo
Цитата(blackfin @ Jul 30 2008, 12:48) *
Ага.. Вся ветка - de ja vue.. laughing.gif

Не вся, но продолжение туда покатилось smile.gif. Посему, если кому еще чего вдруг не понятно, или просто поговорить за "ассемблер рулит" - давайте в ту ветку.
777777
Цитата(SIA @ Jul 30 2008, 12:38) *
Если речь о Xmega, и критерий - "красота архитектуры" - то возможно. Но экономического смысла в их применении сегодня нет - их цена выше, чем у более мощных и экономичных 32 и 16-разрядных.

Несколько странно сравнивать AVR с ARM.
Цена ATtiny13 или 2313 существенно ниже чем 32-разрядных контроллеров, не говоря уж о размере микросхемы.
Цитата(SIA @ Jul 30 2008, 12:38) *
Ни ассортимент, ни качество АЦП/ЦАП в AVR (и большинстве других микроконтроллеров от Atmel) не выдерживают никакой конкуренции с Cygnal, преимуществ по скорости/экономичности - тоже никаких. Тогда нафиг ?

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


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

насчёт производительности
на задачах обработки сигналов дохлый сигнальник натянет любой арм
SIA
Цитата(777777 @ Jul 30 2008, 15:57) *
Несколько странно сравнивать AVR с ARM.
Цена ATtiny13 или 2313 существенно ниже чем 32-разрядных контроллеров, не говоря уж о размере микросхемы

Если нужен простенький предельно дешевый, но надежный контроллер - это тогда к Microchip или Freescale (а-ля 68705). Мелкие AVR в этом отношении ничем не выделяются - ни ценой, ни функциями.
lks
Цитата(Mik174 @ Jul 30 2008, 00:09) *
Во-первых, адрес указан неверно


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


Цитата(Mik174 @ Jul 30 2008, 00:09) *
Во-вторых, он давно не развивается и естественно, очень многие чипы не поддерживает.


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

Цитата(Mik174 @ Jul 30 2008, 00:09) *
Всякий раз когда думал что в компиляторе нашелся какой-то глюк, при ближайшем рассмотрении оказывалась причина в "кривых ручках"


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



Цитата(777777 @ Jul 30 2008, 08:08) *
Без AVR этот набор далеко не полон, ибо именно он на сегодняшний день является лучшим из 8-разрядных контроллеров.


И чем же AVR лучше будет?
Может по быстродействию больше бывают?
Или память может иметь такую же как у 8052?
Совместимость программного кода может тогда лучше чем у 8052?
Чем же тогда лучше?
Herz
Я вам так скажу. Компилятор - сложный программный продукт, намного сложнее, чем большинству из здесь присутствующих приходилось создавать. И вполне естественно, что возможные баги в нём вылавливаются не сразу. Однако что характерно: опытный программист гораздо реже пеняет на компилятор, хоть и знает его значительно лучше. О чём это говорит? Это к вопросу о "глюках" компиляторов. А уж религиозные войны под девизами типа ASM рулит - С must die! и наоборот - и вовсе, ИМХО, детский лепет, как и споры о том, какой контроллер лучше. Ибо взрослому человеку понятен смысл слова целесообразность.
777777
Цитата(lks @ Jul 30 2008, 22:21) *
И чем же AVR лучше будет?
Может по быстродействию больше бывают?
Или память может иметь такую же как у 8052?
Совместимость программного кода может тогда лучше чем у 8052?
Чем же тогда лучше?


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


Цитата(SIA @ Jul 30 2008, 17:22) *
Если нужен простенький предельно дешевый, но надежный контроллер - это тогда к Microchip или Freescale (а-ля 68705). Мелкие AVR в этом отношении ничем не выделяются - ни ценой, ни функциями.


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

Я вижу только один пункт, благодаря которому они обрели у нас такую популярность - у большинства даташиты на русском языке smile.gif
rv3dll(lex)
Цитата(777777 @ Jul 31 2008, 08:18) *
Архитектурой.
По быстродействию - да, 16 МГц при выполнении команды за 1 такт это несомненно лучше, чем 20 МГц за 12 тактов, а нынешние 1-тактовые 8052 не работают на таких частотах.

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

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

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


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

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

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

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

1 такт полноценный возможен только с конвейером - зато при большом количестве переходов это не работает - и получаем теже 4 цикла
Herz
Цитата(777777 @ Jul 31 2008, 06:18) *
Может я действительно чего-то не понимаю, но как раз PIC-и это совершенно отстойные контроллеры, по всем параметрам хуже любого имеющегося. Ну объясните, чем урезанная система команд лучше полноценной? Чем 20 МГц при выполнении на 4 такта лучше, чем 16 МГц - за один такт? Назовите хотя бы один параметр, по которому PIC лучше хотя бы какого-нибудь другого контроллера?
Наверное, чего-то и не понимаете... И я чего-то не понимаю. У каждой архитектуры есть свои плюсы, свои минусы. А что такое урезанная система команд? Все RISC контроллеры имеют "урезанную" систему команд. Кстати, 18-е ПИКи имеют набор из 75 и более инструкций - это мало? Насчёт "самых отстойных" зайдите на этот форум и скажите там об этом. Для себя отметил высокую надёжность ПИКов и замечательную документацию.
Цитата
Я вижу только один пункт, благодаря которому они обрели у нас такую популярность - у большинства даташиты на русском языке smile.gif

Не преувеличивайте. Да и популярны они не только в России.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.