dsPIC и другие... (было AVR vs PIC)

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
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! Куда уж тут дспикам?! Разве что фанаты Микрочипа
вроде тебя их не оставят. :-J

AG> ...

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

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

AG> По-моему обычный внутрисхемный эмулятор, но я его не покупал,

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


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

    Как тебе не повезло. У меня, почему-то, оказался совсем другой путь.


--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
dsPIC и другие... (было AVR vs PIC)
  Привет!

Mon Sep 13 2004 11:00, Harry Zhurov wrote to Alexander Golov:

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

...

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

 HZ>     PIC16 может выигрывать у 430-го только по цене. И то, смотря какие
 HZ> условия.

Не "только по цене", а "и по цене тоже". У конкурентов PIC16 (например,
MSP430F110...123) скроменый набор периферии, практически такое же потребление
на MIPS и ядро с большими потерями времени, понижающее вес MIPS'а.

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

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

 HZ>     А по каким это статьям определяется одноклассность?

Объёмы памяти, набор периферии, цена, размеры -- сплошь объективные
параметры.

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

Нередко маленький МК нужен именно потому что он маленький. Когда же ничего из
вышеуказанного не актуально вряд ли кто-то станет возиться с PIC16.

...

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

 HZ>     Так я не понял, а между измерениями оно чем занимается? И какое общее
 HZ> потребление при этом?

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

...

 AG>> Hичего это не меняет. Я ещё для PIC16C62 делал подобный интерфейс а-ля
 AG>> UART  с помощью capture/compare, работающего во сне.

 HZ>     Это на каждый бит просыпаться? Вот уж на фиг такое счастье!.. Это еще
 HZ> на порядок оверхед - какое уж тут микропотребление?!

Для того времени вполне нормальное микропотребление, порядка 50 мкА. Тот же
PIC совсем без связи потреблял тогда около 30 мкА. Я тебе пример с
обслуживанием АЦП приводил, пару килогерц прерываний от capture обслужить не
сложнее.

 AG>> Hа современных PIC'ах можно сделать ещё проще -- затактовать UART вместе
 AG>> с ядром от кварца 32 768 кГц, 15 мкА не бог весть какое потребление.

 HZ>     И кто из них будет символ-то принимать? UART или ядро?

В чём суть вопроса то? Есть частота на ядре, значит есть везде и на UART'е
тоже. Скорость 2048 бит/с, цена -- 15...20 мкА для PIC16 и менее 10 мкА для
PIC18 (у них есть режим Idle).

...

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

 HZ>     Э-э, не передергивай! Делать пакет выборок АЦП пики не умеют.
 HZ> Иметь низкое соотношение тактовой UART'а и его скорости тоже.
 HZ> Я говорил об этом!

Функционально всё это решается на PIC'ах. А нравится/не нравится -- материя
вне данного спора.

 HZ>  А синхронные порты, capture и прочее - это уже ты приплел сюда
 HZ> зачем-то! Видимо, чтобы отклониться от темы, ибо крыть пикам тут нечем!!

Мои глаза мне говорят об обратном:

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

Это вопрос который я в этой подветке обсуждаю и причём тут исключительно АЦП
и UART'ы не очень понятно.

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

Это факты изложенные в цифрах.

...

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

 HZ>     Фантазии твои, наверное, интересны. Только не мне.

Чтобы сделать оценку навскидку ничего придумывать не нужно, достаточно
почитать даташиты от TI: Comparator_A Idd -- 45 мкА, SVS Icc -- 10 мкА,
Iadc12 -- 800 мкА, Iref+ -- 500 мкА, Isensor -- 60 мкА, DAC12 -- 50...700 мкА
на канал в зависимости от режима усилителя.

Если не убедительно, тогда покажи, например, надёжно работающую схему на
пяток дискретных входов с полосой герц 100 и потреблением, скажем, 1 мкА.
Аналоговые узлы (усилители, фильтры, ИОН) с таким же потреблением, которые
будут работать вместе с нашим якобы ничего не потребляющим АЦП. Примеры
датчиков (или что там?) работающих при таких токах. Интересно было бы
посмотреть на схемы тех самых распределённых линий и их трансиверы с
потреблением в единицы микроампер.

...

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

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

 HZ>     С чего это?

Быстро, надёжно, шина может делиться с другими периферийными ИС. Да и UART
остаётся свободным для более подходящих ему целей (или становится
необязательным при отсутствии таковых).

...

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

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

Да, мне приходится обсуждать каждый твой заворот на очередную архитектуру, но
ты подключился к ветке, когда я в ней говорил про dsPIC30F, а я всегда
обсуждаю ту тему, которую начал. Там я говорил, что dsPIC30F -- тоже PIC'и,
что это очень эффективные МК и на данный момент убеждён в этом ещё больше.

