трудно советoвать не зная задачи. за 25 EUR можно купить SH7125 :
http://www.glyn.de/prod_shop.asp?wdid=878&...9564562505A4652
www.glyn.de неплохои выбор.

Вы сначала требования к задаче (требуемые вычислительные ресурсы/периферия) обрисуйте, а потом уже чипы обсуждать стоит.
p.s. Пост 39 (на 3 странице) я дополнил весьма красноречивыми данными от EEMBC.

Да чего-то на DSP задачах он (UC3, естественно) и дсПИКа @ 40MIPS уделать не смог. Вон, атмель аппноту выпустил, кто хочет, может цифры сравнить. Ладно FFT, у дсПИКа все таки аппаратная битреверсивная адресация есть. А КИХ? Тем более, что у AVR32 есть арифметика с контролем переполнения в системе инструкций.
А что вам конкретно понравилось в системе команд и архитектурном решении? спрашиваю без всяких левых мыслей, не флейма ради...

При работе из-под компилятора и равной тактовой результат скорее будет обратным. Не случайно Atmel даже в рекламе вынуждена была заявить меньшие цифры Dhrystone, чем на PIC32 (при том, что у того они взяты из уже накопленной статистики по ядрам MIPS, т.е. явно реальнее). Единственный шанс - "ручной" код или переработка микроархитектуры. В опубликованном виде ядро AVR32 (я не говорю про камень в целом, там периферия важнее) просто неконкурентоспособно по критерию производительность/МГц с уже известными. Архитектурные новшества там пока актуальны только для специфических применений.

p.s. Все фундаментальные исследования в проектировании процессоров были сделаны еще до микропроцессорной эры, и большинство нынешних "новшеств" при внимательном рассмотрении оказываются давно опробованными и испытанными еще в 60-тых-70-тых годах на "больших" ЭВМ. Более того, до сих пор есть еще очень много полезных решений, не перенесенных на кристаллы

Не очень понял как это все относится к ренесасовсим чипам...
Ну и EEMBC тесты во многом не адекватны, они в основном измеряют "грубую" силу,
те к примеру вопрос времени реакции на прерывание в них просто не рассматривается,
а по "грубой" силе Intel c AMD хрен превзойдешь....
Все действительно зависит от задач, но для многих из них ренесас будет в самый раз...

В архитектуре (UC3) понравилось то, что есть несколько теневых стеков для быстрого переключения контекста. В наборе команд - слишком много интересных вещей, чтобы перечислить - многие я не встречал ни в одном CISC. А вот DSP-часть слабовата - ну типа на уровне ПИК32, но до дсПИК33 - как раком до Китая, если не брать в расчет 32-битность

А у SH-2A 15 теневых банков регистров для быстрых прерываний
ну и DSP в некотором виде тоже присутствует...

Ну против Renesas-овских чипов я вроде ничего не говорил . Разве что поддержки никакой и не особенно быстрые они - максимальная тактовая не выше 200 МГц для SH2(A). Забавно, что SH2 по архитектуре довольно похожи на MIPS, только регистров меньше и немного добавлено "кучерявости" (что снижает максимальную тактовую при прочих равных, но для контроллера это допустимо). Ток потребления, правда, это заметно увеличило.
Время реакции на прерывание в тестах EEMBC на самом деле рассматривается, только в другой группе тестов - automotive index, впрочем, его нетрудно оценить по документации. MIPS (особенно с теневым регистровым блоком) там отнюдь не аутсайдер.
По "грубой силе" - лидеры известны, Power PC, MIPS64 и AMD Opteron/Intel Xeon. При "ручной работе" над кодом - на многих задачах лидер Intel, при коде из под компилятора - наиболее стабильные результаты у старших MIPS64, а PowerPC - "и нашим и вашим".


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

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

То есть последних два десятка постов обсуждают "критерий из последней десятки". А может хватит из себя супермена строить а взять и признать что архитектура имеет важное значение? Вы же её внимательно изучили и сравнили с другими. Так зачем людям мозг парить? Равно как и другие параметры из той же десятки.

