Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: XMega будет честно работать на 32MHz?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
Страницы: 1, 2
zltigo
Цитата(galjoen @ Feb 15 2008, 14:20) *
Если код во флеш разместить, то он и выполнятся медленно будет. Примерно с той-же скоростью, как у AVR.

Ну Flash даже у мелких ARMов бывает 128битным, что позволяет считывать за раз 4 слова, что неплохо компенситует потерю быстродействия. Даже без этого скорость будет совсем не AVRовская за счет регистровых операций и большей их разрядности.
galjoen
Цитата(zltigo @ Feb 15 2008, 14:34) *
Ну Flash даже у мелких ARMов бывает 128битным, что позволяет считывать за раз 4 слова, что неплохо компенситует потерю быстродействия. Даже без этого скорость будет совсем не AVRовская за счет регистровых операций и большей их разрядности.

Реальным конкурентом для мелких АРМов, в режиме выборки команд из FLASH, я xmega считаю. У неё 32 мГц тактовая. А у АРМов при их тактовой в районе 50 мГц - её в этом режиме на 2 делить нужно. А в задачах управления чем-либо - большая разрядность регистров ДАЛЕКО не всегда нужна бывает! А то. что у АРМ FLASH 128 бит, и по 4 слова за раз. Так за всё это платить надо! Из-за этого (конвейер команд) портами АРМ сами знаете как управляет. Для тех, кто не знает, скажу - на АРМе выводами портов с точностью до такта программно управлять невозможно (в отличие от AVR). А портами точно управлять (в задачах управления чем-либо) это первое дело.
Только не подумайте, что я АРМ плохим считаю. Вовсе нет! В вычислительных задачах он АВР по всем параметрам бьёт!!! Просто у каждого своя ниша. Только вот у АВР и АРМ ниши между собой граничат и даже пересекаются. А где граница - там и война (конкурентная)!
Так-что - давайте жить дружно!!!
zltigo
Цитата(galjoen @ Feb 15 2008, 15:21) *
Реальным конкурентом для мелких АРМов, в режиме выборки команд из FLASH, я xmega считаю. У неё 32 мГц тактовая.

Тогда еще огласите, на какой частоте у нее FLASH память работает, и периферия, кстати, тоже....
Цитата
А у АРМов при их тактовой в районе 50 мГц - её в этом режиме на 2 делить нужно.

Нет, у приличных (не Atmel sad.gif реализаций) умножать на 0.9 примерно.
Цитата
Так-что - давайте жить дружно!!!

Без проблем smile.gif я к проигравшим завсегда милосерден smile.gif. Использование AVR оправдано в ценовой категории уровня ниже трех баксов. Ничего оскорбительно-злорадого в моих словах прошу не искать это вполне обьективная реальность.

Цитата(IgorKossak @ Feb 15 2008, 16:52) *
Или давайте закроем тему.

Я обещал со временем разнести по нескольким разным темам, и по накоплению тем, это обещание выполню. Думаю получатся вполне приличные 2-3 темы. Те которые зайдут в тупик, не и закрыть не грех.
galjoen
Цитата(zltigo @ Feb 15 2008, 18:49) *
Тогда еще огласите, на какой частоте у нее FLASH память работает, и периферия, кстати, тоже....

Да на тех-же 32 мГц. Вобщем с тактированием у неё всё как у mega..AT90. Только питание 2.7..3.6 В - 0..32 мГц, 1.8...27 - 0..12 мГц. Думаю атмел просто на более тонкую технологию перешел. Отсюда и ограничение 3.6В.
Хотя в pdf написано Atmel Confidential. Возьмут и изменят. Я такие pdf на AT45DB642D читал. Реальные чипы - несколько хуже. Ну и pdf они потом переделали.
Цитата(zltigo @ Feb 15 2008, 18:49) *
Нет, у приличных (не Atmel sad.gif реализаций) умножать на 0.9 примерно.

Атмеловский SAM7 вполне в своей нише. Поэтому и популярен. А максимальное быстродействие - оно ведь далеко не всем требуется. И ещё: опыт подсказывает, что за всё платить надо. Выиграли в одном - проиграли в другом. Для АРМ это особенно актуально т.к. конкуренция бешенная. Вот с АВР конкуренция поменьше - на них атмел цену и держит.
Цитата(zltigo @ Feb 15 2008, 18:49) *
Использование AVR оправдано в ценовой категории уровня ниже трех баксов. Ничего оскорбительно-злорадого в моих словах прошу не искать это вполне обьективная реальность.

Согласен. Думаю атмел на старшие АВР вынужден будет цену скинуть. Хотя-бы за счёт уменьшения объёма FLASH у них. У меня, например, во всех проектах на старших АВР - FLASH ну просто девать некуда! И ведь есть у них такие АВР. Только малодоступны. Например AT90CAN32 - не продают. А он-бы вполне конкурентоспособным был. Ну не 3, а 5 долларов - зато CAN.
Цитата(zltigo @ Feb 15 2008, 18:49) *
Я обещал со временем разнести по нескольким разным темам, и по накоплению тем, это обещание выполню. Думаю получатся вполне приличные 2-3 темы. Те которые зайдут в тупик, не и закрыть не грех.

Меня достают такие вопросы, как: Я попробовал аппноуты XX и YY, а они не идут (плохие). Какой-бы мне аппноут взять?
Тот, кто такие вопросы задаёт - сам думать не хочет! А наоборот, других пытается подловить: "Это ты сам придумал!?!", или "Что, не придумал ещё!?!"
А я так считаю: Если человек сам думает - честь ему и хвала!
Мне эта тема потому и интересна, что на неё аппноутов нет. Тут те, кто сами думают. А одна она будет, или 3 - не так важно.
zltigo
Цитата(galjoen @ Feb 15 2008, 22:15) *
Да на тех-же 32 мГц.

