Выбор 16-ти разрядного контроллера - Page 4

Hello, Alexey!
You wrote to Alexey Kovalev on Thu, 18 Nov 2004 16:57:05 +0300:

 AK>>     Hу и где для 16-ти разрядных реализован полный Це++ ?
 AM> С++ есть даже для 8-битников (делает IAR),

    IAR-ом пользовался. Там от ++ чуть.

 AM> не гpя yже об MSP430 и пpочая.
 AM> Он не "полный" С++, но yже и не EC++, т.к. в нем есть шаблоны.

   А чего, к примеру, нет?

 AM> В g++ вpоде весь стандаpт,

    Не знаю что это.

 AM> только нахеpа обpаботка исключений и RTTI для embedded пpименений?

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

With best regards, Alexey Kovalev

Thu, 18 Nov 2004 13:17:55 +0000 (UTC) Alexey Kovalev wrote to Alexey Musin:

AK>>>     Hу и где для 16-ти разрядных реализован полный Це++ ?
AM>> С++ есть даже для 8-битников (делает IAR),

AK>     IAR-ом пользовался. Там от ++ чуть.

    Во-первых, IAR'ы бывают разные - разные версии, под разные платформы. И ++
там уже прилично. Например, в версиях для АРМ и MSP430 нет только по-настоящему
тяжелых и накладных вещей (за исключением, пожалуй, множественного
наследования).

AM>> не гpя yже об MSP430 и пpочая.
AM>> Он не "полный" С++, но yже и не EC++, т.к. в нем есть шаблоны.

AK>    А чего, к примеру, нет?

    Так ты не знаешь? А с чего тогда замечания "Там от ++ чуть"?

    Докладываю: там нет трех вещей 1) исключений, 2) информации о типе во время
выполнения, 3) множественного наследования.

    По первым двум вещам - однозначно правильно. Это вещи толстые, накладные,
из-за чего их полезность в ембеддед очень сомнительна. Множественное
наследование можно было бы и включить. Почему этого (пока) нет, думаю, из-за
усложнения компилятора. Думаю, со временем включат и это. Не так давно был
только лишь ЕС++, где не было ни шаблонов, ни пространств имен, хотя ни то, ни
другое не дает никаких накладных расходов. И эти вещи действительно полезны и
удобны (к месту). Лично мне очень не хватало шаблонов.

AM>> В g++ вpоде весь стандаpт,

    На самом деле тоже есть ограничения. Например, afair, avr-gcc тоже не
поддерживает исключения и RTTI (и правильно!).


AM>> только нахеpа обpаботка исключений и RTTI для embedded пpименений?

AK>     Для embedded очень полезно, к примеру inline ф-ии. Перегрузка
AK> операторов тоже весьма полезна если приходится выражения с комплексными
AK> числами использовать.

    :) Это все есть. Это все было сразу и с самого начала. Чего не было, выше
перечислено.

AK>     Да и обработка исключений - как реализована. По сути это просто выход
AK> сразу из многих уровней вложенности (упрощённо). Вроде не должна много
AK> места занимать .Удобно было бы.

    У ты какой! Обработка исключений - это далеко не "просто выход сразу из
многих уровней вложенности". Это довольно нетривиальный в реализации механизм
раскручивания стека - нужно на каждом уровне вызвать деструкторы всех созданных
на этом уровне объектов. Это тянет приличные накладные расходы по памяти, коду
и слабопредсказуемое время выполнения, что (особенно последнее) плохо
согласуется с ембеддед. Поэтому этого нет, и нафиг оно не надо - ситуации не
те. Обработка исключений - это, пожалуй, самое "тяжелое" средство С++, и даже
программисты, пишущие для больших машин, стараются не злоупотреблять этим.
Особенно, когда быстродействие необходимо.

    От себя: ты, я вижу, не слишком-то знаком с языком, и на этом фоне обзывки
в адрес автора выглядят не просто грубыми, но просто глупыми. Извини. Лажать
всегда легко. Попробуй сделать что-нибудь хотя бы в десятеро менее заметное и
значимое!