А я не боюсь показаться непрофессионалом и признаю.
1) Архитектура ИМЕЕТ значение. Достаточно сравнить тот же MIPS, ARM7, AVR32. Даже слепому видно что это не одно и тоже. И при написании программы это необходимо учитывать. Причём не только когда на асме вставки делаешь. Для разных процов при оптимизации сишной проги тоже будут разные подходы.
2) Переферия тоже в пределах семейства перекликается. Таким образом внутри семейства удобнее переходить, чем скакать с камня на камень. Что бы вы не говорили про пару часов.
3) Я не буду обзывать библиотеки поставляемые разными словами, но приходится признать, что порой легче свою написать, чем воспользоваться чужой. Ну и само сабой лучше, если это свои библиотеки.
4) Не каждый легко и непринуждённо переходит со среды на среду. Или вообще работает одновременно в нескольких. Для меня, к примеру, это длительный процесс. И я думаю, что я не одинок. Может именно по этому народ выбирает максимально многоплатформенные компиляторы?
5) И Отладочные средства вместе со всякими лоадерами и прочим барахлом настроить на столе собрать, перходников настрочить разных, проги некоторые писишные подправить. Тоже время.
6) Я не снабженец конечно, но и тут переход с камня на камень ведёт к задержкам и проволочкам как правило.
7) Что-нибудь в платах накосячат по-первой обязательно.

Конечно, когда возникает производственная необходимость, то приходится переходить - хочешь-не хочешь, но если её нет - то не вижу смысла. Ну кроме люботытства или с целью познания нового. И переход с камня на камень всётаки нормально времени отнимает. Там пару часов - там день там два - глядишь и набегает. А где-то к концу проекта - смотришь и думаешь - выкинуть бы всё это в топку и переписать заново - сделал бы уже намного лучше.

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

Мне не надо СПАРК - мне надо вменяемый МК на все случаи жизни, а не голое АЛУ с кучкой регистров. Мне нужна "на борту" вменяемая периферия, к которой я могу обратиться за 1 такт, а не за 83 транзакции периферийной главной шины с юго-западным мостом. Мне не нужна внешняя шина, но нужен достаточный объем опять же однотактовой RAM, да желательно с разделением на XRAM/YRAM/DMARAM. А еще мне хотелось бы вместо всех этих костылей с динамическими стеками прерываний иметь одно хорошо забытое решение - автопереключение базового смещения адреса начала регистрового блока для каждого из имеющихся прерываний, да и еще много чего. Но хотеть, как мы знаем, не вредно

Думаю, что этого нет по маркетинговым причинам. Хорошо сбалансировать архитектуру и периферию - долгая и кропотливая задача, некогда ей заниматься, тем более что в хорошей архитектуре нет "вычурностей", которые легко обыграть в рекламе.. Скажи спасибо, что среди процессорных ядер всего пара-тройка хорошо сбалансированы, а в обрамлении, считай, еще конь не валялся - кто во что горазд!

под эфективностью/производительностью я имел в виду именно производительность
на 1МГц тактовой ну и набор переферии...
понятно что со старшими MIPS сравнивать нет смысла, но вот эфективность
архитектуры/ядра/переферии в комплексе, если "грубой силы" достаточно, впечатляет...
Ну и двухядерные контроллеры у них тоже уже есть SH7265

1. Да. И главное - реальная (а не рекламная) производительность (с учетом мощности потребления и разрядности). Если вычислительной мощности не хватает - все, проект помер. Нехватающую периферию/память можно приделать, а вот ресурсов CPU на реальном коде - не добавишь.
2. Очевидно, хотя тут при необходимости присобачить что-то свое довольно легко (АЦП там).
3. Библиотеки - да, хочется сэкономить время, но в результате часто быстрее написать свое.
4. ТУЛЧЕЙН - ГЛАВНОЕ. Хочется универсальный, например, GNU/GCC.
5. Отладочное железо - тоже статья расходов. Хорошо хоть живет достаточно долго.
6, 7 - понятно, хорошая разработка часто для надежности сразу делается на двух разных камнях (но по возможности с одинаковым тулчейном).


Не все так очевидно. Не все то, что красиво выглядит, оправданно на деле. Тщательно просчитанный "брутальный" подход, как правило, более эффективен.
Эффективность ядра на реальном коде лимитируется ветвлениями и латентностью памяти, поэтому по моей оценке, SH2 хорошо если в среднем выполнит 1.2-1.3 команды за такт. Но бОльшее количество доступов в память из-за меньшего числа регистров запросто съест этот выигрыш. В итоге получаем примерное равенство в производительности на мегагерц с MIPS, но гораздо больше логики в процессоре - в результате минус в тактовой и энергопотреблении (что и имеет место).
А вот то, что это цельный камень, и периферия довольно хорошая - безусловный плюс.
Кстати, в MIPS наконец, поняли, что одних только, пусть и очень "вылизанных", процессорных ядер для успеха мало, и прикупили фирму, разрабатывавшую разнообразную периферию. Так что есть все основания ожидать интересного развития событий.

