|
|
|
|
|
Ну вот, сделал: 8 МГц, все переменные-счётчики типа register (и сразу компилятор показал, какая переменная в каком регистре, а не абстракции как раньше "t =>0165h", например, что это, смещение какое-то?). Оптимизация по скорости теперь, вместо стоявшей по размеру. Сигнал стал ровным, только программно генерируемые частоты придётся поправить, т.к. переключение вывода задаётся программным делителем: f прерывания / значение программного делителя. Ещё почему-то более задумчивой стала реакция на изменение частоты, т.е. перезапись OCR0 и при смене пару раз сигнал затыкался, но это ерунда, дальше видно будет почему так. |
|
|
|
И ещё хотел спросить, почему сигнал, описанный массивом выводился всегда нормально ||-но с кривым сигналом в одном и том же обработчике прерывания? Хотел вообще всё с досады массивами расписать, попробовал, а частота падает сильно генерации когда хотя бы два массива выводятся. |
|
|
|
chav1961: диагноз в принципе понятен А можете его озвучить, чтоб на будущее не вслепую опции выбирать (хоть и по умолчанию всё было)?
|
|
|
|
С массивами проблема по той же причине - слишком большой код приходится выполнять в обработчиках. Кстати, сильно не радуйтесь - проблема на самом деле не решена, вы ее только задавили  С двумя таймерами моменты прерываний когда-нибудь неизбежно пересекутся, если только коэффициент пересчета одного таймера не делится нацело на коэффициент пересчета другого таймера. Просто сейчас код у вас максимально короткий, и вы просто не отлавливаете момент, когда это все-таки происходит. А насчет диагноза и совета - совет один: в другой раз постарайтесь вписаться в один таймер. Все остальные решения - принципиально ущербны, в них этот дефект можно только задавить, но не избавиться от него окончательно. Два асинхронных (по сути) процесса всегда непредсказуемы в своем поведении. |
|
|
|
И на том спасибо. chav1961: если только коэффициент пересчета одного таймера не делится нацело на коэффициент пересчета другого таймера Имеете ввиду прескалер или то, что в OCR  ? chav1961: в другой раз постарайтесь вписаться в один таймер. Ну тогда ведь обработчик ещё длиннее станет. Хотел разделить задачи просто на два "независимых", как оказалось, таймера. Просто в main ещё кнопки есть и в таком варианте наверное нельзя генерировать что-то однозначное типа меандра из main без прерываний по таймеру!? Пробовал сначала вообще на delay-х генерацию из main, но как только нажмешь кнопку, то длииинная пауза получалась П.С. Явно в AVR-ках таймер 2 под часы заточен.
|
|
|
|
Digital: Имеете ввиду прескалер или то, что в OCR ?
Имеется в виду их произведение. Обработчик, действительно, станет длиннее, но зато не будут возникать ситуации, когда появилось прерывание от второго таймера, а микроконтроллер все еще обрабатывает первый таймер. Причина - в этом. |
|
|
|
chav1961: зато не будут возникать ситуации, когда появилось прерывание от второго таймера, а микроконтроллер все еще обрабатывает первый таймер. Причина - в этом. Полностью согласен, убедился, в этом причина и крылась. chav1961: проблема на самом деле не решена, вы ее только задавили С двумя таймерами моменты прерываний когда-нибудь неизбежно пересекутся Вышел из положения когда при обновлении OCR0 по кнопке генерация затыкалась на время примерно равное обработчику по таймеру 2 (не каждый раз, но проявлялось) так: запретил обработку кнопок при входе в прерывание от таймера 2, а разрешил - при выходе из обработчика 0; так всё нормализовалось, времени на кнопки между двумя прерываниями хватает. П.С. а можно приоритеты прерываниям выставлять (ну как процессам из диспетчера задач в виндовс) или не помогло бы такое здесь если и есть? |
|
|
|
Digital: ...а можно приоритеты прерываниям выставлять...
Здесь - нет. В принципе, частично это проблему бы решило - для одного, более критичного сигнала, можно было бы установить более высокий приоритет. В даташитах дают советы разблокировать прерывание в обработчике, чтобы его можно было бы еще раз прервать. Я бы за такие советы стрелял на месте
|
|
|
|
|