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

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

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

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

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

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

Жалко, я не доктор Т. А то считал бы, что цель достигнута :-)
Здесь хоть по сути дела спорят, это уже хорошо. Спасибо модераторам. А телесисям хана полная, хотя и туда хожу по инерции.

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

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

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

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

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

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

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


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


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


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




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


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

Наверное



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

if (int_var1 && int_var2) ...

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

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

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

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

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

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

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