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овская за счет регистровых операций и большей их разрядности.

[Rst7]

Я не очень понял, Вы на чём пишете? На асме что ли? Тогда мы идём к Вам!

На C я пишу.

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

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

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

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

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

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

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

Не спасает. Точнее, не нужна. Потому как MAC-уровень реализован программно. И программно выдавать данные или принимать со скоростью 10мбит мне пофиг, на 8 или 32х битах. А внутри стек устроен таким образом, что пересылается минимальное количество данных, не в последнюю очередь в связи с ограничением по озу. Негде буфера раскладывать. Вот и приходится иметь два маленьких буфера для эзернет-пакетов, прямо в них же и разбирать данные, там же и генерировать ответы и т.д.