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]

И это была не оценка аналитических способностей, а попытка донести важную информацию до "фанатов" AVR. Надеюсь что у меня получилось.

В таком случае, адресуйте пожалуйста Ваш текст "фанатам" AVR, а не мне, потому как, "фанатом" какой-то определенной архитектуры не являюсь, хотя имею некоторые симпатии. Да и "важность" могу оценить сам. Единственно важная для меня информация - это константное время до изменения состояния лапки от начала выполнения команды записи в память на LPC2xxxx с FastGPIO. И то, к сожалению, как у Семенова говорил Мюллер "верить нельзя никому, порой - даже самому себе", так что еще буду проверять. Но за это спасибо. Остальное - что AVR надо забыть как страшный сон, что я "непонимаю" архитектуру и т.д. полезной информации не несет. Больше я данный поворот темы не обсуждаю.

А "PHY" - вообще 4й или 5й!

Видимо, надо начать изучение не с примеряния камней, а с комплекта стандартов IEEE802.3.

[SasaVitebsk]

В таком случае, адресуйте пожалуйста Ваш текст "фанатам" AVR, а не мне, потому как, "фанатом" какой-то определенной архитектуры не являюсь, хотя имею некоторые симпатии. Да и "важность" могу оценить сам.

+1
Один мой знакомый, который в основном пишет на LPC, работал с MSP430 и AVR, в приватной беседе сказал следующее. "Чем больше я узнаю камней, тем больше мне нравится AVR." Естественно речь шла не об архитектуре, а о комплексе в целом. Разработка - отладка - внутрисхемные средства - надёжность - доставаемость - стоимость.

Ещё раз подчеркну, - основные проекты у него на ARM7.

Поэтому - при чём здесь "фанатизм", но некоторые личные симпатии у человека могут быть. Не понимаю за чем его за это пинать? Я, к примеру люблю ловить рыбу на спиннинг. Так вот есть приманки и способы ловли очень результативные, а есть те - ловить которыми мне просто нравится. И я этого не стесняюсь. Уже нет. Я достаточно взрослый чтобы самостоятельно выбирать себе путь. Без внешнего воздействия. А вот за помощь в выборе пути - это спасибо.

[zltigo]

некоторые личные симпатии у человека могут быть

Тем не менее, если попытаться объективно смотреть:

Разработка

Выбор компиляторов у LPC меньше? Они дороже? Нет бесплатных?

- отладка -

Отладчики не отлаживают?

внутрисхемные средства

Вместо целого дикого зверинца внутрисхемных интерфейсов только два - JTAG и ISP на UART. Это недостаток? Цены на JTAG отладчики и их клоны сколь-либо существенно отличаются?

- надёжность -

LPC мрут как мухи?????????

доставаемость

Доставаемость на ОТКРЫТОМ рынке, а не в ближайшем гастраноме хуже?

- стоимость.

C ценами на сопоставимые чипы, так вообще - без комментариев.

Что там еще? Ах да Ножки у AVR круто дергаются. Все?


P.S.
Никакого фанатизма - за последние полгода сделал три небольших железки на AVR - Atmega169,Atmegа162,ATtiny2313. Никаих проблем. Тем не менее не представляю (почти ), что может подвигнуть меня на использование чего-нибудь типа Atmega128. Кстати, ни в одном их них дергать ножками, кроме, как подключенными к светодиодам не сгодилось.

[singlskv]

Что там еще? Ах да Ножки у AVR круто дергаются. Все?

Ну все-таки не только крутодергание ножками, но и со значительными токами,
иногда это имеет решающее значение...

Никакого фанатизма - за последние полгода сделал три небольших железки на AVR - Atmega169,Atmegа162,ATtiny2313. Никаих проблем.

Это уже хорошо, те Вы уже принципиально не против этих чипов....

Тем не менее не представляю (почти ), что может подвигнуть меня на использование чего-нибудь типа Atmega128.

Дык почти и ни кто не спорит с Вами, для чипов с таким размером памяти, особенно
при наличии вычислительных задач, АРМ(ну или другие 32бит архитектуры ) конечно же рулят...,
НО, есть и некоторый класс задач в которых применение одного чипа Mega32/64/128 будет
просто экономически более оправданым...

[KRS]

НО, есть и некоторый класс задач в которых применение одного чипа Mega32/64/128 будет
просто экономически более оправданым...

Это каких задач?
Mega32/64/128 довольно бедный с точки зрения пререфферии контроллер.(один плюс EEPROM) а по цене они далеко не самые дешевые.
Вот если брать AT90CANxx (самый оптимальный по цене IMHO CAN64).

[singlskv]

Это каких задач?

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

[zltigo]

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

Я все больше и больше и больше в качестве периферии для многих многих и многих случаев иcпользую CPLD/FPGA - ножек (это для любителей) завались можно получить, дергать ими так, что не угонишся, если чего премножить-подитожить - со свистом. Цены начинаются от заметно меньше 10 баксов. В 10баксовых тысячи триггеров и килобайты своей памяти.

[singlskv]

Я все больше и больше в качестве периферии иcпользую CPLD/FPGA - ножек (это для любителей) завались можно получить, дергать ими так, что не угонишся, если чего премножить-подитожить - со свистом. Цены начинаются от заметно меньше 10 баксов. В 10баксовых тысячи триггеров и килобайты своей памяти.

В CLD/FPGA пока не силен
Но, представляя себе как оно происходит, для не очень быстрых задач, но требующих именно
определенного, не совсем банального интелекта, ну вобщем ИМХО, есть задачи удачные для
CPLD/FPGA а есть те которые без MCU решать очень грусно...

Ну и про количество UART немного поспорю, многопортовые RS-485 рутуры/свитчеры еще никто не
отменял, да и врятли в ближайшее время кто-нить их отменит....

[zltigo]

..многопортовые RS-485 рутуры/свитчеры еще никто не
отменял, да и врятли в ближайшее время кто-нить их отменит....

Ну в ближайший понедельник, для подключения существующего старого оборудования - нет. Но закладывать в новое уже явная странность - CAN/LIN, Ethernet совершенно обыденная сегодняшняя реальнось. "485" протоколы уже стандартно инкапсулируются и все.