Hello, Harry!
You wrote to Alexey Kovalev on Thu, 18 Nov 2004 14:16:46 +0000 (UTC):

 AK>>     IAR-ом пользовался. Там от ++ чуть.
 AM>>> не гpя yже об MSP430 и пpочая.
 AM>>> Он не "полный" С++, но yже и не EC++, т.к. в нем есть шаблоны.
 AK>>    А чего, к примеру, нет?
 HZ>     Так ты не знаешь? А с чего тогда замечания "Там от ++ чуть"?

    MSP430 не пользовался.

 HZ>     Докладываю: там нет трех вещей 1) исключений, 2) информации о
 HZ> типе во время выполнения, 3) множественного наследования.

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

    3) как раз и не нужно. От него избавляются в новых ЯВУ даже для ПК.
2) согласен. 1) не согласен. Ограниченный вариант был бы полезен. Например,
в throw только целочисленное выражение (или даже константа).

  AK>>     Да и обработка исключений - как реализована. По сути это просто
 AK>> выход сразу из многих уровней вложенности (упрощённо).

^^^^^^^^^
 HZ>     У ты какой! Обработка исключений - это далеко не "просто выход
 HZ> сразу из многих уровней вложенности". Это довольно нетривиальный в
 HZ> реализации механизм раскручивания стека

    за который голова у компилятора болит. И пусть болит - лишь бы код
создал.

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

    какие деструкторы вызывать известно на этапе компиляции. Их столько же
сколько и при обычном выходе из блока/ф-ии.
   Другое дело, что в ембеддед не стОит (часто) использовать виртуальные
функции да нетривиальные деструкторы - вот от них как раз и происходит
"нетривиальный в реализации механизм ".  Без них и throw и return
реализуются
просто, а с ними и без исключений тормоза.
   В альтернативе "голый С" и С++ но virtual  не злоупотребляем понятно что
лучше.

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

    не правда. на больших машинах все нормальные библиотеки широко
используют
исключения - обратное признак непрофессионализма.
    Оставим сложные механизмы исключений. Что удобней:

 bool stop=false; for(){for(){for(){if(){stop=true;
break;}}if(stop)break;}if(stop)break;}
 или try{for(){for(){for(){if()throw 1;}}}catch(...)

     При учете что все известно на этапе компиляции и затраты по коду и
памяти
будут меньше во втором случае (если компилятор не соптимизирует 1 в 2)

 HZ>     От себя: ты, я вижу, не слишком-то знаком с языком

    наоборот :)

 HZ> фоне обзывки в адрес автора

    Укажи где были "обзывки" мылом. Я их не вижу.

With best regards, Alexey Kovalev

Thu, 18 Nov 2004 15:27:59 +0000 (UTC) Alexey Kovalev wrote to Harry Zhurov:

AM>>>> Он не "полный" С++, но yже и не EC++, т.к. в нем есть шаблоны.
AK>>>    А чего, к примеру, нет?
HZ>>     Так ты не знаешь? А с чего тогда замечания "Там от ++ чуть"?

AK>     MSP430 не пользовался.

    Для АРМа там раньше всех появилось - уже больше года точно. Почти год, как
есть для MSP430 и должно появиться в версиях 4.хх для AVR, которые как обычно
задерживаются с выходом.

HZ>>     Докладываю: там нет трех вещей 1) исключений, 2) информации о
HZ>> типе во время выполнения, 3) множественного наследования.

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

AK>     3) как раз и не нужно. От него избавляются в новых ЯВУ даже для ПК.

    Новые ЯВУ для ПК - это инструменты в большинстве для "мальчиков", вчерашних
студентов/школьников. Для них чем проще, тем лучше. Чтобы они быстренько лабали
веб и не грели себе голову высокими концепциями. :))

AK> 2) согласен. 1) не согласен. Ограниченный вариант был бы полезен. Например,
AK> в throw только целочисленное выражение (или даже константа).

    Без разницы. Раскрутка стека все равно понадобится. Усложнение как
компилятора, так и сгенеренного кода большое и неоправданное.

AK>>>     Да и обработка исключений - как реализована. По сути это просто
AK>>> выход сразу из многих уровней вложенности (упрощённо).