...

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

 AG>> И что изменилось?

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

Меняй хоть десять раз на импульс, таймер сбросится (а PWM выработает импульс)
только при совпадении со значением в PR.

...

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

Я ещё в прошлый раз всё описал: Манчестер на низком приоритете формируется
Compare, импульс на высоком, длительность 1 мкс -- программно при 1 MIPS,
дополнительный джиттер отсутствует. Всё тоже самое можно сделать на одном
низком приоритете и двух аппаратных каналах: Compare и ШИМ.

...

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

 HZ>     Это что, за 1 такт, что-ли, и xor, и инкремент счетчика, и переход
 HZ> делаются??! Hу сильно - такое разве что во сне...

Да нет, наяву:

     repeat  W1
     xor     W0,[W2++],W0

1 цикл нужен для команды repeat и в дальнейшем тело (xor) выполяется в каждом
цикле.

...

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

 AG>> Hет. Даже абсолютно 64 слова TMS320F28xx не равны 256 + 256 байтам
 AG>> PIC18.

 HZ>     Во-первых, пики не только 18-е бывают, но и 16-е. Так какой у них там
 HZ> размер страницы?

128 байтов, при этом памяти у них на порядок меньше чем у PIC18. На PIC16
обычно работают с постоянно включённой одной страницей, а далее размещают
косвенно адресуемые данные или локальные данные каких-то алгоритмов не
требующих дополнительных переключений (только вход/выход). В реальности
основное неудобство работы с PIC16 не в этом, а в не слишком удачной модели
адресации SFR'ов и их распределении, то что у PIC18 выше всяких похвал.

...

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

 HZ>     430-й стОит дешевле. Гораздо!

Есть и дороже, есть и дешевле. Те что гораздо дешевле, с теми что гораздо
дороже не сопоставимы никак -- ни по памяти, ни по периферии... а по
производительности ни с какими не соизмеримы.

 HZ> Потребляет меньше. В разы! :-Р

От задачи зависит. Вот на твоей сумме раза в полтора больше.

 HZ>     Мне тут, кстати, про филипсовские АРМы подсказали (сам не следил).
 HZ> LPC2xxxx. 32-разрядная машина.

Теперь ещё одного "чёрта в табакерке" будем обсуждать.

 HZ> Обрати внимание на потребление

На что там обращать внимание? Имеет место одиночный листок из которого
следует только то, что МК при выполнении одной 3-цикловой команды перехода,
которой он к тому же кормится из защёлки, а не Flash, потребляет 30 мА по
источнику 1,8 В, на фоне огромных утечек в статике. Какое потребление при
работе реального кода из Flash? Какое потребление по 3,3 В?  Каковы
зависимости потребления от частоты? Догадывайтесь сами!

 HZ> и производительность! Вот это достижение!

Что там за достижение? Ядро ARM разработано для универсальных компьютеров,
целиком и полностью ориентировано на на многоразрядную арифметику над
локальными данными (в основном в регистрах) и совершенно непригодно для
построения МК обсуждаемого класса. У него медленный доступ к памяти (только
косвенно и только загрузка/выгрузка за 3/2 цикла), а прямые обращения вообще
муки (отдельно стоящая установка бита потянет аж на 9 циклов!).
Дополнительные потери при работе с 8- и 16-разрядными данными, огромная
латентность прерываний, переходы за 3 цикла и необходимость в явном виде
выполнять составляющие операций типа call и link. И эти потери касаются
только голого ядра, а у LPC2x при 60 МГц на него ещё будут навешаны 3
вайт-стейта. При этом никаких костылей в виде периферийных наворотов там нет,
всё достаточно спартанское (разве что GPIO в стиле TMS320F28x).

...


Re: dsPIC и другие... (было AVR vs PIC)
Hello Alexander.

23 Sep 04 19:45, you wrote to Harry Zhurov:

 AG> за 3/2 цикла), а прямые обращения вообще муки (отдельно стоящая
 AG> установка бита потянет аж на 9 циклов!).

Если этот бит в GPIO - то нет. Столько же, как для обычного обращения.
Если программе много битовых переменных - тогда да, _опа. Hо если обработка
битов в регистрах - то все очень радужно.

 AG> Дополнительные потери при
 AG> работе с 8- и 16-разрядными данными,

Hет. Разве что потери места в регистрах.

 AG> необходимость в явном виде выполнять
 AG> составляющие операций типа call и link.

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

 AG> И эти потери касаются только
 AG> голого ядра, а у LPC2x при 60 МГц на него ещё будут навешаны
 AG> 3 вайт-стейта.