Да? Atmel стал делать 30ns FLASH smile.gif И где:
http://atmel.com/dyn/products/devices.asp?family_id=624
Их 16MHz Atmega, это 60ns, 20MHz чипы это их 45ns.. А дальше, а дальше все.
На половинной она работает, однако..... Сюрприз? И периферия тоже.
zltigo
Цитата(galjoen @ Feb 15 2008, 23:10) *
Да. Там меньше 45ns нет. Но может и потом появиться - просто атмел приятный сюрприз сделать хочет.

smile.gif
Цитата
А если xmega с периферией на половинной работать будет

Дык вот тут ссылки на документики:
http://electronix.ru/forum/index.php?showtopic=43230
Цитата
- кому тогда она нужна? Неужто атмел это не понимает.

Фанаты Спартака схавают sad.gif. Чип будет получше, периферия понавоченее и всего поболее - некоторый прогресс налицо.
А больше из восьмибитовиков выжимать нечего.
SasaVitebsk
Цитата(zltigo @ Feb 15 2008, 23:22) *
На половинной она работает, однако..... Сюрприз? И периферия тоже.


Не знаю как на самом деле, но для синхронной архитектуры выход легко можно найти (было бы желание). Например на половинной скорости читать две команды, а исполнять по очереди. Ни конвеер ни кэш для такой системы не нужен. Хотя реализуется, естественно, сложнее. smile.gif

Как там на самом деле - увидим.
zltigo
Цитата(SasaVitebsk @ Feb 16 2008, 00:55) *
Не знаю как на самом деле, но для синхронной архитектуры выход легко можно найти (было бы желание). Например на половинной скорости читать две команды, а исполнять по очереди.

У LPC, так и сделано smile.gif, но 4 команды зараз smile.gif, НО уже даже при двух командах несинхроная штучка, ибо при переходе считанные заранее команды придется выбросить sad.gif и читать ЗАНОВО. Причем у АРМ в этом отношении попроще - мощная система условного исполнения команд позволяет сильно сократить количество мелких переходов и соответственно промахов. А еще во FLASH есть данные smile.gif


Цитата(galjoen @ Feb 15 2008, 22:15) *
И ведь есть у них такие АВР. Только малодоступны. Например AT90CAN32 - не продают. А он-бы вполне конкурентоспособным был. Ну не 3, а 5 долларов - зато CAN.

Совершенно на вскидку - LPC2109FBD64/01 - 5 баксов. http://www.mt-system.ru/index.php?store_se...pc2109&id=5 причем цена, похоже старая, когда привезут свежую - будет дешевле.
Вот такие дела с "конкуренцией". Можно и подешевле среди Cortex поискать.
bzx
Цитата(zltigo @ Feb 15 2008, 22:22) *
Да? Atmel стал делать 30ns FLASH smile.gif И где:

Например, uc3 на 66МГц бегает.
zltigo
Цитата(bzx @ Feb 16 2008, 03:03) *
Например, uc3 на 66МГц бегает.

С двумя вайтстейтами на 45ns FLASH, или тремя на 60ns оно дело простое, нехитрое, но совсем нечестное, ибо в 3-4 (три-четыре) раза медленее.
Ну а дальше компенсация (вполне эффективная!) сего факта конвеерами, кэшами, но прощай "горячо необходимые" одна команда - один такт и махание ножками на 66MHz.
SIA
Цитата(zltigo @ Feb 16 2008, 03:07) *
С двумя вайтстейтами на 45ns FLASH, или тремя на 60ns оно дело простое, нехитрое, но совсем нечестное, ибо в 3-4 (три-четыре) раза медленее.
Ну а дальше компенсация (вполне эффективная!) сего факта конвеерами, кэшами, но прощай "горячо необходимые" одна команда - один такт и махание ножками на 66MHz.

Это не совсем так. Способы обеспечения быстрой и жестко синхронной работы процессора даже при достаточно большой латентности памяти и длинах конвейеров отработаны еще 40 лет назад, просто нынешние разработчики часто об этом не вспоминают. Как результат - лепятся куча прибамбасов там, где рациональнее подумать головой и сделать простое, но мощное решение.
А жесткая синхронность очень нужна в реалтаймовом управлении, т.к. флуктуации времени выполнения программы и отсутствие четких гарантий верхнего предела времени на него приводят к необходимости сильно перезакладываться по вычислительной мощности для обеспечения стабильной частоты квантования в контуре управления.
GetSmart
Разница между ARM7 и AVR примерно такая же как между AVR и MCS-51. Кто работал - тот знает. Интересно, что и аргументы у защитников примерно одни и те же. А после того как цены на ARM7 (особенно Phillips) стали намного дешевле сравнимых хотя бы по размеру флэша AVR, то вообще с AVR-ками продолжают работать только их "фанаты". Любовь затуманивает разум smile.gif
SIA
Цитата(GetSmart @ Feb 16 2008, 05:01) *
Разница между ARM7 и AVR примерно такая же как между AVR и MCS-51. Кто работал - тот знает. Интересно, что и аргументы у защитников примерно одни и те же. А после того как цены на ARM7 (особенно Phillips) стали намного дешевле сравнимых хотя бы по размеру флэша AVR, то вообще с AVR-ками продолжают работать только их "фанаты". Любовь затуманивает разум smile.gif

Так я не по этой части. Просто посмотрев, насколько шустрее один и тот же сишный код идет на Au1100 с древней, но отлаженной архитектурой, против свеженького LPC3180 (разница много больше, чем 2 раза по тактовой), начинаешь задумываться - а где прогресс, блин ?
GetSmart
Вообще-то я не Вам. Что касается LPC3180, то во-первых это ARM9. Во-вторых нужно "фильтровать" рекламные характеристики. Я много работал с LPC2xxx и о них только хорошие впечатления. В-третьих для "выжимания" из процессора максимума (именно это пишут в рекламе) и компилятор должен это уметь делать, и собственные исходники должны быть приспособлены. Возможно Вы неправильно используете опции ускорения проца или что-нибудь ещё.
zltigo
Цитата(SIA @ Feb 16 2008, 05:31) *
...насколько шустрее один и тот же сишный код идет на Au1100 с древней, но отлаженной архитектурой..