кажется Вы не особо в курсе с развитием SH. старшие из них IP core, как и MIPS. поэтому, корректно сравнить mips64 с SH5 ( 64bit IP core)
http://www.renesas.com/fmwk.jsp?cnt=sh5_ch...&title=SH-5
или SH4A. представитель: SH77850.
http://www.renesas.com/fmwk.jsp?cnt=sh7785...s/sh7785_group/
что касается подержки то тут SH и MIPS равны, gcc/gnu и linux имеют оба.
но мне кажется это дискуссия давно вышел за пределы началного вопроса так как микроконтроллеров с такими ядрами нет.

Если Вы заметили, в контроллерном контексте я говорил про SH2(А) и MIPS32, как самые экономичные. Кстати, официальные удельные производительности - 1,5 DMIPS/МГц у них как раз одинаковы, так что получается, что моя оценка подтверждается и официальными данными. Тактовую частоту в 200 МГц оценил навскидку, не смотря на roadmap, просто из очевидных особенностей реализации системы команд. Смотрю - для SH2, судя по roadmap, так и есть.
Про старшие SH4/SH5, к сожалению, могу только посмотреть картинки, подробной доки нет и шансов на ее приобретение тоже немного, тем более что это скорее "индпошив". Что же касается сравнения SH4/5 и MIPS64, то не очень высокочастотные чипы MIPS64 (RM5231/61, 400 МГц, не более 1.2 Вт, реально меньше) - вполне доступны и документация на них есть. Это не контроллер, но embedded вычислитель сделать на них можно. Достать и запустить SH7785, вероятно, тоже можно. FPU у него выглядит поспециализированнее на графике и подохлее на обычной полноразрядной математике, остальное - примерно баш на баш с учетом тактовой. Периферия побогаче у Renesas.

Нет "полноформатных" SH4/SH5, но MIPS-контроллеры есть. У PMC есть как экономичные 400 МГц MIPS32 - микроконтроллеры (MSP8110|20), так и более быстрые (до 1 ГГц) суперскалярные с FPU - MSP8510, это процессоры-контроллеры со встроенными 10|100|1000EthernetMAC, SDRAM int, нормальным контроллером прерываний, UART с FIFO, Watcdog/timers/SPI и т.п.. Еще Cavium делает быстрые и экономичные, в том числе многоядерные контроллеры с архитектурой как MIPS32, так и MIPS64 с кучей интерфейсов, правда, без FPU - а оно-то, IMHO, и представляет самую сильную сторону MIPS64.
Т.е. микроконтроллеры с быстрыми MIPS ядрами и встроенной периферией в виде готовых ИС есть.

Давайте, так, остановимся толко на "контроллерных" чипах,
официальными для SH2A являются 2,4DMIPS/МГц, ну и это конечно сильно завышено, но 1,8-2.0
это уже где-то ближе к реальности...
Хотелось бы услышать Ваши коментарии конкретно про чипы 7201,7203,7263,7265.

1. По поводу ядер и реальной производительности - я ее нашел только на SH2, на SH2А пока стороннего результата нету. Учитывая разницу 2 и 2А плюс доработку кодогенератора, ~1.8 DMIPS/МГц при небольшой "доводке" компилятора вполне реальны.
К примеру, для того же MIPS, даже самого простенького ядра 4Kс, в той бумаге, что я выкладывал, приведены как "тупые" 1.39 DMIPS/МГц, так и при разрешенной компилятору глубокой оптимизации, 1.8DMIPS/MГц. Для более сложных ядер там есть и 2.2, и 2.4 DMIPS/МГц для кода из-под компилятора (не "ручного").

По частотам и отчасти архитектуре на MIPS32 больше похоже более совершенное (чем SH2) семейство SH4, у них (с сайта Renesas) http://www.renesas.com/fmwk.jsp?cnt=sh4_ch...&title=SH-4
....
SH-4 family performance
The SH-4 family delivers impressive performance across a range of multimedia applications.
Benchmark Performance
Dhrystone 2.1 1.5 DMIPS / MHz (SuperH gcc)
.....
Недостаток - маловато регистров в FPU, из-за чего трудно использовать полную производительность FPU при цепочечных операциях в цикле, особенно при двойной точности, т.к. для этого нужно примерно 2,5...4*(длина конвейера) регистров.