AK> ^^^^^^^^^
HZ>>     У ты какой! Обработка исключений - это далеко не "просто выход
HZ>> сразу из многих уровней вложенности". Это довольно нетривиальный в
HZ>> реализации механизм раскручивания стека

AK>     за который голова у компилятора болит. И пусть болит - лишь бы код
AK> создал.

    Он создаст. Ему-то чего переживать, когда у тебя вместо 4 килобайт прошивка
будет 10. И зависать на возбуждении исключения будет на долгие тысячи тактов -
так, что даже и не знаешь реально сколько оно там болтается.

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

AK>     какие деструкторы вызывать известно на этапе компиляции. Их столько же
AK> сколько и при обычном выходе из блока/ф-ии.

    Да? Ну-ка скажи-ка, известно это в таком случае:

class A;
class B;
class C;

extern int x;
extern B eb;

void f()
{
    case(x)
    {
    1: A* pA = new A; break;

    2:  if(!eb.IsEmpty())
        {
            B* pB = new B;
            pB->Copy(eb);
        }
        break;
        ...
    }
    ...
}

    Ну, и как ты и твой компилятор будете узнавать, какие объекты созданы, а
какие нет?

AK>    Другое дело, что в ембеддед не стОит (часто) использовать виртуальные
AK> функции

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

AK> да нетривиальные деструкторы - вот от них как раз и происходит
AK> "нетривиальный в реализации механизм ".  Без них и throw и return
AK> реализуются

    А return-то тут причем? :-|

AK> просто, а с ними и без исключений тормоза.
AK>    В альтернативе "голый С" и С++ но virtual  не злоупотребляем понятно что
AK> лучше.

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

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

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

    Никакой это не признак. Признак непрофессионализма - это использовать
средства не по назначению.

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

    В остальных случаях можно обойтись более простыми, быстрыми и эффективными
методами, чем и пользуются. И в ембеддед нет такой ситуации, как в мире больших
машин, где очень интенсивное использование больших и сложных библиотек. В
ембеддед такие случаи единичные. Особенно на 8/16 битных МК. Если народ и
пользуется библиотеками, то это в 90% случаев RTL, а остальное собственного
производства.

AK>     Оставим сложные механизмы исключений. Что удобней:

AK>  bool stop=false; for(){for(){for(){if(){stop=true;
AK> break;}}if(stop)break;}if(stop)break;}
AK>  или try{for(){for(){for(){if()throw 1;}}}catch(...)

    Для выхода из вложенных циклов есть оператор goto! Это, пожалуй,
единственное его оправданное применение и единственная причина, по которой он
присутствует в языке. И реализация такого перехода в описанном случае (выход из
вложенных циклов наружу) очень проста и эффективна. Использовать тут
исключения - это маразм. Или, пользуясь твоими словами, признак
непрофессионализма. Извини.

AK>      При учете что все известно на этапе компиляции и затраты по коду и
AK> памяти
AK> будут меньше во втором случае (если компилятор не соптимизирует 1 в 2)

    В этом и подобных случаев проще всего, эффективнее всего и разумнее всего
использовать goto.

HZ>>     От себя: ты, я вижу, не слишком-то знаком с языком

AK>     наоборот :)

    Может быть. Но по твоим постам на тему С++ впечатление складывается другое.

HZ>> фоне обзывки в адрес автора

AK>     Укажи где были "обзывки" мылом. Я их не вижу.

    Отмотай немного назад и увидишь.

Hello, Harry!
You wrote to Alexey Kovalev on Fri, 19 Nov 2004 04:34:59 +0000 (UTC):

 AK>>>>     Да и обработка исключений - как реализована. По сути это
 AK>>>> просто выход сразу из многих уровней вложенности (упрощённо).


^^^^^^^^^

 AK>>     за который голова у компилятора болит. И пусть болит - лишь бы
 AK>> код создал.

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

    Это если ему в рантайме нужно определять какая же в действительности