При промахе буфера на 128 бит.

 AG> При этом никаких костылей в виде периферийных наворотов
 AG> там нет, всё достаточно спартанское (разве что GPIO в стиле
 AG> TMS320F28x).

Hу, не знаю. Экзотики нет, а то что есть - достаточно навороченное.

Alexey


dsPIC и другие... (было AVR vs PIC)
  Привет!

Fri Sep 24 2004 13:02, Alexey Boyko wrote to Alexander Golov:

ARM...

 AG>> Дополнительные потери при
 AG>> работе с 8- и 16-разрядными данными,

 AB> Hет. Разве что потери места в регистрах.

Ну как же, необходимо приводить результат операции к 8/16-разрядному, иначе
возможно неадекватное поведение. Собственно всё это прямо сказано в AN34.

 AG>> необходимость в явном виде выполнять
 AG>> составляющие операций типа call и link.

 AB> Это я считаю достоинством. Экономит время вызова коротких функций. Hа
 AB> асме, конечно, неудобно.

Экономит только по сравнение с ARM'ом же, если не сохранять.

 AG>> И эти потери касаются только
 AG>> голого ядра, а у LPC2x при 60 МГц на него ещё будут навешаны
 AG>> 3 вайт-стейта.

 AB> При промахе буфера на 128 бит.

Да, например, при любом переходе дальше 4-х команд.


Re: dsPIC и другие... (было AVR vs PIC)

   Alexander, ты ещё здесь сидишь?


Четверг Сентябрь 23 2004 20:45, Alexander Golov wrote to Harry Zhurov:

[поскипано]

 HZ>> Hе прикидывайся - мы обсуждаем не только dsPIC30F, но и еще
 HZ>> очень много всякого разного (это и по объему сообщений видно).
 AG> Да, мне приходится обсуждать каждый твой заворот на очередную
 AG> архитектуру, но ты подключился к ветке, когда я в ней говорил про
 AG> dsPIC30F, а я всегда обсуждаю ту тему, которую начал. Там я говорил,
 AG> что dsPIC30F -- тоже PIC'и,

 Это не так. Принадлежность к семейству контроллеров определяется _ядром_.
А они у PIC и dsPIC совершенно разные.

 AG> что это очень эффективные МК и на данный момент убеждён в этом ещё
 AG> больше.

 Вот только когда работа с ними станет дешёвой?..

[поскипано]


                                                   Георгий


dsPIC и другие... (было AVR vs PIC)
  Привет!

Fri Sep 24 2004 23:48, George Shepelev wrote to Alexander Golov:

...

 AG>> ...ты подключился к ветке, когда я в ней говорил про
 AG>> dsPIC30F, а я всегда обсуждаю ту тему, которую начал. Там я говорил,
 AG>> что dsPIC30F -- тоже PIC'и,

 GS>  Это не так. Принадлежность к семейству контроллеров определяется
 GS> _ядром_.
 GS> А они у PIC и dsPIC совершенно разные.

Они и у PIC16 c PIC16C54 отличаются не говоря уже о PIC18, но ведь их всё
равно всех как PIC'и воспринимают.

 AG>> что это очень эффективные МК и на данный момент убеждён в этом ещё
 AG>> больше.

 GS>  Вот только когда работа с ними станет дешёвой?..

А работа с ними дорога?


dsPIC и другие... (было AVR vs PIC)
Thu, 23 Sep 2004 16:45:46 +0000 (UTC) Alexander Golov wrote to Harry Zhurov:

AG> Mon Sep 13 2004 11:00, Harry Zhurov wrote to Alexander Golov:

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

    Уже прошло две недели, я уже стал забывать, о чем шла речь. Но дело даже не
в этом... Все идет по кругу. Мне есть что аргументировано возразить почти по
каждому пункту, но я не буду этого делать. Дискуссия и так затянулась, мнения
высказаны и неоднократно, убедить оппонента не удается, очевидно, что
дальнейшее ее продолжение приведет только к дальнейшему увеличению трафика и
только. Поэтому на этом сию тему со своей стороны закрываю.


--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
dsPIC и другие... (было AVR vs PIC)
  Привет!

Sat Sep 25 2004 20:00, Harry Zhurov wrote to Alexander Golov:

...

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

 HZ>     Уже прошло две недели, я уже стал забывать, о чем шла речь. Hо дело

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

 HZ> даже не в этом... Все идет по кругу. Мне есть что аргументировано
 HZ> возразить почти по каждому пункту, но я не буду этого делать. Дискуссия и
 HZ> так затянулась, мнения высказаны и неоднократно, убедить оппонента не
 HZ> удается, очевидно, что дальнейшее ее продолжение приведет только к
 HZ> дальнейшему увеличению трафика и только. Поэтому на этом сию тему со
 HZ> своей стороны закрываю.