Введение в качестве базовой операции FPU умножения матрицы на вектор - весьма рационально, у меня самого так было сделано в 1989 году. Выигрыш - существенное снижение запросного отношения (отношения числа доступов к памяти к числу полезных - алгоритмических - операций) при преобразованиях координат, выполнении ДКП/ДПФ/БПФ (особенно комплексного или вещественного с основанием 4) и на матричной алгебре типа решения СЛАУ (чем контроллер вряд ли будет заниматься).

Общее резюме - архитектура целочисленных ядер SH переусложнена, что снижает эффективность ее реализации.
Пока по рациональности архитектуры, похоже, что лучше MIPS ядер реально нет.

2. На 7265 доки пока нет, комментировать пока нечего. Выигрыш от двуядерности в среднем порядка 1.5, но иногда может быть даже больше двойного, если удается разрезать задачу поровну, за счет сокращения числа переключений контекста.
3. 7263 - "Все в одном", вплоть до CD-ROM декодера. Детально периферию не смотрел, видно, что он заточен под аудио-функции (необязательно суперкачественные, но чтобы было все - и прием данных с Toslink/AES, и с CD, и передискретизация, и всевозможные пролоджики/декодирования - 5.1 на процессоре).
4. 7201 - в целом вполне симпатичный камень. Только шин многовато - сложнее управление периферией, а так вполне.
Вообще, нужно смотреть по задаче. Если реально ничего особенного в именно вычислительном отношении не требуется - то что SH, что MIPS - это пальба из довольно громоздкой и прожорливой пушки по воробьям. При аккуратном подходе для преимущественно логических задач хватит недорогого и беспроблемного ARM, а то и быстрого х51. Реакция на прерывания у них быстрая. Лично был свидетелем того, что замена кода с кучей проверок и switch на табличноуправляемый конечный автомат позволила С8051F131 на неполной тактовой справиться с задачей, которую откровенно не успевал отрабатывать PC104
5. Все упомянутые Вами процы Romless и работают от SDRAM, так что это (как и упомянутые мною MIPS) уже не совсем контроллеры, скорее встраиваемые процессоры. Более существенно то, что в описании, наскоро глянув с экрана, я не нашел (может и есть, но не заметил) или принудительного удержания в кэше команд кода обслуживания прерываний или наоборот, блокировки кэша для предотвращения замены его содержимого. Если это так, то из-за этого не только будет замедляться реакция на прерывание, но и увеличатся потери на замещение кэша после прерываний. Перезагрузка линеек кэша вносит задержку переключения контекста куда больше, чем время загрузки/сохранения регистров.

Romless, но все же, оптимально держать обработку прерываний в SRAM, а там кеш
не играет никакой роли...
Вы пропустили в своем описании чип 7203, а он ИМХО, как раз самый интересный.....

Если процессору можно запретить при этом трогать кэш, чтобы не было вытеснения - то да, это оправданно.
Завтра внимательнее посмотрю, гляну 7203 - но ядро у него на первый взгляд вроде такое же как у 7201, разница в периферии.
Но честно, не зная задач оценивать трудно. А как "универсальный процессор на все случаи жизни" - таких, IMHO, не бывает.
Нелишне припомнить, что "Буран" успешно был посажен 16-битным (если мне не изменяет память) процессором с производительностью менее 10 MIPS и памятью 128К.

Не очень понимаю о чем речь, для SRAM работающей на частоте проца наличие/отсутствие
кеша абсолтно пофиг... или я в чем то заблуждаюсь ?
ядро одинаковое, разные переферия и частоты ядра, ИМХО, просто очень правильный
чип/"контроллер" из топовых и при этом относительно недорогих...
Дык и AVRом наверное можно было бы посадить
Ну а если говорить о задаче, пусть это будет замена промPC...
То есть не промПЦ в чистом виде, а замена промПЦ+(ну то что удасться впихнуть)....

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


А смысл ? Разработка в целом будет долгой и соответственно достаточно дорогой, при тираже до ~50-100 шт. рентабельнее найти недорогую плату PromPC. Они более-менее приличные от $300-400 начинаются, и потребляют не так уж много. Если задача не слишком сложная - PTS DOS и вперед, при грамотной собственной программе машина виснуть не будет, и деньги от заказчиков пойдут быстрее, чем если возиться со своим железом.

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