Ну насчет "древности архитектуры" тут ARM, пожалуй может посоревноваться smile.gif - все у всех начиналось там - в 80x. По любому, эта тема была поднята/выделена для обращения внимания на то, что лобовые жестко синхронные массовые микроконтроллеры кончились на 16-20 мегагерцах. Нежели нужно жестко и быстрее, чем это позволяет делать 16/20 MHz AVR чего-то желать, то FPGA пора осваивать уже более, чем доступные FPGA, а не ждать чудес ввиде такой-же, но "без крыльев" 32MHz, 66MHz...
За десяток, даже не за "другой", а именно за десяток баксов получаем возможнось делать более, чем сотнемегагерцовую ногодрыгалку с небольшим контроллером, если надо, для "всего прочего" на борту. Контроллер набортный, правда сейчас относительно дорого выйдет для такого уровня FPGA и более экономически оправдано применение рядышком контроллера общего назначения за несколько единиц баксов.

Цитата(SIA @ Feb 16 2008, 03:25) *
..просто нынешние разработчики часто об этом не вспоминают. Как результат - лепятся куча прибамбасов там, где рациональнее подумать головой и сделать простое, но мощное решение.

Вам прямой путь вспомнить и сделать IP-Core... Alias, считайте, у Вас уже есть, хороший, трехбуквенный, легко запоминающийся (особено в Латвии - у нас это полный аналог "Общество с Ограниченной Ответственностью" - "Sabiedrība ar Ierobežotu Atbildību"). А? Не думаю, что разработчики забыли, как думать, и где купить книжки по архитектуе процессоров - просто компромис выбирается по другим критериям. Правильные/не правильные эти критерии в общеглобальном плане, я судить не берусь, но лично меня результат вполне устраивает.
Rst7
Цитата(zltigo @ Feb 15 2008, 21:22) *
На половинной она работает, однако..... Сюрприз? И периферия тоже.

Это почему Вы решили, что периферия двухтактовая? Да с флешем пока полная неясность, никаких упоминаний о каких либо задержках или специальных костылях в даташитах нет. Правда даташиты далеко не финальные, так что подождем или живых камней, или нормальных док.
zltigo
Цитата(Rst7 @ Feb 16 2008, 11:08) *
Это почему Вы решили, что периферия двухтактовая?

Ну скажем так, не вся периферия, а GPIO и ее программирование. Таймеры, например, совершенно спокойно могут считать на полной скорости.
А вообще, кто из нас двоих это писал? smile.gif smile.gif :
Цитата
Кстати, по текущим даташитам есть одна неприятность для любителей быстро пощелкать лапками - IN и OUT длятся 2 такта. CBI и SBI правда выполняются за один такт, но результат будет на ножке порта через 2 такта. Вот и неизвестно, что будет, если выполнить подряд CBI потом SBI, например.
Видимо, именно из-за двухтактового чтения из порта, теперь команды SBIC/SBIS занимают 3/4/5 тактов. Хотя тоже не ясно, почему не 2/3/4...


Цитата
Да с флешем пока полная неясность...

Ну нету, вообще нету сколь-нибудь массовой технологии 30ns FLASH. Просто нет. Какая уж тут неясность sad.gif. Atmel в тайне совершит прорыв и использует свои новейшие достижения для продления жизни стремительно устаревающих восьмибитовиков? Верите?
Alex B._
Цитата(zltigo @ Feb 16 2008, 12:07) *
Ну нету, вообще нету сколь-нибудь массовой технологии 30ns FLASH. Просто нет. Какая уж тут неясность sad.gif. Atmel в тайне совершит прорыв и использует свои новейшие достижения для продления жизни стремительно устаревающих восьмибитовиков? Верите?

В каком смысле нету? Совсем нету? sad.gif А микрочип и не знает и уже как года четыре лепит dsPIC30 с частотой выборки из флеши 30 МГц, и уже год как PIC24H/dsPIC33 с частотой выборки из флеши 40 МГц
singlskv
Цитата(zltigo @ Feb 16 2008, 12:07) *
Ну нету, вообще нету сколь-нибудь массовой технологии 30ns FLASH. Просто нет. Какая уж тут неясность sad.gif.

Renesas SH7211, выборка из флеш 12,5ns
proba
Цитата(zltigo @ Feb 16 2008, 13:07) *
Ну нету, вообще нету сколь-нибудь массовой технологии 30ns FLASH. Просто нет.

технология развивается:
http://ieeexplore.ieee.org/Xplore/login.js...35/01221204.pdf
а также применяется в многих мк SH2 серии уже несколько лет.
а в ближаищем будущее появится SONOS,SONNS и др технологии.
список технологии: http://www.memorystrategies.com/report/EmbeddedFlash.htm
zltigo
Цитата(Alex B._ @ Feb 16 2008, 12:37) *
В каком смысле нету? Совсем нету?

У Atmel нету продуктов с такой скоростью Flash. Ссылку на линейку их чисто флешовых продуктов давал. У их ARM - 45ns(лучше, чем NXPишные 60, что на малых частотах с 0ws и отключенном за ненадобностью MAM дает проигрыш ).
Нынешние AVR на 20MHz это тотже 45ns.

Цитата(singlskv @ Feb 16 2008, 12:53) *
Renesas SH7211, выборка из флеш 12,5ns

