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

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 тактов - высокий.

Учение Маркса всесильно, потому что оно верно!


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

Встречный вопрос: а как быть, если управляющая переменная меняется в теле цикла?


Ну почему же, цикл while{} я считаю вполне кошерным, просто забыл упомянуть об этом в посте выше.
Так что дополнительные if'ы не понадобятся.

Вот в это я верю. 5 МГц лучше 730 герц! Хотя и это не предел для LPC214x

2 aaarrr
Скоро модераторы надают нам по ушам....
и правильно сделают кстати
Но все же посоветую взять десяток С компилеров и пособирать
два цикла for и while c разными уровнями оптимизации.
О результах докладывать не обязательно
(Сам for недолюбливал до поры).
Представьте себе Кэрниган и Ричи о чем-то думали и Страуструп через
20 лет с их мнением согласился.

И чем он кошернее вырожденного случая for( ; x; ){} ?
И чем потенциальная возможность задания, например, начального значения сносит
крышу компилятору? Дело обстоит скорее наоборот - указание всего в одной конструкции только
дополнительно увязывает все вместе и потенциально облегчает генерацию кода.

ИМХО если переключать быстрее, чем работает периферия, можно добиться такого состояния, что на выходе все время будет 0 (или 1, как получится). Переключение будет только в момент прерывания.

Хотя бы тем, что ошибку в

человек заметит с большей вероятностью, чем в


Компилятору действительно все равно, речь о читабельности и восприятии.

Есть подозрение что простой джам искажает сигнал так как его тоже надо учитывать =)

лучше мерить что-то типа

while(1) {
AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0 ) ;
AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0 ) ;

AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0 ) ;
AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0 ) ;

AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0 ) ;
AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0 ) ;

AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0 ) ;
AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0 ) ;

}

Странное восприятие....(а 0x01 тоже для недопущения ошибок? ), хотя уже радует то, что расстреливать за for(){} вместо while(){} не предлагается....

Да, проверил и убедился в Вашей правоте, получилось, что на установку и сброс вывода (при выполнении из RAM) уходит по 3 такта, а еще три такта - на возврат к началу цикла. Теоретически, генерируемая частота может достигать в этом случае 48МГц/(3+3)=8МГц.

Здравствуйте, уважаемые коллеги

По поводу таймера (TC0). Я писал так
TC_CMR = AT91C_TC_CLKS_TIMER_DIV1_CLOCK
TC_IER = AT91C_TC_CPCS
При этом скорость таймера была 180 Гц. Подробное изучение докумнетации привело меня вот к чему: AT91C_TC_CLKS_TIMER_DIV1_CLOCK - делитель частоты MCK (это и так было ясно), а вот AT91C_TC_CPCS означает, что прерывание будет сработано тогда, когда сначение счётчика таймера (TC_CV) станет равно значению регистра C таймера (TC_RC). Так вот TC0_RC по умолчаниб равен 0, т.е. по сути прерывания срабатывали при переполнении таймера (он 16-ти битный), т.е. у меня 180 раз в секунду набегало 65536 тиков
Проблема решилась следующим образом:
TC_CMR = AT91C_TC_CLKS_TIMER_DIV1_CLOCK | AT91C_TC_CPCTRG
AT91C_TC_CPCTRG означает, что при равенстве значения в регистре С и в счётчике, счётчик будет обнуляться! Т.е. выставляя значение регистра C от 0 до 65535 могу выбирать скорость вызовов прерываний (если 0xFFFF - 180 Гц, то можно посчитать, сколько нужно для N герц, например мне нужно было 1 кГц - это число 0x2E14)

По поводу PIO.
Выполнение происходило в интеррапте другого таймера, да ещё и в режиме отладки на wiggler'е

Вот так вот.

P.S. Только не бейте больно

Угу!? Там в сабже стоит MAIN. Это как понимать?

На самом деле код в проге совсем другой, а тот, что стоит в топике был написан прям тут же, в окошке ввода сообщения, и "void main" как-то мышинально написалось

Бить, наверное, не будем, но книжки нужно читать даже не перед тем, как поднять вопрос на форуме, а перед тем, как что-либо писать вообще.