У AVR регистр-регистр тоже за один такт. А ещё за один такт - вывод в порт, в отличие от 3-х тактов MSP. Не знаю, как у кого, а на моих задачах MSP всегда оказывался медленнее AVR. Правда, DMA я не использовал. Поэтому я потренировался немного на нём, да и передумал с AVR на MSP переходить.

Что касается цены, то MSP-149 стоит в районе $3.5, а AtMega8 $0.8.
Единственное, что остаётся у MSP - энергопотребление. Но если исполнительные устройства едят на два порядка больше проца, то какая разница?

Только у MSP430 16 бит, а не 8. :-Р Потому и сказано было, что никакой 8-битник тут не угонится, не нужно из контекста выдирать.


У MSP430 это не вывод в порт, а обращение в память. А то, что порты и другие регистры на память отмаплены - это очень правильное, здравое и зрелое решение. AVR из-за своих in/out, во-первых, ввел еще одно адресное пространство - трех имеющихся ему мало, во-вторых, на меге128 и других толстых чипах имеем форменный геморрой, когда регистры специальных функций не помещаются в это маленькое адресное пространство. Кроме того, за сколько тактов выполняется инверсия пина на AVR? И не забываем весь связанный с этим геморрой, когда нужно использовать два регистра - а если это делается в прерывании, то их надо сохрянять - еще оверхед, когда операция эти неатомарна и т.д. :-Р


На каких это Ваших задачах, если Вы раздумали на него переходить? Вот поработали бы нормально, чай мнение бы и поменялось. Я, кстати, не из-за скорости мигрировал на MSP430 - исходно ожидал где-то паритета, а учитывая, что тактовые у AVR выше, то и прироста абсолютной скорости не ожидал. Меня другие фичи сманили.


Ха! Нашли что сравнивать! Да MSP430F149 кроет ATmega8 как бык овцу! У меги скока флеши? 8 кил, а у F149 - 60! ОЗУ у меги 1 килобайт (и это много для такого чипа, непропорционально, я бы сказал, много), у F149 - 2 килобайта. У F149 12-разрядный АЦП с 200 К выборок в секунду, с секвенсором на 16 значений, с индивидуальными настройками опорных напряжений для каждого канала, с различными режимами запуска и т.д. Тут вообще ни один AVR близко не стоял! У F149 два полноценных таймера с суммарно 10 модулями Compare/Capture/PWM. У F149 два USART'а, каждый из которых может быть сконфигурирован либо как UART, либо как SPI. Наконец, у F149 6 8-битных портов, т.е. 48 ног на ввод/вывод.

Кроме того, откуда такие сведения про цены? MSP430F149 стоит существенно дороже - порядка 7-10 баксов. Мега8 тоже больше бакса - порядка двух баксов. Но в любом случае это МК разной весовой категории уже по объему флеши. Одноклассником MSP430F149 является Мега64, и стоит она примерно те же пятаки. А по периферии все так же пролетает. Кстати, MSP430F149 - это уже старый чип, сегодня за почти такие же деньги есть MSP430F169, у которого помимо вышеперечисленного еще есть два 12-битных аналоговых ЦАПа, DMA.


Да уж конечно! Особенно если забыть, что ни у одного AVR нет такого АЦП, ни у одного AVR нет таких ЦАПов (если вообще есть какие-то, я уже перестал за ними следить), если забыть про десяток ШИМов, в том числе и 3 синхронных парафазных с мертвыми зонами, если забыть про аппаратный умножитель-аккумулятор 16х16, которого в AVR нет и, очевидно, не будет.

В заключение, имея пятилетний опыт плотной работы с AVR, имея 3-летний опыт не менее плотной работы с MSP430 (т.е. не потренировался, а именно поработал, сделал эн проектов на нем), могу ответственно сказать, что работать с MSP430 намного приятнее во всех смыслах. Благодаря более стройной архитектуре с одним адресным пространством вместо четырех у AVR, и благодаря более прямой, гибкой и богатой периферии.