Не думаю, что наши достаточно редкие послания сильно поднимают трафик. Но как
скажешь...


dsPIC и другие... (было AVR vs PIC)

...

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

 HZ>     AVR: lds/sts. Hе знаешь, что это? Если вдруг знаешь, то уж сам реши,
 HZ> вчера они появились или позавчера!? Или, может, завтра!?

Читай внимательнее: прямая адресация в _операциях_.

...

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

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

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

...

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

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

...

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

 HZ>     А вот это неизвестно, что там первично, что вторично.

Все опкоды приведены в документации. Их несложно изучить и сделать выводы для
чего там нужны 24 разряда и откуда взялись 13 разрядов прямой адресации.

...

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

...

 HZ> Засыпание ядра, как будто у пика это по-другому!

Не я же заявлял про PIC'и, что там основной режим это работа на максимуме
частоты, а остальное время сон, а как раз ты про MSP430.

 HZ> Блочные пересылки по DMA зачем-то приплел?!

Учитывая медленность MSP430 при работе с памятью, это одна из спасительных
палочек.

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

И что, после этого рассказа, DMA перестал отбирать циклы у MSP430, вплоть до
полной остановки, доводя латентность до огромных величин?

 HZ> Возьми пик и нагрузи его этой же
 HZ> работой, а потом сравнивай, что эффективнее!

dsPIC30F программно делает эту работу эффективнее чем DMA у MSP430.

...

 AG>> Hаписать в обработчике дополнительный if или else if ничем не
 AG>> геморройнее

 HZ>     Однозначно геморройнее. Hо спорить тут бесполезно. "Одни считают, что
 HZ> бить собак можно. Другие считают, что нельзя. И то, и другое не
 HZ> доказуемо" (с). Hо то, что даже и в дспиках от этого отошли, указывает
 HZ> вполне однозначно на геморройность PIC'ового подхода.

Гоморройность тут не причём, это позволило dsPIC30F снизить латентность до
очень низкой величины.

...

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

 HZ>     Да какие еще слезы? Латентность в пределах десятка циклов
 HZ> действительно не интересует

Оказывается проблемы и не было! Вопрос закрыт.

...

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

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

Я не знаю что ты под "хаком" подразумеваешь, но если выбор: одна ИС +
напряжение мозгов, или "пяток", зато на Бейсик-библиотеках, то я чаще всего
за первое.

...

 AG>> А я вот вижу примитивную пересылку байта из регистра в UART за 4 цикла.

 HZ>     А теперь скажи-ка, как часто встречается в программе пересылка в UART
 HZ> (т.е. где операнд 8-битный) по сравнению с обращением в память?

В данном случае UART = любой другой SFR или статическая переменная, причём
тут разрядность вообще не понятно.

...

 AG>> А из памяти она потянет уже на 5...6 циклов.

 HZ>     А что, у пика за один цикл, что-ли, делается пересылка память-память?
 HZ> Hасколько мне известно, нет. Один цикл - загрузить в W.

Если ты опять про PIC18, то у него за 2 цикла, без W и страниц, а у dsPIC30F
косвенно за 1, прямо за 2.

...

 HZ> У 430-го 6 циклов на 16 бит. При этом это может быть не просто
 HZ> пересылка, а, например, сложение:

 HZ>     add   &slon1, &slon2
 HZ>     сложили два 16-битных числа, лежащих в памяти, и поместили результат
 HZ> в память. Все за 6 циклов. Про пик спрашивать даже не буду, и так знаю,
 HZ> что он это не быстрее делает

PIC18:
     movfw   slon1     ; 1
     addwf   slon2,f   ; 1
     movfw   slon1+1   ; 1
     addwfc  slon2+1,f ; 1

dsPIC30F:
     mov     slon1,W0  ; 1
     add     slon2     ; 1

...

 AG>> Да что команды, даже DMA в монопольном режиме требует на пересылку 2
 AG>> цикла!

 HZ>     Да, за два цикла можно переслать 16 бит по схеме память-память.

 AG>> dsPIC30F программно это сделает быстрее.

 HZ>     За один такт? Еще учти, что DMA тут не просто пересылкой занимается,
 HZ> а делает это в связке с остальной периферией. У чипов с DMA, к примеру,
 HZ> ЦАП 12-битный имеется (настоящий честный ЦАП на 200 килоотсчетов в
 HZ> секунду), который может инициировать запуск DMA на пересылку очередного
 HZ> значения, когда текущее установлено. Фактически, ядро работает само по
 HZ> себе, а ЦАП в паре с DMA "рисуют" аналоговый сигнал по табличке. И всего
 HZ> ценой два такта на отсчет.

