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]

Увы я ошибся - 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

[zltigo]

Я прошу пардону, но не кажется ли Вам, многоуважаемый zltigo, что Вы ошибаетесь?!?

Да, бывает...
Да waitstate минус 1. И соответственно 50ns, что радует!