х51 Опции

[Egel]

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

[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 в этом отношении ничем не выделяются - ни ценой, ни функциями.