AVR vs PIC

В статье <cft0q1$u24$ snipped-for-privacy@host.talk.ru> Harry Zhurov написал(а):

А как называется более общий случай с регулировкой скважности?

Tue, 17 Aug 2004 17:22:53 +0600 Dmitry Fedorov wrote to Harry Zhurov:

DF> á ËÁË ÎÁÚÙ×ÁÅÔÓÑ ÂÏÌÅÅ ÏÂÝÉÊ ÓÌÕÞÁÊ Ó ÒÅÇÕÌÉÒÏ×ËÏÊ ÓË×ÁÖÎÏÓÔÉ?

HÅ ÚÎÁÀ. åÓÔØ ÅÝÅ þéí - ÞÁÓÔÏÔÎÏ-ÉÍÐÕÌØÓÎÁÑ ÍÏÄÕÌÑÃÉÑ (ÄÌÉÔÅÌØÎÏÓÔØ ÉÍÐÕÌØÓÁ ÆÉËÓÉÒÏ×ÁÎÎÁÑ, ÐÅÒÉÏÄ ÍÅÎÑÅÔÓÑ). ïÂÁ - É ûéí, É þéí ÍÅÎÑÀÔ ÓË×ÁÖÎÏÓÔØ. åÝÅ ËÏÍÂÉÎÉÒÏ×ÁÎÎÙÊ ÓÐÏÓÏ ûéí-þéí, ÎÏ ÉÍÅÅÔÓÑ ÌÉ Õ ÎÅÇÏ Ó×ÏÅ ÎÁÚ×ÁÎÉÅ, ÎÅ ÚÎÁÀ.

Привет!

Tue Aug 17 2004 17:22, Harry Zhurov wrote to Alexander Golov:

...

AG>> ШИМ позволяет формировать импульсы заданной длительности, AG>> а несколько ШИМов -- импульсы сдвинутые относительно друг-друга на AG>> заданную величину и всё это без вмешательства ядра. С Output Compare AG>> этого достигнуть нельзя.

HZ> ШИМ - широтно-импульсная модуляция. Если у тебя импульсы HZ> фиксированной длительности, то это, строго говоря, не ШИМ, т.к. модуляции HZ> нет.

Строго говоря модуль МК называемый "PWM" ничего и не модулирует. Он вырабатывает периодическую последовательность импульсов установленной длительности и периода. Именно в соответствии с данной функциональностью я его и использовал.

...

HZ>>> Тем не менее 16-разрядный MSP430 в этом вопросе делает их всех с HZ>>> таким отрывом, что об этом даже говорить не приходится!

AG>> С каким таким отрывом? Hасколько мне известно потребление самых "лёгких" AG>> MSP430 при 3 В это около 300 мкА при 1 MIPS

HZ> 240 мкА. При 2.2В - 160 мкА.

Масочные MSP430С? Сомневаюсь, что их параметры тут много кому интересны. Мне точно нет.

AG>> у более "тяжёлых" -- 500 мкА.

HZ> 420 мкА. При 2.2В - 280 мкА.

Я рамки определил, а не какие-то конкретные ИС имел ввиду. По даташиту те же MSP430F155 и Co потребляют 500 мкА.

AG>> PIC16F последнего поколения потребляют при тех же условиях практически AG>> те же 320...370 мкА (в зависимости от вида тактирования),

HZ> Я смотрел на эти нановаттные PIC'и и сравнивал. Hа самом деле HZ> PIC16F7X7 по даташиту потребляет 450 мкА на 4 МГц (т.е. на тот же МИПС).

А многие другие из мелочи (12F636, 16F648A, 676, 688 и т.п.) потребляют столько сколько я указал. Если это важно: на 2 В они потребляют 180 мкА.

HZ> При этом этот PIC более ровня мелким MSP430, да и то по вычислительной HZ> производительности отдыхает.

Производительность MSP430 максимальна только на коротких циклах оперирующих группой регистров. Но в задачах для которых обычно используют PIC16 вычислительные алгоритмы не занимают существенного времени. Напротив, оперировать SFR'ами, флагами (и вообще статическими переменными) он умеет в несколько раз быстрее MSP430.

HZ> А уж для таких, как MSP430F14x среди 16-х HZ> PIC'ов вообще соответствия нет. А 18-е уже потребляют совсем не так. Т.ч. HZ> в разы!

Нет, разница минимальна.

HZ> Еще не надо забывать, что у MSP430 очень гибкая система HZ> тактирования и потребления (и периферия заточена под это), что позволяет HZ> организовать программу так, что реально среднее потребление будет вообще HZ> мизерным.

А PIC'ам, конечно, не доступны энергосберегающие режимы? Или у них там всё так негибко, что ничего микропотребляющего не сделать?

AG>> Hе слишком навороченные PIC18F

HZ> Hе слишком навороченные - это какие? Hа уровне младших MSP430?

Имелись ввиду PIC18F4320 (580 мкА), PIC18F4431 (670 мкА) и т.п. из свежих. Много (1...1,5 мА) потребляют PIC18 с шиной внешней памяти.

AG>> достигли потребления на уровне PIC16C -- 580...680 мкА.

HZ> В разы!!

Ну какие разы? Для диапазона потребления MSP430 сравнимых с PIC18 -- 420...500 мкА это будет 1,16...1,6 раза. Для PIC16 ещё меньше (1,07...1,5 раза). Это вовсе не "...такой отрыв, что даже говорить не приходится!" Как раз много есть о чём поговорить. Кроме того для задач "под PIC16" я однозначно отдам им голос за больший вес MIPS'а.

AG>> dsPIC30F потребляет в три раза больше "тяжёлых" MSP430 из расчёта на AG>> MIPS,

HZ> В том же 70083F.pdf указано потребление на 1 МИПС при 3.3 В - 4 мА. HZ> Почти в 10 раз!!! Это самая скромная цифра - остальные там (при больших HZ> напряжениях питания и частотах) идут уже на десятки мА.

Скажем в DS70135A на dsPIC30F4011 указано потребление при 3,3 В и 4 MIPS -- 7 мА. Какой-нибудь MSP430F155 при 3,3 В потребляет 560 мкА. Это и будет

AG>> но он и существенно производительнее.

HZ> Существенно - это во сколько. Hу грубо, хотя бы на какой-нибудь HZ> типовой задачке, вроде вычисления полинома. Или вот на том тесте, HZ> помнишь, ты приводил, где пачка термометров обсчитывалась, где сравнивали HZ> PIC18, AVR и другие.

У меня нет компиллятора для dsPIC30F, чтобы делать такие сравнения. Да и реальность такова, что скажем после того как Hi-Tech перетряхнула библиотеки у меня та задачка с RTD для PIC18 работает быстрее чем ты приводил для MSP430. Своё мнение я составляю на кодировании алгоритмов из аппнотов к MSP430 для dsPIC30F. Пока я не встречал случаев, чтобы у dsPIC30F что-нибудь получилось дольше, причём это для алгоритмов являющихся коньком MSP430 -- регистровых -- а если откодировать для dsPIC30F что-нибудь вроде "slaa029" то разница получается многократной (вполне типичный пример я привёл ниже, простенькую отправку данных dsPIC30F выполнил в 3,5 раза быстрее).

...

AG>> а если бы памяти было всего пара килобайт?

HZ> Ага, опять "если бы да кабы". "Если бы бабушка была дедушкой..." Там HZ> не пара килобайт, а 36. Там, где пара килобайт, и подходы к реализации HZ> другие.

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

...

AG>> У dsPIC30F опкод 24-разряда, прямой адрес -- 13 (исключая MOV, которая AG>> накрывает все 64 К). Этого вполне достаточно для непосредственного AG>> оперирования SFR'амии и статическими переменными без дополнительных AG>> задержек. Hикаких страшных потерь опкодов не наблюдается и AG>> дополнительные слова не требуются.

HZ> 13 бит - это 8192! Всего-то?! И это называется "прямая адресация"? А HZ> какое у dsPIC'а адресное пространство? 64К? А как же быть с остальными?

Прямая адресация (в составе операций) ко всей памяти не нужна ни в одном процессоре, кроме самых мелких, вроде PIC16. Прямо адресовать нужно только статические данные, включая SFR'ы. Для 64-килобайтного пространства данных (как у dsPIC30F) 8 КБ прямой адресации это с большим запасом.

...

HZ> Кстати, а как оно доступается в область выше 8К?

Для 16-разрядных пересылок память-регистр во всём пространстве данных есть пара:

mov Wns,f mov f,Wnd

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

...

HZ> То, что ты имеешь в виду под прямой адресацией в dsPIC'е, не является HZ> таковой в полной мере. Это прямая адресация только к ограниченному объему HZ> - 12.5% от общего объема - памяти. Продемонстрируй, как ты собрался прямо HZ> обращаться по адресу, например, 0x4e20?

Зачем туда адресоваться прямо? Ты почему-то одновременно ратуешь за ненужность прямой адресации и, раз уж она есть, за её вездесущность. К чему такой экстремизм? Ведь это не нужно с практической точки зрения.

HZ> Когда я говорил про неэффективность прямой адресации (начиная с HZ> некоторых объемов), я имел в виду именно объективный недостаток этого HZ> способа, выражающийся в необходимости кодировать при каждом обращении к HZ> даже рядом лежащим ячейкам полный длинный адрес в каждом случае. Это HZ> раздувает размер кода и, путем увеличения трафика по шинам, уменьшает HZ> быстродействие (либо, если шины толстые, увеличивает энергопотребление). HZ> С увеличением адресного пространства эта проблема усугубляется. Это HZ> _объективное_ свойство данного способа адресации.

Мы обсуждаем конкретный класс вычислительных устройств -- микроконтроллеры -- обладающие весьма ограниченным набором ресурсов. А ты делаешь столь общие выводы, как будто мы говорим об устройстве исполняющем код уровня Windows. Для МК обсуждаемого класса прямая адресация ограниченного (но выбранного не как у AVR, а "с головой в руках") объёма прямо адресуемого пространства обеспечивает выигрыш в производительности, прежде всего потому, что активное оперирование SFR'ами и анализ/модификация флагов весьма характерны для МК.

...

HZ> Так сколько циклов у dsPIC'а переход? И что это за матершинные HZ> картинки в упомянутом пдфнике про "INSTRUCTION PIPELINE FLOW: 1-WORD, HZ> 2-CYCLE" и аналогичные (Figure2-x)?

Всегда 2 цикла сколько раз уже произносим. Требуется 30 нс (или сколько там) для выборкы команды из flash.

...

AG>> Её потому и нет, что память медленная. Если бы инструкцию можно было AG>> выбрать за 8,3 нс он бы её и выбрал в 1-м такте своего цикла и не AG>> вставлял бы лишний цикл при чтении программной памяти.

HZ> Ее нет потому, что новый адрес до выполнения перехода еще неизвестен!

Например, на безусловном переходе известен, но так как команда заранее не декодируется это ничего не меняет.

HZ> В продвинутых процах вроде TigerSHARC имеется специальный автомат - HZ> "предсказатель" ветвлений, который просматривает инструкции вперед, HZ> анализирует их и если попадается команда перехода в новое место, то HZ> считывает инструкции в кэш (откуда сам проц их уже выполняет) из двух HZ> мест. Таким образом, в общем случае, он имеет две очереди инструкций - HZ> для случая, если перехода не будет (если он условный), и для случая, если HZ> переход будет произведен. Проц просто выбирает соответствующую ветку в HZ> кэше инструкций.

Можно просто ОЗУ под всю flash подложить, можно кэш разного уровня сложности построить, только лишнее всё это для МК данного класса.

HZ> Hо в более простых процах такая штука - непозволительная роскошь, вот HZ> и вылезает дополнительный такт на считывание инструкции по новому адресу. HZ> Hикогда не задумывался, почему у PIC'а условные переходы выполняются 1/2 HZ> такта? Для какого случая 1 такт, а для какого - 2. И не в медленности HZ> памяти тут дело!

Могу только ещё раз повториться: лишь в ней и дело. Что там может быть не ясно с условными переходами? Выполнил переход, нужно выбрать команду по новому адресу, плюс цикл на время выборки, нет перехода выполняешь уже выбраную команду.

...

HZ>>> Hу, т.е. все упирается в условия твоей задачи. А надо будет 12 бит HZ>>> и пролетит твой dsPIC аки фанера на Парижем - даже до MSP430 не HZ>>> дотянется.

AG>> Hачальные условия -- тензоизмерения в полосе до 25 кГц с частотой AG>> выборок 100 кГц с разрешением 8-разрядов мультиплексно в 30 каналах. 12 AG>> разрядов это в лучшем случае порядка 0,1 мкВ на МЗР. Как я уже говорил, AG>> даже 10 разрядов в таком прямом рассмотрении не сахар, а там ещё есть AG>> несколько ухудшающих жизнь условий.

HZ> Что, шумное окружение? Или что? 12 бит могут быть проблемой из-за HZ> того, что это набортный АЦП. Внешние (недешевые, конечно) АЦП вполне себе HZ> ничего работают.

Не 12 разрядов проблема, а 0,1 мкВ. Одновременно малошумящие и малопотребляющие усилители это очень непросто.

...

HZ> Hе знаю, не знаю, я бы не стал упираться искать уникальный МК - лучше HZ> поставил бы мелкую ПЛИСку (тот же кулраннер) и организовал бы на нем HZ> быстрый последовательный порт. А МК туда хоть по SPI может заливать, хоть HZ> по параллельному каналу - на вкус.

На вкус по последовательному -- все узлы на разных платах. Собственно я так и собираюсь (не обязательно с PLD), dsPIC30F тоже необходимую скорость обмена не обеспечивает, даже меньше PIC18. Просто тут мы говорили про PIC18F2331 у которого прекрасно подходящий для 200 KSPS UART на 2,5 Мбод имеется внутри.

...

AG>> Развязка механическая через 250 мм свободного пространства (прибор AG>> вращается вместе объектом исследования).

HZ> О! Еще новые условия! :) А куда оно передает?

К такому же МК, через него (возможно ещё через FIFO) в USB и в PC.

...

AG>> У 2331 на АЦП FIFO на 4 отсчёта, прерывания он получает каждые 200 AG>> циклов.

HZ> А MSP430 в этом случае будет получать прерывание каждые 16*5*8 = 640 HZ> циклов.

А смысл? Уже 100 циклов вполне комфортно (во всяком случае для PIC18), а 200

-- расслабленное состояние. Слишком большой буфер скорее помешает -- обработчик будет "подвисать" на время пересылки и вычисления дельт для 16 отсчётов.

AG>> Обработчик считает время и буферирует отсчёты. Когда данных наберётся AG>> полный фрейм, его отправку (с формированием суммы и т.п.)

HZ> Формирование суммы тоже на нем эффективнее благодаря 16-разрядности - HZ> сразу все слово за раз, а не двумя половинками, как на PIC'е.

Уж такой выигрыш! Вот цикл отправки части данных фрейма для PIC18. Его длина

SendFrame0 movfw postinc1 1 SendFrame1 skpbs txif 2 bra endFrame1 movwf txreg 1 addwf TxCheck+0 1 movlw 0 1 addwfc TxCheck+1 1 tstfsz fsr1l 1 bra SendFrame0 2