Пойду посмотрю на это чудо - пожалуйста ссылочку - не на частоту работы ядра а имено на то, что именно из FLASH сие на полной скорости выбирается.
Вот все, что счел нужным Renesas сообщить о FLASH находящемся на борту помянутого SH7211.
Цитата
27.7 Flash Memory Characteristics
Table 27.21 Flash Memory Characteristics
Conditions: VCC = 1.4 V to 1.6 V, VCCQ = 3.0 V to 3.6 V, AVCC = 4.5 V to 5.5 V, AVREF = 4.5V
to AVCC, VSS = PLLVSS = AVSS = 0 V, Ta = −40°C to +85°C
Item Symbol Min. Typ. Max. Unit
Write time *1
*2
*4
t
P — 20 400 ms/256 bytes
Erase time *
1
*
3
*
5
t
E — 2 20 s/byte
Number of rewrite times NWEC — — 100 times
Notes: 1. Use the on-chip writing/erasing routine for writing or erasing.
2. When all 0 is written
3. When a 64-Kbyte block is erased
4. Total rewrite time (write time + erase time) is as follows.
60 s (Typ.), reference value: 90 s, 120 s (Max.)
However, 90% of this time falls within the range of the reference value.
5. tE is distributed centering around the typical value (Typ.).
proba
а это здесь:
http://eu.renesas.com/fmwk.jsp?cnt=press_r.../press_releases
или один из первых monos мк:
http://edageek.com/2006/10/16/renesas-micr...embedded-flash/
GetSmart
Цитата(zltigo)
У Atmel нету продуктов с такой скоростью Flash. Ссылку на линейку их чисто флешовых продуктов давал. У их ARM - 45ns(лучше, чем NXPишные 60, что на малых частотах с 0ws и отключенном за ненадобностью MAM дает проигрыш ).
С каких это пор у NXP стала флэш 60 ns? Если обещают работу на 20 МГц, то явно не выше 50 ns.
zltigo
Цитата(GetSmart @ Feb 16 2008, 13:59) *
С каких это пор у NXP стала флэш 60 ns? Если обещают работу на 20 МГц, то явно не выше 50 ns.

Увы sad.gif я ошибся - 70-75ns. Flash у NXP самый, что ни наесть простой. У них 20MHz обещается с ОДНИМ waitstate sad.gif. Посмотрите внимательно:
Код
For system clock slower than 20 MHz, MAMTIM can be 001. Fo
20 MHz and 40 MHz, Flash access time is suggested to be 2 CC
with system clock faster than 40 MHz, 3 CCLKs are proposed.





Цитата(proba @ Feb 16 2008, 13:58) *

Это круто. Это реально круто! Правда, когда я сунлся прицениться, даже на сайте производителя
ни цены, ни намеков:
http://america.renesas.com/fmwk.jsp?cnt=sh...s/sh7211_group/
Так, для общего развития может како-то когда-то цену озвучивали? Пока вижу, что мои слова
"нету сколь-нибудь массовой технологии" можно отнести не только к Atmel sad.gif.
proba
цена конечно крутая, как у большинства мк ренесас ( за исключением R8C ) - 32$ в Digikey, в наличии DF72115 там уже более года.
zltigo
Цитата(proba @ Feb 16 2008, 14:46) *
DF72115 там уже более года.

Что такое DF72115 я не ведаю, и производитель тоже, что-то затихарился:
http://america.renesas.com/fmwk.jsp?fp=/se...mp;col=iactenam
Я искал поминаемый ранее в этой связи sh7211
AHTOXA
Интересно, а как работали scenix-ы на 100МГц? У них какая-то особая флеш?
singlskv
Цитата(zltigo @ Feb 16 2008, 14:32) *
Это круто. Это реально круто! Правда, когда я сунлся прицениться, даже на сайте производителя
ни цены, ни намеков:
Так, для общего развития может како-то когда-то цену озвучивали? Пока вижу, что мои слова
"нету сколь-нибудь массовой технологии" можно отнести не только к Atmel sad.gif.
Да ладно Вам, у МТ розница ~25, опт ~20
смотрим R5F72115D160FP (DF72115D160FPV) - это и есть SH7211
GetSmart
Цитата(zltigo)
Увы я ошибся - 70-75ns. Flash у NXP самый, что ни наесть простой. У них 20MHz обещается с ОДНИМ waitstate . Посмотрите внимательно:
Я прошу пардону, но не кажется ли Вам, многоуважаемый zltigo, что Вы ошибаетесь?!? С каких это пор MAMTIM стал содержать waitstate? Всегда по моему мнению это был простой делитель на доступ ко флэшу.
Код
These bits set the duration of MAM Flash fetch operations as follows:
.....
1 1 1 = 7 - MAM fetch cycles are 7 processor clocks (cclks) in duration.
Для однозначного убеждения Вас в моей правоте почитайте файлик pg14-15-18-19-9Q6Phillips-Z.pdfс заголовком Enhancing Performance Using an ARM Microcontroller with Zero Wait-State Flash
Rst7
Цитата
А вообще, кто из нас двоих это писал? :


Писал я. Вопрос в том, что OUT занимает 2 такта (если это не опечатка, конечно, потому как в другом месте написано "Both I/O Memory and SRAM have single cycle access for read and write, but certain instructions require more cycles". И в табличке рядом с IN/OUT за 2 такта LDD/STD тоже 2 такта, хотя, если бы доступ был не однотактовым, занимало бы 3 такта), но главное, чтобы точность переключения была 1 такт (а не как на армах, полетели данные в шину, когда реально лапкой щелкнет - хрен его знает).

Про флеш - щас пролистал все, нет никаких упоминаний про костыли для убыстрения. Видимо, все-таки асилили 30ns флешину.

