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

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

Threaded View
Re: Выбор 16-ти разрядного контроллера
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



Выбор 16-ти разрядного контроллера
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> места занимать .Удобно было бы.

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

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

--
H.Z.

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

We've slightly trimmed the long signature. Click to see the full one.
Re: Выбор 16-ти разрядного контроллера
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



Выбор 16-ти разрядного контроллера
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>     Укажи где были "обзывки" мылом. Я их не вижу.

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

--
H.Z.

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

We've slightly trimmed the long signature. Click to see the full one.
Re: Выбор 16-ти разрядного контроллера
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



Выбор 16-ти разрядного контроллера
Привет 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.

Re: Выбор 16-ти разрядного контроллера
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



Re: Выбор 16-ти разрядного контроллера
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


Re: Выбор 16-ти разрядного контроллера
Hello, Alexey Kovalev !

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

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

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

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


Re: Выбор 16-ти разрядного контроллера
Hello, Alexey Kovalev !

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

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

А в чем?

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

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

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


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


Re: Выбор 16-ти разрядного контроллера
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



Re: Выбор 16-ти разрядного контроллера
Thu Nov 18 2004 22:27, Alexey Kovalev wrote to Dima Orlov:

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

Freescale HC12, 9S12 - Codewarrior.

WBR, Юрий.


Re: Выбор 16-ти разрядного контроллера
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



Re: Выбор 16-ти разрядного контроллера
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, Юрий.


Поясните по моторам Re: Выбор 16-ти разрядного контроллера
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



Поясните по моторам Re: Выбор 16-ти разрядного контроллера
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 вполне достаточно.


Re: Поясните по моторам Re: Выбор 16-ти разрядного контроллера
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



Re: Поясните по моторам Re: Выбор 16-ти разрядного контроллера
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. Если к процессору не лежит душа - не надо себя мучать, душевное
спокойствие дороже. :-)


Re: Выбор 16-ти разрядного контроллера
Thu Nov 18 2004 22:27, Alexey Kovalev wrote to Dima Orlov:

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

 DO>> А в чем?

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

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

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


Re: Выбор 16-ти разрядного контроллера
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



Site Timeline