А вот то же для MSP430. Может я где-то ошибся (смотрел в аппноты), но по-моему

SendFrame0 mov.b @r15+,r4 2 SendFrame1 bit.b #UTXIFG0,&IFG2 5 jz SendFrame1 2 mov.b r4,&TXBUF0 4 add r4,r14 1 tst.b r15 1 jne SendFrame0 2

Кстати, версия для dsPIC30F (5 циклов):

do 255,SendFrame0 mov.b [w1++],w0 1 SendFrame1 skpbs u1txif 2 bra endFrame1 mov wreg,u1txreg 1 SendFrame0 add wreg,w2,w2 1

...

AG>> Обычно требуется улучшить качество эксперимента и конца этим пожеланиям AG>> не будет никогда. И если пределы улучшения на данный момент диктуются AG>> доступной элементной базой (и далеко не только МК), то что уж тут AG>> поделаешь?

HZ> Hу, так TMS320F28xx может кардинально поднять планку достижимого. И в HZ> плане энергопотребления не такой уж и большой проигрыш, учитывая HZ> низковольтность питания.

Насчёт небольшого проигрыша не понятно. По 3,3 В потребление будет около 50 мА, т.е. от батареи (при 2,8 В и КПД 90%) будет около 65 мА. По 1,8 В потребление, скажем 150 мА, тогда от батареи будет 107 мА. Итого 170 мА от батареи только МК. У нас сейчас весь прибор вдвое меньше потребляет и даже это, надо заметить, совсем немало.

...

AG>>>> У меня Microchip'овский PRO MATE II с модулем ICSP.

...

AG>> Hет, это просто программатор, причём дорогой (под $1000).

HZ> А чего такой дорогой? Вон под 430-й вообще на коленке собирается за HZ> копейки и все работает. И шьет, и отладка. А тут типа недорогой МК HZ> широкого применения и такие траблы!

Какие "траблы"? Мы приобрели оригинальный промышленный программатор и у меня нет никаких проблем, в том числе и чем шить только-только появившиеся кристаллы (кстати, новый программатор PM3 обойдётся подешевле потому, что у него ICSP встроенный). Творческие метания любителей шить "шнурком с парой резисторов" меня не задевают, я просто не знаком с существующими в этой области проблемами. Если же хочется сэкономить, то и Microchip и масса других производителей предлагают недорогие решения.

AG>> А внутрисхемная отладка это, видимо ICD 2, но я этой штукой никогда не AG>> пользовался.

