короче говоря, цель достигнута - число постов в теме про 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 у обоих... куда настройки писать ?

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

С чего Вы взяли? Просто пример _Bool наглядно показывает несуразности в представлении данных

В этом виноват компилятор. В том, что процессор один бит из памяти достать-таки может, а компиляторописатели не могут обеспечить автоматическое размещение однобитовых переменных, хотя достаточно всего два усилия воли:
1. Выделение битового пула 
2. Оптимизация размещения - исходя из анализа выражений.

От этого ваще никуда не деться Char не пошлешь.

Лично мне более нравятся преимущества Barrel Shifter вместо циклов сдвига при нормализации/выравнивании

Почему же личное? Результат операции сравнения имеет тип int


Во флеш, куда ж еще.

Какой операции? && - этой?

Я о том, что

является сокращенной формой записи

и в итоге результат && становится int, т.к. операнды int по стандарту
Разве не так?

Думаю, что нет. Оператор if принимает уже логическое выражение, к которому сводится арифметическое, т.е. когда доходит принятия решения, то анализируется уже результат выражения в виде "истина/ложь". Поэтому:

bool && bool -> true/false && true/false -> true/false.

А арифметические выражения в операторе обрабатываются по схеме

<арифметическое выражение> && <арифметическое выражение> -> true/false && true/false -> true/false.

Т.е. почти также, но чуть сложнее - надо само арифметическое выражение привести к результату в виде "истина/ложь", тогда как в случае явных bool'ов это есть сразу. Сам анализ результата технически одинаков на большинстве платформ, но это уже детали реализации.

Т.е. сам оператор работает по сути как раз с логическими выражениями, к которым пробразовывает арифметические, если они присутствуют в аргументе. Поэтому нет необходимости логические сначала гнать в арифметические, а потом обратно.

Интересно, каким вообще боком относится тип bool к типу микроконтроллера (AVR/ARM/x86/x64 etc.)?
Понятно, что хочется блестнуть знанием С, но тема ведь не про это.
Лично для меня AVR были и остаются универсальными очень удобными контроллерами для "домашних" поделок. Не надо тебе ни кварца, ни спец-программаторов, нет каких-либо строгих ограничений по питанию, достаточно мощные ноги, достаточный размер памяти, экстремально низкая цена... Плюсы можно перечислять очень долго.
И ARMы эту нишу никогда не займут. Ну не нужно для какого-нибудь терморегулятора 32 битное ядро! Им нужно делать PLL, больше возни с программаторами, большее потребление, больше (а значит страшнее для новичка) даташит... Минусы опять же можно долго перечислять.

Itch, Вы привели пример типично религиозного мнения.
У любимой платформы - плюсы, у нелюбимой - минусы. Причём, многие утверждения - явно устаревшие. А узнать более свежие сведения мешает всё та же религиозность.

Мы здесь говорим о вынужденном переходе с AVR на ARM из-за веяний моды. Когда в кармане в сотике гигагерцы и мегапиксели, то как-то стремно становится иметь 64 байта оперативной памяти. Но это кому как. Мне вот не стремно. Много раз надо было собрать для дома кое-какие вещи. Просто брал простую AVRку и навесным монтажем ее запаивал, даже ПП не делал, из внешних деталей - только один конденсатор по питанию. И все работало, никаких проблем! Зачем мне переходить на ARM?

Это весьма спорное утверждение. Битово-адресуемая память имеется далеко не у всех контроллеров. Вот у кортекса-м3 эта фишка есть с его 4ГБ (или 32Гб, подзабыл немного - скорее 4ГБ т.к. 2^32=4ГБ) адресным пространством это нормально. А у того же АВР придётся заботится об атомарности доступа к таким битовым полям. Что сильно испортит всю малину. Я ещё на заре своей программистской деятельности под АВР тоже "оптимизировал" флаги и паковал их по 8 штук в байт. Но потом быстренько прозрел. И теперь один флаг - один байт. Компиляторописателям есть чем заниматься и так...
Вам не надо

Читаем первый пост:

P.S.
А "сведения" из мира НЕ AVR у Вас устаревшие все

Надо запаковать bool - используйте union. Но зачем?! Если идет разговор о гигагерцах и мегапикселях то там уже заниматься подобной чепухой не остается времени, да и смысла тоже.


SAM7Sxx - не такой уж и старый.
Вообще, мысли об ARM посещают, но сразу с прицелом в линукс. Однако полноценный MMU + контроллер TFT редко где встретишь, даже в контроллерах с ARM9-ядром.

AVR-ки если и смещаются, то в сторону классики микроконтроллеров. Туда-же где находится 51 архитектура. Благодаря удобству программирования, отладки, схемотехнике, уверен, что они будут жить очень и очень долго. Задач для них -море.

Проблема не в том, что старый (а он все-таки старый), а в том, что это одна из "первых ласточек". Хуже только 7A.