вирт. ф-ия вызвана (тесно связано с RTTI). В противном случае для
каждого throw всё извесно на этапе компиляции и  throw сводится к
сдвигу стека и jmp-у.

 HZ>     Да? Ну-ка скажи-ка, известно это в таком случае:
 HZ>     1: A* pA = new A; break;
 HZ>     2:  if(!eb.IsEmpty())
 HZ>         {
 HZ>             B* pB = new B;
 HZ>             pB->Copy(eb);
 HZ>         }

 HZ>     Ну, и как ты и твой компилятор будете узнавать, какие объекты
 HZ> созданы, а какие нет?

    У тебя тут в любом случае меморилики. С жабой спутал или
Managed C ? (см. свой пассаж про web)

    У меня бы была обязательная в любом случае инициализация указателей
на NULL и catch(){if(global_pA){delete global_pA;global_pA=NULL;}....}

    [флейм остановлен]

With best regards, Alexey Kovalev

Привет Alexey!

18 Nov 04 16:57, Alexey Musin писал Alexey Kovalev:

 AM> В g++ вpоде весь стандаpт, только
 AM> нахеpа обpаботка исключений и RTTI для embedded пpименений?

    Разве embedded применения в этом смысле чем-то отличаются от не-embedded?

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... В системе возможно бесконечное число процессов - до 256.

Hello, Alex!
You wrote to Alexey Musin on Thu, 18 Nov 2004 18:55:09 +0300:

 AM>     Разве embedded применения в этом смысле чем-то отличаются от
 AM> не-embedded?

    Имеется ввиду что мы заметно ограничены по памяти и
быстродействию. Если у нас embedded  32-х разрядный и памяти мегами
то нет разницы. А вот для 8-ми, 16-ти разрядных кое что не нужно.
     IMHO, в первую очередь ограничиваем число виртуальных ф-ий и
динамически распределяемой памяти. Конструкторы как правило, а
деструкторы всегда по умолчанию. Да и не нужно это - в объёме ROM
несколько килобайт не запутаемся и без наследования - STL туда
все равно не впихнешь.
     Другое дело когда вместо inline приходится писать
     #define \
                \
     Ну другие примеры я приводил.

With best regards, Alexey Kovalev

Hello Alex.

18 Nov 04 13:47, Alex Kouznetsov wrote to Yurik Andrienko:

 AK> То есть, Фуджицу проводит активную маркетинговую политику на российском
 AK> рынке: не гнушается торговать мелкими партиями (пусть даже себе в убыток),

тоpгyют EBV, КТЦ-МК и т.д.
цены такие же, как и для Евpопы - см. сайты EBV, GLYN.

 AK> без проволочек предоставляет образцы,

Hам не пpедлагали, за кpовные бpали :). Вот филипковые ARM'ы - да,
под пpоект можно и обpазцы полyчить.

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

саппоpт y них действительно хоpоший, pазе что не pyсскоязычный :).

 AK> Однако возможно и другое объяснение. Когда пару лет назад я встречался с
 AK> представителями Фуджиков, которые пытались запарить нам МВ90, я их прямо
 AK> спросил - в чем, по их мнению, сильная сторона Фуджиков, какой мне смысл
 AK> переползать на них с H8S?
 AK> Подумав, они ответили, что сильная сторона
 AK> Фуджитсу - в тесных связях с потребителями, в активной поддержке
 AK> потребителей.

Это действительно так. У меня как-то был вопpос пpо АЦП в их МК, так они мне
пpислали аппнотy, хотя ее еще не yспели выложить на сайте.
Или еще - мы заметили опечаткy в доке, написали, на следyющий день на сайте
появился новый док с испpавлениями.

 AK> То есть, вполне может статься, что российский рынок в
 AK> нынешнем его состоянии сам по себе больше соответствует
 AK> _уже_сложившейся_
 AK> своеобразной политике Фуджитцу.

может быть.

Hy вот, до кyчи, как ты считаешь потpебный стек?
Фyджицy пpедлагает (задаpом!) софт для анализа исходников (С Checker и C
Analyzer). Коммеpческие аналоги этого пpодyкта стоят в pайоне 10К!

Alexey