Если вы помните микропроцессоры классифицируются на 2 группы.Микропрограммные серий 587,589 ..и микрокомандные,например, 580 серии.Микропрограммные используют код операции, а микропрограммные мнемонику кода,т.е асм.Я думаю, что вы не захотите связываться с микропрограммными контроллерами.Здесь надо под каждую задачу создавать свою систему команд.
Вас устроило , что разработчик уже вам предоставил какой-то инструмент.Завтра засунут туда
Паскаль или Бейсик и , что вы будете делать? Я думаю будете изучать бейсик.587 я программировал.
И менчя до сих пор в жар бросает.
Ваши споры полезны в отдельном форуме по максимальному, рациональному использованию МК и
его компиляторов , а не о вечности ассемблера.

Ну вот например смотрим в ДШ на ATmega 48/88/168 и видим
ACTIVE SUPPLY CURRENT vs. VCC
INTERNAL RC OSCILLATOR, 8 MHz
на 3V примерно 2,7ma

А еще у него есть такой регистр CLKPR который позволяет делить тактовую в
1,2,4,8,16,32,64,128,256 раз. (с соответствующим уменьшением потребления)

ИМХО: как раз для батарейных девайсов актуально писать на ASM, т.к. это позволяет
быстрее сваливаться в Idle или Power Down и экономить энергию.

Бейсик изучать точно не буду.

Когда внутрь микропроцессора засунут Бейсик/Паскаль/С/С++/Питон/др., это будут уже не Бейсик/Паскаль/С/С++/Питон/др - это будут уже ассемблеры, похожие на Бейсик/Паскаль/С/С++/Питон/др. Сегодня (и уже давно) фирма ADI применяет для своих DSP ассемблер с алгебраическим синтаксисом, он очень похож на С. И тем не менее, это ассемблер. Не думаете же Вы в самом деле, что появится процессор, у которого на асме можно будет написать TSlon *p = new TSlon;? В любом случае это будет язык элементарных операций данного процессора - его инструкций. И если мнемоники типа mov и jmp будут заменены на свои аналоги из ЯВУ, ассемблер от этого ассемблером быть не перестанет. Уровень абстракции все равно низок, переносимости и стандартности все равно нет.

Вот когда на уровень железа процессоров перенесут абстракции высокого уровня, т.ч. не будет никаких байтов и битов, а будут только объекты в памяти, не будет никаких разных адресных пространств, а будет просто память, где лежат объекты, когда работа с этими объектами - создание, удаление, инкапсуляция (сокрытие внутренней реализации) и многое другое, что свойственно ЯВУ будет реализована на уровне железа процессора, вот тогда можно будет говорить о смерти ассемблера. Только это будет (если будет) уже совсем другой процессор, и вряд ли мы дождемся наступления этих времен.


Какая разница, где дискутировать. Главное, чтобы это было интересно и конструктивно (конструктивно - это когда участники дискуссии и читающие ее находят для себя что-то новое). Случилось это здесь, ничем оно не плохо.

Абсолютно необоснованное. Тяжкое наследие ПДП-11.


Я тут не трактую за всех, только лишь за себя. На моих задачах хватает и 4К флеша. Зато не хватает быстродействия у MSP. Его сильно шустрый АЦП и вовсе членомерия, поскольку сделать сколько-нибудь осмысленную обработку отсчётов, прущих на такой скорости, MSP всё равно не успевает. И периферия его замечательная меня не лечит. В последней задаче каналов ШИМ мне надо 12. А входной сигнал имеет Ft=19кГц. Его надо фильтровать и шевелить каналами ШИМ.

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

Обоснованное именно зрелостью подхода. Когда надо расширять, то есть куда это делать. Это Атмел по молодости пролетел, думал, что 64 байта - это бесконечно много. У всех серьезных МК регистры спецфункций отмаплены на память.


PDP-11 был прекрасный процессор, гибкий, продуманный. Жаль, что развития эта ветка не получила. Во мне говорит не ностальгия, я с ним не работал, не застал уже. И если сегодня уже давно смогли соорудить 1-тактовый 51-й, то и PDP-11 реализовать на быстром ядре было бы возможно.


Быстродействия какого? Вычислительного? Это вряд ли. Ногодрыгания? Вот на это похоже. Для формирования жестких времянок вообще надо периферию использовать. Делать это с помощью программной реализации - хакерство, чреватое гемором.


