Как победить delay раз и навсегда?

[Alcest]

Тема, вероятно, поднималась уже, но не нашел и пришлось создать еще одну. Как в MPLAB с компилятором XC8 добиться правильной работы задержек?

Создаю проект, настраиваю биты конфигурации для PIC16F1829. МК будет работать от внутреннего RC генератора с частотой 8 МГц и с умножением на 4 синтезатором частоты. Вставляю определение #define _XTAL_FREQ 32000000.

В функции main() у меня только задержки __delay_ms(100), __delay_ms(10) и __delay_ms(1). Вместо 100, 10 и 1 миллисекунды при симуляции получаю задержки 800, 80 и 8 миллисекунд в окне Stopwatch.

Экспериментальным путем определил, что правильные задержки формируются только при определении частоты генератора МК равной 4МГц, то есть #define _XTAL_FREQ 4000000.

Полез искать, где же эта самая задержка формируется. В файле pic.h в папке include XC8 нашел вот это:

#ifdef __PICCPRO__
/**************************************************  **************/
/* Built-in delay routine					*/
/**************************************************  **************/
#pragma intrinsic(_delay)
extern __nonreentrant void _delay(unsigned long);
// NOTE: To use the macros below, YOU must have previously defined _XTAL_FREQ
#define __delay_us(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000000.0)))
#define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
#endif

Вся эта белиберда мне ничего не сказала полезного, кроме того, что указанная в определении частота генератора МК делится на 4000 если нужно получить задержки в миллисекундах и на 4000000 для задержек в микросекундах. Вспомнив, что задержки правильно задерживали при #define _XTAL_FREQ 4000000, взял и заменил в файле pic.h _XTAL_FREQ/4000000.0 и _XTAL_FREQ/4000.0 на _XTAL_FREQ/32000000.0 и _XTAL_FREQ/32000.0. И все тут же наладилось, задержки стали формироваться такими, какими указаны в __delay_ms().

Но понятно, что такая ситуация ненормальна. Ковырять файл pic.h всякий раз при переключении между проектами, такого врагу не пожелаешь.

Сдается мне, при всем моем небогатом опыте в программировании, что здесь есть какая-то ошибка. Но где она, я ни сном ни духом... Чего со всем этим делать?

P.S. __PICCPRO__ в свойствах проекта в поле Define macros прописывал. Причем, раньше, в более ранних версиях MPLAB и XC8 без этого попытка ввести задержку в программу вызывало ошибку. С переводчиком через Гугль находил на каком-то зарубежном форуме, что нужно этот макрос подключать. Подключал, и вроде работало в старых версиях среды и комплятора. А сейчас что оно есть, что нет. Задержка вроде работает, но работает коряво. И вообще, раньше без заголовочного файла "delays.h" подключенного к проекту и запихнутого в папку с проектом вылезали ерроры при попытке компиляции. Сейчас нигде этого delays.h не вижу и без него ошибок не возникает, но один хрен ничего добром не работает...

[индюк]

Вставляю определение #define _XTAL_FREQ 32000000.

чото мне кажется уже тут ошибка

[индюк]

а какие задержки то нужны?
я конечно в пиках давно все забыл но обычно программы не настолько круты и вполне хватает вот такого

void delay (int ms)
{
volatile int c1 = 0;
while (c1‹ms) {c1++;}
}
то есть проц тупо постоял на месте.
если много прерываний то оно конечно уплывет.
тогда я применяю таймер - включаю его и жду прерывания от него - так точно ваще выходит.

вобщем учить си надо и внутреннюю структуру проца а не тупо копировать откуда то куски быдло-кода

[Alcest]

чото мне кажется уже тут ошибка

Хорошо бы если так. Смущает то, что во всех примерах по использованию задержек в ХС8 я вижу именно такое определение частоты генератора. И если выставить в определении частоту 4 миллиона герц, задержка работает корректно. Надо думать, что при четырех МГц четыре такта генератора МК занимают 1 мкс времени. Потому в макросе (ведь это макрос, вроде, в файле pic.h?) реализации задержки за эталон принято 4 МГц, на которые делится частота указанная в определении и получается количество циклов, необходимое для задержки в 1 мкс или 1 мс при конкретной частоте указанной в определении. Только почему-то у меня лажа выходит...