Из одних атмелов: AT91SAM9261(S), AT91SAM9263, SAM9G10 - мало?

А в чем разница между радиолюбительством и нерадиолюбительством.
В наличии или отсутствии печатной платы? Или в том кто ставит задачи: руководство или сам себе ? Или какой-то научный подход к решению задачи ?
Большинство того, что мы делаем на работе, можно делать и дома.
И наоборот. Очень часто то, что приходиться делать на работе, больше смахивает на радиолюбительство.

Так где же грань между радиолюбительством и нерадиолюбительством !?

В серийности и ответственности перед покупателями...

Есть предприятия, которые выпускают единичные изделия. А что вы сами к себе относитесь безответственно?
Если электронику воспринимать как хобби, то, по определению, она должна приносить удовольствие. А разве будет приносить удовольствие изделие (сделанное для себя), которое постоянно ломается или глючит?

Несуразности возникают только в сознании , когда путают переменную типа bool и операцию с битами. ЛЮБАЯ ПЕРЕМЕННАЯ - это одна или несколько ячеек памяти, а потому быть тождественной с битом она принципиально не может. А если нужны операции с битами, то это делается не с помощью bool-типа, а с помощью побитово расписанной структуры. Например:

Вот тут уже все становится ясно и компилятору, и процессору, и программисту - видно, что в памяти ассигнован блок в один байт (8 бит), из которого велено таскать биты.


Ни у одного процессора в мире нет в памяти однобитных переменных. И это уже потому, что память побитно не адресуется. Однако компиляторы обычно предоставляют пользователям удобные способы работы как с битами, так и с битовыми полями (см. мою предыдущую реплику). Однако надо понимать, что делается это "через ухо", т.е. компилятор достает слово памяти целиком, а потом вырезает из него нужные биты. Модификация бита стоит еще дороже - сначала процессор прочитывает целиком слово памяти, к которому этот бит относится, при помощи операций or и and модифицирует в нем нужный бит или группу битов, а затем записывает модифицированное слово обратно в память.
Инструкции ряда микропроцессоров (и AVR в том числе) позволяют модифицировать отдельные биты в собственных регистрах и портах, только в этом случае битовые операции над ними реализуются эффективно. Поэтому битовые флаги лучше всего держать в регистрах, а не в памяти. Во всех же остальных случаях, выгоднее не экономить на спичках, а заводить переменную bool типа. Такая кодировка действительно оказывается избыточной, зато ее применение компенсируется максимально высокой скоростью использования.
Можно с полным основанием считать, что тип bool является атрибутом оптимизации как по скорости, так и по объему кода, когда как его недостаток состоит лишь лишнем расходе памяти.

Ну, вообще-то у 51-го ядра есть Bit Addressable Area и набор команд для работы с ней.

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

Как и у всех.

Оооооо! А что это?




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

А хоть немного почитать топик и подумать?

А что, разве АРМы превосходят АВРы в том, что биты поштучно из памяти таскают?

Разговор как всегда уходит в сторону, о чем не забывают напоминать некоторые участники, особенно хорошо это получилось у Ксении, душевно так и логично.
И так по-порядку.
Самый первый пост от IGK навеян просто грустью по поводу прошедшей юности!!! Старые лохматые джинсы, в которых было так удобно тогда, а что сейчас...? - штанишки просто стали просто малы! Метания в рядах АВР-пользователей понятны, грустно прощаться с полюбившейся платформой.
Да мы вырасли на AVR-ках и сейчас на фоне новых требований к продукции разные там интерфейсы, GUI и т.д мощности процессора, надо это признать не хватает. Конечно есть устройства в которых ничего этого не требуется и естественно AVR будет жить, хотя бы как AtX _Mega (думаю по новому техпроцессу устройства получаются конкурентнее классики, поэтому такой соотношение цен на старые и новые модели) и нас просто плавно пытаются перевести на новую микруху. Эх раньше бы все это и не было бы такого разговора сейчас переходить на что то или нет. Например в рядах ПИК-поклонников такого метания нет, там все спокойно, вовремя появился PIC24, dsPIC30, dsPIC33, а теперь и PIC32.

Может быть нам (АВР-пользователям ) повезло меньше чем ПИК-пользователям?

Попробую дать ответ в следующем посте. И так, куда движется мир?

Точно. Между AVR и AVR32 не хватает AVR16.
После изучаемого в стандартном курсе 8080 (и нашего 580) я от AVR просто тащился.
Пока не потрогал MSP.
Теперь любое упоминание об изделиях атмела вызывает кислую гримасу на лице.

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

Вы выросли. Вот и мечетесь Я, например, к моменту первого ознакомления с AVR (в районе 2000ного года) очень плотно работал с PowerPC (не в микроконтроллерном варианте). Так что плотное пересаживание на восьмибитные камни для меня было серьезным даунгрейдом

но вот время реакции на событие у авр несколько сотен наносекунд, а ваше арм такое разве может?


