Ликбез по программированию PIC

БЛ***!!! Полчаса писал ответы по пунктам и на последней строке эта сволочь зависла! Сегодня на такой подвиг больше уже не готов, отвечу завтра утром.

AHTOXA: Представьте таймер без предделителя. И загрузку значения счётчика в конце процедуры прерывания.
Для счета "количества состоявшихся прерываний" (т.е. безотносительно к задаче) какой-либо аппаратный таймер использовать нерационально. Достаточно ячейки и декримента (инкримента).
В "совсем бедной" архитектуре, где для задания времени до следующего прерывания требуется каждый раз программная повторная инициализация, разумеется, она ДОЛЖНА БЫТЬ самым первым фрагментом при входе в прерывание. А например, В ЛЮБОМ
(даже 70-х годов прошлого века) контроллере MCS51 имеется автоматическая аппаратная переинициализация для внутр. таймеров. Промышленный стандарт..однако.

Special for Splav56

Vlad_Petr:
Для счета "количества состоявшихся прерываний" (т.е. безотносительно к задаче) какой-либо аппаратный таймер использовать нерационально. Достаточно ячейки и декримента (инкримента).

При чём тут количество состоявшихся прерываний? Речь о счётчике таймера.
Вы что, не следите за нитью разговора?

Напомню:

SAK:
А у меня есть замечание: инициализацию начального значения таймера лучше производить в начале прерывания сразу после сохранинения регистров, т.к. время выполнения процедуры прерывания в большинстве случаев не определено и не постоянно. По этим причинам загрузка счёчика перед завершением прерывания может привести к нестабильности временных интервалов при длительной обработке прерывания.

Vlad_Petr:
SAK: загрузка счёчика перед завершением прерывания может привести к нестабильности временных интервалов при длительной обработке прерывания.
Ничего подобного...

SAK:
Возьмем такой случай: частота генератора 4 МГц прерывания происходят с частотой 20Гц, из этого следует, что предделитель работает с коэффициентом пересчёта 1:256 и за эти 50 мс происходит приращение счетчика таймара 195 раз. Т. е. после выполнения каждых 256 команд происходит приращение значения счетчика таймера. Теперь представим, что при обработке прерывания потребовалось выполнить 300 команд. За это время уже прошёл один цикл счёта предделителя и счетчик таймера увеличился на единицу, но мы не успели в него загрузить начальное значение, а загружаем его только теперь. Следовательно время до следующего прерывания увеличится на 256 тактов. И эта ошибка действительно будет зависеть от того сколько тактов выполнялась обработка прерывания и в общем случае это значение может скакать в широких пределах от прерывания к прерыванию.

Vlad_Petr
Неужели заданный аппаратным таймером период прерываний =20мс. зависит от количества выполняемых команд?
Что касается "..не успели.." , если я правильно понял, речь идет о случае, когда не успели выйти из прерывания к моменту следующего такого прерывания? Такие случаи недопустимы. За этим программист следит....
Т.е. максимальное время (ход по самой длинной ветке) выполнения команд в прерывании, всяко должно быть меньше заданного периода прерываний. Это очевидно!
ИМХО на asm эти вещи виднее...
Я ответил на вопрос?

AHTOXA :
Вы неправильно поняли. SAK абсолютно прав.

Представьте таймер без предделителя. И загрузку значения счётчика в конце процедуры прерывания. Причём процедура прерывания выполняется, скажем, от 20 до 40 тактов, в зависимости от условий. Так вот, в этом случае, следующее прерывание возникнет не через счётчик тактов после текущего, как бы мы хотели, а через счётчик+20 или счётчик+40 тактов!
То есть, мало того, что мы имеем неправильный период таймера, так ещё и джиттер.
По-хорошему, надо учитывать даже время входа в прерывание, и грузить в счётчик соответственно меньшее значение...

Мне кажется, Вы невнимательно прочитали посты, на которые так авторитетно возражаете.

Vlad_Petr: В "совсем бедной" архитектуре, где для задания времени до следующего прерывания требуется каждый раз программная повторная инициализация, разумеется, она ДОЛЖНА БЫТЬ самым первым фрагментом при входе в прерывание.

Именно об этом SAK и я толковали Вам, уважаемый гуру. Это же ветка про ПИКи, и у них как раз "для задания времени до следующего прерывания требуется каждый раз программная повторная инициализация"...

Vlad_Petr: А например, В ЛЮБОМ
(даже 70-х годов прошлого века) контроллере MCS51 имеется автоматическая аппаратная переинициализация для внутр. таймеров. Промышленный стандарт..однако

Хороший аргумент, да.

picmaniac: Special for Splav56

Special for picmaniac

Что же мне после каждой фразы копировать сообщение в буфер? Так затр******* писАть! А после зависания помогает только одна кнопка!

Отвечаю по-порядку (хорошо что рабочий комп не виснет):

picmaniac:
Замечания по предложенному техзаданию:

1. Это техзадание НОМЕР ЧЕТЫРЕ! Ага - поправили.

YES!

2. При номинальном режиме лучше пусть индикатор изредка вспыхивает. Это будет свидетельством того, что режим в норме, устройство работает нормально, и МК не "завис".
3. При малом отклонении контролируемого параметра от нормы - вспышки должны стать чаще и промежуток между ними поменьше. Это привлечёт внимание.
4. При недопустимом отклонении контролируемого параметра от нормы - вспышки должны стать частыми и с минимальным промежутком. Это ещё лучше привлечёт внимание. А на погасший индикатор наоборот внимания не обратят сразу.