Все равно, будем ждать камней и более правильных даташитов. Кстати, тут человек хвастался, что у него семплы есть, давайте его и попросим проверить...
zltigo
Цитата(GetSmart @ Feb 16 2008, 15:18) *
Я прошу пардону, но не кажется ли Вам, многоуважаемый zltigo, что Вы ошибаетесь?!?

Да, бывает...
Да waitstate минус 1. И соответственно 50ns, что радует!
GetSmart
Цитата(Rst7)
но главное, чтобы точность переключения была 1 такт (а не как на армах, полетели данные в шину, когда реально лапкой щелкнет - хрен его знает).
Вы похоже не знаете о чём пишете. В LPC2xxx, по крайней мере, всё цивильно сделано. Когда надо, тогда и дёрнет лапкой. Без лишних неопределённостей. Сейчас не меньше половины их процов дёргают лапками за 2 такта (можно выдавать стабильный меандр до 15 МГц. AVR так умеет?). Тут всё дело в "понимании" процессора. Суёте особо критичную для Вас процедуру в раму и не паритесь. А когда руки кривые, то не надо на проц наезжать.
Rst7
Цитата
Вы похоже не знаете о чём пишете. В LPC2xxx, по крайней мере, всё цивильно сделано.


Т.е. один такт он тратит на извлечение инструкции из RAM, второй - на запись в FIOPIN, например? И через сколько времени перещелкнет ножка? Через фиксированное? Если да - то мне это подходит вполне. Попробуем что-нибудь слепить в следующий раз на LPC вместо меги.

Цитата
Тут всё дело в "понимании" процессора.


Я все прекрасно понимаю. Просто в LPC есть костыль для быстрого доступа к GPIO, у других (например AT91) - нет. Да и в LPC2131-38 - например костыля нету, а в LPC2131-38/01 - есть.

Цитата
Суёте особо критичную для Вас процедуру в раму и не паритесь.


Я в курсе. Давно причем.

Цитата
А когда руки кривые, то не надо на проц наезжать.


Где наезд???
GetSmart
Цитата(Rst7)
Где наезд???

Тута:
Цитата(Rst7)
когда реально лапкой щелкнет - хрен его знает

Наезд, не наезд. Немного эмоций делу не мешает, как и специй в любимом блюде smile.gif
Цитата
Т.е. один такт он тратит на извлечение инструкции из RAM, второй - на запись в FIOPIN, например? И через сколько времени перещелкнет ножка? Через фиксированное?
Через константное - точно, то бишь фиксированное. Сам недавно день потратил на выяснение подобных "тонкостей".

Цитата(Rst7)
Если да - то мне это подходит вполне. Попробуем что-нибудь слепить в следующий раз на LPC вместо меги.
Попробуйте, не пожалеете!
И забудете о AVR как о школьных мучениях.

Цитата
Я в курсе. Давно причем.
Вы были в курсе, что это даёт максимальную скорость. Но не знали, что выполнение всех инструкций становится с жёстко детерминированными длительностями.
singlskv
Цитата(proba @ Feb 16 2008, 13:58) *
Кстати, уже 10ns... и температура до 150С
http://eu.renesas.com/fmwk.jsp?cnt=press_r.../press_releases
Rst7
Цитата
Попробуйте, не пожалеете!И забудете о AVR как о школьных мучениях.


Я не мучаюсь, не волнуйтесь. И, самое смешное, AVR для меня далеко не школа, не первый и не последний камень в изучении и в использовании. У меня к нему чисто эстетическая привязанность, подкрепленная опытом работы, можно?

Я бы один проектик на ARM перенес, пока он еще не попал в коммерческую струю, но, попробовав собрать пару ревизий под ARM (мысль делать исходник двухкаменный сразу была), пока, как ни странно, особого эстетического удовольствия не получил - все-таки рулит 32 регистра у AVR, весь TCP/IP стек ложится в регистры (даже не во все, а в 28), красиво, блин wink.gif... В тумбе код вообще ужасен (всего-то 8 регистров доступны), а в ARM-режиме - в полтора раза больше флеша надо и все равно стековые переменные. Ну вот не радует и все smile.gif И, самое главное, даже 32хбитность ARMа не спасает ни разу... Так, разве что CRC32 быстрее считается wink.gif

Цитата
Но не знали, что выполнение всех инструкций становится с жёстко детерминированными длительностями.


Eсли RAM на кристалле и сразу к ядру подключено - то да (LPC2xxx - как раз такой). Если ОЗУ внешнее, то нет. Там можно только с ARM9 работать, заполнять кеш и выполнять код из него. Тогда - да, детерминированность есть, но тоже могут быть грабли, например, чтение данных из RAM может привести к непредсказуемым задержкам.


Я так уточняю к тому, что, например товарищ zltigo всегда при агитации за ARM приводит аргумент "куча производителей, а ядро одно". Вот и смотрим, что быстрое IO вроде в одном LPC только, да и то не во всех. А если чего случится с NXP? Чем привязанность к LPC лучше привязанности к AVR? Да ничем. А выход может быть только один - плюнуть на шевеление лапками, делать весь жесткий тайминг на плис... Но тогда мы все превращаемся в ремесленников. Негде приложить мастерство, блеснуть, так сказать...
Обычно людей (таких большинство) устраивает, что им платят деньги за работу, они не будут озадачиваться, как бы блеснуть - "есть бабос, я доволен жизнью". Подход, безусловно, имеет полное право на существование (сторонников такого подхода я ни в чем не обвиняю). Однако, лично мне еще очень хочется удовлетворение получать от сделаной работы, чтобы я мог себе сказать - "вот я какой".

Пардон за оффтоп.
GetSmart
Цитата(Rst7)
Чем привязанность к LPC лучше привязанности к AVR?
Ну это как любить красивую девушку и некрасивую smile.gif
Дело Ваше. Причём красивая совсем не дура, а к тому же и умная впридачу.

