пользовательское прерывание

[mim]

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

К слову ... это когда бы ты прочел все что я писал ранее... Да sei уже вставлено в файле FCD (и об этом писалось), который я выложил для 5 версии... и который ты успешно не смотрел... А в 6 версию я просто скопипастил все то, что создала 5 версия а там естественно полный код на СИ... Поэтому разбираться и подчищать (если ты в 6 версии) это твоя задача... К слову - я тупо скопировал, поэтому не проверял все режимы, возможно где-то ошибся - возьми и проверь все настройки самостоятельно...

То что ты описываешь трудно вникнуть по словесам... если сделаешь в 5 версии и с Протеусом, то я думаю что все решим... тем более мне не понятно что ты там затеял, может все совсем не так нужно делать...
Что в Си что в ассемблере не должно быть ни какой разницы. И я как-то уже доказывал на форуме, что правильно описав все на Си, можно сделать программу по объему кода не более чем и на ассемблере...

Все эти картинки и все эти записи для стороннего человека до одного места... К чему тупо смотреть в то что можно пощупать...

ЗЫ мне совсе не потяно вот это

в регистр сравнения OCR0A загружаются разные числа для изменения частоты. А это никак не должно повлиять на срабатывание прерывания,

Мы же об СТС говорим? Именно это и должно влиять на изменение прерывания. Если разрешено прерывание по "вектору А" то изменение значения в регистре OCR0A влечет за собой изменение периода прерывания, и именно это ДОЛЖНО влиять на изменение срабатывания прерывания.... в этом и суть...

А вот теперь "кстати" я писал что OCR0A и OCR0В взаимосвязаны, если прерывание по "вектору А режим СТС", то частота на пинах OCA и OCB будет определяться частотой установленной в описании прерывания (и будет одинаковой, если не менять значение OCR0A), изменение в OCR0В на частоту ни как влиять не будет, влияние будет на сдвиг фазы на пине OCB, относительно пина OCA. Причем значение OCR0В не может быть больше OCR0А...

[Ник: krianИмя: krian(Харьков)]

К слову - я тупо скопировал, поэтому не проверял все режимы, возможно где-то ошибся - возьми и проверь все настройки самостоятельно...

Ну да, ты тупо скопировал и написал, что это настройка прерывания СТС. А я поверил. Надо ж было сразу написать, что это пример от фонаря, типа КОПИ-ПАСТ из 5-й версии.
Оказалось, эта настройка к режиму СТС никакого отношения не имеет.
Вот то, что ты прислал с моими расшифровками по даташиту:
//Interrupt: Enable TMR0COMPA
TCCR0B &= 0xf8;// FOC0A=1, FOC0B=1,WGM02=1, CS02=0, CS01=0, CS00=0 СЧЕТЧИК ОСТАНОВЛЕН, ПРЕРЫВАНИЕ НЕ ГЕНЕРИРУЕТСЯ.
TCCR0B |= 5; // Делитель 1024
OCR0A=256-1; // В КОМПАРАТОРЕ 0XFF
TCCR0A &= 0x3F;// ВЫХОД А ОТКЛЮЧЕН, ВЫХОД В УСТАНОВЛЕН В 1, ВКЛЮЧЕН РЕЖИМ FAST PWM
sei();
TIMSK0 |= (1 << OCIE0A);// ПРЕРЫВАНИЕ ПО OCR0A РАЗРЕШЕНО, но в режиме СТС оно не генерируется, потому что FOC0A и FOC0B остались установленными в 1.
TCCR0A &= 0xFC;// ВЫХОДЫ ОС0А И ОС0В УСТАНАВЛИВАЮТСЯ В 1, ВКЛЮЧАЕТСЯ РЕЖИМ NORMAL
TCCR0A |= 0x03;// ВКЛЮЧЕТСЯ РЕЖИМ FAST PWM
TCCR0B |= 0x08;// ВКЛЮЧЕТСЯ РЕЖИМ FAST PWM

Т.е такие настройки изначально не подходили для режима СТС. Это для FAST PWM.
Я уже все исправил. Однако это не помогло.

То что ты описываешь трудно вникнуть по словесам...

Что там вникать? Это логический анализатор. В Протеусе тоже не понятно, правильно ли оно моделируется, а тут реальный контроллер на макетке. Когда в режиме СТС задано изменение выхода по каждому совпадению, то прерывание по совпадению с OCR0A должно совпадать с каждым перепадом сигнала на выходе. Это связанная цепочка событий. По совпадению регистров аппаратно изменяется состояние выхода, и программа переходит по вектору прерывания на заданный макрос. Если программа выполнила макрос прерывания, то на моем выходе формируется соответствующий импульс. А на диаграмме с анализатора видно, что этот импульс формируется не по каждому перепаду на выходе. Это значит, что прерывание генерируется не всегда или по вектору программа переходит не всегда.
Интересно то, что если в макросе арифметическое действие заменить на обыкновенную задержку, которая меньше времени между перепадами, то все работает правильно. А если там любые арифметические действия, хоть с длинными числами, хоть с байтами, то прерывание работает не правильно. Хотя это арифметическое действие гораздо короче по времени, чем та задержка, которую я ставлю взамен. И я не пойму причину такого эффекта.

[mim]

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

Это значит ошибка в логике, в понятиях...

И я не пойму причину такого эффекта.

Причина такого эффекта типична и распространена... не правильное сочетание временных интервалов работы цикла тела программы с циклами прерывания... условия программы работают не синхронизировано с прерываниями... разработчик об этом забывает...

TCCR0B &= 0xf8;// FOC0A=1, FOC0B=1,WGM02=1,

Неверно...

TIMSK0 |= (1 << OCIE0A);// ПРЕРЫВАНИЕ ПО OCR0A РАЗРЕШЕНО, но в режиме СТС оно не генерируется, потому что FOC0A и FOC0B остались установленными в 1.

Неверно.... стоит ли еще о чем то спорить...
Мне для таких понятий анализатор не нужен,

soft_CTC_mode_T0.rar

да и тебе тоже... нахрена он тебе...

Короче... Где пример?

[Ник: krianИмя: krian(Харьков)]

Ну вобщем все я понял. Друг надоумил вспомнить Найквиста и все стало на свои места. А в программе все было правильно.