Разработка софта что к ПромПЦ что к своей плате стоит намного больше чем стоимость одной
платы, так что здесь мало что съекономишь, но можно сделать просто более "правильное"
решение.... ну и тиражи не обязательно ограничиваются 50-100шт.....

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


Дело не в SRAM, задержку внесет контроллер кэша - ему же, прежде чем процессор начнет работать, целую строку (не одно слово) загрузить надо. Впрочем, для 200 МГц процессора в абсолютном измерении это немного, не больше нескольких сотен наносекунд (хотя и это порядка сотни команд проца).

На промПЦ софт уже есть,
Очень хотца сделать все на своем железе и более правильно...
А был ли мальчик ?
Вы уверенны что проц будет ждать загрузки всей строки в кеш перед тем как начать
исполнять инструкции ?
ИМХО, здесь паузы быть не должно...

Загрузка линейки кэша начинается не с произвольного адреса, а с адреса, кратного длине линейки. Поэтому, если требуемый код начинается не с адреса первого слова - то все равно нужно будет дожидаться, чтобы контроллер кэша загрузил предшествующие даже при "умном" контроллере кэша, не дожидающемся полного заполнения линейки. Частичная загрузка линейки сильно усложняет (и замедляет работу) автомата загрузки, поэтому ее практически никогда не предусматривают, пока длина линейки меньше ~32...64 слов. В описании я указаний на это не нашел.
В быстрых процессорах не все так очевидно, многие сложившиеся исторически ранее приемы работы на них "не в кассу". Например, сильно развитая система команд, длинные конвейеры и куча слоев кэшей на задачах реального времени, где в коде между плохо предсказуемыми переходами всего по 5-10 команд, запросто приводят не к повышению системного быстродействия, а в основном лишь к повышению энергопотребления. Для рилтаймовой машины "навороты" часто вредны, а наибольшую пользу приносит предельно быстрая (по полному времени доступа!) память с небольшим (2...4) расслоением плюс процессор без "кучерявости", но с коротким конвейером, мощным АЛУ и максимальной частотой. При создании мейнфреймов это все было хорошо изучено еще 25-35 лет назад.

ответ в даташите SH7203 стр 242 и 1411. кешируются адреса 0x00000000 до 0x1FFFFFFF, к осталному обрашаются "обычным" путем.
внутренныи RAM 0xFFF8xxxx. но сколько тактов занимает обращение к нему, так и не нашел, подозреваю что ограничен это с системным bus clock ( max 66 MHz) .

Хорошо, что у него можно обойти кэш. Падение скорости даже в 3 раза при выполнении коротенькой программы отработки прерывания не страшно - потери от порчи содержимого кэша могут быть намного больше. Потом посмотрю поподробнее.

Мда... хороший у вас АВР32 такой получился - душевный, главное. Не пора ли завязывать?

Я тоже подумываю, куда двигаться дальше, после ARM7.
Так получается, что выбор в основном крутится между AVR32UC3 и STM32.

Логичнее ARM9. Опять же, для отладки/программирования можно будет воспользоваться, как правило, средствами от ARM7, если не меняешь производителя камней.

Вовсе нет.
Во-первых, на ядрах ARM9 – это совсем другой класс камней, а, во-вторых, и AVR32UC3 и STM32 (на Cortex-M3) по производительности (нормированной) делают ARM9. Мне, впрочем, такой производительности и не надо, а вот снижение потребления хотелось бы.
По идеи, средства отладки от ARM7 должны подходить к STM32.
У AVR32UC3 характеристики получше (обещают), а на STM32 цены пониже (обещают). Вот и мучаюсь.
Скорее всего, буду применять и то и другое, в зависимости от ситуации.

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

Без "идей" - все нормально.