И не надо искать недостатки там, где их изначально нет. В ARMе по-умолчанию ARM-режим. Лично я всегда пишу на нём. И уж в крайнем случае, когда катастрофически не хватает флэша и не существенно быстродействие, то некоторые процедуры можно написать, а точнее скомпилить в THUMB-режиме. Нету там всеобщей обязанности написания всей программы только в одном режиме. А вот флэша там намного больше чем в AVRках.
Цитата
Я бы один проектик на ARM перенес, пока он еще не попал в коммерческую струю, но, попробовав собрать пару ревизий под ARM (мысль делать исходник двухкаменный сразу была), пока, как ни странно, особого эстетического удовольствия не получил - все-таки рулит 32 регистра у AVR, весь TCP/IP стек ложится в регистры (даже не во все, а в 28), красиво, блин ... В тумбе код вообще ужасен (всего-то 8 регистров доступны), а в ARM-режиме - в полтора раза больше флеша надо и все равно стековые переменные. Ну вот не радует и все И, самое главное, даже 32хбитность ARMа не спасает ни разу... Так, разве что CRC32 быстрее считается
Я не очень понял, Вы на чём пишете? На асме что ли? Тогда мы идём к Вам!
smile.gif
Цитата
Вот и смотрим, что быстрое IO вроде в одном LPC только, да и то не во всех. А если чего случится с NXP? Чем привязанность к LPC лучше привязанности к AVR? Да ничем.
Уж точно не хуже. Что же Вы сразу не подумали когда "садились" на AVR - а если что с Atmel-ом случится, что мне делать? Давайте равноценно рассуждать. И не валить все недостатки всех производителей АРМов в одну кучу. Я вам уже поведал о достоинствах того же LPC, на фоне которых достоинства Mega и XMega блекнут. Заставлять не буду smile.gif Хотя привязанность вряд ли эстетическая. Я уже писал про привязанности к AVR.
zltigo
Цитата(Rst7 @ Feb 16 2008, 19:06) *
А выход может быть только один - плюнуть на шевеление лапками, делать весь жесткий тайминг на плис... Но тогда мы все превращаемся в ремесленников. Негде приложить мастерство, блеснуть, так сказать...

Прежде всего, плюнуть на привязанности вообще smile.gif и решать задачи на соответствующем железе, включая FPGA. Причем программирование FPGA, смею Вас заверить, ничуть не менее увлекательное и блестяще полирующее ум занятие. А уж новые горизонты для шевеления лапками просто дух захватывает!
galjoen
Цитата(Rst7 @ Feb 16 2008, 19:06) *
Я не мучаюсь, не волнуйтесь. И, самое смешное, AVR для меня далеко не школа, не первый и не последний камень в изучении и в использовании. У меня к нему чисто эстетическая привязанность, подкрепленная опытом работы, можно?

+1
И думаю АВР - это последний чип для которого проекты на ассемблере есть смысл писать. Ностальгия млин.

Но вот вопрос. Допустим у xmega даже 32 мГц честных будет. Сколько же он стоить должен, чтобы был смысл его применять? Ну то, что меньше $10, думаю все согласятся. А вот минимум какой? Для себя я эту границу в $6..7 определил. А вы?
GetSmart
Никого не хочу обидеть.

Но внутренний голос мне говорит, что высказанные аргументы напоминают неудачный первый сексуальный опыт smile.gif И последующую боязнь всего нового. Необъективно вобщем.

Пардон ещё раз smile.gif
zltigo
Цитата(Rst7 @ Feb 16 2008, 19:06) *
все-таки рулит 32 регистра у AVR, весь TCP/IP стек ложится в регистры (даже не во все, а в 28), красиво, блин wink.gif...

Весь стек? TCP/IP? В регистры? Что-то я не понимаю о чем мы все это. Ну пусть в ARM чего-то в регисты не ложится, а то, что RAM там шустрее, чем у мноих регистры, с этим-то что делать? То, что тот-же TCP/IP стек, это вообще-то передача данных, а не, например, виртуозное формирование IP заголовков, а передача данных это рано или поздно пересылка массивов памяти и что, для этого 32 бита зараз на в несколько раз большей тактовой "не спасает ни разу"?
Цитата
В тумбе код вообще ужасен (всего-то 8 регистров доступны)

Нет такого дополнительного ограничения.
Цитата
, а в ARM-режиме - в полтора раза больше флеша надо

Из практики - много меньше - на уровне 20% и Flash по нынешним временам неприлично дешев. На RAM жмутся все sad.gif, а FLASH напихают, и еще добавят.
GetSmart
Цитата(galjoen)
. А вот минимум какой? Для себя я эту границу в $6..7 определил. А вы?
LPC2101 за 2 бакса.
zltigo
Цитата(galjoen @ Feb 16 2008, 19:45) *
А вот минимум какой? Для себя я эту границу в $6..7 определил. А вы?

Если не будет какого-то совершенно изумительно ложащегося в конкретный проект свойства
(подчеркиваю, что не вообще "хорошего" свойства а подходящего к конкретному случаю, на что особо массово рассчиывать не приходится для контроллеров общего применения), то конкурировать ему придется с младшими ARM7 и Cortex-M3, а это уже отнюдь не 6...7. Это 2..3, ну 4 бакса, однако.... Причем это уже сегодня продающиеся чипы в нише, куда еще лезут новые производители. Тот-же NXP не скрывает своего желания захватить кусочек рынка младшей серией LPC1000.
galjoen
Цитата(zltigo @ Feb 16 2008, 20:01) *
это уже отнюдь не 6...7. Это 2..3, ну 4 бакса, однако....