Никакая не членомерия. Для таких быстрых потоков там у АЦП есть секвенсор, который собирает сразу до 16 отсчетов, благодаря чему не надо прыгать за каждым отсчетом отдельно, имея оверхед, что и происходит с AVR'ом, а один раз пошли и забрали сразу все 16. Получается для максимальной скорости 5 мкс * 16 = 80 мкс период поступления прерываний, вполне реально. Насчет "делать осмысленную обработку отсчетов, прущих на такой скорости" - есть задачи, когда надо собрать данные, собирать надо на максимальной скорости. А обсчитать их можно и потом. В любом случае AVR тут курит в уголке.


Кто ж спорит, не на все случаи жизни MSP430 годится. Для этой вашей последней задачи самое оно TMS320F28xx. Или Вы хотите сказать, что мега8 здесь замечательно справляется?

[quote name='dxp' date='Jun 29 2006, 11:17' post='129281']
Если вы помните микропроцессоры классифицируются на 2 группы.Микропрограммные серий 587,589 ..и микрокомандные,например, 580 серии.Микропрограммные используют код операции, а микропрограммные мнемонику кода,т.е асм.Я думаю, что вы не захотите связываться с микропрограммными контроллерами.Здесь надо под каждую задачу создавать свою систему команд.
Вас устроило , что разработчик уже вам предоставил какой-то инструмент.Завтра засунут туда
Паскаль или Бейсик и , что вы будете делать? Я думаю будете изучать бейсик.[/quote]

Когда внутрь микропроцессора засунут Бейсик/Паскаль/С/С++/Питон/др., это будут уже не Бейсик/Паскаль/С/С++/Питон/др - это будут уже ассемблеры, похожие на Бейсик/Паскаль/С/С++/Питон/др. Сегодня (и уже давно) фирма ADI применяет для своих DSP ассемблер с алгебраическим синтаксисом, он очень похож на С. И тем не менее, это ассемблер. Не думаете же Вы в самом деле, что появится процессор, у которого на асме можно будет написать TSlon *p = new TSlon;? В любом случае это будет язык элементарных операций данного процессора - его инструкций. И если мнемоники типа mov и jmp будут заменены на свои аналоги из ЯВУ, ассемблер от этого ассемблером быть не перестанет. Уровень абстракции все равно низок, переносимости и стандартности все равно нет.

Вот когда на уровень железа процессоров перенесут абстракции высокого уровня, т.ч. не будет никаких байтов и битов, а будут только объекты в памяти, не будет никаких разных адресных пространств, а будет просто память, где лежат объекты, когда работа с этими объектами - создание, удаление, инкапсуляция (сокрытие внутренней реализации) и многое другое, что свойственно ЯВУ будет реализована на уровне железа процессора, вот тогда можно будет говорить о смерти ассемблера. Только это будет (если будет) уже совсем другой процессор, и вряд ли мы дождемся наступления этих времен.

[/quote]

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

ЯВУ уже вставляли и вставляют в процы. Например Java, Forth:)

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

Сообщение отредактировал Kopa - Jun 30 2006, 03:31

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

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

Согласен на все 100, за исключением "жаль". Потому что его архитектура - ад для конвейера.
А для микроконтроллера такая архитектура - и вовсе тормоз.
Во мне и ностальгия говорит. Работал я с ним, а ещё с VAX.


Я-я. Иллюстрирующий пример:


MSP - 27 тактов
AVR - 30 тактов.
Угадайте, кто быстрее.


Нащёт "замечательно" - пока не уверен - ещё не отполировал до конца. Но справляется.

Если по теме. Ассемблер жил и будет жить, это очевидно. Но необходимость в нём с каждым днём уменьшается. Помнится, было где-то прекрасное исследование оптимизации некоторых компиляторов С для х86. Так вот, компиляторы оптимизировали так, что рядовому программисту на ассемблере и не снилось. Это и понятно. Оптимизацию для хорошего компилятора пишут профессионалы, которые на этой архитектуре десяток собак съели, а программисту приложений вникать во все тонкости просто времени нет - у него план горит.
Если же брать ассемблер AVR, то он довольно мутный (PIC, конечно, ещё хуже), но обычно хватает возможностей по оптимизации того же IARа. Если и пишу сейчас на ассемблере небольшие кусочки, то только очень примитивные по функциональности, как например, те самые 12 каналов ШИМ.

Сообщение отредактировал pokos - Jun 30 2006, 05:59