На STM32 уже не обещают - это реально выпускаемый чип с низкой ценой, например, даже Arrow (http://www.arrow.com/) в Латвии вчера назвал "стандартной ценой"
STM32F101T6U6 - 1,43LVL
STR910FAM32X6 - 3,25LVL.
USD это примерно 0.47LVL
При этом у нас в розницу какая-нибудь
ATMEGA8-16AI - 2.00LVL

Это, считай, 4 бакса? Ох что-то совсем круто. 1$ ей красная цена

Жутко круто, но не обманываю:
http://www.ormix.lv/Veikals/Mikroshemi/microcontroller.htm
http://www.elfa.lv/cgi-bin/index.cgi?artnr=73-672-04
Хтя это типа розничная c местными гримасами "бизнеса" - (типа "вот на эти 2% и живу").

Тогда понятна Ваша "нелюбовь" к AVR (я шучу)

Цена на ту же M128 у нас $7(розница), у вас $14

M16 у нас $2, даже дешевле чем M168 (та почти 3, вынужден использовать из-за 20МГц, опять же ждем XMega).

Так что мы ждем вполне удобоваримых цен на AVR32.

Даже Ваша цена в 7USD абсолютно неадекватна уровню M128. Абсолютно!
И именно это вызывает не нелюбовь, а просто удивление, когда их начинают использовать в новых разработках. Для ниши самых мелких контролеров до уровня в пару баксов использую (буквально в субботу сделал финтифлюшку на ATTiny2313 ). А для другого есть более правильные вещи. Причем сейчас, ждать милостей

от природы Atmel совершенно незачем. Тое-же трехбаксовый STM32 уже реальность.
NXP, тоже туда подгребет (Atmel тоже обещает , но тогда ему придется продавать AVR8 по цене кадиллаков 68 года для особых ценителей ).

Многовато. Но, иногда надо. Больше денег получается в варианте плис+арм, а 32 бита и нафиг не нужно.

А сама архитектура AVR32 мне кажется более достойной, чем костыль под названием Thumb2 - давайте смотреть правде в глаза, ведь получить полностью набор комманд ARM-состояния можно через специальные инструкции, т.е. даже просто 30 процентов регистров (R8-R12) можно использовать только так (ну не считая возможностей пересылки, арифметика уже кривая). Вот такая структура в корне подрывает идею ортогональности набора регистров. В этом отношении у AVR32 все впорядке. Про загрузку непосредственных операндов я уже как-то писал.

Сильно-сильно сомневаюсь, что использование M128 сегодня объективно "надо" , ну разве только какой-то вырожденный вариант типа с большим (внешним) обемом RAM, относительно мало потребляющий и с мощным ногодрыганием и мееедленный. Но что это такое, я, например, не представляю

Это чего такого из периферии НЕТ у котроллеров на ARM платформе, что к ним для получения фукциональности ATMega приходится CPLD/FPGA цеплять?

Ну-ну я тут в прошлом посте поминал, что в субботу делал поделку на ATTiny. Так вот, на вскидку там вроде тоже 32bit и не пахло и заказчик самоcтоятельно сваял простую железку, но потом пришлось банально раз в 50ms на лету сгенерить псевдослучайное число и, что хуже, на лету просчитать (пару 32bit делений и умножение обязательны) ширину следующего импульса, причем длинна генерируемой последовательности добрых 4 миллиона отсчетов. Без 32bit, и отсутствующих у Tiny команд умножения "в лоб" получил порядка 120us на 9MHz тактовой, пришлось мудрить, немного снижать точность и уходить на 18MHz. При всем этом устойство на самом деле простейшее.

Как мало меня волнуют архитектуры - пусть об этом в подавляющем большинстве случаев голова у разработчиков компиляторов (кои для классических архитектур достигли хорошей степени совершенства) болит. А пару десятков-сотню команд я вполне эффективно напишу на ASM в любой системе команд, естественно в случае жестокой необходимости.

Лапками подвигать в точно заданный момент времени. Я понимаю, можно таймера позаводить, ну а если не хватит? Кстати, если вопрос про ногодрыгание армов обсосали до костей, то вот обратный процесс - считывание состояния в нужный момент пока покрыт мраком (может только для меня, тогда просьба просветить, например дачей ссылки)



Надо было ATMega48 брать, дешевле и с аппаратным умножением.



Да не такое уж оно и медленное, все от задачи зависит. Ну вот для примера такой проектик - надо, например, обслужить много емкостных датчиков (сигнал возбуждения генерит сама мега, она же управляет зарядовым усилителем и сигма-дельта АЦП, тут точность лапкодвижения очень помогает)), посчитать результаты измерений (тоже по каким-то формулам, не очень сложным, но с * и /) и вывести на ЖКИ, по интерфейсику просунуть, например, попутно еще организовать архивчик, еще полезности какие - то в самый раз. Да, и из-за малого потребления взрывозащита вида "искробезопасная электрическая цепь" на раз. Понятно, если мне надо будет, ну например, многоканальный коррелятор для РЛС делать, так я возьму другой камень, да и Вы тоже

Дык, не подумали творцы. В общем-то все сделал и на том, что есть и по верхнему генерируемому диапазону в желаемые потом на вырост 30KHz уложился. Естественно, могли взять Meгу, пусть даже подороже на 5 центов и программиста подешевле

