[ARV 1]

Дык, весь прикол в том, что если путать, то bool просто НИЧЕМ не помогает. Сюрприз!

а если путать?

[zltigo 2]

а если путать?

Это написано в отцитированной Вами строке.

[Dx! 0]

Дык я к тому - не использовать bool ввиду убогости. Если в программировании путать божий дар с яичницой - ничего хорошего не будет при любых раскладах.

[sonycman 1]

Дык я к тому - не использовать bool ввиду убогости. Если в программировании путать божий дар с яичницой - ничего хорошего не будет при любых раскладах.

Имхо, опять же, в ситуациях, когда функция возвращает только два значения - TRUE и FALSE, запись возвращаемого значения как bool выглядит гораздо логичнее и красивее, чем громоздкое и непонятное int :laughing:

[Dx! 0]

Грабли тоже выглядят обычным садовым инвентарем 8)

[ARV 1]

короче говоря, цель достигнута - число постов в теме про AVR резко подскочило за счет нашего флуда именно ведь с этого тема-то началась теперь с первого взгляда уже не придет в голову мысль, что AVR потихоньку загибается, как предполагал топикстартер

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

нас не догонят!!!

[IGK 0]

короче говоря, цель достигнута - число постов в теме про AVR резко подскочило за счет нашего флуда именно ведь с этого тема-то началась теперь с первого взгляда уже не придет в голову мысль, что AVR потихоньку загибается, как предполагал топикстартер нас не догонят!!!

 

Жалко, я не доктор Т. А то считал бы, что цель достигнута :-)

Здесь хоть по сути дела спорят, это уже хорошо. Спасибо модераторам. А телесисям хана полная, хотя и туда хожу по инерции.

[sonycman 1]

А телесисям хана полная, хотя и туда хожу по инерции.

Меня только от вида их форума тошнить начинает. Они там со времён DOS движок не меняли... :cranky:

[Dir 0]

Ну и ? Полюбовался. Большой, дорогой (больше 8$), жутко крутой, ... Вот только токи потребления в доке не указаны. Наверное, что-бы потенциальных клиентов заранее не пугать :smile3046: ...

 

Ну, вообще-то большое потребление старых Luminary было не от некачественной схемотехники, а от устаревшей технологии производства 0,25мкм. Учитывая, что новые чипы имеют напряжение питания ядра 1,2В, то технология должна быть 0,13мкм. Поэтому ваше предположение о большом потреблении вряд ли чем то обосновано. Понятно, что если запустить встроенный PHY, то потребление будет больше, чем у МК без PHY. Но внешний PHY тоже ведь не святым духом питается...

Т.е. в сухом остатке имеем очень достойный современный МК. Один из лучших в своем классе Cortex-M3.

[sonycman 1]

Т.е. в сухом остатке имеем очень достойный современный МК. Один из лучших в своем классе Cortex-M3.

Да, и с оперативной памятью никаких проблем! А то вон жмут тут некоторые (STM32 к примеру) ;)

[artemkad 89]

Ну, вообще-то большое потребление старых Luminary было не от некачественной схемотехники, а от устаревшей технологии производства 0,25мкм.

Не скажи. 10 лет назад первые AVR-ы выпускались по 0,35-й технологии, но при этом не позволяли себе столь большие токи потребления. Если в сухом остатке - потребление было примерно раза в 2 выше, но никак не на порядок! Да и как по мне - cовременные AVR просто лучше вылизаны по потреблению чем десятилетие назад (добавлена возможность отключать ненужные блоки, введены синхронизаторы по портам, расширены режимы сна).

Учитывая, что новые чипы имеют напряжение питания ядра 1,2В, то технология должна быть 0,13мкм. Поэтому ваше предположение о большом потреблении вряд ли чем то обосновано....

Если TI не "вправили мозги" команде разработчиков этих чипов, я думаю ток потребления уменьшится не более чем в два раза. Т.е. ток будет не 45-50мА на 20МГц, а где-то 20-35мА.

Понятно, что если запустить встроенный PHY, то потребление будет больше, чем у МК без PHY. Но внешний PHY тоже ведь не святым духом питается...

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