Я думал на тему индикации и пришел к выводу, что состояния: лампа горит (норма) - лампа мигает (допустимое отклонение) - лампа гаснет (отклонение выше допустимого) для человека субъективно намного более легко различимы и правильно истолкованы, чем состояния: лампа мигает редко (норма) - лампа мигает быстрее (допустимые отклонения) - лампа мигает часто (отклонения выше нормы). Погасание одной из четырех ламп человеком будет замечено довольно быстро. Чтобы увеличить надежность вместо ламп можно применить с/д. Чтобы м/к не зависал можно использовать WDT.

5. Через какое время должен происходить отклик устройства на выход измеряемого параметра за установленные рамки? Иными словами - быстродействие.

Быстродействие будем считать не критичным, поэтому отклик на событие можно выводить после опроса всех 4-х линий.

6. Не описаны действия устройства после возвращения контролируемого параметра в установленные рамки. Требуется ли вмешательство пользователя?

Во всех случаях система продолжает мониторинг, но если параметр выходит за рамки критического отклонения (+/- 10%), то на управляющем пине (одном на все четыре канала) появляется сигнал управления, которым можно управлять внешними устройствами. Т.к. критическим является отклонение выше нормы по любому из каналов, а какой конкретно указывает световая сигнализация, то четыре упаравляющих канала (по одному на каждый параметр) полагаю ни к чему.

7. Пункт 7 в техзадании лишний. Как именно составить программу - решается не на этом этапе.

Вчера приводил аргументы в защиту возможности задания метода (т.к. это учебная программа), но сегодня поутру решил Let it be.

8. Требуется ли вообще вмешательство пользователя в работу устройства?

Нет. Пользователь только следит за индикацией и на основе ее принимает решение о возможности дальнейшей эксплуатации объекта, параметры которого отслеживаются.

9. На 4 контролируемых параметра - 1 выход?

Да, см ответ на п.6

Zandy

Предлагаю аппаратный формирователь не затрагивать. Пусть будет лог. уровень. Мы же все-таки в этой ветке программировать собрались. Если встроенный компаратор использовать - другое дело.

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

Splav56: ВременнАя стабильность входной последовательности +/- 0.1% (0,5 Гц) Чего-то я не понял. А что мы измерять собираемся?

Имелась в виду скважность.

Предлагаю в качестве выхода на с/д использовать RB1. С/д подключаем к питанию. На RB2 - канал управления. Лог. 0, если <10% и 1, если >10%
А такой ситуации, как отсутствие сигнала на входе не предполагается вообще?

Я бы использовал RB4:RB7 как входы каналов контроля, а RA0:RA3 как выходы на индикацию. Исполнительный выход подвесил бы на RA5.

Я так понял, что данная опция - не в этой жизни?

Ну почему же? Это не так и сложно.

Моё предложение по распиновке такое: RB4-RB7 входы, RB0-RB3 светодиоды, RA0 - выход. Что вам так RA5 нравится, он же без выходного буфера (RTFM!). И, к тому же, почему не оставить его входом сброса _MCLR?
Если было бы 1-2 входа, то можно было бы задействовать встроенный триггер Шмитта, либо встроенные компараторы. А так потребуются внешние формирователи.
Splav56: копировать сообщение в буфер? Так затр******* писАть!
Я длинные сообщения в "Блокноте" (Notepad) пишу, периодически сохраняясь. И никакие зависания не страшны.

picmaniac: Что вам так RA5 нравится, он же без выходного буфера (RTFM!).

Sorry, сейчас все время работаю с 874-м, забыл что на 628-м собираемся делать, а у 874-го RA5 стандартный TTL.

picmaniac: Моё предложение по распиновке такое: RB4-RB7 входы, RB0-RB3 светодиоды, RA0 - выход.

Можно и так. Не принципиально RA0:RA3 или RB0:RB3

picmaniac: Я длинные сообщения в "Блокноте" (Notepad) пишу, периодически сохраняясь.

А я по-старинке - в окошке ответа. Буду теперь блокнот использовать для длинных тирад. Правда я стараюсь писАть покороче.

И всё- таки погасание индикатора не используют обычно для сигнализации о неполадке. Уж у нас в энергетике сигнализаций всяческих - ого-го! И везде либо загораются, либо мигают индикаторы. Это ж неспроста. Ещё и звуковые сигналы применяются, кстати над этим тоже можно подумать. А уж если погасло - значит дела совсем плохи. (или просто лампочка сгорела )

Предлагаю все-таки не "распыляться". Можно предложить еще кучу вариантов, и долго обсуждать, как лучше, как хуже. В конечном случае наша цель-то несколько другая. Мне думается, что лучше обсуждения направить в другое русло, поближе к тематике этого топика. Чем больше мы разберем учебных программ, тем лучше. А то, уже начал забывать, что делает команда clrf.
Меня, например больше волнует другое. Каким образом можно организовать подсчет, используя прерывания по входному сигналу, как предлагал Splav56, а точнее, как организовать приоритет между четырьмя входными сигналами, если все они будут "провоцировать" прерывания. А какой критерий выхода из этих прерываний? В прерывании организовывать цикл и проверять состояние порта? А нужны ли нам такие прерывания? С прерываниями по обнулению таймера и ухода в прерывание для принятия решения, как то более понятно.
Давайте лучше обсудим различные варианты алгоритмов решения задачки. Здесь демократия более уместна. А постановку задачи все-таки лучше производить "волевым" решением, иначе "прозаседаемся".

Хорошо, давайте откажемся от полного погасания индикатора. Пусть будет так:

1. Режим "Норма" ["Norm"] (отклонение от номинала +/- 5%) - индикатор светится постоянно.
2. Режим "Предел" ["Limit"] (отклонение от номинала в пределах от +/- 5% до +/-10%) - индикатор мигает с малой частотой (раз в 3 - 5 сек.).
3. Режим "Авария" ["Alarm"] (отклонение частоты от номинала более 10%) - индикатор мигает с большой частотой (раз в секунду).