Для этого примера берется тот-же STM32/LPC210x с их мегагерцами и уже быстрыми GPIO за 3USD и все....

Нет, я возьму другой и для многих других задач попроще, если цена (реальная) контроллера на котором можно его сделать будет превышать 2-3USD, или при маленьких тиражах, когда поставив, например, 5USD контроллер можно сильно сэкономить свое, достаточно дорогое, время.

У нас сравнимый по размеру флеша и количеству лапок LPC210x стоит как мега128, местами даже дороже. И я еще не уверен, смогу ли я пошевелить лапками LPC210x в нужный момент для переключения выходов возбуждения и ключей зарядового усилителя без джитера. Так что неизвестно, сэкономлю я время на разработке с учетом исследования этого вопроса или нет.

Да и есть еще один момент. В таких шевелениях лапками я руку набил уже будь-здоров, так что уже знаю, на что можно расчитывать. И не займет у меня уйму времени написание софта, все будет в пределах разумного. Зато каждый доллар, сэкономленный на камне, капнет мне в карман. Даже на серии в 100-200 штук будет приятно. Если задача чисто вычислительная (ну или подобного плана), я конечно буду действовать другими методами (вот и склоняюсь к AVR32, маленькие приятные мелочи в архитектуре радуют).


Опять же, вот любят говорить - "поставь плис". А чем, собственно говоря, проектирование прошивки плисины отличается от того, что я программу напишу для проца с точно описываемым поведением ядра.

Но чето мы от темы отошли. Начали за AVR32, а переехали на AVR8 и на ARM.

Сравнивать бамбуковые цены (точнее размер аппетитов мелких локальных торговцев) занятие бессмысленное - а реальные цены на LPC2101 в той-же России у MT-System 1,6USD.

Ну и продолжайте шевелить лапками ...., я собственно ничего проив совершенно не имею.
А пошевелить, пошевелить сможете - максимальный джитер определяется максимальной длинной прерываемой команды выполняемой из FLASH (реально MAM будет сие улучшать) и частотой контроллера - команды есть и подлиннее AVR-овских 1-5 тактовых( и самые длинные можете в любом случае не использовать), но и частоты повыше - результат, как минимум, не хуже.

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

Я туда не помещаюсь. И привезти из России 100-200 камней - целая проблема. А на 100-200 мне и местные "бамбуковые" терйдеры сбросят на AVR. Так вопрос цен пока не в пользу LPC или других армов. Но это дело пятое.



Вот тут и возникают интересные вещи. Допустим, на AVR я могу (если есть запас по тактам) устранить влияние времени реакции на прерывание (ну допустим, банально выполнив сonst-TCNT операций NOP в процедуре обработки прерывания по переполнению). Тем самым я точно могу гарантировать момент переключения вывода или чтения состояния входа с точностью до такта. Теперь вопрос - я, конечно, такой же финт ушами могу провернуть на ARM, никто не мешает (вроде). И дальше я делаю шевеление лапкой через Fast GPIO. Вот будет оно точно в одном и том же месте или нет? И что же там со вводом? Как долго происходит данная операция?

Ну да ладно, опять флужу. Фиг бы с ним.

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

ну так и на m128 реальные цены не 7USD.
"не в селухе на мопеде небось." © т2.


Вы сами-то верите в то, что пишете?



+1

LPC с MAM'ом и всеми его мегагерцами курит бамбук в сторонке.

Я знаю .

Команды AVR до пяти тактов, посему рассказывать сказки о дергании лапками по/при прерыванию(ях), с точностью до такта, можете кому-нибудь другому в другом месте. Про изделия работающие без прерываний - тоже, тем более про изделия с контроллервми уровня M128 а на Tiny. Радость от "качества" ногодрыгания на AVR часто обусловлена исключительно отсутсвием приличных цифровых осциллографов .
МАМ у LPC реально работает, но для особо критических ко времени и стабильности исполнения участков можно и из RAM работать, можно и без MAM. Ну а поскольку некоторым, прежде, чем "дергать" еще и подумать надо, то и 32 бита и мегагерцы очень кстати.

Ссылку на реального (не аукцион по продаже неликвидов в USA) поставщика стабильно поставляющего контроллеры.
По LPC2101 я назвал. Цена вывешена официально, на складе есть.
Жду ссылки на конкурентные цены по AVR.