Не два, а четыре, два -- только в монопольном режиме. Но в том то и дело, что
dsPIC30F на всю обработку прерывания, скажем от АЦП (вход, выход, пересылку
16 значений), нужно меньше времени чем DMA MSP430 на одну только пересылку
этих же 16 значений в монопольном режиме:

                              4
     push.d    w0             2
     mov       #adcbuf0,w1    1
     mov       BufAdr,wreg    1
     mov       [w1++],[w0++]  1
     ...                     15
     mov       wreg,BufAdr    1
     pop.d     w0             2
     bclr      adif           1
     retfie                   3
                            ----
                             31

И тут нельзя забывать, что для монопольной передачи MSP430 ещё нужно в
прерывание войти/выйти и DMA настроить, а в бакграунде уже сам DMA будет
пересылать вдвое медленнее чем dsPIC30F программно, заходя в прерывания.

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

:)

...

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

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

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

Тогда претензии про болтовню адресуй к себе.

...

 AG>> У TI описания очень куцые...

 HZ>     Hормальные там описания. Просто не все лежит на поверхности -
 HZ> генераторы констант ты упустил из виду (эмуляция тут вообще мимо кассы).

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

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

...

 HZ>     Что-то ошибся ты, по ходу! DC28a: 16 MIPS, 3.3V -> 42 mA. P = 138.6
 HZ> mW. Hе хило!

 HZ>     А то, что ты тут привел - это для 8 MIPS.

Нет. Верная инфорация 16 MIPS, 3,3 В -- 22 мА, 40 мА это при 5 В. Читай
документацию на указанные ИС (DS70135A), а не на непонятно что.

...

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

 HZ>     А какие требования? Габариты?

Я же писал: прибор должен не менее 2-х месяцев отдежурить, и не менее 2-х
часов отработать при -20...+70 С. Размер CR-123: диаметр 17, длина 34,5,
масса 17 г. По даташиту у Panasonic CR-123 максимальный продолжительный ток
20 мА и импульсный 1,4 А. Экспериментально было установлено, что DL-123 от
Duracell 100 мА (2,8 В при -20 С) продолжительно выдерживает без проблем.

...

 HZ>     Hе нравится. Ценой. У ТИ для МСП оригинальный программатор стОит
 HZ> $180. Hе понятно, почему этот на порядок дороже?! Что в нем особенного?

Почему на порядок? Он стоит $900, а не $1800. А TI продаёт за $180
stand-alone программатор?

...

 HZ>     Hа хрен я буду ждать чего-то. У меня уже все есть для решения задач.
 HZ> И при таком положении я даже смотреть в сторону дспиков не буду.

Я так и не понял, что не так с ICD2?

...

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

 AG>> По-моему обычный внутрисхемный эмулятор, но я его не покупал,

 HZ>     Обычный внутрисхемный эмулятор в MSP430 - это вещь, встроенная в
 HZ> кристалл.

И что же он тащит на себе аппаратуру эмулятора? Может у него ещё и Tracing
memory на борту есть и он обеспечивает триггеринг по внешним и внутренним
аппаратным событиям?


dsPIC и другие... (было AVR vs PIC)
Mon Sep 13 2004 11:00, Harry Zhurov wrote to Alexander Golov:

 HZ>     Обычный внутрисхемный эмулятор в MSP430 - это вещь, встроенная в
 HZ> кристалл.

То, что встроено в кристалл MSP430, не является "обычным внутрисхемным
эмулятором". Это недоэмулятор (типа "для студентов и отсталых районов" :). У
него всего три брекпойнта, периферия не останавливается при остановке чипа, и
т.п (я работал с FET149). На безрыбье и он сгодится, но все же после
нормального пиковского эмулятора я долго ругался разными словами на это
сиротское поделие. Т.к. отлаживаться с его помощью неэффективно, на простейшие
вещи уходит масса времени. Даже время исполнения кусков кода померять нельзя.
Или пройти по шагам по программе, если в моей проге включено прерывание по
таймеру -  недоэмулятор тут же шагнет в ISR, и так и будет ходить вечно по
телу ISR. Настоящий эмулятор MSP430 стоит десяток колобаксов, дороже чем
нормальные эмуляторы для конкурирующих процев.

 HZ> И для отладки (и зашивки) нужен только копеечный адаптер.

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

Пока,                                 Алексей


dsPIC и другие... (было AVR vs PIC)
Fri, 24 Sep 2004 11:48:04 +0000 (UTC) Alex Kouznetsov wrote to Harry Zhurov:

HZ>>     Обычный внутрисхемный эмулятор в MSP430 - это вещь, встроенная в
HZ>> кристалл.