HZ> Так есть у него (dsPIC'а) на борту эмулятор или нет?

Эмулятор для них есть нормальный ICE 4000, стоит около $2500. Processor Module ещё около $600. И каждый Device Adapter по $225 (комплекты ICE 2000 для PIC16/18 были немного подешевле: $1600/450/200). Внутрисхемный отладчик ICD 2 стоит $160...230 в зависимости от комплектации. Что там у них внутри: то ли аппаратная поддержка есть, то ли они просто монитор грузят внутрь я не знаю, но думаю, если не хочется тратиться на промышленный программатор и эмулятор, то ICD 2 может быть вполне сносным экономичным решением.

Привет!

Tue Aug 24 2004 17:45, Harry Zhurov wrote to Alexander Golov:

...

HZ>>>>> Тем не менее 16-разрядный MSP430 в этом вопросе делает их всех с HZ>>>>> таким отрывом, что об этом даже говорить не приходится!

AG>>>> С каким таким отрывом? Hасколько мне известно потребление самых AG>>>> "лёгких" MSP430 при 3 В это около 300 мкА при 1 MIPS

HZ>>> 240 мкА. При 2.2В - 160 мкА.

AG>> Масочные MSP430С? Сомневаюсь, что их параметры тут много кому интересны. AG>> Мне точно нет.

HZ> Hет, не масочные, флешовые.

Какие, например? В соответствии со всеми доками, что есть у меня, минимум для Flash -- 300 мкА.

...

HZ> А MSP430 это и не надо. У него другая идеология - богатая периферия, HZ> которая делает все, что возможно, а проц только настраивает ее. А на HZ> вычислениях, которые, обычно, 16 бит и больше, этим 8-биткам за ним не HZ> угнаться.

Я повторюсь: в задачах "под PIC16" вычисления вряд ли когда-нибудь потянут даже на 10% машинного времени, но и при этом весь твой максимальный выигрыш в энергоэффективности не превысит те же 10...15%. И это абстрактно от потерь на управление периферией и данными. Кстати, богатство периферийных возможностей одноклассников PIC16 из серий: MSP430F11x1, 11x2, 12x2, 41x, не оставляет неизгладимых впечатлений.

...

AG>> А PIC'ам, конечно, не доступны энергосберегающие режимы? Или у них там AG>> всё так негибко, что ничего микропотребляющего не сделать?

HZ> И что, они умеют одновременно с запуском АЦП на очередь из 16 HZ> измерений падать в глубокий слип, чтобы по окончании проснуться за 6 мкс?

Вот уж совершенно бестолковая фича. PIC16 реально на операцию преобразования (вместе с обслуживанием) нужно микросекунд 30. Это даст эквивалент добавочного потребления на секундном интервале -- 10 нА на одно преобразование. Т.е. для 1000 преобразований в секунду (что для микропотребляющего устройства совсем не типично) это добавит лишь 10 мкА.

HZ> Они умеют находиться в полном дауне, когда все выключено, кроме HZ> генератора на 32768 и UART'а, который принимает байты на 4800? HZ> Потребление при этом составляет единицы мкА. Общее потребление.

UART -- нет, синхронные интерфейсы, таймеры, capture и т.п. можно; потребление -- на том же уровне. Только вот не нужно мне рассказыать все эти рекламные сказки про потребление в единицы микроампер. Я сделал за последние годы немало микропотребляющих устройств и на практике знаю, что создать обслуживающую МК периферию (дискретные входы/выходы, усилители, высокоразрешающие АЦП и т.п.), работающую в зоне единиц микроампер совершенно нереально. Уже давно не потребление собственно PIC'а ограничивает микропотребляющие свойства прибора.

AG>>>> Hе слишком навороченные PIC18F

HZ>>> Hе слишком навороченные - это какие? Hа уровне младших MSP430?

AG>> Имелись ввиду PIC18F4320 (580 мкА), PIC18F4431 (670 мкА) и т.п. из AG>> свежих. Много (1...1,5 мА) потребляют PIC18 с шиной внешней памяти.

HZ> Hеадекватная оценка. Эти 580 мкА у него достигаются только при работе HZ> от внутреннего RC и, насколько я понял, больше он не может. MSP430 я могу HZ> от его RC запустить на 5 МГц, что есть его 5 16-разрядных МИПС. А тут HZ> чтобы достичь такой производительности, надо питание поднимать - 25 МГц - HZ> 6.25 МИПС - это уже 4.2 В и потребление 6.3 мА...

Мы начинаем ходить по кругу. Я понимаю, что тебе очень удобно сравнивать MSP с PIC16 по быстродействию и с dsPIC30F по потреблению, только любой нормальный разработчик будет применять в микропотребляющих устройствах PIC16, в смешаных и переходных PIC18 и в быстродействующих dsPIC30F, для того и создано это разнообразие.

Сравнивать АЦП, количество capture'ов и т.п. наверное интересно, но только не в рамках спора про потребление. Я возращаюсь к исходному постулату: "Тем не менее 16-разрядный MSP430 в этом вопросе делает их всех с таким отрывом, что об этом даже говорить не приходится!". Его несостоятельность, на мой взгляд, была показана со всей очевидностью: отрыв есть, в идеальном для MSP430 случае полуторакратный, при этом на реальных задачах встаёт масса "НО", вплоть до смены знака. И напомню с чего начался спор: мы сравниваем 3-вольтовый МК с

...

AG>> Кроме того для задач "под PIC16" я однозначно отдам им голос за больший AG>> вес MIPS'а.

HZ> Ты просто не знаешь как следует подход в случае с MSP430. Там,

Я по твоему читать не умею? Или аппноты для MSP430 написаны теми кто тоже не знает "как следует"?

HZ> повторяю, другая идеология - максимум риалтаймового махания ножками HZ> возложить на периферию,

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

HZ> ядру тактироваться от своего встроенного RC, HZ> падать в слип при первой же возможности, что очень хорошо согласовывается HZ> с тем, что ядро может просыпаться всего-лишь за 6 мкс.

У PIC16 ядро на RC-генераторе всю жизнь первом же цикле запускалось; в современных "Nanowatt" за 10 мкс. Что такого здесь особенного?

...

HZ> Реально быстро прыгать и дергать ножками программно там почти HZ> никогда не надо - с этим прекрасно справляется периферия (например, HZ> необходимо было формировать импульсы с частотой 10 кГц и длительностью 1 HZ> мкс для запуска лазера, причем длительность была жестко оговорена HZ> производителем лазера - 0.5 - 1.5 мкс. Джиттер фронта запуска импульса не HZ> должен был превышать 0.5 мкс - это уже по условиям задачи - там передача HZ> данных шла. Какой МК умеет формировать импульс?),

Любой с ШИМом. Впрочем с такими либеральными требованиями на PIC18 и программно не трудно сделать.

...

AG>>>> dsPIC30F потребляет в три раза больше "тяжёлых" MSP430 из расчёта на AG>>>> MIPS,

...

HZ> Вот я и говорю - в разы!

Ну так он и быстрее MSP430 в разы. А говорил ты это, кстати, по отношению к PIC'ам вообще, прежде всего PIC16/18.

...

AG>> А вот скажем на 5...8 MIPS'ах, где MSP430 нужно будет поднимать AG>> напряжение до 3,6 В, а dsPIC30F всё ещё можно снизить до 2,5 В (до 7,5 AG>> MIPS), боюсь, что разница в потреблении может и исчезнуть.

HZ> Hе бойсь, не исчезнет.

По голым MIPS'ам может быть и нет, по производительности к потреблению вне всякого сомнения.

HZ> Вряд ли они пересекутся в таких условиях.

Тогда зачем ты начал их между собой сравнивать? Или ты серьёзно считаешь, что они могут пересечься на задачах в 1 MIPS и никогда на 5...8 MIPS? Довольно смелое допущение, по-моему скорее наоборот.

...

AG>> У меня нет компиллятора для dsPIC30F, чтобы делать такие сравнения.

HZ> А как же ты с ним работаешь? Или собрался работать?.. У IAR'а вроде HZ> есть компилятор, можно скачать.

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

AG>> Да и реальность такова, что скажем после того как Hi-Tech перетряхнула AG>> библиотеки у меня та задачка с RTD для PIC18 работает быстрее чем ты AG>> приводил для MSP430.

HZ> Да? Вот интересно. А можно еще разок привести тот исходный текст и HZ> результаты для PIC18?

Вот код:

---------------------------------------------------------------------- // Объявление real как double сделано из-за особенностей компилятора // Hi-Tech у которого float 24-разрядный; подразумевается // использование 32-разрядного формата, т.е. обычно float

typedef double real ;

#define NumTerms 10

real Res [ NumTerms ] ; real Temp [ NumTerms ] ;

void CalcTerms ( real *, real *, char ) ; void CalcRTD ( real *, real * ) ;

void main () { char i = 0 ; do { Temp [ i ] = 100 ; Res [ i ] = i * 5.4321 + 80 ; } while ( ++ i < NumTerms ) ; CalcTerms ( Res, Temp, NumTerms ) ; }

void CalcTerms ( real * R, real * T, char N ) { char i = 0 ; do { CalcRTD ( R + i, T + i ) ; } while ( ++ i < N ) ; }

#define R0 100.0 #define A 3.850e-3 #define B -5.802e-07 #define C -4.2735e-12

void CalcRTD ( real * R, real * T ) { real x ; real t = * T ; x = A + B * ( t - 100 ) ; if ( t < 0 ) { x += C * t * t * ( t - 100 ) ; } * T = ( * R / R0 - 1 ) / x ; }

---------------------------------------------------------------------

Вот что я писал в качестве комментария (какая версия компилятора Hi-Tech была у меня на тот момент, я уже не помню):

--------------------------------------------------------------------- Обсчитываются новые значения с 10 термометров (текущие значения температуры в массиве Temp). Чтобы результаты были аутентичными, сначала в main() новые значения сопротивления термометров заносятся в массив Res, а начальные значения температуры в Temp. Вызов CalcTerms() выполняет одну операцию приближения над 10-ю термометрами. Собственно время однократного выполнения CalcTerms() нас и интересует.

Для PIC18 я получил следующие цифры: общий размер 1506 байтов, время работы 32 580 циклов...

---------------------------------------------------------------------

Для компилятора Hi-Tech PICC-18 v8.30 объём 2550 байтов, время 13 285 циклов.

HZ> Хотя тот тест в большей мере тест на качество HZ> библиотек, а не на сам чип.

Это я и имел ввиду. Впрочем, потребителю то всё равно. Одно дело 20-командный цикл или обработчик прерываний на асме написать предельно оптимально и совсем другое FP-библиотеки. Вряд ли много кто станет это делать.

HZ> Поэтому не трудно ли тебе будет прогнать не HZ> так давно приводившиеся VV тесты на целочисленку и плавучку? Где HZ> сравнивали как раз PIC и AVR.

Я тогда же результаты и отсылал. Сейчас скомпилировал "плавучку" для v8.30: объём -- 5820 байтов, время -- 978 178 циклов. Тест "целочисленки" измеряет погоду в Африке там одна строка выполняется 2/3 времени, поэтому смысла прогонять его не вижу.

...

...

AG>> Прямая адресация (в составе операций) ко всей памяти не нужна ни в одном AG>> процессоре, кроме самых мелких, вроде PIC16. Прямо адресовать нужно AG>> только статические данные, включая SFR'ы. Для 64-килобайтного AG>> пространства данных (как у dsPIC30F) 8 КБ прямой адресации это с AG>> большим запасом.

HZ> Ой, как ты любишь условия подгонять. То берешь какие-то маргинальные HZ> случаи, где в силу некой уникальной способности одного из PIC'ов (вроде HZ> мегабитного уарта) только он и рулит,

UART у всех PIC'ов практически одинаковый и ничего уникального в нём нет. Тот же AVR на 20 МГц может обмениваться на 2,5 Мбод, TMS430F2401 на 40 МГц тоже, у Cygnal'а, думаю тоже нет проблем, твой TMS320F2810 вообще 9,37 Мбод потянет. Не я виноват в том, что этого не умеют MSP430.

HZ> то обоснования вроде этого HZ> приводишь! Hужна или не нужна прямая адресация для всего адресного HZ> пространства - это отдельная тема. Ты не видишь в ней необходимости, но HZ> не надо утверждать, что это не надо.

Нормальное обоснование, за ним стоит опыт: я ежедневно работаю с МК имеющими прямую адресацию в качестве основной. На основании чего ты делаешь свои выводы мне трудно понять, когда получается, что ты работаешь либо с МК вообще не предоставляющими прямую адресацию в операциях (AVR, TMS320F280xx) или предоставляющим, но с крайне посредственным качеством (MSP430).

HZ> Кто знает, как сложится задача. Ведь HZ> и к агрегатным типам бывает эффективнее обращаться прямо, когда делается HZ> единственное обращение к одному члену и адрес известен статически.

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

...

AG>> Для 16-разрядных пересылок память-регистр во всём пространстве данных AG>> есть пара:

AG>> mov Wns,f AG>> mov f,Wnd

HZ> Т.е. в опкоде закодирован полный 16-битный адрес? И сколько циклов HZ> это занимает?

Естественно один.

AG>> Hо выше 8 КБ скорее всего будут лежать динамические или изначально AG>> косвенно адресуемые структуры данных, для работы с которыми, AG>> естественно, доступен комплект способов косвенной адресации.

HZ> Из 8К 2К отведено под SFR. Вроде 2К немало, но жизнь показывает, что HZ> наступает момент, когда байтов и герцев начинает не хватать. И dsPIC не HZ> 8-битка, он уже достаточно толст, и под будущие расширения может через HZ> некоторое время не хватать места. И будет геморрой.

Не будет. У того же PIC18 нет никакого геморроя, а там многократно меньшее пространство. Реально у самого толстого из существующих dsPIC30F всё управление ядром, прерываниями, портами, АЦП и другой периферией размещается в 768 адресах и при этом там море дырок (370 адресов). Ещё 310 адресов -- управление 2-мя модулями CAN. Чем можно задействовать неиспользованные 65% адресов я не могу даже абстрактно придумать, но не вижу препятствий, если уж это понадобится, расширить пространство до 3 К или больше, запас более чем достаточный.

HZ> Остальные 6К. Для какого-нибудь PIC'а или AVR'а это более, чем HZ> достаточно. HZ> Для младших dsPIC'ов, видимо, тоже. Hо ведь развитие на этом не HZ> останавливается. А если внешняя память? Как быть с ней?

В чём проблема то? Или ты и внешнюю память прямо адресуемыми переменными набить собрался? У тебя памяти команд не хватит, чтобы к небольшому подмножеству её обратиться с мало-мальски вразумительными операциями.

HZ> Короче, все эти ограничения - всегда палка о двух концах. И где HZ> вылезет второй конец, никто не знает. А он вылезет обязательно. Вон у HZ> AVR'ов с их IO Space он уже вылез. И dsPIC'а это не минует.

Совершенно не обязательно. Да и вообще говорить об ограничениях в данном случае бессмысленно. Предоставляемая dsPIC30F прямая адресация 8 К это дополнительное средство по отношению к любому из упоминавшися ранее МК.

...

HZ>>> Продемонстрируй, как ты собрался прямо обращаться по адресу, например, HZ>>> 0x4e20?

AG>> Зачем туда адресоваться прямо? Ты почему-то одновременно ратуешь за AG>> ненужность прямой адресации

HZ> Э, не надо переиначивать - я говорил про ее неэффективность из-за HZ> таскания полного адреса, который занимает львиную долю опкода.

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

AG>> и, раз уж она есть, за её вездесущность. К чему такой экстремизм? Ведь AG>> это не нужно с практической точки зрения.

HZ> Это не экстремизм. А границы применимости того или иного способа HZ> адресации в рамках того или иного объема - вещь очень субъективная.

Что здесь может быть субъективного? Берутся реальные программы соответствующего масштаба и просто оценивается реальный объём прямо адресуемых данных. Лично я наблюдаю многократный запас.

HZ> Сегодня они считают, что 13 бит - это достаточно, но ведь будет еще и HZ> завтра... Многие помнят, когда 640К на писюке (после 64К на спектруме) HZ> казались огромным объемом, который никогда не кончится.

Вообще не понятно к чему эти пассажи, адресное пространство данных у dsPIC30F не 8 К, а 64 К.

...

HZ> А разработчики AVR в 1994 году тоже считали, что они с "головой в HZ> руках", когда выделили это самое пресловутое пространство ввода-вывода.

Не вижу никаких причин делать из "заскоков" AVR выводы в отношении dsPIC30F.

...

AG>> объёма прямо адресуемого пространства обеспечивает выигрыш в AG>> производительности, прежде всего потому, что активное оперирование AG>> SFR'ами и анализ/модификация флагов весьма характерны для МК.

HZ> Это наверное так для микрочиповских поделий. Когда входишь в HZ> обработчик прерываний и начинаешь выяснять, а хто энто меня дернул. Для HZ> этого надо кучу флагов перебрать... Как вспомню... бррр...

Мы опять PIC16 обсуждаем? Сколько в реальности ты для него источников прерываний ожидаешь? Я порылся в десятке программ в самом тяжёлом случае это были 4 источника, т.е. 6 доп. циклов на все проверки. PIC18 уже имеет

HZ> Вот тут-то это самое пресловутое активное оперирование HZ> с анализом/модификацией флагов и нужно.

Быстрая работа с флагами и другими данными нужна любому МК и с прерываниями связана не более чем любой другой задачей.

HZ> А в том же MSP430 такой бред совсем не нужен.

"Размышления" MSP430 над запросом могут продлиться до 12 циклов (6 на завершение команды и 6 вход в обработчик), весьма вероятна необходимость сохранение контекста. PIC18 на высоком приоритете войдёт в обработчик за 3 цикла и за оставшиеся 9 циклов успеет проанализировать 4+1 источника прерываний. Логическое преимущество системы прерываний MSP430 физически весьма виртуально при сравнении с PIC18 (с dsPIC30F там и сравнивать особо нечего).

HZ> Там даже у HZ> периферийных узлов, где на один вектор зацеплено несколько источников HZ> (как, например, в Timer_B) анализ флагов не требуется, а выявление HZ> правильного источника с переходом соответствующий код обработки HZ> происходит путем арифметической операции (как по таблице).

У PIC18 и dsPIC30F прерывания от модуля CAN обрабатываются таким же образом, что в этом такого особенного?

HZ> Поэтому при HZ> разумно спроектированной архитектуре "ядро+периферия" интенсивное лазание HZ> по SFR совсем не так актуально, как ты пишешь...

Разумно спроектированной архитектуре не требуется по 4 цикла на простое обращение к переменной, от этого попахивает нафталином 70-х. И сколько тут не шлифуй периферию, сколько не навешивай на неё дополнительной функциональности результаты в лучшем случае -- приемлимые, а на фоне dsPIC30F -- провал.

HZ> Hе, долгое сидение на HZ> PIC'ах все-таки, по ходу, оказывает влияние на образ мыслей. :)

Давай мы раз и на всегда договоримся, что обсуждаем здесь dsPIC30F, а не чьи-либо образы мыслей.

...

AG>> Всегда 2 цикла сколько раз уже произносим. Требуется 30 нс (или сколько AG>> там) для выборкы команды из flash.

HZ> А если бы это была не флешь, а ОЗУ? Что - за один такт переходил бы?

Для МК с 4-тактовым циклом это не составляет труда.

...

AG>> Hапример, на безусловном переходе известен, но так как команда заранее AG>> не декодируется это ничего не меняет.

HZ> Это он тебе известен - ты можешь по листингу посмотреть. А проц, пока HZ> не считал команду, он не знает, где это. А когда перешел на новое место, HZ> ему нужно сначала считать. В случае же линейного кода считывание HZ> следующей инструкции производится одновременно с выполнением текущей. HZ> Причем тут медленность памяти, не пойму?

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

...

AG>> Могу только ещё раз повториться: лишь в ней и дело. Что там может быть AG>> не ясно с условными переходами? Выполнил переход, нужно выбрать команду AG>> по новому адресу, плюс цикл на время выборки, нет перехода выполняешь AG>> уже выбраную команду.

HZ> Да, поэтому у PIC16 условный переход 1/2 цикла. А причем тут скорость HZ> памяти?

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

...

...

AG>> Hа вкус по последовательному -- все узлы на разных платах. Собственно я AG>> так и собираюсь (не обязательно с PLD), dsPIC30F тоже необходимую AG>> скорость обмена не обеспечивает, даже меньше PIC18. Просто тут мы AG>> говорили про PIC18F2331 у которого прекрасно подходящий для 200 KSPS AG>> UART на 2,5 Мбод имеется внутри.

HZ> А электрический интерфейс какой?

Никакой: оптика у нас, на базе IrDA трансивера.

...

HZ>>> А MSP430 в этом случае будет получать прерывание каждые 16*5*8 = HZ>>> 640 циклов.

AG>> А смысл? Уже 100 циклов вполне комфортно (во всяком случае для PIC18), а AG>> 200 -- расслабленное состояние. Слишком большой буфер скорее помешает -- AG>> обработчик будет "подвисать" на время пересылки и вычисления дельт для AG>> 16 отсчётов.

HZ> Что-то не пойму, про какие дельты ты толкуешь?

Чтобы по скорости обмена пройти, нужно либо свести данные к байту, вычисляя дельты между предыдущим и текущим отсчётами, либо перепаковывать каждые четыре 10-разрядных отсчёта в 5 байтов. Я выбрал первое, как более экономичное по потоку и по затратам машинного времени, тем более что дельты на реальном сигнале никогда не превышают +-127.

HZ> Я же ясно сказал - пересылкой занимается DMA.

Тогда причём тут прерывания каждые 640 циклов, если данные идут сами? Вычислять дельты в обработчике выгодно -- нужно вдвое меньше памяти под буферы, но, конечно, не обязательно.

HZ> А у проца время пойдет на вычисление этих HZ> твоих сумм и на спячку, чтобы потребление экономить.

Спать ему некогда будет.

...

AG>> Уж такой выигрыш! Вот цикл отправки части данных фрейма для PIC18.

HZ> Я не про отправку говорил, а про формирование контрольной суммы HZ> (читай внимательнее). А отправка вообще без участия ядра делается.

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

...

HZ> Контрольная сумма по XOR:

HZ> MOV.W #0x0, R15 HZ> JMP checksum_2 HZ> checksum_1: XOR.W @R12+, R15 2 HZ> checksum_2: ADD.B #0xff, R14 2 HZ> CMP.B #0x0, R14 2 HZ> JGE checksum_1 2 HZ> MOV.W R15, R12 HZ> RET

HZ> Сам цикл занимает 6 машинных циклов. Вызов функции

Может я чего-то не понимаю, но по-моему 8 циклов. Только кривая это программа, через DEC было бы 5 циклов.

...

HZ> занимает 112 циклов. Это для вычисления контрольной суммы для массива HZ> из 16 отсчетов - 32 байт. За сколько времени сделает вычисление HZ> контрольной суммы массива из 32 байт PIC18?

Я же тебе полный код приводил, выкинь отправку в UART, останется только сумма, 7 циклов. Только зачем что-то выкидывать?

...

AG>> Hасчёт небольшого проигрыша не понятно. По 3,3 В потребление будет около AG>> 50 мА, т.е. от батареи (при 2,8 В и КПД 90%) будет около 65 мА. По 1,8 AG>> В потребление, скажем 150 мА, тогда от батареи будет 107 мА. Итого 170 AG>> мА от батареи только МК. У нас сейчас весь прибор вдвое меньше AG>> потребляет и даже это, надо заметить, совсем немало.

HZ> Я по энергии сравнивал - мы уже как-то это вычисляли. Получалось HZ> где-то раза в полтора.

Вот я тебе выше вычислил во сколько: не в 1,5 и даже не в 3. Что тебе не нравится? КПД преобразователей? Вряд ли получится больше, зато я уверен что при 200 с лишним милиампер на батарейке и 2,8 В уже не обнаружить.

HZ> И потом, эта штука даст новое качество - ваш вдвое HZ> меньше потребляющий прибор и результаты выдает более скромные. Осмелюсь HZ> предположить, результаты значительно более, чем в два раза, скромные.

Наш прибор потребляет вдвое меньше чем один только твой МК, в целом разница будет раза в три. И я тебе сразу сказал, что энергопотребление существенно повышать нельзя. Ну 50...60 мВт к 50 мВт PIC18, добавить можно, но не больше, или предложи источник питания в габаритах CR-123 способный обеспечить работу твоего МК не менее 2 часов в активном режиме и 2 месяцев в ожидании (-20...+70 С).

...

HZ> Траблы в том, что цена его плохо сочетается с прицелом на широкое HZ> применение недорогого МК.

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

...

HZ> Причем тут творческие метания? Тот же TMS320F28xx может как шиться с HZ> помощью эмулятора (кстати, $800), так и с помощью двух проводов через HZ> ком-порт писюка. У себя на столе мне удобнее работать с эмулятором, но в HZ> производстве это дорогое и излишнее решение - там два провода рулят.

Довольно странное утверждение. К этим двум проводам ещё компьютер подцеплен, а для промышленной зашивки PIC'ов ничего кроме самого PRO MATE или PM3 не нужно. Впрочем, не пойму, что ты споришь сам с собой -- нужен "шнурок", бери ICD 2. Да и других "компиков" понаделано было не мало, у кого есть потребности и желание -- разберётся.

AG>>>> А внутрисхемная отладка это, видимо ICD 2, но я этой штукой никогда не AG>>>> пользовался.

HZ>>> Так есть у него (dsPIC'а) на борту эмулятор или нет?

...

AG>> Эмулятор для них есть нормальный ICE 4000, стоит около $2500. Processor AG>> Module ещё около $600. И каждый Device Adapter по $225 (комплекты ICE AG>> 2000 для PIC16/18 были немного подешевле: $1600/450/200).

HZ> Мда... даже для настоящих DSP такие вещи стоят дешевле... очень HZ> сбалансированный подход у Микрочипа.

Понится году эдак в 99-м, TI за эмулятор к MSP430P337 под $10 000 запросила. Комплект для PIC18C252 который поставила Гамма за $2500 (включая компилятор Hi-Tech) мне на этом фоне показался копеечным.

AG>> Внутрисхемный отладчик ICD 2 стоит $160...230 в зависимости от AG>> комплектации. Что там у них внутри: то ли аппаратная поддержка есть, то AG>> ли они просто монитор грузят внутрь я не знаю,

HZ> А что, в доке это прямо не сказано?

В доке на ICD 2? Я её и не видел за ненадобностью. В обзоре сказано, что он обеспечивает прошивку, точки останова, пошаговое исполнение. Какая разница как там всё это реализовано, фичей нормальных эмуляторов (tracing memory, аппаратные сигналы остановки, мониторинг данных в real-time и т.п.) всё равно ни в каком случае не будет.

Sun, 29 Aug 2004 00:03:22 +0600 Alexander Golov wrote to Harry Zhurov:

HZ>> äÁ? ÷ÏÔ ÉÎÔÅÒÅÓÎÏ. á ÍÏÖÎÏ ÅÝÅ ÒÁÚÏË ÐÒÉ×ÅÓÔÉ ÔÏÔ ÉÓÈÏÄÎÙÊ ÔÅËÓÔ É HZ>> ÒÅÚÕÌØÔÁÔÙ ÄÌÑ PIC18?

AG> ÷ÏÔ ËÏÄ:

AG> ---------------------------------------------------------------------- AG> // ïÂßÑ×ÌÅÎÉÅ real ËÁË double ÓÄÅÌÁÎÏ ÉÚ-ÚÁ ÏÓÏÂÅÎÎÏÓÔÅÊ ËÏÍÐÉÌÑÔÏÒÁ AG> // Hi-Tech Õ ËÏÔÏÒÏÇÏ float 24-ÒÁÚÒÑÄÎÙÊ; ÐÏÄÒÁÚÕÍÅ×ÁÅÔÓÑ AG> // ÉÓÐÏÌØÚÏ×ÁÎÉÅ 32-ÒÁÚÒÑÄÎÏÇÏ ÆÏÒÍÁÔÁ, Ô.Å. ÏÂÙÞÎÏ float

AG> typedef double real ;

AG> #define NumTerms 10

AG> real Res [ NumTerms ] ; AG> real Temp [ NumTerms ] ;

AG> void CalcTerms ( real *, real *, char ) ; AG> void CalcRTD ( real *, real * ) ;

AG> void main () AG> { AG> char i = 0 ; AG> do AG> { AG> Temp [ i ] = 100 ; AG> Res [ i ] = i * 5.4321 + 80 ; AG> } AG> while ( ++ i < NumTerms ) ; AG> CalcTerms ( Res, Temp, NumTerms ) ; AG> }

AG> void CalcTerms ( real * R, real * T, char N ) AG> { AG> char i = 0 ; AG> do AG> { AG> CalcRTD ( R + i, T + i ) ; AG> } AG> while ( ++ i < N ) ; AG> }

AG> #define R0 100.0 AG> #define A 3.850e-3 AG> #define B -5.802e-07 AG> #define C -4.2735e-12

AG> void CalcRTD ( real * R, real * T ) AG> { AG> real x ; AG> real t = * T ; AG> x = A + B * ( t - 100 ) ; AG> if ( t < 0 ) AG> { AG> x += C * t * t * ( t - 100 ) ; AG> } AG> * T = ( * R / R0 - 1 ) / x ; AG> } AG> ---------------------------------------------------------------------

AG> ÷ÏÔ ÞÔÏ Ñ ÐÉÓÁÌ × ËÁÞÅÓÔ×Å ËÏÍÍÅÎÔÁÒÉÑ (ËÁËÁÑ ×ÅÒÓÉÑ ËÏÍÐÉÌÑÔÏÒÁ Hi-Tech AG> ÂÙÌÁ Õ ÍÅÎÑ ÎÁ ÔÏÔ ÍÏÍÅÎÔ, Ñ ÕÖÅ ÎÅ ÐÏÍÎÀ):

AG> --------------------------------------------------------------------- AG> ïÂÓÞÉÔÙ×ÁÀÔÓÑ ÎÏ×ÙÅ ÚÎÁÞÅÎÉÑ Ó 10 ÔÅÒÍÏÍÅÔÒÏ× (ÔÅËÕÝÉÅ ÚÎÁÞÅÎÉÑ ÔÅÍÐÅÒÁÔÕÒÙ AG> × ÍÁÓÓÉ×Å Temp). þÔÏÂÙ ÒÅÚÕÌØÔÁÔÙ ÂÙÌÉ ÁÕÔÅÎÔÉÞÎÙÍÉ, ÓÎÁÞÁÌÁ × main() ÎÏ×ÙÅ AG> ÚÎÁÞÅÎÉÑ ÓÏÐÒÏÔÉ×ÌÅÎÉÑ ÔÅÒÍÏÍÅÔÒÏ× ÚÁÎÏÓÑÔÓÑ × ÍÁÓÓÉ× Res, Á ÎÁÞÁÌØÎÙÅ AG> ÚÎÁÞÅÎÉÑ ÔÅÍÐÅÒÁÔÕÒÙ × Temp. ÷ÙÚÏ× CalcTerms() ×ÙÐÏÌÎÑÅÔ ÏÄÎÕ ÏÐÅÒÁÃÉÀ AG> ÐÒÉÂÌÉÖÅÎÉÑ ÎÁÄ 10-À ÔÅÒÍÏÍÅÔÒÁÍÉ. óÏÂÓÔ×ÅÎÎÏ ×ÒÅÍÑ ÏÄÎÏËÒÁÔÎÏÇÏ ×ÙÐÏÌÎÅÎÉÑ AG> CalcTerms() ÎÁÓ É ÉÎÔÅÒÅÓÕÅÔ.

AG> äÌÑ PIC18 Ñ ÐÏÌÕÞÉÌ ÓÌÅÄÕÀÝÉÅ ÃÉÆÒÙ: ÏÂÝÉÊ ÒÁÚÍÅÒ 1506 ÂÁÊÔÏ×, ×ÒÅÍÑ AG> ÒÁÂÏÔÙ 32 580 ÃÉËÌÏ×... AG> ---------------------------------------------------------------------

AG> äÌÑ ËÏÍÐÉÌÑÔÏÒÁ Hi-Tech PICC-18 v8.30 ÏÂߣÍ 2550 ÂÁÊÔÏ×, ×ÒÅÍÑ 13 285 AG> ÃÉËÌÏ×.

HZ>> èÏÔÑ ÔÏÔ ÔÅÓÔ × ÂÏÌØÛÅÊ ÍÅÒÅ ÔÅÓÔ ÎÁ ËÁÞÅÓÔ×Ï HZ>> ÂÉÂÌÉÏÔÅË, Á ÎÅ ÎÁ ÓÁÍ ÞÉÐ.

AG> üÔÏ Ñ É ÉÍÅÌ ××ÉÄÕ. ÷ÐÒÏÞÅÍ, ÐÏÔÒÅÂÉÔÅÌÀ ÔÏ ×ӣ ÒÁ×ÎÏ. ïÄÎÏ ÄÅÌÏ AG> 20-ËÏÍÁÎÄÎÙÊ ÃÉËÌ ÉÌÉ ÏÂÒÁÂÏÔÞÉË ÐÒÅÒÙ×ÁÎÉÊ ÎÁ ÁÓÍÅ ÎÁÐÉÓÁÔØ ÐÒÅÄÅÌØÎÏ AG> ÏÐÔÉÍÁÌØÎÏ É ÓÏ×ÓÅÍ ÄÒÕÇÏÅ FP-ÂÉÂÌÉÏÔÅËÉ. ÷ÒÑÄ ÌÉ ÍÎÏÇÏ ËÔÏ ÓÔÁÎÅÔ ÜÔÏ AG> ÄÅÌÁÔØ.

HZ>> ðÏÜÔÏÍÕ ÎÅ ÔÒÕÄÎÏ ÌÉ ÔÅÂÅ ÂÕÄÅÔ ÐÒÏÇÎÁÔØ ÎÅ HZ>> ÔÁË ÄÁ×ÎÏ ÐÒÉ×ÏÄÉ×ÛÉÅÓÑ VV ÔÅÓÔÙ ÎÁ ÃÅÌÏÞÉÓÌÅÎËÕ É ÐÌÁ×ÕÞËÕ? çÄÅ HZ>> ÓÒÁ×ÎÉ×ÁÌÉ ËÁË ÒÁÚ PIC É AVR.

AG> ñ ÔÏÇÄÁ ÖÅ ÒÅÚÕÌØÔÁÔÙ É ÏÔÓÙÌÁÌ. óÅÊÞÁÓ ÓËÏÍÐÉÌÉÒÏ×ÁÌ "ÐÌÁ×ÕÞËÕ" ÄÌÑ v8.30: AG> ÏÂߣÍ -- 5820 ÂÁÊÔÏ×, ×ÒÅÍÑ -- 978 178 ÃÉËÌÏ×.

AG> ôÅÓÔ "ÃÅÌÏÞÉÓÌÅÎËÉ" ÉÚÍÅÒÑÅÔ ÐÏÇÏÄÕ × áÆÒÉËÅ ÔÁÍ ÏÄÎÁ ÓÔÒÏËÁ ×ÙÐÏÌÎÑÅÔÓÑ AG> 2/3 ×ÒÅÍÅÎÉ, ÐÏÜÔÏÍÕ ÓÍÙÓÌÁ ÐÒÏÇÏÎÑÔØ ÅÇÏ ÎÅ ×ÉÖÕ.

Привет!

Tue Aug 31 2004 14:37, Harry Zhurov wrote to Alexander Golov:

...

AG>> Я повторюсь: в задачах "под PIC16" вычисления вряд ли когда-нибудь AG>> потянут даже на 10% машинного времени, но и при этом весь твой AG>> максимальный выигрыш в энергоэффективности не превысит те же 10...15%.

HZ> Что ты понимаешь под вычислениями? Обсчет полиномов в плавучке?

Арифметические и алгебраические преобразования данных.

...

AG>> И это абстрактно от потерь на управление периферией и данными. Кстати, AG>> богатство периферийных возможностей одноклассников PIC16 из серий: AG>> MSP430F11x1, 11x2, 12x2, 41x, не оставляет неизгладимых впечатлений.

HZ> Hу, так есть F14x. Честно говоря, я не очень понимаю необходимости в HZ> такой мелочи с 16-битным ядром.

С чего и начали: ненужная 16-разрядность, неторопливое ядро и отсутствие жизненно необходимой ему периферийной поддержки, вот как он выглядит на фоне задач класса PIC16.

HZ> Hикогда ею не интересовался и не HZ> использовал. Мой основной камень - F149, сейчас уже F169.

Это не однокласники PIC16.

...

HZ>>> И что, они умеют одновременно с запуском АЦП на очередь из 16 HZ>>> измерений падать в глубокий слип...

AG>> Вот уж совершенно бестолковая фича...

HZ> Для PIC16 может и бестолковая - тебе видней. А по мне так очень она HZ> кстати в MSP430. Я не очень понял, как ты тут что посчитал, но реальное HZ> потребление выходит из соотношения активного времени CPU к неактивному.

Это соотношение я и рассчитал: при 33 мкс на обслуживание АЦП получается соотношение 1/30 000 на один отсчёт в секунду, а для 1000 отсчётов в секунду

HZ> Здесь в значительной мере все определяется прикладной задачей. Hо то, что HZ> не нужно на каждое преобразование прыгать на обработку прерываний, а HZ> можно это сделать сразу не 16 - несомненный плюс.

Это плюс для скоростных задач (и PIC'и со скоростным АЦП имеют буфер), но мы говорим о микропотреблении, а для этих целей данная фича не имеет смысла.

...

HZ> И еще - АЦП в MSP430 12-разрядный, когда ядро спит, шумов HZ> меньше весьма. Т.ч. для пиков с их убогим АЦП такая фича возможно и HZ> бестолкова, но в MSP430 она очень нелишняя.

Эта фича (сон во время преобразования для снижения шумов) был ещё у античного PIC16C73, естественно есть и у всех современных. PIC'и с 12-разрядным АЦП тоже давно есть. Среди dsPIC30F опять же.

...

AG>> UART -- нет,

HZ> А это главное. Hа таких скоростях/потреблениях не синхронный HZ> интерфейс нужен (который, обычно, быстрый), неторопливый UART. Просто HZ> разработчики MSP430 подумали над этим и сделали специально в Baud Rate HZ> генераторе UART'а модулятор, позволяющий иметь широкую сетку скоростей HZ> даже при очень низкой тактовой. Это усиливает позиции 430-х как HZ> микропотребляющих МК.

Ничего это не меняет. Я ещё для PIC16C62 делал подобный интерфейс а-ля UART с помощью capture/compare, работающего во сне. На современных PIC'ах можно сделать ещё проще -- затактовать UART вместе с ядром от кварца 32 768 кГц, 15 мкА не бог весть какое потребление.

HZ> О чем я и говорил - не только возможность падать в HZ> слип, но и периферия по максимуму заточена под микропотребление. Сюда же HZ> относится поддержка мультипроцессорного обмена через UART, когда HZ> аппаратно распознается первый символ в пакете (двумя способами - по HZ> специальному адресному биту или по преамбуле - паузе перед ним).

В UART'е современных PIC'ов также есть маркер на 9-м бите и сравнение с адресным словом (на мой взгляд тоже бесполезные фишки). А вот связывать между собой МК вполне комфортно по синхронному интерфейсу, да ещё и быстро (у меня в одном микропотребляющем приборе так связаны платы вычислителя и терминала).

AG>> синхронные интерфейсы, таймеры, capture и т.п. можно; потребление -- на AG>> том же уровне.

HZ> Это умеют все, ничего особенного.

Естественно, я тебе сразу об этом и сказал. Во всех "фишках" о которых ты рассказываешь нет ничего особенного, всё давно освоено (в основном ещё до появления на свет MSP430).

...

HZ> А чего ты сторону полез? Что там снаружи - это уже следующий вопрос. HZ> Мы сами фичи МК обсуждаем и тут MSP430 имеет несомненный приоритет!

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

HZ> А внешняя обвязка от задачи зависит. Вполне может статься, что один МК HZ> передает данные по UART'у другому такому же МК, стоящему на этой же HZ> плате. И на фиг тут обвязка? Да мало ли какие могут быть задачи!

Как раз для этого куда удобнее не UART, а SPI.

...

HZ> А другой нормальный разработчик будет применять во всех этих задачах HZ> (конечно в рамках достижимого - уж первые две точно в рамках достижимого) HZ> MSP430, т.к. он покрывает потребности.

Очевидно, что не покрывает. Альтернатива PIC16 из MSP430 очень слабая -- плохо подходящее ядро не способно компенсировать недостатки периферии лёгких МК и вообще экономить, делая многие функции программно. Как альтернатива dsPIC30F -- вообще не видно. Реальная конкуренция -- между MSP430/PIC18 и вовсе не с однозначным ответом, как ты пытался это сразу представить.

...

HZ> Ок, давай конкретно!? Вот основной режим работы MSP430 - это HZ> тактирование ядра от RC осциллятора... Hа 3.3 В можно получить, не HZ> выходя за рамки спецификаций, порядка 7.37 МИПС... HZ> Теперь скажи, какой из PIC'ов (16-х или 18-х) может HZ> выдавать такую производительность при адекватном потреблении?

...

Мы обсуждаем dsPIC30F, а выбирать я должен быстродействующий МК из PIC16/18?

HZ> Очень интересуют условия (напр. питания) и ситуации, где имеет HZ> место смена знака!? Hе сочти за труд?!

Этот хоровод уже порядком надоел. Уже неоднократно сказано: dsPIC30F многократно быстрее MSP430 и на 5 В и на 3,3 и на 2,5 В, и потреблять при равной производительности будет меньше. PIC16 на задачах в своём классе тоже может быть экономичнее.

...

HZ> Вообще-то, я этого не имел в виду, не говорил, не намекал и даже не HZ> думал (хотя теперь уже начинаю сомневаться - об этом ниже). Я имел в виду HZ> то, что одного прочтения тут недостаточно. Лично мне для достаточного HZ> понимания необходимо было реально поработать с микрухами, сделать HZ> реальные проекты, чтобы прочувствовать. Из прочтения даташитов и аппликух HZ> идеология эта мне была совсем не очевидна. Хотя ты может вундеркинд, HZ> сразу все насквозь видишь?

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

...

AG>> Мне "махать ножками",

HZ> Программно махать ножками? Для каких целей?

Для управления внешней периферией.

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

HZ> Использовать CPU для _риалтаймового_ махания ножками - может это в HZ> рамках идеологии PIC (не даром же Scenix из него вырос), но не в рамкх HZ> идеологии нормальных процессоров. Процессор - он для процессов.

А я не процессоры обсуждаю, а МК.

AG>> Если бы можно было это делать периферией, вряд ли бы понадобился МК.

HZ> Периферией надо рулить. МК - это процессор + периферия.

"Размахивание ножками", "руление периферией", работа со статическими флажками и данными это одни и те же операции. Разделение на "ножки" и всё остальное, совершенно излишне.

HZ> И риалтаймовая (не вычислительная) мощь любого МК в бОльшей HZ> степени определяется возможностями периферии.

Только если ядро очень слабое.

...

HZ>>> Какой МК умеет формировать импульс?

AG>> Любой с ШИМом.

HZ> А-а, забыл сказать - импульсы эти не сами по себе, они служат для HZ> модуляции при передачи данных. Т.е. данные закодированы во временных HZ> интервалах между импульсами. Передается пакет, состоящий из различных HZ> временных интервалов.

...

И что изменилось? Модуль ШИМ PIC18 обеспечивает формирование импульсов и пауз необходимой длины, хотя при длительности импульсов 0,5...1,5 мкс их не сложно сформировать программно, а собственно прерывание по Compare.

AG>> Впрочем с такими либеральными требованиями на PIC18 и программно не AG>> трудно сделать.

HZ> Пупок у него развяжется программно. Там помимо формирования этого HZ> сигнала еще Манчестер2 формируется для передачи по радиоканалу с примерно HZ> такими же требованиями (тоже по таблице кодирование). Кому приоритет HZ> отдадим?

Тревиальная задача для PIC18 на 1 MIPS. У Манчестера скважность мягко говоря немного поменьше и он прекрасно может быть отработан Compare с прерыванием с низким приоритетом.

...

...

HZ> Ок! Давай с цифрами.

HZ> MSP430F149, 420 uA@3V/1 МИПС. 5 МИПС - 2100 uA. HZ> MSP430F169, 500 uA@3V/1 МИПС. 5 МИПС - 2500 uA. HZ> dsPIC, 4 mA @3.3V/1 МИПС. (DC20a) HZ> dsPIC, 13 mA @3.3V/4 МИПС. (DC23a) HZ> Итого, по МИПСам 5 на MSP430 против 4 на dsPIC - от 13/2.1 = 6.2 до HZ> 13/2.5 = 5.2 раза.

Всё фантазируешь... В очередной раз: правильные значения для dsPIC30F4012:

HZ> Hасколько dsPIC'овый МИПС эффективнее MSP430'шного, это надо HZ> еще посмотреть. Hа реальных задачах. Хотя бы на тех же вычислениях.

Вот твоя вроде бы реальная задача вычисления контрольной суммы будет выполняться в 5 раз быстрее. Писать и отлаживать функции FP-операций, раньше чем они мне реально понадобятся я, естественно, не стану, а готовых аппнот нет.

...

AG>> UART у всех PIC'ов практически одинаковый и ничего уникального в нём AG>> нет. Тот же AVR на 20 МГц может обмениваться на 2,5 Мбод, TMS430F2401 AG>> на 40 МГц тоже, у Cygnal'а, думаю тоже нет проблем, твой TMS320F2810 AG>> вообще 9,37 Мбод потянет.

HZ> Ага, за счет высокой тактовой, главным образом. И платят за это HZ> потреблением. Сомнительной правильности, надо сказать, шаг.

Нет, скорость 115 кбод на 1 MIPS вполне тревиальна, если очень нужно можно выжать и 230 кбод.

AG>> Hе я виноват в том, что этого не умеют MSP430.

HZ> Потому, что на практике это на фиг не надо. Ты первый на моей памяти, HZ> кому понадобилось 2.5 МБода от UART'а. Если уж такая экзотическая задача HZ> и возникнет, то решить ее не составит большого труда с помощью средств, HZ> которые более для этого подходят - ПЛИС.

Вот уж что точно нафиг не нужно так это ставить какие-то PLD в задачу прекрасно решаемую на одном универсальном МК.

...

HZ> Hа PIC'ах эта адресация точно такая же прямая как и на TMS320F28xx.

Нет. Даже абсолютно 64 слова TMS320F28xx не равны 256 + 256 байтам PIC18. Реально же у PIC18 прямо адресуются все SFR'ы (кроме буферов CAN, где они есть) и ещё есть память для статических переменных.

HZ> А на dsPIC достаточно приличное (на текущий момент) количество HZ> прямоадресуемой памяти исключительно из-за того, что опкод у него HZ> слоновий. За него ты платишь потреблением и ценой! Т.ч. тут тоже шило на HZ> мыло поменяли.

Потреблением -- нет, ценой тоже не особенно: Flash не SRAM -- места занимает мало, стоит дёшево. Впрочем на фоне MSP430 которому на каждый чих то 2, а то и 3 слова на команду подавай эти 1,5 слова даже компромиссом не выглядят.

AG>> Hа основании чего ты делаешь свои выводы мне трудно понять,

HZ> Чтобы понять, не лишне вспомнить, что свет клином на PIC'ах не HZ> сошелся, что есть еще и другие процессоры, другие архитектуры. Hапример, HZ> фон Hеймановская, где одно адресное пространство и для данных, и для HZ> кода. Hапример, все тот же MSP430. И ему реально нужно все адресное HZ> пространство, т.к. во флеши его очень даже замечательно располагаются и HZ> данные, которые только для чтения. Поэтому 13 бит прямого адреса тут HZ> пролетают.

Что это за данные ты собрался адресовать в программной памяти прямо и почему их нельзя загрузить в составе второго слова команды "MOV #"?

AG>> когда получается, что ты работаешь либо с МК вообще не предоставляющими AG>> прямую адресацию в операциях (AVR, TMS320F280xx)

HZ> С чего ты взял, что там ее нет?

А что, вдруг появилась? Позавчера? Вчера?

AG>> или предоставляющим, но с крайне посредственным качеством (MSP430).

HZ> И в чем посредственность?

add &EDE,Rm 2 слова 3 цикла, обратно вообще 4

Эмуляция на dsPIC30F через косвенную:

mov #lit16,W1 2 слова 2 цикла в любую сторону add Wb,[W1],Wd

...

HZ> А что, не может быть структуры/класса, у которого есть пара-тройка HZ> членов обычных типов и массив? Массив место занимает. И таких структур HZ> несколько. К обычным членам при статически известном адресе (а для HZ> глобальных/статических объектов он известен) можно и прямо обратиться...

Если обращение к таким элементам за 2 цикла (и слова) вместо одного критично, грамотный программист просто не станет их объединять, если нет, то и проблемы нет. Это неравноценно выбору для SFR'ов, флагов и т.п.

...

AG>> Hе будет. У того же PIC18 нет никакого геморроя, а там многократно AG>> меньшее пространство. Реально у самого толстого из существующих AG>> dsPIC30F всё управление ядром, прерываниями, портами, АЦП и другой AG>> периферией размещается в 768 адресах и при этом там море дырок...

...

HZ> Поживем, посмотрим. Это для самого мелкого dsPIC'а, который ты юзать HZ> собрался, запас большой. Hо семейство это не им одним ограничено, HZ> потребности постоянно растут. Тот же один модуль CAN жрет полтораста HZ> адресов. А мало ли чего еще может понадобиться. Гадать не будем, время HZ> покажет.

Я приводил цифры для самых толстых: dsPIC30F6010/6014. Аналогов модулям CAN по прожорливости адресов нет, а их там уже 2, причём как раз их буферы вовсе не обязательно размещать в прямо адресуемой памяти (также как и любые другие вновь вводимые большие периферийные буферы).

...

HZ> Кстати, пользуясь случаем, хочу уточнить. Разглядывая табличку с HZ> Instruction Set, увидел, что эта самая прямая адресация кроме команд HZ> пересылки может работать только с одним единственным регистром W0. Это HZ> так?

Там это сделано также как и в любом другом PIC'е. Это не преподносит никаких проблем, т.к. трёхадресные операции всегда позволяют поместить результат в том числе и в W0 (он же WREG).

...

AG>> В чём проблема то? Или ты и внешнюю память прямо адресуемыми переменными AG>> набить собрался?

HZ> А почему нет? Почему я не могу хранить во внешней ПЗУхе какие-то HZ> данные по известным мне адресам? По-моему, обычное дело.

Потому что во всех смыслах экономнее хранить их непосредственно в коде команды. Если же об экономии речь не идёт, то и о проблемах адресации в этом контексте говорить нечего.

...

AG>> Да и вообще говорить об ограничениях в данном AG>> случае бессмысленно. Предоставляемая dsPIC30F прямая адресация 8 К это AG>> дополнительное средство по отношению к любому из упоминавшися ранее МК.

HZ> За это "дополнительное" средство заплачена цена! И не малая!! Когда HZ> самый разнесчастный nop тащит полноценные 24 бита!

Нет, как раз прямая адресация сделана по остаточному принципу. Длинный опкод нужен прежде всего для кодирования 2 и 3 адресных операций и хранения многоразрядных констант (адресов, смещений переходов и т.п.) в составе одного командного слова.

...

AG>> Быстрая работа с флагами и другими данными нужна любому МК

HZ> Пока что я вижу, что "медленный" MSP430 делает "быстрый" PIC18 при HZ> работе с данными.

А я вот помню, что даже несложную пересылку в UART он делал более чем 1,5 раза дольше.

AG>> и с прерываниями связана не более чем любой другой задачей.

HZ> Более! В прерываниях надо шевелиться как можно быстрее, чтобы не HZ> мешать другим прерываниям. И двухуровневая система прерываний тут не HZ> очень спасает. 4 уровня - еще куда ни шло. А 2 - это мало. Ради этого и HZ> огород городить, имхо, не стОило.

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

...

AG>> "Размышления" MSP430 над запросом могут продлиться до 12 циклов (6 на AG>> завершение команды и 6 вход в обработчик), весьма вероятна необходимость AG>> сохранение контекста.

HZ> Могут продлиться, а могут и нет. В среднем 3-4 цикла. 6 циклов на HZ> вход в ISR включают в себя и сохранение статусного регистра.

А рассчитывать приходится на все 12, а при фоновой работе DMA ещё плюс 4...5 циклов, а при засыпании ядра ещё плюс 6 мкс, а при использовании DMA для блочных пересылок латентность может увеличиться до огромных величин.

...

AG>> Логическое преимущество системы прерываний MSP430 физически весьма AG>> виртуально при сравнении с PIC18

HZ> Преимущество прежде всего в том, что не надо геморроиться с HZ> определением источника: возникло прерывание - попали в обработчик. Все. HZ> Hикакого лишнего кода и, как следствие, никаких ошибок.

Написать в обработчике дополнительный if или else if ничем не геморройнее чем оформить дополнительный обработчик и ошибиться ничем не легче:

void interrupt IntFunc () { if ( CCP2IF ) { CCP2IF = 0 ; PulseCount ++ ; }

else if ( INT0IF ) { INT0IF = 0 ; Time_Cnt ++ ; New_Time_Fl = Yes ; New_Second_Fl = Yes ; New_Corr_Oper_Fl = Yes ; }

else if ( RCIF ) { Comm_Buf [ Comm_Recv_Ptr ++ ] = RCREG ; if ( Comm_Recv_Ptr == Comm_Decd_Ptr ) Comm_Recv_Ptr -- ; } }

Причём код, вполне возможно и меньше будет -- сохранение контекста общее.

AG>> (с dsPIC30F там и сравнивать особо нечего).

HZ> Я вот еще не пойму, зачем эти чемпионские показания по latency?

Если тебя не интересует латентность, тогда к чему эти слёзы по поводу анализа флагов в общем обработчике прерываний?

HZ> С прерываниями главное, чтобы успеть (с запасом некоторым) обработать HZ> запрос - байт там из уарта выгрести, пока следующий не прилетел или HZ> значение CCR обновить до следующего совпадения. И какая разница, 4 цикла HZ> там или 10?!

Периферия бывает и внешняя и она вовсе не собирается работать по этим красивым правилам: что-то там буферировать, чего-то дожидаться, подключаться к DMA. В таких случая разница в латентности 3 или 12 циклов равнозначна

...

...

HZ> Hе, я понимаю, что если ножками программно махать, то тут HZ> задержка влияет, но это исходно порочный путь и на MSP430, к счастью, так

Путь хорош один -- по которому задача решается эффективно, а что там кому-то кажется порочным, лично меня мало занимает.

...

AG>> Разумно спроектированной архитектуре не требуется по 4 цикла на простое AG>> обращение к переменной, от этого попахивает нафталином 70-х.

HZ> add r15, &slon

HZ> Это простое обращение? Я вижу тут сложение двух 16-битных чисел, одно HZ> из которых находится в памяти, и сохранение результата в память...

mov.b r4,&TXBUF0

А я вот вижу примитивную пересылку байта из регистра в UART за 4 цикла. А из памяти она потянет уже на 5...6 циклов. Да что команды, даже DMA в монопольном режиме требует на пересылку 2 цикла! dsPIC30F программно это сделает быстрее.

...

HZ> Или более изощренный вариант, когда адрес операнда назначения на HZ> этапе компиляции неизвестен.

HZ> add r15, 16(r12)

HZ> За сколько тактов эту работу делает PIC? Судя по тестам, не быстрее! HZ> Причем заметно не быстрее!!!

Вот именно, что _всегда_ быстрее:

2: mov #16,W0 1 add W0,W12,W0 1 add W15,[W0],[W0] 1

Я умышленно закодировал всё полностью аналогично, хотя вряд ли в реальном коде для dsPIC30F последовательность будет такой. Скажем если смещение в пределах 5 или 10 разрядов можно команду сэкономить, а если это не сложение, а пересылка -- две.

...

HZ> Я все же жду результатов по тестам. А так - просто болтовня.

Ну откодируй что-нибудь на MSP430, а я это перепишу для dsPIC30F, например, функцию из FP-библиотеки.

...

HZ> Тогда не понятно, почему goto два цикла выполняется?

В каком смысле? Переход же нужно выполнить, значит новая выборка. Или ты про то, что второе слово выбирается, а не 3 цикла? А это как раз срабатывает, что команда (первое слово) уже декодирована и после выборки второго слова выбирается сразу адресуемая команда.

HZ> И ведь МК не всегда на маскимальной скорости работает. Hа более низких HZ> тогда могли бы за счет того, что быстродействия по памяти хватает, HZ> за одни цикл и делать все переходы!

Это требует абсолютно различной структуры командных циклов.

...

HZ> Hу, так и выбирай, кто мешает-то? Если следующую команду ты можешь HZ> выбрать - хватает быстродействия памяти, то кто мешает выбрать вместо нее HZ> ту, которая по новому адресу?

Следующая команда к моменту завершения выполнения условного перехода уже выбрана и её приходится выбрасывать и выбирать новую.

...

AG>> Чтобы по скорости обмена пройти, нужно либо свести данные к байту, AG>> вычисляя дельты между предыдущим и текущим отсчётами...

HZ> А-а, опять все упирается в _конкретные_ условия. Это в данном HZ> конкретном случае они не превышают. А в общем случае вполне могут и HZ> превышать.

Не могут, это противоречит физике материалов. Основной тон -- максимум 500 Гц, а полоса 25 кГц это уже 50-я гармоника. Там в соседних отчётах и близко к границе +-127 не подходит.

HZ> Особенно, когда по разным каналам АЦП оцифровывает.

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

HZ> Поэтому HZ> если уж упаковывать, то адекватный способ именно на основе разрядности HZ> АЦП. Hо паковать 10-битные значения в байты - геморрой почти на любом МК.

Нет там ничего сложного. Один раз на фрейм запоминаются отсчёты целиком, а потом в буфер кладётся разность между млашими байтами и запоминается новый младший байт. Запаковать старшие биты 4-х слов в один пятый чуть ли не ещё проще, просто тогда часть данных фрейма вырастет с 256 до 320 байтов и съест окно обратного канала; нужно увеличивать скорость обмена.

HZ> Уже если бы понадобилось именно выжать все из канала путем упаковки, то я HZ> бы стопудово применил бы внешнюю ПЛИСку и не парился. И порт на ней бы HZ> организовал. Какой угодно. И по потреблению вышло бы более чем пристойно HZ> даже в случае с FPGA.

Я не могу так вот легко разбрасываться дополнительными ИС такого масштаба, потому что это лишняя плата, лишние связи. Для такого шага нужны веские основания. Вот переход на 400 KSPS и освоение скоростей обмена выше 4 Мбод (на HIR IrDA трансивере) это серьёзный повод, потому что тут уже никакой UART не поможет, но ещё не факт, что здесь не будет выгоднее обойтись без PLD.

...

AG>> Тогда причём тут прерывания каждые 640 циклов, если данные идут сами?

HZ> При том, что данные сначала надо подготовить. А DMA уже просто HZ> отправляет их в порт.

И какой толк в таком DMA, если всё равно требуется обслуживание? А данные должны идти не в порт, а в буфер (временнЫе масштабы АЦП и порта разные), а отправку производить когда будет готов целый фрейм.

...

HZ> Именно. Hе понимаешь (к вопросу, дает ли прочтение даташитов и HZ> аппнотов достаточное понимание).

Ну если хорошо написано то без проблем. У TI описания очень куцые, да и перемудрили они со своими эмуляцими команд, бывает трудно понять, что стоит за однотипной мнемоникой.

...

AG>> Я же тебе полный код приводил, выкинь отправку в UART, останется только AG>> сумма, 7 циклов. Только зачем что-то выкидывать?

HZ> У меня уже нет того сообщения. 7 циклов - то на два байта?

Если ты имеешь ввиду, делать сумму как у тебя, тогда так:

SendFrame0 movfw postinc1 1 xorwf TxCheck+0 1 movfw postinc1 1 xorwf TxCheck+1 1 tstfsz fsr1l 1 bra SendFrame0 2

HZ> Тогда, против 5 циклов на MSP430, потеря 30-40% по эффективности. HZ> Об этом я и говорил.

Эффективности чего? Мне такой отдельный цикл суммы 16-разрядных слов на PIC18 не нужен, удобнее и эффективнее делать это вместе с отправкой. В исходном коде сумма считается за 3 цикла на байт, причём где угодно, обработчике прерывания тоже добавится лишь 3 цикла.

...

HZ> Полная мощность dsPIC на полной скорости:

HZ> 146*5 = 730 мВт. (146 мА@5V - DC29a)

Во-первых, на полной скорости -- 70 мА, во-вторых, мне она ни к чему. На реальных 16 MIPS: 3,3 В, 22 мА -- 75 мВт (dsPIC30F4012: DC28a).

HZ> И при этом скорость их несравнима! И нечего тут спорить.

А у Пентиума производительность ещё в 100 раз выше. "И нечего тут спорить."

...

HZ> А почему именно такая батарея? Что, другие нельзя применять?

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

...

HZ> А вполне неплохо эту задачу может решить связка АЦП + ПЛИС...

HZ> Причем очень похоже, что и 8 МГц тут не нужно.

А сколько нужно, чтобы по оптике передавать/принимать от 5 Мбит/с (минимум для 400 KSPS)? Я не особенно надеюсь на менее чем 16 МГц.

...

HZ> на ПЛИС реализуются очень хорошо. Все, что связано с риалтаймом, HZ> формированием диаграмм, дерганием ножек, там гораздо гибче, чем в любом HZ> процессоре и МК. И по потреблению все очень пристойно. По кр. мере по HZ> соотношению производительность на потоке/потребление dsPIC тут уже вполне HZ> сможет скромно перекуривать в углу.

О потреблении в статике 6 мА не может быть и речи, 100 мкА в среднем для всего устройства максимум. На данный момент видно, что предлагается поставить

...

AG>> О чём речь то? Что он для радиолюбителей дороговат? Так это их проблемы

...

HZ> Ты можешь и дальше задирать нос, только при таком подходе сложновато HZ> dsPIC' будет стать _массовым_ процессором. Ты забываешь, что у каждого HZ> потребителя (в данном контексте - потребителя МК) есть своего рода HZ> "кадровая" база.

Какое отношение мой подход имеет к массовости dsPIC30F? Вообще, к чему все эти заклинания? Не нравится тебе оригинальный промышленный программатор? Несколько раз уже сказал: "Бери ICD2 за $160". Этот не нравится? Сотни фирм выпускают программаторы поддерживающие PIC'и (наверняка и до поддержки dsPIC30F недалеко) от навороченных до форменных поделий. Душит и на это тратиться? Жди пока радиолюбители соорудят поддержку dsPIC30F на каком-нибудь компике или LPT-порте. Всё это не мои проблемы и, уверен, не Microchip.

А за будущее dsPIC30F беспокоиться не приходится, это слишком хороший МК, чтобы чьи-то "2-проводковые" проблемы ограничили его распространение, также как не было этого при становлении PIC16 и PIC18.

...

AG>> Понится году эдак в 99-м, TI за эмулятор к MSP430P337 под $10 000 AG>> запросила.

HZ> А что это за эмулятор такой? Hе внутрисистемный?

По-моему обычный внутрисхемный эмулятор, но я его не покупал, потому что отказался от использования MSP430P337. Он мне не очень подходил: работал медленно, потреблял много, а этот ответ TI по эмулятору просто стал последней каплей (отладочные кристаллы, тоже под $100 предлагали).

Привет!

Mon Aug 30 2004 17:20, Harry Zhurov wrote to Alexander Golov:

...

HZ>>> Да? Вот интересно. А можно еще разок привести тот исходный текст и HZ>>> результаты для PIC18?

AG>> Вот код:

...

AG>> Для компилятора Hi-Tech PICC-18 v8.30 объём 2550 байтов, время 13 285 AG>> циклов.

HZ> Э-э.., правильно ли я понял, что объем вырос чуть ли не вдвое, а HZ> время выполнения уменьшилось в два с половиной раза? Hепонятно, откуда HZ> такой прирост. HZ> Я еще могу понять процентов 30, но не 250 же! И почему объем кода вырос? HZ> Что-то _очень_ странное! Тут явно что-то не так.

Ничего такого уж странного, там используются новые (условно новые, их ещё для PIC17 написали) версии подпрограмм умножения и деления активно использующие умножитель (если очень интересно, почитай AN575 для того же PIC17). Там кстати ещё не все возможности оптимизации выбраны, сложение из AN575 тоже быстрее.

...

HZ>>> Поэтому не трудно ли тебе будет прогнать не HZ>>> так давно приводившиеся VV тесты на целочисленку и плавучку? Где HZ>>> сравнивали как раз PIC и AVR.

AG>> Я тогда же результаты и отсылал. Сейчас скомпилировал "плавучку" для AG>> v8.30: объём -- 5820 байтов, время -- 978 178 циклов.

HZ> Для MSP430: 3842 байта, время выполнения 512033 цикла.

HZ> Что-то как-то не чувствуется кривизна 430-го при работе с памятью, HZ> медленность его, неповоротливость.

Это просто факт, он прочитывается в документации.

HZ> При интесивной работе с данными, а HZ> плавучка - это именно интенсивная работа с памятью, он заметно обходит и HZ> 18-го PIC'а!

А на предыдущем тесте проигрывает, весь такой 16-разрядный, оптимизированный на регистровые операции... а ведь плавучка это как раз чисто регистровые операции!

AG>> Тест "целочисленки" измеряет погоду в Африке там одна строка выполняется AG>> 2/3 времени, поэтому смысла прогонять его не вижу.

HZ> Какая строка?

if(syndrome==syndtable[cj]) // Error position found

HZ> Теперь было бы интересно узнать, как с этими тестами справляется HZ> dsPIC!

Да ответ очевиден. Если положить те же циклические регистровые алгоритмы что и у MSP430 то даже в худшем случае получится быстрее чем у MSP430, просто потому что он ни на что не тратит времени больше чем MSP430. Но для dsPIC30F вполне реальны и реализации алгоритмов умножения/деления аналогичные PIC18, скорее всего малопригодные для MSP430 у которых и умножитель не у всех есть да и трафик между ним и ядром сожрёт всё выигранное время.

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

Mon, 6 Sep 2004 11:37:58 +0000 (UTC) Alexander Golov wrote to Harry Zhurov:

AG>>> äÌÑ ËÏÍÐÉÌÑÔÏÒÁ Hi-Tech PICC-18 v8.30 ÏÂߣÍ 2550 ÂÁÊÔÏ×, ×ÒÅÍÑ 13 285 AG>>> ÃÉËÌÏ×.

HZ>> ü-Ü.., ÐÒÁ×ÉÌØÎÏ ÌÉ Ñ ÐÏÎÑÌ, ÞÔÏ ÏÂßÅÍ ×ÙÒÏÓ ÞÕÔØ ÌÉ ÎÅ ×Ä×ÏÅ, Á HZ>> ×ÒÅÍÑ ×ÙÐÏÌÎÅÎÉÑ ÕÍÅÎØÛÉÌÏÓØ × Ä×Á Ó ÐÏÌÏ×ÉÎÏÊ ÒÁÚÁ? HÅÐÏÎÑÔÎÏ, ÏÔËÕÄÁ HZ>> ÔÁËÏÊ ÐÒÉÒÏÓÔ. HZ>> ñ ÅÝÅ ÍÏÇÕ ÐÏÎÑÔØ ÐÒÏÃÅÎÔÏ× 30, ÎÏ ÎÅ 250 ÖÅ! é ÐÏÞÅÍÕ ÏÂßÅÍ ËÏÄÁ ×ÙÒÏÓ? HZ>> þÔÏ-ÔÏ _ÏÞÅÎØ_ ÓÔÒÁÎÎÏÅ! ôÕÔ Ñ×ÎÏ ÞÔÏ-ÔÏ ÎÅ ÔÁË.

AG> HÉÞÅÇÏ ÔÁËÏÇÏ ÕÖ ÓÔÒÁÎÎÏÇÏ, ÔÁÍ ÉÓÐÏÌØÚÕÀÔÓÑ ÎÏ×ÙÅ (ÕÓÌÏ×ÎÏ ÎÏ×ÙÅ, ÉÈ Åݣ AG> ÄÌÑ PIC17 ÎÁÐÉÓÁÌÉ) ×ÅÒÓÉÉ ÐÏÄÐÒÏÇÒÁÍÍ ÕÍÎÏÖÅÎÉÑ É ÄÅÌÅÎÉÑ ÁËÔÉ×ÎÏ AG> ÉÓÐÏÌØÚÕÀÝÉÅ ÕÍÎÏÖÉÔÅÌØ (ÅÓÌÉ ÏÞÅÎØ ÉÎÔÅÒÅÓÎÏ, ÐÏÞÉÔÁÊ AN575 ÄÌÑ ÔÏÇÏ ÖÅ AG> PIC17). ôÁÍ ËÓÔÁÔÉ Åݣ ÎÅ ×ÓÅ ×ÏÚÍÏÖÎÏÓÔÉ ÏÐÔÉÍÉÚÁÃÉÉ ×ÙÂÒÁÎÙ, ÓÌÏÖÅÎÉÅ ÉÚ AG> AN575 ÔÏÖÅ ÂÙÓÔÒÅÅ.

AG> ...

AG>>> ñ ÔÏÇÄÁ ÖÅ ÒÅÚÕÌØÔÁÔÙ É ÏÔÓÙÌÁÌ. óÅÊÞÁÓ ÓËÏÍÐÉÌÉÒÏ×ÁÌ "ÐÌÁ×ÕÞËÕ" ÄÌÑ AG>>> v8.30: ÏÂߣÍ -- 5820 ÂÁÊÔÏ×, ×ÒÅÍÑ -- 978 178 ÃÉËÌÏ×.

HZ>> äÌÑ MSP430: 3842 ÂÁÊÔÁ, ×ÒÅÍÑ ×ÙÐÏÌÎÅÎÉÑ 512033 ÃÉËÌÁ.

HZ>> þÔÏ-ÔÏ ËÁË-ÔÏ ÎÅ ÞÕ×ÓÔ×ÕÅÔÓÑ ËÒÉ×ÉÚÎÁ 430-ÇÏ ÐÒÉ ÒÁÂÏÔÅ Ó ÐÁÍÑÔØÀ, HZ>> ÍÅÄÌÅÎÎÏÓÔØ ÅÇÏ, ÎÅÐÏ×ÏÒÏÔÌÉ×ÏÓÔØ.

AG> üÔÏ ÐÒÏÓÔÏ ÆÁËÔ, ÏÎ ÐÒÏÞÉÔÙ×ÁÅÔÓÑ × ÄÏËÕÍÅÎÔÁÃÉÉ.

HZ>> ðÒÉ ÉÎÔÅÓÉ×ÎÏÊ ÒÁÂÏÔÅ Ó ÄÁÎÎÙÍÉ, Á HZ>> ÐÌÁ×ÕÞËÁ - ÜÔÏ ÉÍÅÎÎÏ ÉÎÔÅÎÓÉ×ÎÁÑ ÒÁÂÏÔÁ Ó ÐÁÍÑÔØÀ, ÏÎ ÚÁÍÅÔÎÏ ÏÂÈÏÄÉÔ É HZ>> 18-ÇÏ PIC'Á!

AG> á ÎÁ ÐÒÅÄÙÄÕÝÅÍ ÔÅÓÔÅ ÐÒÏÉÇÒÙ×ÁÅÔ, ×ÅÓØ ÔÁËÏÊ 16-ÒÁÚÒÑÄÎÙÊ,

AG> ÏÐÔÉÍÉÚÉÒÏ×ÁÎÎÙÊ ÎÁ ÒÅÇÉÓÔÒÏ×ÙÅ ÏÐÅÒÁÃÉÉ... Á ×ÅÄØ ÐÌÁ×ÕÞËÁ ÜÔÏ ËÁË ÒÁÚ AG> ÞÉÓÔÏ ÒÅÇÉÓÔÒÏ×ÙÅ ÏÐÅÒÁÃÉÉ!

AG>>> ôÅÓÔ "ÃÅÌÏÞÉÓÌÅÎËÉ" ÉÚÍÅÒÑÅÔ ÐÏÇÏÄÕ × áÆÒÉËÅ ÔÁÍ ÏÄÎÁ ÓÔÒÏËÁ ×ÙÐÏÌÎÑÅÔÓÑ AG>>> 2/3 ×ÒÅÍÅÎÉ, ÐÏÜÔÏÍÕ ÓÍÙÓÌÁ ÐÒÏÇÏÎÑÔØ ÅÇÏ ÎÅ ×ÉÖÕ.

HZ>> ëÁËÁÑ ÓÔÒÏËÁ?

AG> if(syndrome==syndtable[cj]) // Error position found

HZ>> ôÅÐÅÒØ ÂÙÌÏ ÂÙ ÉÎÔÅÒÅÓÎÏ ÕÚÎÁÔØ, ËÁË Ó ÜÔÉÍÉ ÔÅÓÔÁÍÉ ÓÐÒÁ×ÌÑÅÔÓÑ HZ>> dsPIC!

AG> äÁ ÏÔ×ÅÔ ÏÞÅ×ÉÄÅÎ.

AG> åÓÌÉ ÐÏÌÏÖÉÔØ ÔÅ ÖÅ ÃÉËÌÉÞÅÓËÉÅ ÒÅÇÉÓÔÒÏ×ÙÅ ÁÌÇÏÒÉÔÍÙ ÞÔÏ É Õ MSP430 ÔÏ AG> ÄÁÖÅ × ÈÕÄÛÅÍ ÓÌÕÞÁÅ ÐÏÌÕÞÉÔÓÑ ÂÙÓÔÒÅÅ ÞÅÍ Õ MSP430, ÐÒÏÓÔÏ ÐÏÔÏÍÕ ÞÔÏ ÏÎ AG> ÎÉ ÎÁ ÞÔÏ ÎÅ ÔÒÁÔÉÔ ×ÒÅÍÅÎÉ ÂÏÌØÛÅ ÞÅÍ MSP430. HÏ ÄÌÑ dsPIC30F ×ÐÏÌÎÅ AG> ÒÅÁÌØÎÙ É ÒÅÁÌÉÚÁÃÉÉ ÁÌÇÏÒÉÔÍÏ× ÕÍÎÏÖÅÎÉÑ/ÄÅÌÅÎÉÑ ÁÎÁÌÏÇÉÞÎÙÅ PIC18, ÓËÏÒÅÅ AG> ×ÓÅÇÏ ÍÁÌÏÐÒÉÇÏÄÎÙÅ ÄÌÑ MSP430 Õ ËÏÔÏÒÙÈ É ÕÍÎÏÖÉÔÅÌØ ÎÅ Õ ×ÓÅÈ ÅÓÔØ ÄÁ É AG> ÔÒÁÆÉË ÍÅÖÄÕ ÎÉÍ É ÑÄÒÏÍ ÓÏÖңÔ ×ӣ ×ÙÉÇÒÁÎÎÏÅ ×ÒÅÍÑ.

Hello, Harry Zhurov !

Привет!

Mon Sep 13 2004 10:32, Harry Zhurov wrote to Alexander Golov:

...

HZ>>> Что-то как-то не чувствуется кривизна 430-го при работе с памятью, HZ>>> медленность его, неповоротливость.

AG>> Это просто факт, он прочитывается в документации.

HZ> Факт в том, 430-й быстрее!! Даже в том аномальном случае.

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

...

HZ>>> При интесивной работе с данными, а плавучка - это именно интенсивная HZ>>> работа с памятью, он заметно обходит и 18-го PIC'а!

AG>> А на предыдущем тесте проигрывает, весь такой 16-разрядный,

HZ> Почему это проигрывает?! 13 285 у 18-го и 12 535 у 430-го. Что HZ> больше, а что меньше, не так уж сложно увидеть.

Во-первых, я не ясновидящий: эти цифры тобой озвучены впервые (тогда в 2001-м называлось что-то около 23 000 циклов, потом порядка 15 000 циклов). А во-вторых, PIC18 всё равно быстрее из-за более короткого цикла.

HZ> И надо еще разобраться, HZ> откуда такая цифра у 18-го взялась. И почему на другом тесте с плавучкой HZ> (который от VV) не наблюдается такой картины прироста в 3 раза - она, как HZ> раз, более правильная и привычная - где-то в два раза.

Ну давай попробуем разобраться. Для PIC18 с медленным вариантом библиотек получается 2 095 003 циклов для программы VV и 28 751 циклов для термометров. С быстрым вариантом, соответственно -- 978 751 и 13 296. Таким образом соотношение времени выполнения задач для медленного варианта -- 73 и для быстрого -- 74.

Для AVR по словам VV время выполнения его задачи составляет 1,9...2 млн. циклов. Насколько я помню термометры были выполнены за 33 000 циклов и потом с другой версией компилятора что-то около 28 000. Другими словами мы имеем схожее соотношение около 60...70. И вот теперь с представленными тобой показателями для MSP430 (512 033 и 12 535) мы получаем весьма неожиданное соотношение 41.

Мне, например, интересно, почему при сравнении с AVR у меня сохранилось близкое отношение для термометров и задачи VV, а вот MSP430 вдруг неожиданное ускорился почти вдвое?

Далее... Мы имеем корневой цикл занимающий более 90% машинного времени:

for(j=1;j<=f;j++) { for(i=j;i<=n;i+=e) { o=i+f-1; o1=i-1; p=x[o1]+x[o]; // 185 r=x[o1]-x[o]; // 211 q=y[o1]+y[o]; // 185 t=y[o1]-y[o]; // 211 x[o]=r*u-t*v; // 493 y[o]=t*u+r*v; // 465 x[o1]=p; y[o1]=q; } w=u*c-v*s; // 453 v=v*c+u*s; // 462 u=w; } }

Тело цикла содержит 8 FP-операций умножения и 8 сложения и выполняется 32 x 6 x 2 = 384 раза. Для случая общего времени 978 751 цикл я имею в среднем 2549 циклов на итерацию или 160 циклов на одну FP-операцию (грубой оценки вполне достаточно). Это неплохо согласуется с рассчётными показателями времени работы соответствующих функций (в сущности данный тест отражает производительность двух операций -- сложения и умножения). Так или иначе в коде выше привожу реальное время работы тела цикла для каждой строки, для прямого преобразования на итерации: j = 5. Итого 16 FP-операций в данной итерации требуют 2665 циклов.

Для заявленного тобой суммарного времени 512 033 цикла, получается среднее время FP-операции 83 цикла. Достаточно взглянуть на "отшлифованную" подрограмму умножения 16 x 16 для MSP430:

clr.w R14 clr.w R15 clr.w R13 mov.w #1,R10 MPY2 bit.w R10,R11 ; 1 jz MPY1 ; 2 add.w R12,R14 addc.w R13,R15 MPY1 rla.w R12 ; 1 rlc.w R13 ; 1 rla.w R10 ; 1 jnc MPY2 ; 2 ret

чтобы убедиться, что даже если сомножитель R11 равен нулю она выполняется не менее 130 циклов, а простое увеличение числа итераций до 24 (без соответствующего увеличения разрядности операндов и введения антуража сопутствующего FP-умножению) сразу выводит время её работы за грань 166 циклов, т.е. даже при нулевом времени работы сложения невозможно достигнуть скорости 512 033 цикла. Отсюда я делаю вывод, что или я круто отстал в методологии умножения, или имеет ошибка в опыте, либо один из видов жульничества.

В любом случае я хочу видеть построчный тайминг этого цикла для MSP430 и код использованных подпрограмм умножения и сложения. Где можно посмотреть код быстрых функций используемых у Hi-Tech в варианте для PIC17 я ссылку давал, если очень нужно, могу дать непосредственно Hi-Tech'евский код для для PIC18.

HZ> При этом размер кода у 430-го в полтора раза меньше!

Код? Вряд ли, в основном это касается размера библиотек. Впрочем, я никогда и не заявлял, что Hi-Tech даёт компактный вычислительный код. Как раз наоброт, они там непосредственно гоняют 32-разрядные данные. На PIC16 на асме я работал по ссылкам и код был существенно плотнее, при том, что на PIC18 это делать удобнее.

AG>> оптимизированный на регистровые операции... а ведь плавучка это как раз AG>> чисто регистровые операции!

HZ> Плавучка - это, как раз и в первую очередь, работа с памятью - со HZ> стеком.

Какая память, какой стек? Основные арифметические операции большую часть времени работают в коротких циклах с небольшим количеством локальных переменных. Для PIC16 у меня пул данных FP-библиотеки был порядка 16 байтов, т.е. десятка регистров MSP430 вполне хватит.

HZ> Тут огромное количество пересылок. Собственно регистровые операции, такие HZ> как арифметика, занимают едва ли не меньшую долю в объеме кода.

Сколько бы они кода не занимали, времени они требуют дай бог -- единицы процентов.

AG>>>> Тест "целочисленки" измеряет погоду в Африке там одна строка AG>>>> выполняется 2/3 времени, поэтому смысла прогонять его не вижу.

HZ>>> Какая строка?

AG>> if(syndrome==syndtable[cj]) // Error position found

HZ> И что тебе не нравится? Как раз та самая работа с памятью, которая на HZ> PIC'е такая быстрая и замечательная. Он, как раз, должен тут проявить HZ> свои лучше качества! Вообще, операция типовая и в значительной степени HZ> характеризует эффективность ядра.

HZ> И кроме того, там еще циклы вращаются - а это сравнение и условные HZ> переходы. И доля кода цикла значительна. Hе понимаю, что тебя смущает, HZ> вполне нормальный тест на производительность, все операции типовые - HZ> обращение в память, сравнения, переходы.

HZ> Видимо, PIC'у против MSP430 тут похвастать нечем, вот и ищешь HZ> отмазки.

Я понятия не имею сколько времени всё это занимает у MSP430, для AVR VV приводил значение 9670 циклов. Я скомпилировал тот текст в почти неизменном виде на Hi-Tech PICC18 8.20PL4 и получил время 14 800 циклов. Потом немного подвигал строчки в тексте и получил 10 240 циклов. Потом написал два десятка строк на асме -- кусочек ищущий значение в syndtable -- и получил 8100 циклов и всё это без малейших изменений в алгоритме, модели данных и коде за рамками поиска в syndtable! В качестве теста чего-либо эта программа совершенно непригодна.

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

HZ>>> Теперь было бы интересно узнать, как с этими тестами справляется HZ>>> dsPIC!

AG>> Да ответ очевиден.

HZ> Ушел от ответа. Сказал бы честно, что, дескать, нету компилятора и HZ> взять негде. Это, кстати, тоже характеризует продукт. :-Р

Я тебе так прямо ещё несколько писем назад и сказал, чем ты не доволен? А где взять я знаю: например купить у Hi-Tech (CCS, IAR и т.п.). Только я этого делать не буду, мне он на данный момент не нужен, как и не нужен мне компиллятор (наверняка ещё сырой с неоптимизированными библиотеками), чтобы оценить производительность МК, особенно на критических участках кода, которые я в любом случае напишу на асме.

Thu, 23 Sep 2004 16:43:44 +0000 (UTC) Alexander Golov wrote to Harry Zhurov:

AG>>> Это просто факт, он прочитывается в документации.

HZ>> Факт в том, 430-й быстрее!! Даже в том аномальном случае.

AG> Факт, что он медленно работает с памятью, а упоминаемые тобой случаи к AG> этому вопросу никакого отношения не имеют.

Нормально он работает с памятью. Как подобает фон Неймановской машине. И в итоге все равно на вычислениях и обращениях в память быстрее. Что и видно на тестах.

AG> ...

HZ>>>> При интесивной работе с данными, а плавучка - это именно интенсивная HZ>>>> работа с памятью, он заметно обходит и 18-го PIC'а!

AG>>> А на предыдущем тесте проигрывает, весь такой 16-разрядный,

HZ>> Почему это проигрывает?! 13 285 у 18-го и 12 535 у 430-го. Что HZ>> больше, а что меньше, не так уж сложно увидеть.

AG> Во-первых, я не ясновидящий: эти цифры тобой озвучены впервые (тогда в AG> 2001-м называлось что-то около 23 000 циклов, потом порядка 15 000 циклов). AG> А во-вторых, PIC18 всё равно быстрее из-за более короткого цикла.

Блин! Да ты сравнить два числа-то можешь? Уже явно их написал, а он все про какие-то "более короткие циклы" толкует. На том тесте MSP430 быстрее по факту! А уж из чего там складываются выигрыши и проигрыши - другой вопрос.

HZ>> И надо еще разобраться, HZ>> откуда такая цифра у 18-го взялась. И почему на другом тесте с плавучкой HZ>> (который от VV) не наблюдается такой картины прироста в 3 раза - она, как HZ>> раз, более правильная и привычная - где-то в два раза.

AG> Ну давай попробуем разобраться. Для PIC18 с медленным вариантом библиотек AG> получается 2 095 003 циклов для программы VV и 28 751 циклов для AG> термометров. С быстрым вариантом, соответственно -- 978 751 и 13 296. Таким AG> образом соотношение времени выполнения задач для медленного варианта -- 73 AG> и для быстрого -- 74.

Ты перевел тему в другое русло. Я спрашивал, откуда такой прирост от простого переписывания библиотеки - в три раза? На это ответа нет! Все же интересно, что там можно сделать, чтобы так кардинально изменилась производительность на плавающей точке? Если только при написании предыдущего варианта не ставилась задача сделать его как можно более тормозным.

AG> Для AVR по словам VV время выполнения его задачи составляет 1,9...2 млн. AG> циклов. Насколько я помню термометры были выполнены за 33 000 циклов и AG> потом с другой версией компилятора что-то около 28 000. Другими словами мы AG> имеем схожее соотношение около 60...70. И вот теперь с представленными AG> тобой показателями для MSP430 (512 033 и 12 535) мы получаем весьма AG> неожиданное соотношение 41.

Не знаю. Не досуг мне разбираться в этом. Могу код показать, если есть желание копаться в нем. Очевидно, какие-то особенности реализации функций библиотеки.

AG> Мне, например, интересно, почему при сравнении с AVR у меня сохранилось AG> близкое отношение для термометров и задачи VV, а вот MSP430 вдруг AG> неожиданное ускорился почти вдвое?

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

AG> Далее... Мы имеем корневой цикл занимающий более 90% машинного времени:

AG> for(j=1;j<=f;j++)

AG> Для заявленного тобой суммарного времени 512 033 цикла, получается среднее AG> время FP-операции 83 цикла. Достаточно взглянуть на "отшлифованную" AG> подрограмму умножения 16 x 16 для MSP430:

AG> clr.w R14 AG> clr.w R15 AG> clr.w R13 AG> mov.w #1,R10 AG> MPY2 bit.w R10,R11 ; 1 AG> jz MPY1 ; 2 AG> add.w R12,R14 AG> addc.w R13,R15 AG> MPY1 rla.w R12 ; 1 AG> rlc.w R13 ; 1 AG> rla.w R10 ; 1 AG> jnc MPY2 ; 2 AG> ret

AG> чтобы убедиться, что даже если сомножитель R11 равен нулю она выполняется AG> не менее 130 циклов, а простое увеличение числа итераций до 24 (без AG> соответствующего увеличения разрядности операндов и введения антуража AG> сопутствующего FP-умножению) сразу выводит время её работы за грань 166 AG> циклов, т.е. даже при нулевом времени работы сложения невозможно достигнуть AG> скорости 512 033 цикла. Отсюда я делаю вывод, что или я круто отстал в AG> методологии умножения, или имеет ошибка в опыте, либо один из видов AG> жульничества.

Ага, жульничество. Умножение 16х16 на f149 (который использовался в тесте) выглядит, например для беззнакового умножения, так:

mov x, &MPY mov y, &OP2

Для знакового:

mov x, &MPYS mov y, &OP2

И так далее вплоть до умножения с накоплением (если оно нужно). Вот такое вот жульничество. А то, что ты привел, по объему больше похоже на 32х32 умножение (с 32-битным результатом):

MOV L0L, &MPY MOV L1L, &OP_2 // Compute L0L*L1L

MOV L0L, &MAC MOV &ResLo, L0L // Save LSW of product MOV &ResHi, &ResLo // Accumulate MSW of L0L*L1L MOV L1H, &OP_2 // Accumulate L0L*L1H

MOV L0H, &MAC MOV L1L, &OP_2 // Accumulate L0H*L1L

MOV &ResLo, L0H // Save MSW of product

AG> В любом случае я хочу видеть построчный тайминг этого цикла для MSP430 и AG> код использованных подпрограмм умножения и сложения. Где можно посмотреть AG> код быстрых функций используемых у Hi-Tech в варианте для PIC17 я ссылку AG> давал, если очень нужно, могу дать непосредственно Hi-Tech'евский код для AG> для PIC18.

Ну, так возьми, скачай evaluation trial EW430 v3.20, он месяц полностью функциональный (при желании можно и таблеткой разжиться в нулевой будке). Свободно скачивается с

AG>>> оптимизированный на регистровые операции... а ведь плавучка это как раз AG>>> чисто регистровые операции!

HZ>> Плавучка - это, как раз и в первую очередь, работа с памятью - со HZ>> стеком.

AG> Какая память, какой стек?

Да такая. Вот фрагмент из кодогенерации того цикла:

Сплошные пересылки между регистрами, памятью и стеком (который тоже есть память).

AG> Основные арифметические операции большую часть времени работают в коротких AG> циклах с небольшим количеством локальных переменных.

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

HZ>> Тут огромное количество пересылок. Собственно регистровые операции, такие HZ>> как арифметика, занимают едва ли не меньшую долю в объеме кода.

AG> Сколько бы они кода не занимали, времени они требуют дай бог -- единицы AG> процентов.

Доли процентов?!!! Как бы не так! Вот, например, из это же цикла: выражение

p=x[o1]+x[o];

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

HZ>> И кроме того, там еще циклы вращаются - а это сравнение и условные HZ>> переходы. И доля кода цикла значительна. Hе понимаю, что тебя смущает, HZ>> вполне нормальный тест на производительность, все операции типовые - HZ>> обращение в память, сравнения, переходы.

HZ>> Видимо, PIC'у против MSP430 тут похвастать нечем, вот и ищешь HZ>> отмазки.

AG> Я понятия не имею сколько времени всё это занимает у MSP430, для AVR VV AG> приводил значение 9670 циклов. Я скомпилировал тот текст в почти неизменном AG> виде на Hi-Tech PICC18 8.20PL4 и получил время 14 800 циклов. Потом немного AG> подвигал строчки в тексте и получил 10 240 циклов. Потом написал два AG> десятка строк на асме -- кусочек ищущий значение в syndtable -- и получил AG> 8100 циклов и всё это без малейших изменений в алгоритме, модели данных и AG> коде за рамками поиска в syndtable! В качестве теста чего-либо эта AG> программа совершенно непригодна.

Тем не менее 6380 циклов на MSP430 все равно характеризуют ситуацию. По крайней мере, пусть далеко не точную, но характеристическую оценку это дает.

AG> Рассматриваемый выше тест FP тоже не намного лучше, т.к. ничего кроме двух AG> подпрограмм FP-библиотеки не проверяет, но я по крайней мере согласен, что AG> умножение и сложение (и, наверное, деление) -- действительно самые важные AG> FP-операции и именно они в общем случае определяют производительность AG> вычислений.

Эти тесты - это из реальных задач. И для реальных условий. В жизни всегда так - есть условия, есть задачи, их надо решать имеющимися средствами. А не придумывать гипотетическую ситуацию, где бы тот или иной вариант был бы круче. Реальность такова, что нет у пользователя возможности (времени, квалификации и т.д.) зарываться в реализацию и оптимизировать, оптимизировать. Ему нужно решить задачу здесь и сейчас с помощью имеющегося арсенала средств. Вот и взяли реальные задачи (а не синтетические тесты), реальный имеющийся в наличие инструментарий, прогнали тест и сравнили результат. Во всех случаях MSP430 быстрее, чем PIC18. Что бы ты там не говорил про особенности.

Другое дело, что есть тебя устраивает производительность PIC18 на твоих задачах, то тут тогда и обсуждать нечего - значит не нужен тебе MSP430. Но медленнее он от этого не становится.

В заключение: MSP430 является фон Неймановским процессором, у него одна и та же память и для команд и для данных. Это имеет свои преимущества и удобства, но производительность тут не сильная сторона. Поэтому он при прочих равных медленнее, чем процессоры, выполненные по Гарвардской архитектуре, которые имеют возможность одновременного обращения к памяти программ и памяти данных. Но по сравнению с 8-битными процессорами MSP430 компенсирует недостаток "поворотливости" более широкой шиной, что на 16-разрядных операндах уже дает если не выигрыш, то паритет, а ортогональность регистров, которые могут быть также и указателями, приводит к почти полному отсутствию накладнОго кода копирования данных между регистрами (что имеет место, например, в AVR), что дает еще некоторый прирост. Итого, реальная эффективность MSP430 не так уж плоха, что и видно на реальном коде.

Привет!

Mon Sep 27 2004 11:46, Harry Zhurov wrote to Alexander Golov:

...

AG>> Факт, что он медленно работает с памятью, а упоминаемые тобой случаи к AG>> этому вопросу никакого отношения не имеют.

HZ> Hормально он работает с памятью. Как подобает фон Hеймановской HZ> машине. И в итоге все равно на вычислениях и обращениях в память быстрее. HZ> Что и видно на тестах.

На всех примерах пока было видно только, что обращения к памяти медленные. А "неймановость" тут вообще не причём. Flash, ОЗУ, SFR'ы -- всё разные устройства и могут выбираться параллельно, независимо от того, что они отмаппированы в одно адресное пространство. Более того, никого же не удивляет, что PIC за цикл может дважды обратиться к ОЗУ, т.е. уже в одно устройство.

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

...

HZ> Блин! Да ты сравнить два числа-то можешь? Уже явно их написал, а он HZ> все про какие-то "более короткие циклы" толкует. Hа том тесте MSP430 HZ> быстрее по факту! А уж из чего там складываются выигрыши и проигрыши - HZ> другой вопрос.

Могу: 1,32 мс для PIC18 и 1,56 мс для MSP430 -- это по факту, даже без оглядки на твоё жульничество.

...

AG>> Hу давай попробуем разобраться. Для PIC18 с медленным вариантом AG>> библиотек получается 2 095 003 циклов для программы VV и 28 751 циклов AG>> для термометров. С быстрым вариантом, соответственно -- 978 751 и 13 AG>> 296. Таким образом соотношение времени выполнения задач для медленного AG>> варианта -- 73 и для быстрого -- 74.

HZ> Ты перевел тему в другое русло. Я спрашивал, откуда такой прирост от HZ> простого переписывания библиотеки - в три раза? Hа это ответа нет! HZ> Все же интересно, что там можно сделать, чтобы так кардинально изменилась HZ> производительность на плавающей точке? Если только при написании HZ> предыдущего варианта не ставилась задача сделать его как можно более HZ> тормозным.

Я тебе уже неоднократно (впервые ещё в 2001-м году) сообщал, что новые операции умножения и деления построены не на базе традиционных циклических алгоритмов, а на линейных с использованием умножителя 8x8 PIC17/18 (например в делении используются 35 операций умножения и табличные интерполяции). Если тебя интересует конкретика пожалуйста читай AN535, или могу прислать HiTech'евские переработчки тех же Microchip'овских исходников.

...

AG>> Мне, например, интересно, почему при сравнении с AVR у меня сохранилось AG>> близкое отношение для термометров и задачи VV, а вот MSP430 вдруг AG>> неожиданное ускорился почти вдвое?

HZ> С чего ты взял, что он ускорился? Мне дак представляется, что это он HZ> на одном из тестов замедлился очень.

Потому что основные операции в обоих тестах одни и те же. А необходимая для показателя 512000 циклов скорость сложения и умножения применительно к MSP430 навскидку выглядит сюреалистично.

...

AG>> Для заявленного тобой суммарного времени 512 033 цикла, получается AG>> среднее время FP-операции 83 цикла. Достаточно взглянуть на AG>> "отшлифованную" подрограмму умножения 16 x 16 для MSP430:

...

AG>> чтобы убедиться, что даже если сомножитель R11 равен нулю она AG>> выполняется не менее 130 циклов, а простое увеличение числа итераций до AG>> 24 (без соответствующего увеличения разрядности операндов и введения AG>> антуража сопутствующего FP-умножению) сразу выводит время её работы за AG>> грань 166 циклов, т.е. даже при нулевом времени работы сложения AG>> невозможно достигнуть скорости 512 033 цикла. Отсюда я делаю вывод, что AG>> или я круто отстал в методологии умножения, или имеет ошибка в опыте, AG>> либо один из видов жульничества.

HZ> Ага, жульничество. Умножение 16х16 на f149 (который использовался в HZ> тесте) выглядит, например для беззнакового умножения, так:

HZ> mov x, &MPY HZ> mov y, &OP2

Понятно. Значит при обсуждении проблем производительности _ядра_ MSP430 ты предъявлешь в качестве результатов теста работу выполненную периферийным модулем, не являющимся неотъемлемой частью семейства (более 2/3 членов его не имеет), даже не считая необходимым упоминуть об этом! Это классическое введение в заблуждение через выборочное умолчание фактов, т.е. жульничество и есть.

А теперь прошу предъявить результаты работы ядра для теста VV и термометров.

...

HZ> И так далее вплоть до умножения с накоплением (если оно нужно). Вот HZ> такое вот жульничество. А то, что ты привел, по объему больше похоже на HZ> 32х32 умножение (с 32-битным результатом):

То, что я привёл это умножение 16x16->32 -- самый традиционный и самый примитивный алгоритм взятый их аппнотов, а для FP-умножения в single нужно умножение мантисс 24x24->24. На 16-разрядном МК это делатся заметно дольше чем 16x16->32.

...

HZ> MOV L0L, &MPY 4 HZ> MOV L1L, &OP_2 4 // Compute L0L*L1L

HZ> MOV L0L, &MAC 4 HZ> MOV &ResLo, L0L 3 // Save LSW of product HZ> MOV &ResHi, &ResLo 6 // Accumulate MSW of L0L*L1L HZ> MOV L1H, &OP_2 4 // Accumulate L0L*L1H

HZ> MOV L0H, &MAC 4 HZ> MOV L1L, &OP_2 4 // Accumulate L0H*L1L

HZ> MOV &ResLo, L0H 3 // Save MSW of product ---- 36

А вот это очень показательно в плане скорости работы MSP430 по сравнению с аналогичным умножением на dsPIC30F (причём MSP430 для этого нужен специальный, а dsPIC30F -- любой, хоть 18-ногий, тогда как среди MSP430 ничего меньше 64 ног с умножителем нет):

muluu W6,W1,W8 1 muluu W7,W0,W4 1 add W4,W8,W8 1 addc W5,W9,W9 1 muluu W7,W1,W4 1 muluu W6,W0,W0 1 add W1,W8,W1 1 addc W4,W9,W2 1 ---- 8

AG>> В любом случае я хочу видеть построчный тайминг этого цикла для MSP430 и AG>> код использованных подпрограмм умножения и сложения. Где можно AG>> посмотреть код быстрых функций используемых у Hi-Tech в варианте для AG>> PIC17 я ссылку давал, если очень нужно, могу дать непосредственно AG>> Hi-Tech'евский код для для PIC18.

HZ> Hу, так возьми, скачай evaluation trial EW430 v3.20, он месяц HZ> полностью функциональный (при желании можно и таблеткой разжиться в HZ> нулевой будке).

Я не имею возможности ставить и разбираться с непростым и совершенно не нужным мне программным продуктом. Я ведь не заставляю тебя прогонять тесты для PIC'ов, а делал это сам, так уж и ты изволь проделать эту совсем не сложную работу, потому что без этих данных принять версию про 512000 циклов я не смогу. Чем дальше, тем больше у меня сомнений в возможности MSP430 показать такой результат даже вооружишись умножителем.

HZ> Свободно скачивается с

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

Но в любом случае, пришли их мне на snipped-for-privacy@mail.ru.

...

AG>> Какая память, какой стек?

HZ> Да такая. Вот фрагмент из кодогенерации того цикла:

...

HZ> p=x[o1]+x[o]; HZ> RLA.W R10 HZ> RLA.W R10 HZ> MOV.W 0x2(SP), R15 HZ> ADD.W R10, R15 HZ> MOV.W R15, 0x8(SP) HZ> RLA.W R11 HZ> RLA.W R11 HZ> MOV.W 0x2(SP), R15 HZ> ADD.W R11, R15 HZ> MOV.W R15, 0x6(SP) HZ> MOV.W @R15, R14 HZ> MOV.W 0x2(R15), R15 HZ> MOV.W 0x8(SP), R13 HZ> MOV.W @R13, R12 HZ> MOV.W 0x2(R13), R13 HZ> CALL #_Add32f HZ> MOV.W R12, 0x20(SP) HZ> MOV.W R13, 0x22(SP)

...

Я просил код _Add32f и _Mul32f, а не вызывающий их. Хотя, кстати, аналог этого кода для dsPIC30F (номера регистров меняются, т.к. W15 это SP):

sl w10,#2,w10 1 mov [w15+2],w9 1 add w10,w9,w1 1 sl w11,#2,w11 1 add w11,w9,w9 1 mov.d [w9],w10 2 mov.d [w1],w12 2 <- 9 rcall _Add32f 2 mov w12,[w15+0x20] 1 mov w13,[w15+0x22] 1

Не знаю зачем для MSP430 понадобилось сохранять в локальных переменных "эффектив-адрес" складываемых значений, но если это внести в код dsPIC30F добавятся 2 цикла. Ещё немного (посмотреть код Add и Mul) и мы вполне объективно сможем оценить соотношение производительности MSP430 и dsPIC30F на данных задачах.

...

AG>> Сколько бы они кода не занимали, времени они требуют дай бог -- единицы AG>> процентов.

HZ> Доли процентов?!!! Как бы не так! Вот, например, из это же цикла: HZ> выражение

HZ> p=x[o1]+x[o];

HZ> на подготовку операндов при передаче их в функцию уходит 33 цикла, а HZ> на выполнению самой функции сложения 49 циклов.

...