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

Hello, Alex! You wrote to Vladimir Vassilevsky on Thu, 18 Nov 2004 09:10:41 +0000 (UTC):

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

Ну и где для 16-ти разрядных реализован полный Це++ ? Так что бы труп страуса остался доволен. Или ты про визуальные, так сказать, средства проектирования - игрушки, не более.

With best regards, Alexey Kovalev

Thu Nov 18 2004 11:17, Alexey Kovalev wrote to Alex Kouznetsov:

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

AKov> Hу и где для 16-ти разрядных реализован полный Це++ ? AKov> Так что бы труп страуса остался доволен.

Я ++ вообще не упоминал, непонятно с чего вдруг возник твой вопрос. Но раз уж тебя этот вопрос интересует, то - 8086

AKov> Или ты про визуальные, так сказать, средства проектирования - AKov> игрушки, не более.

Опять непонятно, как это ты перескочил на визуальные ср-ва проектирования, если я про них ни словом не обмолвился, да и в мыслях их не держал. Или ты думаешь, что Це неразрывно связан с гуями, и без них существовать не может? А где гуя, там ++, так что ли? Странные у тебя ассоциации... Я про то, что Це является языком среднего уровня, недалеко ушедшим от ассемблера.

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

Wed Nov 17 2004 23:57, Yurik Andrienko wrote to Alex Kouznetsov:

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

YA> Разгадка этой загадки проста и тривиальна, здесь их можно купить и в YA> малых количествах и в больших. Благодаря кому... вот это загадка. YA> Попробуйте купить на "Гамме" какой-нибудь TC74 или MCP3301 или новые ОУ YA> от Microchip. Они, оказывается, не пользуются спросом... Хотя, купленные YA> мимо "Гаммы", со слов продавцов, улетают со свистом...

YA> Кстати, про Фудзиков, нужен был 32-разрядный процессор не в BGA-корпусе, YA> с флэшем, с ОЗУ, с ISP, с большим количеством портов, дык, YA> альтернативы-то практически и нету... То есть их есть, но купить пару YA> штук на попробовать, это только за много денег и очень нескоро... А эти, YA> опять-таки, мимо наших представителей фирмы, худо-бедно, но за две недели YA> появились...

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

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

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

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

Hello, Alex! You wrote to Alexey Kovalev on Thu, 18 Nov 2004 10:19:13 +0000 (UTC):

AK> Я ++ вообще не упоминал, непонятно с чего вдруг возник твой вопрос. AK> Но раз уж тебя этот вопрос интересует, то - 8086

Это микропроцессор, а не микроконтроллер (см. сабж)

AK> Я про то, что Це является языком среднего уровня, недалеко ушедшим AK> от ассемблера.

Так что же вместо него нужно использовать?

With best regards, Alexey Kovalev

Thu Nov 18 2004 12:51, Alexey Kovalev wrote to Alex Kouznetsov:

AK>> Я ++ вообще не упоминал, непонятно с чего вдруг возник твой вопрос. AK>> Hо раз уж тебя этот вопрос интересует, то - 8086

AK> Это микропроцессор, а не микроконтроллер (см. сабж)

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

AK>> Я про то, что Це является языком среднего уровня, недалеко ушедшим AK>> от ассемблера.

AK> Так что же вместо него нужно использовать?

Кому нужно, тебе? Ищи ответ сам. Вопрос твой - неприкрытая провокация флейма.

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

Hello, Alex! You wrote to Alexey Kovalev on Thu, 18 Nov 2004 11:19:43 +0000 (UTC):

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

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

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

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

With best regards, Alexey Kovalev

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

Hello Alexey.

18 Nov 04 12:17, Alexey Kovalev wrote to Alex Kouznetsov:

AK>> Кстати, AK>> Це, как известно, это тоже в общем-то ассемблер ;-) AK> Hу и где для 16-ти разрядных реализован полный Це++ ?

Я тоже не понял, пpичем тyт Си++, но коли yж ты наpываешься...

С++ есть даже для 8-битников (делает IAR), не гpя yже об MSP430 и пpочая. Он не "полный" С++, но yже и не EC++, т.к. в нем есть шаблоны.

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

AK> Так что бы труп страуса остался доволен. AK> Или ты про визуальные, так сказать, средства проектирования - AK> игрушки, не более.

AK гpил пpо язык пpогpаммиpования Си и не более :).

Alexey

Hello Yurik.

18 Nov 04 00:57, Yurik Andrienko wrote to Alex Kouznetsov:

AK>> Почему малоизвестный во всем мире МВ90 стал так популярен в России - AK>> загадка. Похоже, Фуджики в свое время просто сильно заложились на этот AK>> рынок, поскольку в другие места всерьез им втиснуться не дали более AK>> сильные конкуренты. YA> Кстати, про Фудзиков, нужен был 32-разрядный процессор не в BGA-корпусе, YA> с флэшем, с ОЗУ, с ISP, с большим количеством портов, дык, альтернативы-то YA> практически и нету... То есть их есть, но купить пару штук на попробовать, YA> это только за много денег и очень нескоро...

Так было паpy лет назад, щас АРМ легко достать (LPCxxxx Philips'a). пpичем с очень пpивлекательными ценами. Остается вопpос, вся ли тpебyемая пеpифеpия в них есть...

У нас тyт Аpгyссофт начинает пpедлагать ADшные ARM'ы.

Alexey

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

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

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

Привет 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, Alexey Kovalev !

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

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

Hello, Alexey Kovalev !

А в чем?

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

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

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

В наличии встроенной периферии. У проца её нет или почти нет, обычно даже тактовый генератор требуется внешний. Контроллер - это процессор с периферийными узлами в одном флаконе - порты 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