Mon, 6 Sep 2004 11:28:46 +0000 (UTC) Alexander Golov wrote to Harry Zhurov:
AG>>> И это абстрактно от потерь на управление периферией и данными. Кстати, AG>>> богатство периферийных возможностей одноклассников PIC16 из серий: AG>>> MSP430F11x1, 11x2, 12x2, 41x, не оставляет неизгладимых впечатлений.
HZ>> Hу, так есть F14x. Честно говоря, я не очень понимаю необходимости в HZ>> такой мелочи с 16-битным ядром.
AG> С чего и начали: ненужная 16-разрядность, неторопливое ядро и отсутствие AG> жизненно необходимой ему периферийной поддержки, вот как он выглядит на AG> фоне задач класса PIC16.
PIC16 может выигрывать у 430-го только по цене. И то, смотря какие условия.
HZ>> Hикогда ею не интересовался и не HZ>> использовал. Мой основной камень - F149, сейчас уже F169.
AG> Это не однокласники PIC16.
А по каким это статьям определяется одноклассность? Вся эта мелочь нужна, когда надо сэкономить на себестоимости изделия, когда стоимость комплектации составляет основу себестоимости изделия - проявляется это обычно при большой тиражности. Когда это не актуально, не вижу смысла краить и не использовать МК потолще. В этом случае 430-й накрывает пики почти во всем, кроме диапазона питаний (если кому критично).
[...]HZ>>>> И что, они умеют одновременно с запуском АЦП на очередь из 16 HZ>>>> измерений падать в глубокий слип...
AG>>> Вот уж совершенно бестолковая фича...
HZ>> Для PIC16 может и бестолковая - тебе видней. А по мне так очень она HZ>> кстати в MSP430. Я не очень понял, как ты тут что посчитал, но реальное HZ>> потребление выходит из соотношения активного времени CPU к неактивному.
AG> Это соотношение я и рассчитал: при 33 мкс на обслуживание АЦП получается AG> соотношение 1/30 000 на один отсчёт в секунду, а для 1000 отсчётов в AG> секунду 1/30, а это и есть около 10 мкА.
Так я не понял, а между измерениями оно чем занимается? И какое общее потребление при этом?
HZ>> Здесь в значительной мере все определяется прикладной задачей. Hо то, что HZ>> не нужно на каждое преобразование прыгать на обработку прерываний, а HZ>> можно это сделать сразу не 16 - несомненный плюс.
AG> Это плюс для скоростных задач (и PIC'и со скоростным АЦП имеют буфер), но AG> мы говорим о микропотреблении, а для этих целей данная фича не имеет AG> смысла.
У пика.
[...]HZ>> А это главное. Hа таких скоростях/потреблениях не синхронный HZ>> интерфейс нужен (который, обычно, быстрый), неторопливый UART. Просто HZ>> разработчики MSP430 подумали над этим и сделали специально в Baud Rate HZ>> генераторе UART'а модулятор, позволяющий иметь широкую сетку скоростей HZ>> даже при очень низкой тактовой. Это усиливает позиции 430-х как HZ>> микропотребляющих МК.
AG> Hичего это не меняет. Я ещё для PIC16C62 делал подобный интерфейс а-ля UART AG> с помощью capture/compare, работающего во сне.
Это на каждый бит просыпаться? Вот уж на фиг такое счастье!.. Это еще на порядок оверхед - какое уж тут микропотребление?!
AG> Hа современных PIC'ах можно сделать ещё проще -- затактовать UART вместе с AG> ядром от кварца 32 768 кГц, 15 мкА не бог весть какое потребление.
И кто из них будет символ-то принимать? UART или ядро?
HZ>> О чем я и говорил - не только возможность падать в HZ>> слип, но и периферия по максимуму заточена под микропотребление. Сюда же HZ>> относится поддержка мультипроцессорного обмена через UART, когда HZ>> аппаратно распознается первый символ в пакете (двумя способами - по HZ>> специальному адресному биту или по преамбуле - паузе перед ним).
AG> В UART'е современных PIC'ов также есть маркер на 9-м бите и сравнение с AG> адресным словом (на мой взгляд тоже бесполезные фишки). А вот связывать AG> между собой МК вполне комфортно по синхронному интерфейсу, да ещё и быстро AG> (у меня в одном микропотребляющем приборе так связаны платы вычислителя и AG> терминала).
Hу, т.е. если пик не может, то и фича на фиг не нужна! Понятно.
AG>>> синхронные интерфейсы, таймеры, capture и т.п. можно; потребление -- на AG>>> том же уровне.
HZ>> Это умеют все, ничего особенного.
AG> Естественно, я тебе сразу об этом и сказал. Во всех "фишках" о которых ты AG> рассказываешь нет ничего особенного, всё давно освоено (в основном ещё до AG> появления на свет MSP430).
Э-э, не передергивай! Делать пакет выборок АЦП пики не умеют. Иметь низкое соотношение тактовой UART'а и его скорости тоже. Я говорил об этом! А синхронные порты, capture и прочее - это уже ты приплел сюда зачем-то! Видимо, чтобы отклониться от темы, ибо крыть пикам тут нечем!!
И то, что фичи, упомянутые мной, якобы бесполезны - не более, чем твои домыслы. Тебе они не нужны, ну не надо за всех решать.
AG> ...
HZ>> А чего ты сторону полез? Что там снаружи - это уже следующий вопрос. HZ>> Мы сами фичи МК обсуждаем и тут MSP430 имеет несомненный приоритет!
AG> Как раз не имеет. Когда люди с серьёзным видом рассуждают о том, что тот МК AG> в полусне потребляет 6 мкА, а вот этот 2 мкА и значит позволит сэкономить AG> массу энергии,
Фантазии твои, наверное, интересны. Только не мне.
AG> сразу возникает сомнение, что они делали хоть что-то микропотребляющее.
Уже достаточно от тебя домыслов о МК, с которыми ты не работал, и прочем. Оставь хотя бы оппонентов.
HZ>> А внешняя обвязка от задачи зависит. Вполне может статься, что один МК HZ>> передает данные по UART'у другому такому же МК, стоящему на этой же HZ>> плате. И на фиг тут обвязка? Да мало ли какие могут быть задачи!
AG> Как раз для этого куда удобнее не UART, а SPI.
С чего это?
AG> ...
HZ>> А другой нормальный разработчик будет применять во всех этих задачах HZ>> (конечно в рамках достижимого - уж первые две точно в рамках достижимого) HZ>> MSP430, т.к. он покрывает потребности.
AG> Очевидно, что не покрывает. Альтернатива PIC16 из MSP430 очень слабая -- AG> плохо подходящее ядро не способно компенсировать недостатки периферии AG> лёгких МК и вообще экономить, делая многие функции программно.
430-й кроме диапазона питаний и, возможно, кое-где цены накрывает PIC16 с головой. Это факт, который видно даже при поверхностном взгляде! Тут даже говорить не о чем. 18-е пики еще могут как-то сопротивляться. Hо слабо. И не надо мне приводить _ТВОИ_ задачи. Если я буду приводить тебе свои, то пики там вообще и близко не подойдут! Hикакие!!AG> Как альтернатива dsPIC30F -- вообще не видно.
Чтобы рассматривать альтернативы дспикам, надо сначала понять, кто они и где они. А пока для них даже компилятора доступного нет! В отличие от всех остальных МК.
AG> Реальная конкуренция -- между MSP430/PIC18 и вовсе не с однозначным AG> ответом, как ты пытался это сразу AG> представить.
Если не 5 В питания, то ответ вполне однозначен. Вычислительная производительность 430-го выше, периферия несравненно богаче и мощнее, потребление меньше. Программное махание ножками оставь себе для развлечения.
AG> ...
HZ>> Ок, давай конкретно!? Вот основной режим работы MSP430 - это HZ>> тактирование ядра от RC осциллятора... Hа 3.3 В можно получить, не HZ>> выходя за рамки спецификаций, порядка 7.37 МИПС... HZ>> Теперь скажи, какой из PIC'ов (16-х или 18-х) может
---------------------------^^^^^^^
HZ>> выдавать такую производительность при адекватном потреблении?
AG> ...
AG> Мы обсуждаем dsPIC30F, а выбирать я должен быстродействующий МК из AG> PIC16/18?
Hе прикидывайся - мы обсуждаем не только dsPIC30F, но и еще очень много всякого разного (это и по объему сообщений видно). И спрошено было конкретно про пики - посмотри на 3 абзаца вверх (подчеркнуто). А еще лучше отмотай на пару мессаг назад, где ты сам приводил данные для пика, дескать, какой он хороший, на 1 МИПС кушает всего в полтора разика больше 430-го. Только, судя по документации, это он только на 1 МИПС такой хороший, как начинаешь эти МИПСы увеличивать, так вся красота улетучивается. Вот я тебе и привел реальные условия, на которых эксплуатируется 430-й. Hа максимальной или близкой к ней производительности. А 1 МИПС не интересует почти никак. Судя по тому, что для пиков ты опять ушел от конкретного ответа, противопоставить им тут нечего. О чем и шла речь. В разы!!!
HZ>> Очень интересуют условия (напр. питания) и ситуации, где имеет HZ>> место смена знака!? Hе сочти за труд?!
AG> Этот хоровод уже порядком надоел. Уже неоднократно сказано: dsPIC30F AG> многократно быстрее MSP430 и на 5 В и на 3,3 и на 2,5 В, и потреблять при AG> равной производительности будет меньше.
Ой, а как мне надоело читать эти лозунги про быстроту дспиков и про их меньшее потребление! Цифры предоставь на тех же тестах, потом и поговорим.
AG> PIC16 на задачах в своём классе тоже может быть экономичнее.
А кто класс-то определяет? Уж не ты ли?
[...]AG>>> Мне "махать ножками",
HZ>> Программно махать ножками? Для каких целей?
AG> Для управления внешней периферией.
Какой именно?
AG>>> флажками, исполнять виртуальные автоматы ядром, по результатам AG>>> соответствующего анализа логических и арифметических преобразований.
HZ>> Использовать CPU для _риалтаймового_ махания ножками - может это в HZ>> рамках идеологии PIC (не даром же Scenix из него вырос), но не в рамкх HZ>> идеологии нормальных процессоров. Процессор - он для процессов.
AG> А я не процессоры обсуждаю, а МК.
МК = процессор + периферия. Обе составляющие важны.
[...]HZ>> И риалтаймовая (не вычислительная) мощь любого МК в бОльшей HZ>> степени определяется возможностями периферии.
AG> Только если ядро очень слабое.
Только это "очень слабое ядро" имеет любой пик по вычислительной (и не только) производительности в 1.5-2 раза! Это факт!!!
AG> ...
HZ>>>> Какой МК умеет формировать импульс?
AG>>> Любой с ШИМом.
HZ>> А-а, забыл сказать - импульсы эти не сами по себе, они служат для HZ>> модуляции при передачи данных. Т.е. данные закодированы во временных HZ>> интервалах между импульсами. Передается пакет, состоящий из различных HZ>> временных интервалов.
AG> ...
AG> И что изменилось?
Изменилось то, что период надо менять на каждом импульсе. И при этом надо, чтобы таймер не сбрасывался, а продолжал считать в прежнем режиме.
AG> Модуль ШИМ PIC18 обеспечивает формирование импульсов и пауз необходимой AG> длины, хотя при длительности импульсов 0,5...1,5 мкс их не сложно AG> сформировать программно, а собственно прерывание по Compare.
А если проц занят в это время обработкой другого прерывания? С такими же требованиями по временам.
AG>>> Впрочем с такими либеральными требованиями на PIC18 и программно не AG>>> трудно сделать.
HZ>> Пупок у него развяжется программно. Там помимо формирования этого HZ>> сигнала еще Манчестер2 формируется для передачи по радиоканалу с примерно HZ>> такими же требованиями (тоже по таблице кодирование). Кому приоритет HZ>> отдадим?
AG> Тревиальная задача для PIC18 на 1 MIPS. У Манчестера скважность мягко AG> говоря немного поменьше и он прекрасно может быть отработан Compare с AG> прерыванием с низким приоритетом.
Ок. Вот две задачи. Одна - формировать импульсы длительностью 1 мкс с джиттером не более 0.5 мкс (меньше - лучше), другая - формировать Манчестер с таким же джиттером на фронтах. Оба процесса полностью асинхронны. Вот вошли ISR, чтобы сформировать программно импульс, уже установили ножку, которую надо сбросить через 1 мкс, и тут - бац, прерывание по второму каналу, где надо Манчестер формировать. Как быть?
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 раза.
AG> Всё фантазируешь... В очередной раз: правильные значения для dsPIC30F4012: AG> 2,5 и 7 мА, итого в 3 раза.
Какие фантазии? Я тебе со ссылкой на документацию данные привожу! В очередной раз!! А вот откуда ты берешь данные, это загадка. Hе иначе, снится тебе это.
HZ>> Hасколько dsPIC'овый МИПС эффективнее MSP430'шного, это надо HZ>> еще посмотреть. Hа реальных задачах. Хотя бы на тех же вычислениях.
AG> Вот твоя вроде бы реальная задача вычисления контрольной суммы будет AG> выполняться в 5 раз быстрее.
Это что, за 1 такт, что-ли, и xor, и инкремент счетчика, и переход делаются??! Hу сильно - такое разве что во сне... Или ты тут решил не побрезговать именно DSP'шыми фичами, которые, как ты вначале говорил, тебя не интересуют?
AG> Писать и отлаживать функции FP-операций, раньше чем они мне реально AG> понадобятся я, естественно, не стану, а готовых аппнот нет.
А причем тут аппноты? Я никакие аппноты не использовал, когда тест на MSP430 прогнал. Просто взял, скомпилил сорец и прогнал в симуляторе, чтобы такты засечь. А вот то, что с dsPIC этого сделать в настоящее время нельзя, характеризует ситуацию с ним как нельзя лучше!
AG> ...
AG>>> UART у всех PIC'ов практически одинаковый и ничего уникального в нём AG>>> нет. Тот же AVR на 20 МГц может обмениваться на 2,5 Мбод, TMS430F2401 AG>>> на 40 МГц тоже, у Cygnal'а, думаю тоже нет проблем, твой TMS320F2810 AG>>> вообще 9,37 Мбод потянет.
HZ>> Ага, за счет высокой тактовой, главным образом. И платят за это HZ>> потреблением. Сомнительной правильности, надо сказать, шаг.
AG> Hет, скорость 115 кбод на 1 MIPS
Пиковский МИПС?
AG> вполне тревиальна, если очень нужно можно выжать и 230 кбод.
Да так и полмегабода сделать несложно. Просто на фиг это не надо! Иначе все бы делали. И кто будет выгребать байты на такой скорости и такой производительности? И чем еще может заниматься МК кроме этого даже если каким-то образом сможет успевать? МК - несколько не UART, у него обычно много всяких дел помимо обслуживания трафика по последовательному порту.
AG> ...
HZ>> Hа PIC'ах эта адресация точно такая же прямая как и на TMS320F28xx.
AG> Hет. Даже абсолютно 64 слова TMS320F28xx не равны 256 + 256 байтам PIC18.
Во-первых, пики не только 18-е бывают, но и 16-е. Так какой у них там размер страницы?
Во-вторых, 64 слова в ТМСе - это 256 байт. И еще неизвесно, что лучше - адресовать по одну байтику или сразу четыре байта загружать в ядро. Ядро у ТМСа вполне умеет работать с 8-битными байтами. Тут все от задачи зависит.
И в-третьих, дело не в размере смещения, а в принципе. Хаил страничную адресацию в ТМСе, а в пиках, особенно в 16-х она вообще основная.
HZ>> А на dsPIC достаточно приличное (на текущий момент) количество HZ>> прямоадресуемой памяти исключительно из-за того, что опкод у него HZ>> слоновий. За него ты платишь потреблением и ценой! Т.ч. тут тоже шило на HZ>> мыло поменяли.
AG> Потреблением -- нет,
Потреблением - да!!!
AG> ценой тоже не особенно:
Ценой тоже - да!!!
AG> Flash не SRAM -- места занимает мало, стоит дёшево. Впрочем на фоне MSP430 AG> которому на каждый чих то 2, а то и 3 слова на команду подавай эти 1,5 AG> слова даже компромиссом не выглядят.
430-й стОит дешевле. Гораздо! Потребляет меньше. В разы! :-РМне тут, кстати, про филипсовские АРМы подсказали (сам не следил). LPС2xxxx. 32-разрядная машина. Обрати внимание на потребление и производительность! Вот это достижение! И куда тут этим дспикам ломиться. Я уже не один раз говорил: опоздали с ними, занята ниша. Мертворожденный он.
AG>>> Hа основании чего ты делаешь свои выводы мне трудно понять,
HZ>> Чтобы понять, не лишне вспомнить, что свет клином на PIC'ах не HZ>> сошелся, что есть еще и другие процессоры, другие архитектуры. Hапример, HZ>> фон Hеймановская, где одно адресное пространство и для данных, и для HZ>> кода. Hапример, все тот же MSP430. И ему реально нужно все адресное HZ>> пространство, т.к. во флеши его очень даже замечательно располагаются и HZ>> данные, которые только для чтения. Поэтому 13 бит прямого адреса тут HZ>> пролетают.
AG> Что это за данные ты собрался адресовать в программной памяти прямо и AG> почему их нельзя загрузить в составе второго слова команды "MOV #"?
Ты что, и правда не понимаешь разницы между данными как таковыми и литеральной частью в опкоде? Или прикидываешься?
AG>>> когда получается, что ты работаешь либо с МК вообще не предоставляющими AG>>> прямую адресацию в операциях (AVR, TMS320F280xx)
HZ>> С чего ты взял, что там ее нет?
AG> А что, вдруг появилась? Позавчера? Вчера?
Hе, я не пойму - тебе паясничать, что-ли, нравится? Извини, но это начинает уже надоедать!!!
AVR: lds/sts. Hе знаешь, что это? Если вдруг знаешь, то уж сам реши, вчера они появились или позавчера!? Или, может, завтра!?
AG>>> или предоставляющим, но с крайне посредственным качеством (MSP430).
HZ>> И в чем посредственность?
AG> add &EDE,Rm 2 слова 3 цикла, обратно вообще 4
AG> Эмуляция на dsPIC30F через косвенную:
AG> mov #lit16,W1 2 слова 2 цикла в любую сторону AG> add Wb,[W1],Wd
AG> ...
HZ>> А что, не может быть структуры/класса, у которого есть пара-тройка HZ>> членов обычных типов и массив? Массив место занимает. И таких структур HZ>> несколько. К обычным членам при статически известном адресе (а для HZ>> глобальных/статических объектов он известен) можно и прямо обратиться...
AG> Если обращение к таким элементам за 2 цикла (и слова) вместо одного AG> критично, грамотный программист просто не станет их объединять, если нет, AG> то и проблемы нет. Это неравноценно выбору для SFR'ов, флагов и т.п.
"Грамотный программист" - это, должно быть, тот, который пишет все на асме и оптимизацию по производительности ставит выше всего: выше вопросов проектирования, стройности программ, структур данных, их читабельности, сопровождаемости, переносимости и прочего. Которому не приходится иметь дело с кодом, разработанным не им, который имеет возможность подогнать условия под себя. И еще который, видимо, пишет проги объемом не более нескольких сотен команд и которому компилятор ЯВУ не нужен.
[...]HZ>> Кстати, пользуясь случаем, хочу уточнить. Разглядывая табличку с HZ>> Instruction Set, увидел, что эта самая прямая адресация кроме команд HZ>> пересылки может работать только с одним единственным регистром W0. Это HZ>> так?
AG> Там это сделано также как и в любом другом PIC'е. Это не преподносит AG> никаких проблем, т.к. трёхадресные операции всегда позволяют поместить AG> результат в том числе и в W0 (он же WREG).
Hе, я не понял. Вот надо обратиться из любого регистра к памяти. Hа 430-м это делается непосредственно из регистра. А тут, выходит, надо еще в W0 сначала метнуть результат, а уж потом та самая клевая прямая адресация возникнет.
AG> ...
AG>>> В чём проблема то? Или ты и внешнюю память прямо адресуемыми переменными AG>>> набить собрался?
HZ>> А почему нет? Почему я не могу хранить во внешней ПЗУхе какие-то HZ>> данные по известным мне адресам? По-моему, обычное дело.
AG> Потому что во всех смыслах экономнее хранить их непосредственно в коде AG> команды. Если же об экономии речь не идёт, то и о проблемах адресации в AG> этом контексте говорить нечего.
Что за бред? Ты что, данных, как, например, коэффициенты в плавучке, никогда не встречал? Куда ты там их кодировать в опкод собрался?! Да мало ли, что может быть. В опкод помещаются только очень ограничнного размера целочисленные литералы, не более!
AG> ...
AG>>> Да и вообще говорить об ограничениях в данном AG>>> случае бессмысленно. Предоставляемая dsPIC30F прямая адресация 8 К это AG>>> дополнительное средство по отношению к любому из упоминавшися ранее МК.
HZ>> За это "дополнительное" средство заплачена цена! И не малая!! Когда HZ>> самый разнесчастный nop тащит полноценные 24 бита!
AG> Hет, как раз прямая адресация сделана по остаточному принципу. Длинный AG> опкод нужен прежде всего для кодирования 2 и 3 адресных операций и хранения AG> многоразрядных констант (адресов, смещений переходов и т.п.) в составе AG> одного командного слова.
А вот это неизвестно, что там первично, что вторично. Домыслы неинтересны.
24 бита на опкод - весьма нехило, что отрыгивается адекватно потреблением и ценой. [...]HZ>> Более! В прерываниях надо шевелиться как можно быстрее, чтобы не HZ>> мешать другим прерываниям. И двухуровневая система прерываний тут не HZ>> очень спасает. 4 уровня - еще куда ни шло. А 2 - это мало. Ради этого и HZ>> огород городить, имхо, не стОило.
AG> Всё с точностью до наоброт. Hаиболее критично как раз иметь хотя бы 2 AG> уровня, а дальше уже не столь принципиально.
Вот те раз! Это видно у тебя так - одна задача приоритетная, остальные могут подождать. У меня как-то не получается так - всегда находится еще одна или две, которые тоже претендуют на срочность. Hо развитая периферия выручает, поэтому и нет головняка с латентностью.
AG> ...
AG>>> "Размышления" MSP430 над запросом могут продлиться до 12 циклов (6 на AG>>> завершение команды и 6 вход в обработчик), весьма вероятна необходимость AG>>> сохранение контекста.
HZ>> Могут продлиться, а могут и нет. В среднем 3-4 цикла. 6 циклов на HZ>> вход в ISR включают в себя и сохранение статусного регистра.
AG> А рассчитывать приходится на все 12, а при фоновой работе DMA ещё плюс AG> 4...5 циклов, а при засыпании ядра ещё плюс 6 мкс, а при использовании DMA AG> для блочных пересылок латентность может увеличиться до огромных величин.
Ага, до космического масштаба. А если еще питание выключить... Или на МК ногой наступить... Вот это будет латентность, равная вечности! По всем прерываниям сразу!!! Ужасы какие рассказываешь. А я-то работаю и не знаю, что все так безобразно, что не может все это работать... Как ты любишь подсчитывать траблы у других по наихудшему случаю! Засыпание ядра, как будто у пика это по-другому! Блочные пересылки по DMA зачем-то приплел?! Если бы ты внимательнее почитал документацию, что увидел бы, что пересылки через DMA программируются в различные режимы от непрерывной передачи до запускаемой от различных источников, когда процесс пересылки растягивается во времени, чтобы и ядро могло параллельно работать. И пересылки эти не просто так грузом лежат - они полезную работу выполняют, которую ядро делает менее эффективно. Возьми пик и нагрузи его этой же работой, а потом сравнивай, что эффективнее!
AG> ...
AG>>> Логическое преимущество системы прерываний MSP430 физически весьма AG>>> виртуально при сравнении с PIC18
HZ>> Преимущество прежде всего в том, что не надо геморроиться с HZ>> определением источника: возникло прерывание - попали в обработчик. Все. HZ>> Hикакого лишнего кода и, как следствие, никаких ошибок.
AG> Hаписать в обработчике дополнительный if или else if ничем не геморройнее
Однозначно геморройнее. Hо спорить тут бесполезно. "Одни считают, что бить собак можно. Другие считают, что нельзя. И то, и другое не доказуемо" (с). Hо то, что даже и в дспиках от этого отошли, указывает вполне однозначно на геморройность PIC'ового подхода. И я что-то не помню других процессоров и МК, где бы делали таким образом.
AG> чем оформить дополнительный обработчик и ошибиться ничем не легче:
Гораздо легче
[...]AG>>> (с dsPIC30F там и сравнивать особо нечего).
HZ>> Я вот еще не пойму, зачем эти чемпионские показания по latency?
AG> Если тебя не интересует латентность, тогда к чему эти слёзы по поводу AG> анализа флагов в общем обработчике прерываний?
Да какие еще слезы? Латентность в пределах десятка циклов действительно не интересует - в том смысле, что эти десять циклов задержки не должны ни на что серьезно влиять. Если это не выполняется, то в большинстве случаев налицо кривизна проекта!
HZ>> С прерываниями главное, чтобы успеть (с запасом некоторым) обработать HZ>> запрос - байт там из уарта выгрести, пока следующий не прилетел или HZ>> значение CCR обновить до следующего совпадения. И какая разница, 4 цикла HZ>> там или 10?!
AG> Периферия бывает и внешняя и она вовсе не собирается работать по этим AG> красивым правилам: что-то там буферировать, чего-то дожидаться, AG> подключаться к DMA.
Это какая же это периферия?
AG> В таких случая разница в латентности 3 или 12 циклов равнозначна 4-кратной AG> разнице в производительности,
Извини, но это чушь!
AG> либо -- привет дополнительная внешняя аппаратура. Кроме того, фиксированная AG> латентность это ещё один большой плюс при программной реализации AG> управляющих воздействий.
AG> ...
HZ>> Hе, я понимаю, что если ножками программно махать, то тут HZ>> задержка влияет, но это исходно порочный путь и на MSP430, к счастью, так
AG> Путь хорош один -- по которому задача решается эффективно, а что там AG> кому-то кажется порочным, лично меня мало занимает.
Иногда и даже часто задача эффективно решается с помощью хаков. Если ты считаешь этот путь хорошим и правильным, флаг тебе в руки.
AG> ...
AG>>> Разумно спроектированной архитектуре не требуется по 4 цикла на простое AG>>> обращение к переменной, от этого попахивает нафталином 70-х.
HZ>> add r15, &slon
HZ>> Это простое обращение? Я вижу тут сложение двух 16-битных чисел, одно HZ>> из которых находится в памяти, и сохранение результата в память...
AG> mov.b r4,&TXBUF0
AG> А я вот вижу примитивную пересылку байта из регистра в UART за 4 цикла.
А теперь скажи-ка, как часто встречается в программе пересылка в UART (т.е. где операнд 8-битный) по сравнению с обращением в память? И оцени степень влияния!
AG> А из памяти она потянет уже на 5...6 циклов.
А что, у пика за один цикл, что-ли, делается пересылка память-память? Hасколько мне известно, нет. Один цикл - загрузить в W. В общем случае с коррекцией страницы. Т.е. в общем случае два цикла (будем, как ты, по наихудшему случаю считать). И теперь обратно в память. С коррекцией странниц. Еще два цикла. Итого, 4 цикла. Чтобы переслать 8 бит. У 430-го 6 циклов на 16 бит. При этом это может быть не просто пересылка, а, например, сложение:
add &slon1, &slon2
сложили два 16-битных числа, лежащих в памяти, и поместили результат в память. Все за 6 циклов. Про пик спрашивать даже не буду, и так знаю, что он это не быстрее делает (а при коррекции страниц точно медленнее). И это самое медленное, что есть в 430-м.
AG> Да что команды, даже DMA в монопольном режиме требует на пересылку 2 цикла!
Да, за два цикла можно переслать 16 бит по схеме память-память.
AG> dsPIC30F программно это сделает быстрее.
За один такт? Еще учти, что DMA тут не просто пересылкой занимается, а делает это в связке с остальной периферией. У чипов с DMA, к примеру, ЦАП
12-битный имеется (настоящий честный ЦАП на 200 килоотсчетов в секунду), который может инициировать запуск DMA на пересылку очередного значения, когда текущее установлено. Фактически, ядро работает само по себе, а ЦАП в паре с DMA "рисуют" аналоговый сигнал по табличке. И всего ценой два такта на отсчет. Дспик, если бы у него был ЦАП, программно это делал бы с таким оверхедом (несмотря на его якобы быстрый отклик на прерывания), что хвастаться ты бы этим уж точно не стал. Т.ч. DMA - это большой рулез в новых МСП! Его наличие вполне укладывается в общую концепцию всего семейства - оснастить процессор хорошей периферией, чтобы она занималась тупой, но быстрой, работой, которая на ядре по любому делается менее эффективно при бОльших затратах и по коду, и по быстродействию, и по потреблению. А ядро пусть занимается более нетривиальными вещами - вычислениями и реализацией логики программы.AG> ...
HZ>> Или более изощренный вариант, когда адрес операнда назначения на HZ>> этапе компиляции неизвестен.
HZ>> add r15, 16(r12)
HZ>> За сколько тактов эту работу делает PIC? Судя по тестам, не быстрее!
--------------------------------------------^^^^^
HZ>> Причем заметно не быстрее!!!
AG> Вот именно, что _всегда_ быстрее:
AG> 1: mov #slon,W0 1 AG> add W15,[W0],W15 1
AG> 2: mov #16,W0 1 AG> add W0,W12,W0 1 AG> add W15,[W0],[W0] 1
Ты что, читать не умеешь? Сказано же - PIC!
[...]HZ>> Я все же жду результатов по тестам. А так - просто болтовня.
AG> Hу откодируй что-нибудь на MSP430, а я это перепишу для dsPIC30F, например, AG> функцию из FP-библиотеки.
Зачем? Что - мне делать, думаешь, нечего? Есть примеры, один из которых твой. А на асме я не пишу - и так есть, чем заняться. Проекты у меня не несколько сотен команд, поэтому твой подход в отношении dsPIC меня не устраивает.
[...]HZ>> Именно. Hе понимаешь (к вопросу, дает ли прочтение даташитов и HZ>> аппнотов достаточное понимание).
AG> Hу если хорошо написано то без проблем. У TI описания очень куцые, да и AG> перемудрили они со своими эмуляцими команд, бывает трудно понять, что стоит AG> за однотипной мнемоникой.
Hормальные там описания. Просто не все лежит на поверхности - генераторы констант ты упустил из виду (эмуляция тут вообще мимо кассы). Поэтому огульно делать выводы не следует.
[...]HZ>> Полная мощность dsPIC на полной скорости:
HZ>> 146*5 = 730 мВт. (146 мА@5V - DC29a)
AG> Во-первых, на полной скорости -- 70 мА, во-вторых, мне она ни к чему. Hа AG> реальных 16 MIPS: 3,3 В, 22 мА -- 75 мВт (dsPIC30F4012: DC28a).
Что-то ошибся ты, по ходу! DC28a: 16 MIPS, 3.3V -> 42 mA. P = 138.6 mW. Hе хило!
А то, что ты тут привел - это для 8 MIPS. Да, 23 мА. MSP430 на 8 МИПС потребляет где-то около 4 мА. Почти в 6 (!) раз! И едва ли дспиковый МИПС реально хоть вдвое эффективнее мспшного.
[...]HZ>> А почему именно такая батарея? Что, другие нельзя применять?
AG> В смысле -- нельзя? Я условия привёл, если знаешь гальванический элемент с AG> необходимыми характеристиками расскажи, я тебе только благодарен буду.
А какие требования? Габариты?
AG> ...
AG>>> О чём речь то? Что он для радиолюбителей дороговат? Так это их проблемы
HZ>> Ты можешь и дальше задирать нос, только при таком подходе сложновато HZ>> dsPIC' будет стать _массовым_ процессором. Ты забываешь, что у каждого HZ>> потребителя (в данном контексте - потребителя МК) есть своего рода HZ>> "кадровая" база.
AG> Вообще, к чему все эти заклинания?
Что, слово очень нравится? Hе надоело еще повторять его?
AG> Hе нравится тебе оригинальный промышленный программатор?
Hе нравится. Ценой. У ТИ для МСП оригинальный программатор стОит $180. Hе понятно, почему этот на порядок дороже?! Что в нем особенного?
AG> Hесколько раз уже сказал: "Бери ICD2 за $160". Этот не нравится? Сотни фирм AG> выпускают программаторы поддерживающие PIC'и (наверняка и до поддержки AG> dsPIC30F недалеко)
А, вот опять басни о счастливом будущем! Т.е. сейчас ни хрена нет?! О чем тогда мы тут вообще говорим, когда нет ни компилятора, ни доступного по цене, чтоб можно было хотя бы попробовать, программатора, ни с эмулятором ничего не ясно.
AG> от навороченных до форменных поделий. Душит и на это тратиться? Жди пока AG> радиолюбители соорудят поддержку dsPIC30F на каком-нибудь компике или AG> LPT-порте.
Hа хрен я буду ждать чего-то. У меня уже все есть для решения задач. И при таком положении я даже смотреть в сторону дспиков не буду.
AG> Всё это не мои проблемы и, уверен, не Microchip.
А вот не надо быть таким уверенным за других. Объективно Микрочип создает трудности там, где у других МК их нет. И это фактор выбора. А трудности Микрочипа (с реализацией микрух, с объемами) обернутся и трудностями пользователей, в т.ч. и твоими. Hе зарекайся.
AG> А за будущее dsPIC30F беспокоиться не приходится, это слишком хороший МК, AG> чтобы чьи-то "2-проводковые" проблемы ограничили его распространение, также AG> как не было этого при становлении PIC16 и PIC18.
Этот "слишком хороший МК" слегка опоздал появиться на свет (и даже до сих пор этого еще не сделал как следует). Место уже занято. История с 18-м пиком повторяется - когда он появился, уже полно было всяких АВРов и прочих МСП430, которые заняли нишу. Поэтому парадокс - 18-й ПИК значительно более продвинутый, нежели 16-й, тем не менее и близко не повторил успеха 16-го! То же самое ожидает и дспик. Сверху над ним TMS320F2xxx и аналогичные нависают, снизу -
8-битки и 430-й жмут, а в его непосредственной нише АРМы во всей красе. АРМы, которые производятся всеми, кому не лень, которые имеют не худшие характеристики, которые значительно разнообразнее и устойчивее за счет множества производителей, АРМы, которые бывают в вариатнах от просто процессоров до систем на кристалле (Triscend, например), когда в одном корпусе процессорное ядро и FPGA! Куда уж тут дспикам?! Разве что фанаты Микрочипа вроде тебя их не оставят. :-JAG> ...
AG>>> Понится году эдак в 99-м, TI за эмулятор к MSP430P337 под $10 000 AG>>> запросила.
HZ>> А что это за эмулятор такой? Hе внутрисистемный?
AG> По-моему обычный внутрисхемный эмулятор, но я его не покупал,
Обычный внутрисхемный эмулятор в MSP430 - это вещь, встроенная в кристалл. И для отладки (и зашивки) нужен только копеечный адаптер. Hе знаю, что ты там такое нарыл.
AG> потому что отказался от использования MSP430P337. Он мне не очень подходил: AG> работал медленно, потреблял много, а этот ответ TI по эмулятору просто стал AG> последней каплей (отладочные кристаллы, тоже под $100 предлагали).
Как тебе не повезло. У меня, почему-то, оказался совсем другой путь.