[dxp 65]

Странно :( лично мне достаточно второго аргумента, дабы его не пользовать.

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

 

Я в С99 в моих ситуациях тоже не жаловался, но честно говоря, представлял себе, это много более безопасным, нежели приведенная реализация bool в GCC.

Я не пользуюсь голым С, поэтому для меня тоже оказалось неожиданным реализация в виде макроса. В С++ этот тип является встроенным интегральным, таким же как инт.

 

Так "предсказуемый" или "завистит от реализации"?

Предсказуемый в конкретной реализации. Как int или enum.

 

Со всеми вышеперечисленными, включая enuм действительно ясно (в рамках зависящих от платформы), а вот что такое боол и размер достаточный для его хранения? Огласите, сколько это в битах, как размещается в регистрах, как в памяти, как пакуется в структуры, union-ы.....

Ответ на этот вопрос должен находиться в документации на используемый компилятор. Обычно под хранение bool в памяти отдается минимально адресуемая ячейка на данной платформе. А уж как оно в регистра обрабатывается - это вообще интимное дело компилятора.

 

 

 

Помню:) Однако я помню также, что инверсия бита на i51 получалась быстрее, если написать bit = ~bit.

Дык там минимально адресуемое целое - 1 бит, поэтому результат операций ~ и ! совпал. :)

 

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

А тут не понял. Почему это компилятор при обработке логических выражений не пользуется bool? Или вы про какой компилятор говорите?

[AHTOXA 18]

Дык там минимально адресуемое целое - 1 бит, поэтому результат операций ~ и ! совпал. :)

 

Наверное :)

 

А тут не понял. Почему это компилятор при обработке логических выражений не пользуется bool? Или вы про какой компилятор говорите?

 

Да про любой компилятор Си (или C++, в данном аспекте неважно).

 

if (int_var1 && int_var2) ...

 

Приведёт компилятор int_var1 и int_var2 к bool при сравнении? Нет. Он, как и до введения bool, сравнивает на ноль/не ноль. Это и понятно, менять поведение компилятора для введения нового типа данных никто бы не решился. Всё, что разработчики смогли сделать, это описать поведение типа bool так, чтобы оно не противоречило устоявшейся обработке логических выражений. Получилось, что теперь обработку выражения if (int_var1 && int_var2)... можно объяснить в терминах bool. Но bool тут нет.

Я не смог сходу придумать пример, где бы это было существенным. Возможно, такого примера и нет. Даже наверное нет. Но это как раз и означает (имхо), что типа bool практически нет, ибо что с ним, что без него - всё едино :)

[dxp 65]

Да про любой компилятор Си (или C++, в данном аспекте неважно).

 

if (int_var1 && int_var2) ...

Теперь понятно. :) Как это компилятор внутри разруливает, его личное дело. В данном случае действительно не важно, приводит компилятор внутри к bool или нет. Но в есть случаи, где это актуально (явное использование).

[Serj78 0]

Чтобы не плодить новые ветки решил вопрос задать тут.

Стою перед выбором между cortexM3 от ST и LPC от NXP/

Сейчас есть двухпроцессорный проект на меге32+ мега8. Используются все ноги и оба UART-a, 16 каналов АЦП.

 

Хочется следующую версию сделать на одном контроллере. с целью сокращения площади платы и расширения функциональности.

 

По запросам- хочется АЦП в 12 бит, ( в старом проекте использовался оверсэмплинг до 12бит, для поднятия разрешающей способности.) Но! измеряемое напряжение в районе 4.5 в :), поэтому, его придется делить, и 1 бит потеряется...

 

Код написан на С, есть несколько кусков, где программно делаются временные интервалы на 14 ногах одновременно, их, понятное дело придется переделывать. PWM 16-ти канальный у ST в этом смысле удобнее....

Был сильно удивлен отсутствием eeprom у обоих... куда настройки писать :( ?

 

По производительности устроит любое из предполагаемых семейств, какое, на ваш взгляд быстрее в освоении?

С АРМ-ом работать не приходилось еще...