Точка зрения известная, но неубедительная.
Хотя бы потому, что пример Renessas не вписывается - крупный производитель МК с массовой линейкой 16 бит.

ARM конечно хорошо(для него сейчас и пишу ), но авр32 круче... а ренесас sh-2a еще круче...
А вопрос только в стоимости для начала реальных разработок для этих процов...

Коллеги, у меня к вам два вопроса.

1. А часто ли вам приходится самостоятельно выбирать контроллер? По моим наблюдениям (по крайней мере там где я успел поработать) выбор контроллера остается вопросом политическим или данью традиций. А мнение разработчика учитывается в последнюю очередь.

2. Почему Atmel до сих пор продолжает поддержку линейки контроллеров 51 серии, добавляя в нее новые кристаллы?

1. Всегда.

2. Ну, 51-й еще AVR32 переживет

51-й это ведь тоже 8 бит, а он до сих пор живее всех живых.

Так почему же все так пророчат скорую кончину AVR ?!

Видать xelax всетаки прав !!!

Всегда. Естественно, окружающие реалии на этот выбор влияют.

Потому, что и другие выпускают. И будут выпускать с разнообразной, в первую очередь уникальной, периферией еще долго. Причина - открытое, свободное от лицензионных отчислений ядро, очень простое - по нынешним временам в уголке чипа со своей периферией разместил, и порядок. Цены, правда, для 51 контроллеров общего примения вынускаемых, что Atmel, что NXP,.. тоже уже давно негуманные. Зато встречал всяких безвестных китайских производителей - у них дешевле только даром.

Много и других производителей, выпускающих "эксклюзивные" контроллеры, и среди них те, которые даже в России не продаются, но от этого они не развалились или не сняли с производсва свои контроллеры.

Просто всему свое место. Хотя эта мысь и пробегала по топику, но от прочтения всего топика в целом, складывается впечатление, что AVR must be die.

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

Вы работали с АВР32? Чем "круче"? Крутость пока только в рекламах Атмела. Интересует сравнение на реальных проектах. Типа: "Мы тут скомпилили для АРМа такого-то и для АВР32 такого-то, получили такой-то прирост производительности/энергопотребления/латентности и пр." Часто бывает на тестах фирмы производителя одно, а на реальной практике совсем другое. Где-то на форуме пробегала тема, что Атмел заявлял декодирование mpeg4 VGA в реальном времени 25 кадров в секунду, а в реальности не получалось больше 5 кадров/сек. Чем принципиально АВР32 отличается от XScale (кроме как более низкими частотами и сомнительного будущего)? Прошу к моему посту отнестись адекватно. Я не критикую АВР32, просто хочу узнать мнение со стороны.

Ну, на нашем пространстве, где "все вокруг колхозное, все вокруг мое", точка отсчета смещена.
По нашему - это взять лучшие в мире компиляторы бесплатно, и зажать пару сотен на средства программирования и отладки, потому что дорого. Да и уровень знаний... Вот АVR и становится "нашим всем".

Кстати, на lpc yahoo group кто-то из русскоязычных недавно удивил импортный народ вопросом, как подключить u-link к IAR. Мало кто мог понять зачем

Да и мне не нужна

Я наоборот за разнообразие. Должен быть выбор. Кому что надо.

Только выбор должен быть осознанный, а не инстинктивный, как у Ежика, которому ну очень "надо" стало кактус.

Так уж и добавили: при попытке сравнить с AVR8 для команд ничтоже сумняшеся делим память на 2, для данных - где-то тоже на 2, если не хотим разменять шустрость на оверхед 

В ARM тип данных char никто не отменял !!!

В кортексах уже ни то ни другое не актуально. Код получается компактнее и выравнивание данных не требуется.

Только скорость падает без выравнивания. Так что если давить последние соки, то надо следить.

Я поэтому не на 4 поделил Кроме массивов есть еще рабочие переменные, которые "посодють" весь перфоманс в лужу, если их представлять разрядностью, отличной от разрядности армового регистра, даже если Вам надо всего-то 1 байт от него. 

Всего то новая система исчисления:
10 (new) = 100000000H

В своё время меня до глубины души возмутила запись в <stdbool.h>
#define bool uchar

А теперь ничего, привык

А как по вашему можно еще?
Делать ее размером в бит и обединять все логические переменные проекта в байты?
По памяти будет выйгрыш, но по производительности не всегда, не все же контроллеры могут тестировать биты, а проверить на ноль байт все.

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

+ пицот

Тем более, что важен не сам bool, а в логическом выражении. А тут уже структуры с битовыми полями утрясутся компилятором до пары выражений and/or с константой (набором бит), а при операциях с тупо bool - никогда красоты такой не увидать.

Если звезды зажигаются, значит это кому-то нужно.

Эта звезда точно нах не нужна

Bool - это закидон из языка другого уровня, повыше, чем Си (хоть с десятью плюсами).

В курсе

Эта "звезда" предусмотрена специально для пришедших с "языка другого уровня", дабы не вызывать у них состояние когнитивного диссонанса.

