Atmega128 тормозит? AVRStudio+Proteus

[lsdy]

вызов брошен

[Satyr]

только вот с проектами не ясно, откуда их брать... может, что предложите?

рекомендую попробовать на симметричном шифровании на основе сетей Фестеля какой нибудь алгоритм.

[mbzyab]

Пользуясь случаем, передаю привет моей маме, моему тренеру и Сатане!

Всем спасибо за советы и за помощь, очень большое спасибо!

[ARV]

рекомендую попробовать на симметричном шифровании на основе сетей Фестеля какой нибудь алгоритм.

если б я еще знал, что это такое вы код дайте, и всех делов. желательно на стандартном ANSI-С или еще лучше С99...

[Satyr]

Тут есть http://www.cryptocom.ru/opensource/openssl100.html
в gost89.c алгоритмы

[ARV]

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

[Satyr]

Куда ближе ?
Только для этого и используем -)))

[ARV]

Куда ближе ?
Только для этого и используем -)))

ну так и дайте готовый код или хотя бы упрощенный. тестирование тестированием, но тратить силы и время на составление исходника теста, а потом еще доказывать, что я его не подогнал специально под avr-gcc - нет уж, увольте...
скомпилировать с "подбором опций" - готов, но не более.

[Murav]

давайте соберем какой-нибудь проектик - я в WinAVR, вы в IAR и поглядим, действительно ли результат WinAVR настолько ужасен, чтобы об этом говорить.

У меня IAR нет, так что я такое сравнение произвести не смогу. Кстати кто-нибудь знает, где его можно достать?

для объективности можно взять в качестве платформы attiny13 и atmega128 - то есть один из самых мелких и один из самых "просторных" МК.

Здесь важен не размер МК, а набор команд(прежде всего наличие аппаратного умножения - умножение переменной на константу очень важно, а у компиляторов с этим часто бывает плохо) и размер адресов. Так что скорее всего достаточно будет одной tiny и одной mega, например ATTiny461(в ) и ATMega16

рекомендую попробовать на симметричном шифровании на основе сетей Фестеля какой нибудь алгоритм.

Алгоритмы плохи тем, что они сильно отличаются по виду от того кода, который обычно используется на МК: там много арифметических(или логических) операций с небольшим объёмом переменных. А обычно МК занимается управлением какой-либо системой, так что там в основном последовательные действия с минимальными рассчётами, обработка различных ситуаций(для каждой из которых свой код), обработка массивов данных, работа с регистрами ввода-вывода, прерывания и т.п.

ИМХО, лучше стоит взять какой-нибудь реально работающий проект(или несколько), в котором есть весь код, с которым у компиляторов могут быть проблемы.

И при тестах стоит разделять оптимизацию на процессорно-независимую и процессорно-зависимую. У GCC куча проблем именно со второй, а по первой он вполне может обходить IAR.

Для процессорно-независимого кода возможные проблемы оптимизации уже выяснены - достаточно найти тесты для сравнения любых компиляторов. В основном это исправление неоптимального кода, а так же
А вот процессорно-зависимый проблемный код надо искать самим. Из того что я вспомнил: 16-разрядные(32-разрядные встречаются слишком уж редко) переменные, умножение и деление на константу, прерывания с вызовом функций(которые не инлайнятся) и без вызовов функции, которые компилятор может заинлайнить(а может и не заинлайнить), работа с массивами, большие switch'и (генерация кода для них в компиляторе часто делается отдельно) и чтение массивов из flash.