Имеющий уши - да услышит.

Напоследок, утомили вы меня. Ваши слова



Finito!

2sergeev - да никто вам не мешает воткнуть осциллограф - расслабьтесь, пользуйтесь на здоровье Вообще забудьте что тут говорили, вы - самый лучший.

Если все же вернуться к нашему барану - LPC2478, то ситуация с работой SDRAM чуть менее чем полностью очевидна: так как кэш отсутствует, для случайного доступа она практически непригодна, но зато ее можно использовать для буферизации всего и вся. Каких-либо специальных инструментов для изучения ее поведения тоже не нужно, достаточно почитать документацию и потратить пару-тройку часов на написание тестовых программок, если уж сильно захочется. LPC2478 - это весьма маленький процессор, не нужны ему счетчики.

это все уже понятно. и по-сути в случае чужого кода (который предполагался к работе как есть, без вникания в детали), нужно потратить время на тесты типа "кладем вот эту структуру в sram - меряем, теперь повторим для другой структуры". и, по большому счету, может потребоваться повторение этого для разных комбинаций размещения структур. но это - еще не самый худший случай. потому что автор кода мог не предполагать использования кода на платформе, где разработчик выбирает что положить в sram-кэш, а не автоматический кэш-менеджер. и мог элементы раскидать по структурам не самым оптимальным образом. тогда окажется, что для хорошей производительности нужно либо класть все структуры в срам (которой, вообщем, не шибко много), либо переделывать код. что тоже можно, но ...


ps. процессору счетчики точно не нужны. счетчики могут быть нужны разработчику

Зачем решать задачу с конца? Сразу кладем все со случайным доступом в SRAM, буферы - в SDRAM. А вот если SRAM не хватает, тогда только нужно начинать думать, перекладывать и тестировать.

уже влазит с трудом, уже usb/eth-ram задействованы. уже буферы для fat в sdram. а функционал еще хочется добавить.

DMA используется? В LPC имеется поддержка memory-to-memory и scatter/gather трансферов. В декодировании MP3 не очень вижу как это может помочь, но вдруг.

SG видел, полезная штука. хотел попробовать SG для вывода буферов в DAC. касательно mem2mem не уверен - похоже helix'у важнее иметь временные переменные в sram, а собственно mp3 данные можно положить в sdram без особенной потери в производительности.

Осталось только научиться все эти ХАРДВАРДНЫЕ счетчтики чисто программно считывать в строго детерминированные
моменты времени, особенно при наличии OS...
Здесь без Event System Вы мало что точно намеряете.

там все несколько проще. на каждый счетчик есть счетчик превышения по достижению которого срабатывает прерывание и регистрируется адрес, на котором это случилось. от ОС ничего не требуется. от профайлера - только настроить события, счетчики превышения и регистрировать адреса. ну и потом соотнести эти адреса с функциями-инструкциями. так работает oprofile, а на его основе - amd code analyst. и этого хватает для нормального профилирования.

Это вам 90 килобайт оперативки не хватило для MP3 декодера? Откуда такие запросы-то?
Люди вон на 50 килобайтах справляются...

Ололо, давайте померяемся, кому сколько надо

Ничего смешного не вижу
Сам рассчитываю на 24 килобайта для декодера, плюс буфера для ЦАПа и файловые - в 32 кб надо бы уложиться

А я не в Ваш огород Я чисто топикстартера, ага