Ну вот цену своей ностальгии определил - 2..3 бакса. Недорого однако. Хотя с другой стороны - 30%.
А когда я с PIC на АВР переходил у меня цена цена ностальгии вообще отрицательная получалась! А ведь до сих пор фанаты PIC есть! Только за счёт них PIC и существует. Думаю и к атмелу это в какой-то степени применимо. Если объективно разобраться их xmega - мертворождённая.
Если конечно её по 3 бакса продавать не начнут!
SIA
Цитата(zltigo @ Feb 16 2008, 10:44) *
Ну насчет "древности архитектуры" тут ARM, пожалуй может посоревноваться smile.gif - все у всех начиналось там - в 80x. По любому, эта тема была поднята/выделена для обращения внимания на то, что лобовые жестко синхронные массовые микроконтроллеры кончились на 16-20 мегагерцах. Нежели нужно жестко и быстрее, чем это позволяет делать 16/20 MHz AVR чего-то желать, то FPGA пора осваивать уже более, чем доступные FPGA, а не ждать чудес ввиде такой-же, но "без крыльев" 32MHz, 66MHz...
За десяток, даже не за "другой", а именно за десяток баксов получаем возможнось делать более, чем сотнемегагерцовую ногодрыгалку с небольшим контроллером, если надо, для "всего прочего" на борту. Контроллер набортный, правда сейчас относительно дорого выйдет для такого уровня FPGA и более экономически оправдано применение рядышком контроллера общего назначения за несколько единиц баксов.

С этим согласен практически полностью. Быстрый автомат на FPGA для логического управления, особенно "табличный" - уделает на этих приложениях любой MCU. Я сам вместо DSP с большой разрядностью часто применяю комбинацию MCU+FPGA. Деньги примерно те же, а энергопотребление меньше.
Цитата(zltigo @ Feb 16 2008, 10:44) *
Вам прямой путь вспомнить и сделать IP-Core... Alias, считайте, у Вас уже есть, хороший, трехбуквенный, легко запоминающийся (особено в Латвии - у нас это полный аналог "Общество с Ограниченной Ответственностью" - "Sabiedrība ar Ierobežotu Atbildību"). А? Не думаю, что разработчики забыли, как думать, и где купить книжки по архитектуе процессоров - просто компромис выбирается по другим критериям. Правильные/не правильные эти критерии в общеглобальном плане, я судить не берусь, но лично меня результат вполне устраивает.

Я немного разбирался с этим вопросом. Во-первых, здесь многое от нашей (и европейской) недообразованности - многие хорошие архитектуры подробно разбираются в американских курсах Computer Science, те же MIPS студентами Стэнфорда изучаются вдоль и поперек. Причем, что важно, с изучением взаимосвязей всех характеристик, влияющих на реальную (а не рекламную) производительность. Поэтому и "продвигать" их в штатах особенно незачем - и так это там RISC #1, соответственно и вылизано это семейство по критерию площадь/мощность/эффективность практически вплотную к теоретическому пределу для данной технологии. Собственно ядра сильно лучше с точки зрения реальной эффективности для очень широкого круга задач сделать практически невозможно - у него реальная производительность мало отличается от пиковой. (Естественно, для узкоспециализированных применений всегда можно сделать что-то лучше, только вот экономически это оправданно разве что для очень массовых вещей). Соответственно и особых усилий в маркетинге MIPS не предпринимали. А остальные - суетились, пусть с худшими собственно процессорами, гораздо большей разницей между пиковой и реальной производительностью из-за наличия "узких мест", но с более развитой периферией, меньшей стоимостью освоения для разработчиков. Главный минус MIPS-ориентация строго на IP, плюс высокая стоимость освоения, и соответственно недостаточность ассортимента универсальных кристаллов с развитой периферией.
Но признаки понимания ошибочности этого и исправления - есть, поэтому, когда Microchip таки родил PIC32, и явно будет развивать эту тему, то это становится интересным не только для приложений где кровь из носу нужна большая вычислительная мощность при небольшом энергопотреблении.
А с AVR/ARM, IMHO, тут все гораздо проще. Сегодня во многих западных компаниях разработчиков никто всерьез и не спрашивает, рулят амбиции маркетологов, типа это мы продадим! При этом о технической рациональности и оправданности всерьез уже не парятся, т.к. в нынешних условиях, что в Европе, что во многих случаях в США, решение о выборе поставщика для продукта с вероятностью более 50% приниматься будет менеджером, зачастую не имеющим даже минимального технического образования. Этот сдвиг уловили многие реально работающие на рынке фирмы, и заметно изменили формы и методы продвижения продукции - рекламные материалы готовятся в расчете не на инженеров, а на менеджеров.
IP core - я в принципе думал об этом, и кое что даже делал для себя, но экономический смысл сомнителен - архитектур и так слишком много, большая часть из них неизбежно умрет или осядет в нишах просто из-за недостатка средств на продвижение. Например, Infineon TriCore довольно удачный проц, но так и не выбрался из ниши автоэлектроники.
Что-то интересное (реально быстрый при частых переходах и в то же время флэшовый контролллер) можно сделать при тщательной отработке многобанкового флэша (когда параллельно запускается доступ по разным адресам), но такой готовый IP блок флэша до сих пор толком не стандартизован у производителей кристаллов, а разработка его с нуля стоит неподъемных для мелкой фирмы денег (логику процессора сделать проще).
Некоторое время назад для применения в дешевых маленьких FPGA мог представлять интерес предельно компактный по числу вентилей и плотности кода, но шустрый процессор, но ПЛИС дешевеют достаточно быстро, и экономического смысла сегодня в этом уже не видно. Интереснее хороший компилятор и IDE для существующих.
zltigo
Цитата(galjoen @ Feb 16 2008, 20:47) *
Только за счёт них PIC и существует.

Для начала PIC PICу рознь. Даже если о старых и мелких, то простите там выбор чипов для точного попадания в проект очень и очень неплох.
Rst7
Цитата
Я не очень понял, Вы на чём пишете? На асме что ли? Тогда мы идём к Вам!


