XMega будет честно работать на 32MHz?, Вынесено из "Защита секции кода.." Опции

[galjoen]

Это вариант. Только я считаю, что это лишнее..

В принципе могу с вами и согласится. Т.к. сам всегда CRC32 FLASH в основном цикле считаю (по слову за раз - см. мои предыдущие посты). Но ни разу не сработало.

Ну просто не будет программа работать нормально если часть флеша слетит по причине прыжка на erase sequence в бутлоадере, не вернемся мы оттуда в ОС... Следовательно тут как раз WDT помощник.
Ну а если предположить, что мы все-таки вернулись после erase sequence в ОС и продетектили нарушение флеш в основной программе, что дальше? Выход ведь тот же самый - сброс и запуск бутлоадера.

Насчёт защиты от несанкционированного запуска бутлоадера. Я бы предложил написать так:

; до последней проверки
ldi R17,Tag ; что такое Tag думаю объяснять не надо
; начинается последняя проверка. В ней R17 не используется.
...
; последняя проверка закончена. Дальше пошли аварийно опасные команды.
....
; дальше пример от 'Дон Амброзио'. Чуть переделанный
OUT SPMCR , R16
; ---------------
cpi R17 , Tag
brne CRASH
;-----------------
SPM

Если предположить, что аварийно опасных команд 8 шт. А у R17, в остальных частях программы, значения от 0 до FF равновероятны. То вероятность "не попорчивания" FLASH при случайном прыжке для AVR с 128 кБайт памяти будет: (1-(8/65536)/256)*100%=99.9999523%. Что существенно выше, чем надёжность CRC16 с производящим многочленом 0x11021, которая составляет 99.9984% для пакетов данных длиной более 17 бит (Р.Л. Хаммел "Последовательная передача данных").

У мелких АРМов (конкурентов мег) есть FLASH. Хотите размещайте во флеш, не хотите - копируйте и запускайте в RAM.

Если код во флеш разместить, то он и выполнятся медленно будет. Примерно с той-же скоростью, как у AVR. А у мелких АРМов разве защита кода есть? Я считал, что нет. Но м.б. у каких-то и есть - просветите.

[zltigo]

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

Ну Flash даже у мелких ARMов бывает 128битным, что позволяет считывать за раз 4 слова, что неплохо компенситует потерю быстродействия. Даже без этого скорость будет совсем не AVRовская за счет регистровых операций и большей их разрядности.

[GetSmart]

Разница между ARM7 и AVR примерно такая же как между AVR и MCS-51. Кто работал - тот знает. Интересно, что и аргументы у защитников примерно одни и те же. А после того как цены на ARM7 (особенно Phillips) стали намного дешевле сравнимых хотя бы по размеру флэша AVR, то вообще с AVR-ками продолжают работать только их "фанаты". Любовь затуманивает разум

Сообщение отредактировал GetSmart - Feb 16 2008, 02:08

[SIA]

Разница между ARM7 и AVR примерно такая же как между AVR и MCS-51. Кто работал - тот знает. Интересно, что и аргументы у защитников примерно одни и те же. А после того как цены на ARM7 (особенно Phillips) стали намного дешевле сравнимых хотя бы по размеру флэша AVR, то вообще с AVR-ками продолжают работать только их "фанаты". Любовь затуманивает разум

Так я не по этой части. Просто посмотрев, насколько шустрее один и тот же сишный код идет на Au1100 с древней, но отлаженной архитектурой, против свеженького LPC3180 (разница много больше, чем 2 раза по тактовой), начинаешь задумываться - а где прогресс, блин ?

[zltigo]

...насколько шустрее один и тот же сишный код идет на Au1100 с древней, но отлаженной архитектурой..

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

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

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

[SIA]

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

С этим согласен практически полностью. Быстрый автомат на FPGA для логического управления, особенно "табличный" - уделает на этих приложениях любой MCU. Я сам вместо DSP с большой разрядностью часто применяю комбинацию MCU+FPGA. Деньги примерно те же, а энергопотребление меньше.

Вам прямой путь вспомнить и сделать 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 для существующих.