Цитирую дословно:Assembler-компонующая программа,программа сборки.А язык зашит в каждом
микроконтроллере аппаратно.И для каждого микроконтроллера нужен свой ассемблер.Более того,
компиляторы Си,Паскаль и т.п. для микроконтроллеров я тоже не считаю языками ЯВУ.Они настолько урезаны , что от них остался только ассемблер.Сколько пустых споров что лучше IAR,Keil,Hi-Tech и др.
А сторонники C++ и Delphi вообще убивают друг друга.
Я согласен с dxp , что это инструмент, а мы инструмент в руках разработчиков МК. Они нашими руками
заставляют работать свои микроконтроллеры.Да, мы умные , но они умнее.Пока будет рынок, будет
много типов МК и ассемблеров.Иначе незьзя.Так диктует рынок.Они нас заставили писать на ассемблере.И мы пишем.Засунут Бейсик -будем писать на Бейсике. Многие думают , что они выбирают
микроконтроллеры.Нет это МК выбирают вас.
А если предположить , что это "они" инструмент в наших руках.Тогда давайте диктовать им свои
условия, но если мы счастливы писать на ассеблере, то ничего не изменится.
Я думаю, ассебблер на том уровне на котором он сейчас, не имеет перспектив.Его время ушло.
Кроме того специалисты по ассемблерам уже не нужны рынку.В мире уже сложились монополии на все.
Что-то там изменить сложно.Высшая школа выпускает уже не инженеров , а специалистов.Только еще
мы (осколки бывшего Союза) можем позволить себе пустые и ненужные споры.
Кто не читал, то прочитайте Айзека Азимова -"Профессия". Это про нас.

Те кто выжил в катаклизме пребывают в пессимизме
Да все определяет рынок. А деньги мера труда. И если завтра будет значительно легче и быстрее сделать девайс на жеской логике (ну например ПЛИСины будут продаваться по цене резисторов), послезавтра микроконтроллеры умрут как класс.

Мы не знаем как устроено железо. Мы можем об этом только догадываться. Но мы знаем систему команд и их двоичные коды.Этим кодам присвоены удобные названия - это и есть ассемблер. По другому нельзя, всегда будет точка соприкосновения между разработчиком и пользователем. Можно писать на ЯВУ и не знать ассемблера, но полный контроль над процессом разработки будет только при его знании. Сравню это с программированием на том же Билдере - да новичок, может быстро нарисовать форму с кнопками, НО, если он не знает как работает главное окно, зачем и как ходят сообщения, дальше этой формы он не пойдет. Поэтому ассемблер не есть самоценным для программиста. Это такой же бэкграунд как знание работы транзистора, для разработчика электроники. Это понимание процесса от и до.


А вот это утверждение меня откровенно порадовало. Приведите пожалуйста возможности стандартного С99, недоступные для работы на какой-нибудь Тини26 ? Насколько я знаю - только ограничения на использование *alloc(), что определяется не компилятором, а малым объемом доступной памяти.

???<<Те кто выжил в катаклизме пребывают в пессимизме >>

Те кто выжил , получили закалку.Поэтому я и спрашиваю,кому вы будете сбывать свою
продукцию если вы ее будете писать долго на асм.?Особенно нам с вами надо потеть очень
много.Россия в лучшем положении.

???<<Поэтому ассемблер не есть самоценным для программиста. Это такой же бэкграунд как знание работы транзистора, для разработчика электроники. Это понимание процесса от и до.>>

Совершенно верно.Выросшему на Си-компеляторе,ассемблер вообще не нужен.

???<<Сравню это с программированием на том же Билдере - да новичок, может быстро нарисовать форму с кнопками, НО, если он не знает как работает главное окно, зачем и как ходят сообщения, дальше этой формы он не пойдет. >>

Пойдет и дальше вас.

???<<Приведите пожалуйста возможности стандартного С99, недоступные для работы на какой-нибудь Тини26 ? Насколько я знаю - только ограничения на использование *alloc(), что определяется не компилятором, а малым объемом доступной памяти.>>

Тем более это не в пользу ассемблера.

И вообше-то я совсем не против ассемблера.Я вырос на нем.Но надо трезво смотреть на жизнь.

Если вы внимательно читали мои посты, заметили бы - я сторонник ЯВУ.

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

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

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