Я же вроде объяснил метод выравнивания. Может недостаточно прозрачно объяснил? Могу на примерах показать.

Кстати, не 5 тактов, а 4. Хотя, конечно, можно стеки ставить во внешнее озу с максимальным количеством тактов ожидания, тогда и больше можно.



Без прерываний - это не к нам. Мы обычно ничем не гнушаемся - ни вложенными прерываниями, ни командой IJMP прямо на месте вектора, и еще на машинке вышивать умеем



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



А почему сравниваем младший ARM с далеко не младшим AVR?

Таймер запускается с делителем "1". Не вижу причин по которым нельзя гарантировать интервалы между дерганием с точностью до такта, если выполнить коррекцию в ISR'е:



dW тем не менее Atmel делает именно на m128..


Можно, можно и протокол пересмотреть.
Но например программный HDLC приемник/передатчик я бы не рискнул делать на LPC, а на AVRе рискнул бы.


http://shop.efo.ru/cgi-bin/shop.pl?categor...p;mh=50&a=1
сорри на адекватные m128-au цены там "договорные",
но можно ориентироваться по ближайшим аналогам:
mega64-AU - 3.75$ (абсолютно то же самое что m128, разница только во флеш 64k вместо 128k)
mega128L-MU - 5.6$ (индекс "L" означает - для "Loh'ov", чип такой же как m128 только не работает на 16Mhz, но платить надо больше.. да еще и корпус MLF)..

красная цена m128 - 4-4.5$. это не 1.6, но и не 7.

Ну и справедливости ради, LPC2101 (8kb flash/ 2kb sram) должен конкурировать не с m128, а с m8/m88
http://shop.efo.ru/cgi-bin/shop.pl?categor...p;mh=50&a=1
к сожалению m8 - цена опять договорная, а
m88 - 1.32$.

Не вижу причин не поступить аналогично для ARM и время можно для конкретной ситуации вхда в обработчик подогнать или, что еще проще пользуясь (4-5 кратным)запасом по частоте заняться сканированием того-же счетчика.

Как я уже писал, нет проблем используя запас по скорости, или угробив оную в угоду повторяемости сделать из АRM7 "AVR". Что касается HDLC - я даже и не думал делать "программный", просто взял одного из представителей ARM семейства STR711 и все. Можно было и Samsung. Возможность выбора не заморачиваясь на одного производителя великое дело.



Ну так гамма LPC не ограничивается LPC2101. Есть и старшие модельки с 128K Flash и "обычной" ценой не хуже "красной эксклюзивной" цены M128. Есть тот-же ST32 c ценами за 64K (как и у M64) в три бакса, и низким потреблением, и хорошей периферией, только вот частота у него до 72Mhz и 32бита даются, получается, бесплатно.



Хорошо, 4, но для контроллеров с ограничением в 128K

Нет, об этом речь не идет.

Я не сравниваю. Выше поминаются одинковые по памяти за 3-4 бакса, ну и что? Более того, на сегодняшний день признаю преимущество 8bit контроллеров ценой в пару баксов и тем более менее перед аналогичными ARM. И сам такие использую. Только вот, когда речь идет уже о 3 или тем паче 4-5USD и выше, то тут уже увольте .

Вы знаете, мне кажется мы никогда не увидим идеального МК. И это отчасти объяснимо. Это как аппаратура HiEnd. У каждого есть свой крендель, но ни у одного эти фишки не сходятся.

Происходит выпячивание достоинств, чтобы чётко завоевать свою нишу. Так MSP - малое потребление, AVR - соотношение цена/возможности, PIC - соотношение цена/богатый выбор чипов, ARM - хорошая семейственность с широкими возможностями. Ну и так далее. Время от времени производится попытка отвоёвывания ниши соперника, но глобальные изменения не часты, так как требуют гигантских вложений.
А появление суперуниверсального проца приведёт к серьёзному росту цены. А цена, на рынке МК имеет решающее значение. Это с нашими объёмами 3.5$ ничего не решает, а для какого-нибудь потребителя чипов с объёмом 50000 в месяц и 10 центов будет важным. А стоимость разработки нового ПО окупится при такой разнице за 2 месяца. Для контроллера, по сути - только цена. Если данный МК справляется со своей задачей, то потребителю конечного изделия глубоко плевать какая у него разрядность. Исключения распространяется только на те изделия, для которых возможна модернизация в процессе эксплуатации, либо от процессора зависит производительность (потребительские свойства) изделия. Как правило это только дорогостоящее оборудование.