Hello, Alexey Kovalev !

 >  AK> Кстати,
 >  AK> Це, как известно, это тоже в общем-то ассемблер ;-)

 >     Hу и где для 16-ти разрядных реализован полный Це++ ?

Какая связь одного с другим?

С уважением, Дима Орлов.

Hello, Alexey Kovalev !

 >  AK>>> Hо раз уж тебя этот вопрос интересует, то - 8086
 >  AK>>     Это микропроцессор, а не микроконтроллер (см. сабж)
 >  AK> Hе вижу принципиальной разницы. И х86 существует в виде
 >  AK> микроконтроллеров, и многие микроконтроллеры могут работать с
 >  AK> внешней памятью.

 >     Разница между микроконтроллером и микропроцессором не в этом.

А в чем?

 >  AK>>> Я про то, что Це является языком среднего уровня, недалеко ушедшим
 >  AK>>> от ассемблера.
 >  AK>>     Так что же вместо него нужно использовать?
 >  AK> Кому нужно, тебе? Ищи ответ сам. Вопрос твой - неприкрытая
 >  AK> провокация флейма.

 >     Hу зачем так. Я подумал, что ты скажешь: "Це является языком
 > среднего уровня, недалеко ушедшим от ассемблера. А вот под семейство X
 > сделали реализацию языка Y, который уже не среднего уровня, и  что мол он
 > рулез и я, мол, им пользуюсь."

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


С уважением, Дима Орлов.

Hello, Dima!
You wrote to Alexey Kovalev on Thu, 18 Nov 2004 21:17:00 +0300:

 >>     Разница между микроконтроллером и микропроцессором не в этом.
 DO> А в чем?

    В наличии встроенной периферии. У проца её нет или почти нет,
обычно даже тактовый генератор требуется внешний.
    Контроллер - это процессор с периферийными узлами в одном
флаконе - порты I/O, таймеры,  поддержка последовательных
интерфейсов, ЦАП, АЦП  ...
    Параллельная шина для первого обязательна, для второго опциональна.

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

    Я так вопрос не ставил. Я хотел бы знать для каких семейств 16-ти
разрядных МК реализовали что ли бо получше скушного C.
Не обязательно С++. Кстати, вопрос открыт.

With best regards, Alexey Kovalev

Thu Nov 18 2004 22:27, Alexey Kovalev wrote to Dima Orlov:

 AK>     Я так вопрос не ставил. Я хотел бы знать для каких семейств 16-ти
 AK> разрядных МК реализовали что ли бо получше скушного C.
 AK> Hе обязательно С++. Кстати, вопрос открыт.

Freescale HC12, 9S12 - Codewarrior.

WBR, Юрий.

Hello, Yuriy!
You wrote to Alexey Kovalev on Thu, 18 Nov 2004 23:48:48 +0300:

 YK> Freescale HC12, 9S12 - Codewarrior.

    А где его взять?
    Или хотя бы почитать описание?

With best regards, Alexey Kovalev

Thu Nov 18 2004 23:20, Alexey Kovalev wrote to Yuriy K:

 YK>> Freescale HC12, 9S12 - Codewarrior.

 AK>     А где его взять?
 AK>     Или хотя бы почитать описание?

www.freescale.com

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CWHC12&nodeId01%

http://www.metrowerks.com/MW/Develop/Embedded/HC12/Default.htm #
http://www.metrowerks.com/MW/Develop/Embedded/HC12/Downloads

Limited to 12Kbyte of code - free, если я правильно понял.

WBR, Юрий.

Hello, Yuriy!
You wrote to Alexey Kovalev on Fri, 19 Nov 2004 01:37:29 +0300:

 YK> www.freescale.com

    У них такая фирменная "изюмина" - один таймер у всех?
(Несмотря на тучу к нему compare/capture).
    Неудобно же: ни режимов счётчика ни некратных др-другу
интервалов организовать.
    Или я не понял и там, вглубине, это всё делается но очень
по мотороловски?

With best regards, Alexey Kovalev

Fri Nov 19 2004 08:36, Alexey Kovalev wrote to Yuriy K:

 YK>> www.freescale.com

 AK>     У них такая фирменная "изюмина" - один таймер у всех?
 AK> (Hесмотря на тучу к нему compare/capture).
 AK>     Hеудобно же: ни режимов счётчика