А эффект от него - обратный. Вводящий в ступор.  Как и реализация довольно-таки абстрактного и платформенно-зависимого типа Boolean на "языке другого уровня" в виде 1 байта. Дурдом.

Какой ещё ступор? Нормальный тип, два состояния, "да" или "нет".
Логически воспринимается проще, чем int или char для этой же цели.

Человеком, но не процом с разрядностью регистров больше char.

Хороший пример. Хотя эти заразы (Luminarymicro) для получения даташита требуют регистрации, нашел, хоть и устаревший (2006-го). И что там видим.

Да, круто. PLL до 200МГц, UART с буферами, до 4-х 16 битных таймеров, встроенное деление, LDO .... В общем ГУД.

А теперь ложка дегтя . Традиционно - отсутствие ЕЕPROM. Нет АЦП. Ну и самое главное - потребление 35 мА на 20 МГц "System Clock(with PLL)" (сколько кушает в sleep-е в той доке не указано )!!!

ЗЫ. В общем вот так и получаем, что как только речь заходит о устройстве с батарейным питанием AtMega88 становится в данном случае более разумным выбором (кстати, и более дешевым) чем LM3S102...

Ну тут, видимо, компромисс между скоростью обработки и обьёмом занимаемой памяти...


А что так боимся зарегистрироваться? Не съедят, уверяю!

Какой, к черту, компромисс? Вот если бы bool был нативным типом у компилятора, да еще и правильно обрабатывался, тогда да.

Чего-то я не понимаю. В чём проблема-то? Хотите быстро, определите свой тип BOOL как uint_fast8_t. Хотите компактно используйте макрос битовой упаковки. Си позволяет делать и то и другое. Контроллеры то тут причём?

Хочется, чтобы и быстро, и качественно. А это значит, что пока операнд в регистрах - должен иметь тип uint_fast8_t, а когда попадает в ОЗУ - просто uint8_t. Без нативной поддержки компилятором это сделать автоматически невозможно, а значит bool идет лесом



Контроллеры ни при чем. Так, оффтоп небольшой. Щас завяжем, опять будем AVR8 гноить

Простите, а как хранится uint8_t в регистрах 32битного процессора?

Помоему WORD или DWORD, если не ошибаюсь.

Даже это не факт - и в RAM, может потребоваться uint_fast8_t, короче, bool несколько скользкий уровень абстракции. Хотя ввиде enum, для повышения степени контролируемости его использование не исключено.

В регистах предлагалось uint_fast8_t - а это не 8 bit , на ARM платформе.

Я про то, что если для булевых выражений использовать uint8_t, то в памяти это будет компактно, и при булевых операциях это будет быстро на 32битной архитектуре.

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

не думаю что
"!(uint8_t)"
будет медленее
"!(uint_fast8_t)"
(при логических операциях маску не надо накладывать)

Не требуют, а предлагают зарегистрироваться. Можете отказаться от регистрации (выберите кнопку OPTIONS) и ссылку на даташит вам-таки дадут, но в следующий раз опять предложат зарегистрироваться.

Да? а ~boolvalue кто будет запрещать делать с Вашим 'bool'
Ну и нафиг такой bool ......

Так в трезвом уме делать низззя =) потому-что (0x02) это истина для компилятора, а ~(0x02) получится тоже истина, вопреки ожиданиям. А тех кто путает битовые операции с логическими воспитывать надо =). Сейчас речь шла о логических операциях.

Повторяю вопрос - лично Вы будете воспитывать, следить и так далее, дабы с этим "чудесным" bool работали только &&, ||, =0, =1? Не компилятор? Ну и зачем этот 'bool', который и не bool? Для удобного наступания на грабли?

~ это есть тоже вполне себе логическая операция. Поразрядное логическое НЕ.

Спасибо, помогло. Правда от полноты информации не стало выглядеть лучше. Итого - ток рабочего режима вырос до 45-50ма, ток Sleep в режиме "все остановлено" - 17-20ма, ток Sleep в режиме "все выключено" и тактовая разделена на 16 - 0,8-1ма. И на кой при батарейном питании такое потребление?!

ЗЫ. Кстати, бегло просмотрел доку и не совсем понял. На кой там 200 МГц PLL если System Clock не более 20 МГц?

Это риторика? В противном случае вопросы не по адресу. Причем тут частоты и батарейное питание? Упоминание этих МК было в ответ на реплику как пример ARM в корпусе SOIC-28. И не более того.

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

Вообще, серия Luminary (по крайней мере их младшая линейка) никоим образом не конкурент по потреблению тока.
Чипы здорово греются и жрут немеряно.
Их привели только в качестве малоногих армов. Может быть отладят техпроцесс или доработают камень когда нибудь...

А вообще, такое ощущение, что их разрабатывали впопыхах, лишь бы успеть побыстрее выкинуть на рынок...

Чипы попали в лапы TI - теперь им ппц. Максимум останутся такими же как были. (imho)