Сделал такую вот программу:

void main()
{
AT91F_PMC_EnablePeriphClock(AT91C_BASE_PMC, 1 << AT91C_ID_PIOA);
AT91F_PIO_CfgOutput(AT91C_BASE_PIOA, 1 << 17);

while(1)
{
AT91F_PIO_ClearOutput(AT91C_BASE_PIOA, 1 << 17);
AT91F_PIO_SetOutput(AT91C_BASE_PIOA, 1 << 17);
}
}

Почему скорость переключения такая маленькая (~730 Гц)?? Прога в целом работает быстро, а вот PIO почему-то тормозит. Можно как-то выставить частоту для PIO?

А как ему не тормозить в таких условиях?
1. Регистры PIO стоит писать напрямую, без использования библиотечных функций.
2. PIO подключен через APB. В случае с атмелом, доступ будет осуществляться за два такта MCLK.
Но основные тормоза это, конечно, п.1

Это каким же образом?
Смотрим библиотечную функцию:

Куда уж быстрее...
Другое дело она по каким-то причинам не отработала как inline (директива не обязательная к исполнению).
Мне думаеться здесь отсутствие инлайна, оптимизации и while(1) как неоптимальный вечный цикл - лучше поменять на for(;;).
А также не слова не сказано про установки частоты.

ИМХО, библиотечными функциями можно пользоваться только в том случае,
если они были написаны собственноручно или хотя бы проверены.
Нормальных готовых библиотек не видел ни у одного производителя.


За использование цикла for в embedded приложениях я бы увольнял
без выходного пособия.


Ну да, не сказано. Сказано, что остальное работает быстро.

Вообще, в таких случаях asm листинг первым делом смотреть нужно...

Вчера вечером нарыл одну кривизну в lib_AT91SAM7S64.h,
но огорчаться не стоит, это же не компилированная хрень, а просто набор макросов.
Не всегда удобных

Это почему? И именно в embedded?

Посмотрел пост про таймеры и понял, что таки да, грабли в установках клоков.

sure

Тут вопрос перетекает в религиозную плоскость
Моё ИМХО:
Все, что можно реализовать циклом for, реализуется циклом do..while с такой же или большей эффективностью. Да и читаемость выше.

А embedded потому, что в маленьких задачах на "больших" машинах на эффективность можно и забить.


Да не скажите, я вот ничего не понял: установил человек режим тактирования и включил
прерывания по сравнению с непонятно чем, и получил в результате 180Гц.
Я ж не телепат

Вы ещё подеритесь, господа, из-за чужой глупости. Ну даже если обкекаться то АРМ не может выдавать такое медленное переключение в при компиляции такого простого кода - 730 Гц !!! Это просто немыслимо! Я бы ещё чуть-чуть поверил если 730 КГц. Но и это для САМа маловероятно. Что-то здесь в другом дело.

Хозяин, листинг покажи. Ну и кварц какой?

Испытал я данную констукцию у себя для интереса, компилятор WinARM, на кварце 18.432 (MSK 73.9232)
при компиляции без оптимизации (-O0) даёт приетно 0.5 Мгц
при компиляции с оптимизацией (-O2) скважность сигнала уже не 0.5 да и форма на моем домашнем осцилографе сильно непрямоугольная F > 2-4 mhz (больше он у меня не берёт)

Можете обы не волноваться :-) оба приведенных примера относятся к седой старине 80x годов (но успешно до сих пор кочуют по книжкам в качестве 'откровений') когда еще существовали неоптимизирующие однопроходные компиляторы на которые for( ; ; ){} вместо while( 1 ){} и do{}while() вместо for(){} ложились естественее. Все давно в прошлом.

действительно, надо бы в генерируемый ассемблерный код иногда всё-таки заглядывать
IAR, да и любой другой серьёзный компилятор, не делает никакой разницы между while(1), do...while(1) и for(;;).
Он успешно оптимизирует и куда более навороченные конструкции.

По теме: PIO Clock не влияет на скорость и вообще на возможность переключения состояний ног. Если не нужны внешние прерывания, его можно не включать.

По поводу do..while.
Хочу тоько заметить, что:

Будет оптимально откомпилирован в ADS всегда, а

- только при включенной оптимизации.

То, что while(1), do...while(1) и for(;;) дадут один и тот же код, ясно и дураку.
Тем не менее, организовывать бесконечный цикл при помощи for(;;) я считаю дикостью.

P.S. Книжки я не читаю, все вышесказанное - мое личное ИМХО.

Напротив, для себя пришёл к выводу, что самым грамотным способом организации бесконечного цикла нужно считать for(;;) - в этой конструкции нет константы, чистый синтаксис.
Впрочем, на любителя.

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






C компиляцией, считаем, разобрались. А Вы действительно искренне считаете, что первый вариант
читабельнее? Особенно, когда тело цикла одним взгядом не окидывается :-)
Ну и по поводу возможности всегда заменить на do{} - а что если тело цикла не надо выполнить
НИ РАЗУ, дополнительнвй if() будем вешать снаружи за ради следования идее?

Как ни странно, мне встречались варианты, когда while(1) совершал кучу ужимок и прыжков, for(;;) в любом случае дает goto label, даже без оптимизации.
Каждый раз копаться в листингах для выяснения этого вопроса достаточно лениво, а компиляторы у нас эмбеддеров меняються часто

Померил на своей плате с таким же кварцем и MCK 48 Мгц (IAR EWAVR 4.30A).
................................................................................
...........
#define EXT_OC 18432000 // Exetrnal ocilator MAINCK
#define MCK 48054857 // MCK (PLLRC div by 2)
................................................................................
...........
while(1) {
AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0 ) ;
AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0 ) ;
}
Получилось:
при исполнении из RAM:
частота 5,34 Мгц и скважность 67%, джиттер не заметен.
Т.е. 3 такта MCK - низкий уровень, 6 тактов - высокий.
при исполнении из FLASH:
частота 4,00 Мгц и скважность 67%, джиттер не заметен.
Т.е. 4 такта MCK - низкий уровень, 8 тактов - высокий.