AK> То, что встроено в кристалл MSP430, не является "обычным внутрисхемным
AK> эмулятором". Это недоэмулятор (типа "для студентов и отсталых районов" :).
AK> У него всего три брекпойнта, периферия не останавливается при остановке
AK> чипа, и т.п (я работал с FET149).

    Это касается 149. В 169-м (который у меня сейчас) 8 брейкоинтов, в
том числе не только на код, но и на данные.

AK> На безрыбье и он сгодится, но все же после нормального пиковского эмулятора
AK> я долго ругался разными словами на это сиротское поделие.

    "Нормальный пиковский эмулятор" - это то, что работает в системе, в
реальном кристалле? Или это вставляется _вместо_ кристалла. Подозреваю, что
вместо. Если так, то тут свои проблемы, начиная от невозможности работать с
девайсом, закрытом в корпусе в реальных условиях (очень надо иногда бывает при
отладке и доводке, когда вылезают вопросы на конечном этапе), продолжая
необходимостью в каких-то POD-ах, сложностью работы с мелкими корпусами (не
очень представляю, как работать в мелкими корпусами, вернее, где мелкий шаг) и
заканчивая ценой.

AK> Т.к. отлаживаться с его помощью неэффективно, на простейшие вещи уходит
AK> масса времени. Даже время исполнения кусков кода померять нельзя. Или
AK> пройти по шагам по программе, если в моей проге включено прерывание по
AK> таймеру -  недоэмулятор тут же шагнет в ISR, и так и будет ходить вечно по
AK> телу ISR.

    Согласен, на 149 и более старых есть описанные тобой неудобства. Но на
новых, которые вместо идут, это учтено. Там можно индивидуально указать, какие
модули останавливать при остановке эмулятора. Т.ч. "жизнь налаживается" (с).


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

    Не видел такого. Не предлагают его, видно, последние годы. М.б. это было
для первых серий P и однократок С? Скорее всего так.

HZ>> И для отладки (и зашивки) нужен только копеечный адаптер.

AK> При помощи FET нельзя залочить проц.

    И не надо. Он не для этого.

AK> Он пригоден для разработки и мелких серий,  в случае если не нужна
AK> полноценная защита кода.

    А для крупных, что, не годится? Если прошивку лочить не надо.

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

    Неправильно помнишь. Два года назад оно стоило 180 зеленых денег.

AK> При этом, помнится, он не умеет ничего кроме как шить MSP430.

    А что еще ему надо уметь? Он программатор, он для программирования.

--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
dsPIC и другие... (было AVR vs PIC)
Sat Sep 25 2004 20:00, Harry Zhurov wrote to Alex Kouznetsov:

 AK>> При помощи FET нельзя залочить проц.

 HZ>     И не надо. Он не для этого.

 AK>> Он пригоден для разработки и мелких серий,  в случае если не нужна
 AK>> полноценная защита кода.

 HZ>     А для крупных, что, не годится? Если прошивку лочить не надо.

Не годится, даже если не надо лочить. Поскольку для более-менее крупной серии
необходим такой программатор, которым мог бы пользоваться неквалифицированный
оператор. Программатор без писюка, с одной-единственной кнопкой
"запрограммировать" и зеленой/красной лампочками "успех/неуспех".

Пока,                                 Алексей


dsPIC и другие... (было AVR vs PIC)

Sun, 26 Sep 2004 03:04:53 +0000 (UTC) Alex Kouznetsov wrote to Harry Zhurov:

AK>>> Он пригоден для разработки и мелких серий,  в случае если не нужна
AK>>> полноценная защита кода.

HZ>>     А для крупных, что, не годится? Если прошивку лочить не надо.

AK> Не годится, даже если не надо лочить. Поскольку для более-менее крупной
AK> серии необходим такой программатор, которым мог бы пользоваться
AK> неквалифицированный оператор. Программатор без писюка, с одной-единственной
AK> кнопкой "запрограммировать" и зеленой/красной лампочками "успех/неуспех".

    По-моему, сложность весьма преувеличена. На заводе, где шла (и идет) серия
наших приборов, советском ВПКшном заводе, в цехе, где производится сборка плат,
настройщик(ца) эти платы программирует. Там стоит AVR. С помощью именно писюка.
При том, что он/она ни шиша не разбирается даже в том, какой процессор и
сколько памяти в этом ПК. Он/она умеет только включить его, дождаться, пока
загрузится, запустить по ярлыку программу-программатор, нажимать на нужную
кнопку в этой программе и контролировать выдачу сообщений об успехе или
неуспехе операции. Для него выпущена по всем правилам в соответствии с ГОСТ
инструкция по настройке и проверке, в соответствии с которой он/она действует
(там не только программирование). Никаких проблем нет. Если вдруг что-то не
работает, он/она обращается за помощью к тем, кто в этом больше разбирается.
Но, как показала реальная практика, никаких проблем нет. Более того, на крупных
партиях удельный геморрой по постановке и освоению производства меньше, т.к.
обучение настройщика ровно такое же, что и при мелких, а настраивает он потом
больше устройств.

    Не думаю, что другое решение - не писюк - будет проще. Я же не предлагаю