Счетчиков 4-8 штук.

 AK>  ни некратных др-другу интервалов организовать.

Compare вполне достаточно.

Hello, Yuriy!
You wrote to Alexey Kovalev on Fri, 19 Nov 2004 10:28:04 +0300:

 YK> Счетчиков 4-8 штук.

    Кажется понимаю почему фиджики популярнее моторов ;)

    На сайте в таблицах только таймер "одын штюк". Это уже
отвращает. Скачал даташит по MC9S12DJ64, читаю

Enhanced Capture Timer
....
- Four 8-bit or two 16-bit pulse accumulators

    Это и есть счётчики (таймеры с внешним тактированием) ?

   Радостно лезу в  "Section 9 Enhanced Capture Timer (ECT) Block"
но там  "Consult the ECT_16B8C Block User Guide for information
about the Enhanced Capture".

   Ладно, скачал и его. А там:

This timer contains 8 complete input capture/output compare
channels and ___one____ pulse accumulator.


    Так можно на него (или другой мотор) подать 2/4/8
импульсных сигналов что бы они считались независимо?
На какие хоть ноги, для определенности?

With best regards, Alexey Kovalev

Fri Nov 19 2004 10:55, Alexey Kovalev wrote to Yuriy K:

 AK> Enhanced Capture Timer
 AK> ....
 AK> - Four 8-bit or two 16-bit pulse accumulators
 AK>     Это и есть счётчики (таймеры с внешним тактированием) ?

Да.

 AK>     Так можно на него (или другой мотор) подать 2/4/8
 AK> импульсных сигналов что бы они считались независимо?

2/4 сигнала.

"ECT_16B8C Block User Guide V01.03"
1.2 Features

 Four 8-Bit Pulse Accumulators with 8-bit buffer registers associated
with the four buffered IC channels.
Configurable also as two 16-Bit Pulse Accumulators.

 AK> Hа какие хоть ноги, для определенности?

"ECT_16B8C Block User Guide V01.03"
Figure 4-3 8-Bit Pulse Accumulators Block Diagram
Figure 4-4 16-Bit Pulse Accumulators Block Diagram


P.S. Вся дока качается одним файлом, 6мег зипа.
http://www.freescale.com/files/microcontrollers/doc/user_guide/9S12DJ64_ZIP.zip


P.P.S. Если к процессору не лежит душа - не надо себя мучать, душевное
спокойствие дороже. :-)

Thu Nov 18 2004 22:27, Alexey Kovalev wrote to Dima Orlov:

 >>>     Разница между микроконтроллером и микропроцессором не в этом.

 DO>> А в чем?

 AK>     В наличии встроенной периферии. У проца её нет или почти нет,
 AK> обычно даже тактовый генератор требуется внешний.

Так по твоему, 80188 - это микроконтроллер? У него периферия на борту, хоть
памяти и нет. А Юбикомы/Синиксы, если по твоему считать, микропроцессоры, бо
периферии у них, как раз по твоему определению, "почти нет" (с)? "А мужики-то
и не знают" (с), ты им черкани письмецо, поправь, мол, неправильно вы все
назвали ;-)

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

Hello, Alex!
You wrote to Alexey Kovalev on Fri, 19 Nov 2004 08:34:16 +0000 (UTC):

 AK> Так по твоему, 80188 - это микроконтроллер? У него периферия на
 AK> борту, хоть памяти и нет.

    Периферии чуть (3 таймера) по сравнению с ядром. Всякие DMA вполне
микропроцессорные модули (служат для сопряжения с специфической
микропроцессорной обвязкой).
    Насчёт памяти ты загнул - она есть (регистры).

    Аналогично: если в пне встроен датчик температуры то он все равно
микропроцессор.

 AK> А Юбикомы/Синиксы, если по твоему считать, микропроцессоры, бо

    Ты про виртуальную периферию? Именно потому что она предусмотрена
производителем их и называют Controller


With best regards, Alexey Kovalev