На C я пишу.

Цитата
Нет такого дополнительного ограничения.


Эээ... Как насчет, например, ADD R8,R9 в тумбе, слабо? wink.gif Я к тому, что использование регистров R8-R12 возможно только как хранилищ, нельзя непосредственно производить операции с ними. Как на AVR нельзя, например, непосредственный операнд загрузить в младшие регистры. Это минус. Да и вообще, в тумбе кастрированный набор комманд, где трехадресность, где сдвиги? wink.gif В этом смысле AVR32 более продуман, там все регистры ортогональны до конца.

С другой стороны, если так подходить - так по мне PowerPC рулит, я еще со 103тьего начинал. 32 регистра и вперед.

Цитата
В ARMе по-умолчанию ARM-режим. Лично я всегда пишу на нём


Вы не поверите, я тоже сторонник ARM-режима. В одной операционной системе я даже не довел до ума диспечер системных вызовов, работал только в ARM-режиме, а в Thumb - нет. И люди даже слова не сказали. А для тех юзеров, кто когда-нибудь раскроет рот о больших размерах выполняемых файлов (озу там, на платформе, хватает), у меня есть секретное оружие - загрузка секций .elf-файлов через zlib smile.gif))

Да, но черт возьми, а в новой ARM-парадигме под названием Cortex ARM-режима вообще нет. Есть костыль - вместо BLX - выполнение комманды ARM-режима. Во как, неожиданно?

Цитата
а передача данных это рано или поздно пересылка массивов памяти и что, для этого 32 бита зараз на в несколько раз большей тактовой "не спасает ни разу"?


Не спасает. Точнее, не нужна. Потому как MAC-уровень реализован программно. И программно выдавать данные или принимать со скоростью 10мбит мне пофиг, на 8 или 32х битах. А внутри стек устроен таким образом, что пересылается минимальное количество данных, не в последнюю очередь в связи с ограничением по озу. Негде буфера раскладывать. Вот и приходится иметь два маленьких буфера для эзернет-пакетов, прямо в них же и разбирать данные, там же и генерировать ответы и т.д.
SIA
Цитата(Rst7 @ Feb 16 2008, 21:01) *
Не спасает. Точнее, не нужна. Потому как MAC-уровень реализован программно. И программно выдавать данные или принимать со скоростью 10мбит мне пофиг, на 8 или 32х битах. А внутри стек устроен таким образом, что пересылается минимальное количество данных, не в последнюю очередь в связи с ограничением по озу. Негде буфера раскладывать. Вот и приходится иметь два маленьких буфера для эзернет-пакетов, прямо в них же и разбирать данные, там же и генерировать ответы и т.д.

А на фига делать программный MAC ?! Полно контроллеров со встроенным аппаратным, разница в цене даже при многотысячных тиражах не перекроет перерасход зарплаты на написание софтового, да еще и медленного (100 мбит/1Гбит - не видать как своих ушей).
zltigo
Цитата(Rst7 @ Feb 16 2008, 21:01) *
Не спасает. Точнее, не нужна. Потому как MAC-уровень реализован программно.
Вот и приходится....

А почему не и PHY до кучи? Не удалось помахать ножками на 10MHz, а только на 2,5 smile.gif
Только вот почему вы этот трюк называете ТCP/IP стеком? В сколь-нибудь обычных реальных применениях требования к нему заментно другие.

Цитата(SIA @ Feb 16 2008, 21:51) *
да еще и медленного (100 мбит/1Гбит - не видать как своих ушей).

Дело даже не в медленном, а в том,что пару буферов - в реальной сети не выживут никак, только в тепличных точка-точка с единственным протоколом. Ну и насколько сие полезно в реальности?
Rst7
Цитата
100 мбит/1Гбит - не видать как своих ушей


А часто и не нужно столько. Нужен один интерфейс на всю систему. И Ethernet - вполне хорошая альтернатива.

Цитата
А почему не и PHY до кучи? Не удалось помахать ножками на 10MHz, а только на 2,5


PHY пока только в одну сторону могу - USART'ом в SPI-режиме.
Хотя была версия и с приемом wink.gif тактовая частота проца синхронизировалась ФАПЧем с принимаемым потоком и тем-же USART'ом принималась. Только рассыпухи много, PHY за 1$ решает много проблем wink.gif

Цитата
Только вот почему вы этот трюк называете ТCP/IP стеком


Я не этот трюк называю TCP/IP стеком. TCP/IP стеком я называю задачу, которая представляет из себя вечный цикл, в котором обрабатываются входящие пакеты (они принимаются процедурой, реализующей MAC RX, на прерывании), генерируются выходные пакеты, и, для TCP-сокетов вызываются колбеки о соединении, приходе данных, необходимости сгенерировать следующую порцию данных, необходимости отката, о подтверждении переданных данных принимающей стороной, и о разрыве соединения (культурно или аборт). Столь не совпадающий с bsd_socketами интерфейс был придуман для минимизации затрат оперативной памяти. Хотя, как оказалось, ничем не хуже банальных send/recv. Имею я право называть это TCP/IP-стеком?
Собственно, эта задача и требует 28 регистров проца, стековых переменных не хранит. Сами данные сокета занимают 38 байт.

Цитата
а в том,что пару буферов - в реальной сети не выживут никак, только в тепличных точка-точка с единственным протоколом.


Обоснуйте. Я понимаю, что flow-controll методом back-pressure не панацея, однако, работает, так что считайте, буферов - сколько в свиче на порт - все мои. Кроме того, жизнеспособность железки проверялась на практике, благо под рукой есть пионернет о 500 компьютерах без роутеров, загаженый вирусней и качанием порнографиии, вполне можно тестироваться wink.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.