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]

100 мбит/1Гбит - не видать как своих ушей

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

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

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

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

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

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

Обоснуйте. Я понимаю, что flow-controll методом back-pressure не панацея, однако, работает, так что считайте, буферов - сколько в свиче на порт - все мои. Кроме того, жизнеспособность железки проверялась на практике, благо под рукой есть пионернет о 500 компьютерах без роутеров, загаженый вирусней и качанием порнографиии, вполне можно тестироваться