а какие задержки то нужны?

Собстна, хотелось бы просто заставить работать конкретно этот __delay_ms() так как обещали разработчики ХС8. Я бы мог и циклы вставить, подогнав время количеством итераций или аппаратный таймер задействовать, но я из принципа хочу заставить работать __delay_ms(). Чтобы работало так как было задумано разработчиками, если только последние ничего не налажали.

вобщем учить си

Боюсь, тут оно мне ничем не поможет. У меня здесь из Си ничего кроме main() нету. Архитектура МК мне конкретно в этом случае тоже ничего не даст.

а не тупо копировать откуда то куски быдло-кода

Это "NOTE: To use the macros below, YOU must have previously defined _XTAL_FREQ" скопировано из файла pic.h, если что

[tanq]

Alcest,
Запись _delay((unsigned long)((x)*(_XTAL_FREQ/4000000.0)))
подразумевает, что функция _delay принимает на вход число N и крутит цикл N раз, причем каждая итерация цикла занимает 4 такта процессора. Ошибок тут нет.
По всей видимости, реальная частота процессора не 32 МГц, а 4. Т.е. надо разбираться в конфигурации клока. И ещё. Правильнее писать так:
#define _XTAL_FREQ 32000000UL
потому что 32000000 в диапазон int не влазит.

[CERGEI1982]

А правильней задержку делать с помощью таймера и флагом проверять с помощью if ,тогда у тебя никогда впустую не будет простаивать проц.

[mike-y-k]

Если возвратиться к исходной точке, то:
- прочитать, понять, освоить работу препроцессора;
- проанализировать всю цепочку директив #include и разобрать все использованные заголовки ручками, выполнив подстановку переменных (можно и в листинге конечно, но не так информативно и познавательно);
- научиться работать с хеш-суммами для файлов и утилитой diff для отслеживания вносимых разработчиками изменений.
Полученный опыт позволит решать подобные вопросы не совсем методом тыка, и с уверенностью в сделанном и в результате.

[scorpi_0n]

Взять нормальный МК с системным таймером, а не это убожество и

Полученный опыт позволит решать подобные вопросы

, и "победить delay раз и навсегда"!

[Alcest]

Запись _delay((unsigned long)((x)*(_XTAL_FREQ/4000000.0)))
подразумевает, что функция _delay принимает на вход число N и крутит цикл N раз, причем каждая итерация цикла занимает 4 такта процессора. Ошибок тут нет.

Да, меня ночью та же мысль посетила. Здесь просто количество циклов увеличивается настолько же, насколько частота МК отличается от 4000000. Сейчас только проснувшись прикрутил к проекту передачу данных по SPI. В Proteus измеряю скорость, с которой SPI передает 8 бит. Скорость не меняется при изменении частоты #define _XTAL_FREQ. Задержки меняются (хоть и неправильно), а скорость работы SPI нет. По-видимому количество циклов в pic.h увеличивается, а частота процессора не растет, вот и получаю задержки больше чем нужно.

Значит, определение #define _XTAL_FREQ не только к pic.h относится. Должен быть еще какой-то файл, где она вносится изменение в скорость работы процессор. И этот файл нужно найти и подключить к проекту, я так думаю. Буду его искать.

И ещё. Правильнее писать так:
#define _XTAL_FREQ 32000000UL
потому что 32000000 в диапазон int не влазит.

При #define _XTAL_FREQ 8000000 тоже самое. Хотя я уже думал, что 32 миллиона могут в какую-то переменную не влезать там, внутри компилятора. Но не знал как записать, чтобы правильно было. Спасибо за совет.

P.S. Кажется все значительно проще, чем я думал. Просто не обратил внимание на очевидные вещи.

[OakRidge]

Может OSCCON = %11110000 поможет. PLL включить в конфигурации !!!!

ПС _XTAL_FREQ 32000000 как знаю только говорит компилятору что частота 32МГц. И никакого отношения к настройке осцилятора не имеет. Настроить его Ваше дело.