время загрузки у авр микросекунды, а ваше арм такое разве может?

Кто это "мы"?

Или, куда делись те, кто вырос на К580, Z80 и AT89S.. (или i4004)?

А до этого были и Z80 (восьмибитовик?), и MC680х0?
Вам было не привыкать.

Никуда не делись.
Выросли...

А еще был K580 (факультативно, но результативно - кличку я еще в те времена заработал) и PDP-11 (до Z80). Так что и там даунгрейд

Любые 16/32 бит контроллеры "таскают" не так, как вы живописали по ширине шины, а в том числе и побайтно.
А подумать это относилось конкретно к тому, в ответ на что было написано, а не по поводу Ваших шинных размышлизмов.

А я вот видел людей, которые с MSP пересели на AVR и дико плевались от MSP. Кстати, в том числе и от их хлипкости. Так что всётаки это сугубо субъективно всё. Я, от MSP, никакого экстаза не получил что-то.
Ни система команд, ни переферия, ни наладка чёто впечатления не произвела. Прорывов в производительности тоже не ощутил. Короче те же грабли - вид сбоку. Тот же M16 круче на порядок. Сейчас ещё пикоманы подтянутся. со своими DS и 32-ыми.

Конечно, каждый камень свою нишу занимает, и есть неочевидные применения. Так например тот же сименс SC186 до сих пор широко применяется. Хот тоже как то мало смысла в этом видится. То есть просматриваются шкурные, корпоративные и прочие интересы. Думаю что TI принадлежит к компаниям, которые "продавят" на рынок любой камень. А столь малая ниша MSP как раз указывает на слабость решения.

Ниши занимают не камни.. Скорее, люди с камнями..

Мне нравится его чёткая упорядоченность.
Не хватило памяти или функциональности, скажем, 135-го - ставим на то же место 149 или 169.
Пин-ту-пин совместимость внутри серии плюс 100% переносимость прошивки снизу вверх.

Посмотрел бы я, как вместо 8-й меги впаяли бы 16-ю или 32-ю, и залили бы ту же прошивку!

Посмотрите LPC2368 - для моих задач перекрывает все (пока). Хорошая цена, много ног, много всего на борту. Правда 6 каналов АЦП (10бит). По площади платы врядли выиграете (если 2-х сторонняя). EEPROM поставте внешнюю (можно SD карту). Похоже по ногам совместим с LPC1768 (на будущее).
И вопросы:
у Вас работает действительно хорошо оверсэмплинг до 12бит?
Как делали - по апликейшену Атмела (с подмешиванием шума)?

Вы лучше в разделе ARM спросите, эта ветка такая, немного "флудоватая" , что не отменяет важности затронутых вопросов.
Я попробовал и STM32 и LPC ... Трудно сказать, что лучше, есть разные аспекты, зависят от приложения. В более простых проектах ориентируюсь на STM32.

Если по деньгам не сильно жмет, ставьте FRAM на SPI.

ну, 449 вместо 149 тоже не становится. У мег есть совместимость 48->88. 88->168 с перекомпиляцией.

В одну из страниц флеша программ.

[offtop]Кажется, я теперь знаю, что такое торллеркоастер.[/offtop]

Типа bool все-таки в С нет.
Мы добрались, до того что в C99 есть встроенный _Bool (назначение которого непонятно), то ли это int то ли это char, но однозначно не boolean... И некий козий #define bool. Проdefineное слово называть типом - извините не катит. Соответственно объявлять структуры так как предлагаете вы
...
bool a: 1;

не годится. Не место там макросу.

Вот именно, с перекомпиляцией. Потому что в соседних кристаллах все управляющие биты разные, как и адреса регистров.
А у нас снабженец надыбал где-то ящик 149-х по цене дешевле, чем 135 покупали.
Спокойно ставим, шьём тем же, всё работает.



Э нет, а точность 0,1% ?
С2-29 - практически единственный отечественный компонент, который мы используем в своих изделиях.
Даже разъёмы типа РС(Г)ххТВ проклятые китайцы почти научились делать

Сорри за офтоп, не сдержался...

Конечно нет. Но уровень ответственности не сопоставим когда для себя, как хобби, а когда для атомной станции или военного корабля (это не шутка я реально разрабатывал приборы для обоих случаев).
И ещё когда ты занимаешься этим каждый божий день - это уже перестаёт быть хобби. И большую радость приносят только заработанные деньги, нежели процесс... И даже всё это начинает надоедать, хочется чего-нибудь нового. Но зато уже телепатом становишься и фактически на любой вопрос имеешь ответ. Вот тогда то ты и перестаёшь быть радиолюбителем. А потом как ты это осознал, то попадаются тебе на форуме люди типа Zltigo или Real'а ну и ещё 5-10 человек и ты вновь себя уже раскрутейшим профи перестаёшь чувствовать Всё относительно ИМХО