Вот как мне известно прямой доступ к памяти в SAM7X SAM7S реализован с приоритетом не процессора, а контроллера ПДП. Так вот, в каких случаях возможны такие случаи, когда нужно, чтобы процессор в данный момент времени не отвлекался ни на микросекунду, но в тоже самое время и данные по DBGU (RS232) не потерять (данные по DBGU передаются в SRAM с интервалом в 5 секунд, после чего обработка, затем всё повторяется...)?

Спасибо.

Недавно обсуждали атмеловский PDC.
Если Вы не хотите тормозить процессор ни на такт, то остается только отказаться от PDC. Хотя это странное требование.

Хорошо, а если 5 или 10 тактов для моей проги - ничего страшного? Вообще, на какое время (тактов или мксек) отвлечется процессор для того, чтобы приянть данные по DBGU (USART)?

На 2 такта.

А если без приколов, кто знает какое гарантированное время "отвлечения" проца?

А где Вы увидели прикол, уважаемый? 2 такта на одну пересылку из периферии.

Ну на самом деле, конечно же больше. Процессор по любому должен распознать, что данные в DBGU появились. Другое дело, что мне лично, так и не ясно, что автор данной ветки хочет узнать, т.к. толком про свою задачу не написал. DBGU данные через PDC пишет?

Вот и мне теперь не понятно
Я привел данные для чтения DBGU при помощи PDC. Т.е. процессор встанет максимум на 2 такта в то время, пока PDC будет окучивать DBGU.

Да, именно DBGU данные через PDC пишет... скорость 115К...

Тогда все правильно - процессор будет вставать максимум на 2 такта каждые 86.8мкс.

Для того, чтобы "ничего не терялось" Atmel и реализовал пару связанных DMA буферов. Прерывание приходит по заполнению первого буфера и автоматически DMA переключается на второй буфер. Соответственно у процессора вагон времени, чтобы чего-то с этими данными сделать. Так и не понимаю, в чем проблема у автора?

Спасибо, просто в точку попали!

А в буфера когда писать? ....... Вот про эти 2 такта и разговор ведётся. Это те 2 такта, которые процессор простаивает, когда ПДП захватывает шину памяти. Был бы кеш такого бы небыло.
Если я не прав - поправьте.

Правы, только наличие кэша ничего не гарантирует, а лишь снижает вероятность простоя.

Да, спасибо. этот момент я забыл упомянуть - вероятность

Все равно не могу понять логику разработчика, озабоченного простоем процессора 2 такта на 90 мкс. Либо задача плохо сформулирована, либо совсем слаб процессор. Касательно cache. Так как у Atmel'а аппаратно не решен вопрос когерентности кеша при совместной работе процессора и DMA, то и толку от его наличия немного, в смысле минимизации простоя процессора.

А у кого он решен, можете сказать? Когерентность кэша - забота программиста.
И к минимизации простоя процессора при работе DMA данная проблема отношения не имеет.

У Freescale решен. Кеши некоторых PowerPC ядер могут поддерживать когерентность - как относительно доступа других ядер, так и DMA. Лично не пробовал "как оно", но собираюсь . А то скорости по 2xGbE нужны большие - кеши инвалидировать целиком жалко, а выборочно - относительно долго

Дык мы все же об ARM'ах говорим (и UART'е на скорости 115200, а не 2xGbE ).

Да понятно . Это я вылез с "исторической справкой", для общего развития .
А для топикстартера - для того чтобы "выровнять" ядро на микросекунды - надо еще и код во флешке выравнивать. Наткнулся я на такое в SAM7 - написал код, просто генерирует импульс на ножке - допустим скоп видит 150нс. Потом чего-то поменял незначительно в процедуре - и оп-па - уже скоп показывает импульс 250нс. А выяснилось, что просто код немного сдвигался и выборка из флеша немного по-другому сработала. Думаю что в LPC-ях, с их MAM-ом, разброс может быть еще значительно больше.

Программа в thumb'е была?

Угу, в thumb'e.

Тем не менее просто даже интересно узнать, что у автора такого немыслимого непрерывно делает процессор, что он (автор) сильно озабочен выпадением 2 тактов процессорного времени?

Думаю что автор топика считал что затраты будут куда как больше...(в данном
конкретном случае конечно...)
поэтому и недоверие ПДП...

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