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


Да, я действительно так считаю, и особенно в случае с длинным циклом. Неудобно мне хранить в памяти полное описание из 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. Только не бейте больно

Сообщение отредактировал Pasha 111 - May 22 2006, 19:26

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

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

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