использовать для программирования в серии иаровский С-SPY. Есть и более простые
варианты. Если надо, то можно и специальный написать - протокол
программирования через JTAG для MSP430 открыт.

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

--
H.Z.

h.z<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: dsPIC и другие... (было AVR vs PIC)

HZ>>  А для крупных, что, не годится? Если прошивку лочить не надо.
AK>
AK> Не годится, даже если не надо лочить. Поскольку для более-менее
AK> крупной серии необходим такой программатор, которым мог бы
AK> пользоваться неквалифицированный оператор. Программатор без
AK> писюка, с одной-единственной кнопкой "запрограммировать" и
AK> зеленой/красной лампочками "успех/неуспех".

Ага, щаз...

 В начале по поводу "неквалифицированного оператора"

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

2) Заводской наладчик предпочтет (хотя бы из самоуважения)
   сидеть за чем-то более-менее сложным (и необязательно
   чтоб за компом, хотя и приятней).
   Соответсвенно и ответное благодушное отношение наладчика
   к разработчику, если кому это важно... (мне, к примеру)

 А теперь про производство

3) Зачем производству организовывать дополнительное рабочее
   место вместо естественной интеграции с рабочим местом на
   участке настройки-контроля?
   И от участка этого никуда не убежишь, только если не
   собрался сразу с монтажа в конечную тару паковать...

   А если выделять для программизма отдельное рабочее место
   с отдельным питекантропом...   Да мне кнопу жалко...  ;)



<< Когда я вырасту, то хочу стать паровым экскаватором...
<<                                       ...  (c) Bender [8E]
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*

Re: dsPIC и другие... (было AVR vs PIC)
Sun Sep 26 2004 21:34, Dmitry Kuznetsov wrote to "Alex Kouznetsov":

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

 DK>  В начале по поводу "неквалифицированного оператора"

 DK> 1) Цеховое начальство такого питекантропа, что только тупо
 DK>    на кнопу жать может, на пушечный выстрел не подпустит к
 DK>    изделиям, потому как ученое...

У нас подпускает. И нареканий ни у кого нет.

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

Зачем на эту тупую операцию сажать наладчика? У нас сажали "человека с улицы",
что гораздо дешевле.
Гы, надо сказать, что у нашего программатора, стоящего на этой операции, даже
кнопки нет. Он "чувствует" когда мелкосхема вставлена в панельку, и
программирует ее автоматически.

 DK>  А теперь про производство

 DK> 3) Зачем производству организовывать дополнительное рабочее
 DK>    место вместо естественной интеграции с рабочим местом на
 DK>    участке настройки-контроля?
 DK>    И от участка этого никуда не убежишь, только если не
 DK>    собрался сразу с монтажа в конечную тару паковать...

 DK>    А если выделять для программизма отдельное рабочее место
 DK>    с отдельным питекантропом...   Да мне кнопу жалко...  ;)

Речь шла о _крупном_ производстве. На участке контроля у нас тоже сидит не
наладчик, а "человек с улицы". Изделие проверяется автоматизированным стендом,
у которого одна кнопка и две лампочки :-)
А наладчики занимаются только теми изделиями, которые не прошли автоматическое
тестирование.

Пока,                                 Алексей


Re: dsPIC и другие... (было AVR vs PIC)

Quoted text here. Click to load it

 Одного подпустили. Половину SMD электролитов и диодов поставил
 наоборот - для него просто двуногое из коробочки, на маркировку
 плевать. Правда, это случай опытных образцов, которые все равно
 мне на стол попал.
 Так что проколы бывают...

Quoted text here. Click to load it

 Почему тупую? К примеру контроль напряжений на плате.
 У меня как-то набралось: 5, 3.3, 2.5, и 1.8...
 И все ведь надо проверить. Мало-ли что, 3-вольтовая
 электроника может прекрасно и на 5 вольтах работать,
 только греться по тихому.
 А у вас что, собрали, включили, и если зеленая лампочка
 горит, то сразу в коробку?

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

Quoted text here. Click to load it

 Это пока "оператору" не покажется что криво встала...  ;)
 Да и возможно мы друг друга не поняли, а я, как обычно,
 веду речь про ISP.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

 Это место контроллера. Эти здесь дотошные. Смотрят все, начиная
 с внешнего вида платы - макаку здесь не посадишь. Иначе кое-что,
 для чего электронику там же делают, сразу бы падало...

Quoted text here. Click to load it

 То есть этот стенд диагноза не выдает... а ведь мог бы...

 У нас это называется КПА (контрольно-проверочная аппаратура)
 и далеко не все операции автоматизированны - используется
 тумблерно-кнопочное управление и стрелочная навигация :)
 И хотя программный тест идет автоматом с сообщениями по
 пунктам проверки, в целом, до полного автомата - далеко.

Quoted text here. Click to load it

 Сойдемся на том, что для крупного производства это в порядке вещей.

Пока!
<< "Сладкий плод в саду висит, раздвигает стебли..." (c) 790
 Dmitry Kuznetsov, Moscow, http://www.orc.ru/~dkuzn/index.htm
[Team Беговая Черепаха] [Team LEXX]
*

Re: dsPIC и другие... (было AVR vs PIC)

   Alexander, ты ещё здесь сидишь?


Вторник Сентябрь 28 2004 00:52, Alexander Golov wrote to George Shepelev:

 AG>>> ...ты подключился к ветке, когда я в ней говорил про
 AG>>> dsPIC30F, а я всегда обсуждаю ту тему, которую начал. Там я
 AG>>> говорил, что dsPIC30F -- тоже PIC'и,
 GS>> Это не так. Принадлежность к семейству контроллеров определяется
 GS>> _ядром_.
 GS>> А они у PIC и dsPIC совершенно разные.
 AG> Они и у PIC16 c PIC16C54 отличаются не говоря уже о PIC18, но ведь их
 AG> всё равно всех как PIC'и воспринимают.

 Да, воспринимают как несколько семейств PIC-процессоров. Все они
8-ми битные и с очень похожими ядрами.

 dsPIC - совсем другая история. Похож по цоколёвке и периферии,
но ядро там - совершенно другое...


 AG>>> что это очень эффективные МК и на данный момент убеждён в этом
 AG>>> ещё больше.
 GS>> Вот только когда работа с ними станет дешёвой?..
 AG> А работа с ними дорога?

 Да, если нужно "штучное" изделие сделать, "на попробовать".
"Hаколенные" варианты, как это было с PIC'ами, не проходят...


                                                   Георгий


dsPIC и другие... (было AVR vs PIC)
  Привет!

Tue Sep 28 2004 17:32, George Shepelev wrote to Alexander Golov:

...

 GS>>> Это не так. Принадлежность к семейству контроллеров определяется
 GS>>> _ядром_. А они у PIC и dsPIC совершенно разные.

 AG>> Они и у PIC16 c PIC16C54 отличаются не говоря уже о PIC18, но ведь их
 AG>> всё равно всех как PIC'и воспринимают.

 GS>  Да, воспринимают как несколько семейств PIC-процессоров. Все они
 GS> 8-ми битные и с очень похожими ядрами.
 GS>  dsPIC - совсем другая история. Похож по цоколёвке и периферии,
 GS> но ядро там - совершенно другое...

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

...

 AG>> А работа с ними дорога?

 GS>  Да, если нужно "штучное" изделие сделать, "на попробовать".
 GS> "Hаколенные" варианты, как это было с PIC'ами, не проходят...

Я что-то не ощущаю никакой принципиальной разницы в этом деле с "обычными"
PIC'ами.


Re: dsPIC и другие... (было AVR vs PIC)
24-Sep-04 11:48 Alex Kouznetsov wrote to Harry Zhurov:

 HZ>>     Обычный внутрисхемный эмулятор в MSP430 - это вещь, встроенная в
 HZ>> кристалл.

AK> То, что встроено в кристалл MSP430, не является "обычным внутрисхемным
AK> эмулятором". Это недоэмулятор (типа "для студентов и отсталых районов"
AK> :). У
AK> него всего три брекпойнта, периферия не останавливается при остановке
[...]
AK> Или пройти по шагам по программе, если в моей проге включено прерывание
AK> по
AK> таймеру -  недоэмулятор тут же шагнет в ISR, и так и будет ходить вечно
AK> по телу ISR.

Вот, кстати, по этой причине я с чистой совестью JTAG-ноги AVR пускаю как
рабочие, аналогично поступил на единственной плате с MSP430F147 (причём на
ней и свободные ноги оставались, но так легче трассировалось :-).
При работе с таким эмулятором он в основном должен не работать :-)
Левые записи в некие области данных таким "эмулятором" отлавливать можно,
а остальное, IMHO, никак. Но null pointer assignment и его родственников
у меня не было уже больше 10 лет. Так что имеющаяся в наличии платка
для AVR JTAG ICE так и лежит не спаянная.

wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Site Timeline