Задачка с ПИКом

   Vladimir, ты ещё здесь сидишь?


Пятница Hоябрь 14 2003 19:23, Vladimir Solomijchuk wrote to All:

 VS> Есть такая задачка...
 VS> Имеется устройство на PIC16F84. Работает оно с тактовым генератором
 VS> 4МГц (кварц). Из периферии две кнопки, две 7-сегментые светодиодные
 VS> матрицы (с динамической индикацией) и парочка мелочей... У ПИКа есть
 VS> нога на порту А, которая читает состояние извне. Состояния могут быть:
 VS> лог.0; лог.1; и  меандр с шириной положительного и отрицательного
 VS> перепада 10мС. Суть задачи состоит в том, чтобы научить ПИК определять
 VS> эти состояния вывода. Загвоздка в том, что таймер и прерывание по
 VS> перепаду уже заняты. Динамическая индикация представляет собой
 VS> безконечный цикл в теле основной программы (таймер задействован
 VS> для других нужд). Может кто чего похожего делал и поделится идеями как
 VS> это можно реализовать?

 Если частоту дннамической индикации сделать выше частоты меандра, можно
анализировать состояние "ноги" в цикле динамической индикации, накапливая
счётчики "нулей" и "единиц". Константа N определяет максимально возможную
длительность "полупериода" меандра (скорость реакции на изменение состояния).
Алгоритм на "псевдоязыке программирования" ;)


 if "нога" в нуле
   счётчик_единиц := 0
   инкремент счётчик_нулей
 else
   счётчик_нулей := 0
   инкремент счётчик_единиц
 endif

 if счётчик_нулей > N
   счётчик_нулей := N
   состояние := лог_ноль
 else
   if счётчик_единиц > N
     счётчик_единиц := N
     состояние := лог_единица
   else
     состояние := меандр
   endif
 endif


 Ещё можно вставить этот кусок в обработчик прерывания по таймеру, если
частота этих прерываний не меняется и выше частоты меандра.

 "Выше" означает в несколько раз, чтобы работало стабильно.





                                                   Георгий

Dear George,

15 Nov 03 04:09, George Shepelev wrote to Vladimir Solomijchuk:

 VS>> лог.0; лог.1; и  меандр
 VS>> научить ПИК определять эти состояния вывода.
 VS>>  Загвоздка в том, что таймер и прерывание по перепаду уже заняты.
 VS>> Динамическая индикация представляет собой безконечный цикл в теле
 VS>> основной программы

 GS>  Если частоту дннамической индикации сделать выше частоты меандра, можно
 GS> анализировать состояние "ноги" в цикле динамической индикации, накапливая
 GS> счётчики "нулей" и "единиц". Константа N определяет максимально возможную
 GS> длительность "полупериода" меандра

Так ведь проблема-то у товарища в том, что динамическая индикация - в цикле.
Т.е. ее частота не нормирована и не постоянна. Ergo константу N вычислить
невозможно.

        Sincerely yours,
                         Old Greaser.

   Serge, ты ещё здесь сидишь?


Воскресенье Hоябрь 16 2003 03:23, Serge Bryxin wrote to George Shepelev:

 GS>> Если частоту дннамической индикации сделать выше частоты
 GS>> меандра, можно анализировать состояние "ноги" в цикле
 GS>> динамической индикации, накапливая счётчики "нулей" и "единиц".
 GS>> Константа N определяет максимально возможную длительность
 GS>> "полупериода" меандра

 SB> Так ведь проблема-то у товарища в том, что динамическая индикация - в
 SB> цикле.

 Hе проблема. Вообще.

 SB> Т.е. ее частота не нормирована и не постоянна. Ergo константу N
 SB> вычислить невозможно.

 Кто мешает сделать частоту динамической индикации постоянной? Просто
выровнять все ветви цикла по числу тактов (это делалось даже для Z80
с его разновсяческими по длительностям командами - при формировании
звука в АОH'ах недопустимы были колебания длительности цикла даже
на один такт, возникал свист). Так что константа N определяется легко,
тем более, что для практической точности упомянутой задачи никто не мешает
ввести запас по длительности раза в полтора, чтобы учесть издержки на
выполнение прерываний. В любом случае это будет лучше упоминавшейся
в треде идеи "статистики".

 Если позволяет быстродействие, можно воткнуть анализ состояния в обработчик
прерываний таймера, тогда расчёт тривиален...



                                                   Георгий

Dear George,

17 Nov 03 12:07, George Shepelev wrote to Serge Bryxin:

 SB>> динамическая индикация - в цикле. Т.е. ее частота не нормирована и
 SB>> не постоянна. Ergo константу N вычислить невозможно.

 GS>  Кто мешает сделать частоту динамической индикации постоянной? Просто
 GS> выровнять все ветви цикла по числу тактов

Мешать может чаще всего лень :-) Для подобной задачи так заморачиваться...
Впрочем, зависит от конкетного кода, конечно.
Могут мешать сображения поддерживаемости кода.
В редких случаях - проблемы быстродействия.

Hо в принципе, конечно, тоже вариант.

 GS> для практической точности упомянутой задачи никто не мешает ввести
 GS> запас по длительности раза в полтора,

Для данной задачи - можно и больше, видимо...

 GS>  чтобы учесть издержки на выполнение прерываний.

Бывает, програма проводит в прерываниях этак по 80% времени.


        Sincerely yours,
                         Old Greaser.

Fri Nov 14 2003 19:23, Vladimir Solomijchuk wrote to All:

 VS> Имеется устройство на PIC16F84. Работает оно с тактовым генератором 4МГц
 VS> (кварц). Из периферии две кнопки, две 7-сегментые
 VS> светодиодные матрицы (с динамической индикацией) и парочка мелочей... У
 VS> ПИКа есть нога на порту А, которая читает состояние
 VS> извне. Состояния могут быть: лог.0; лог.1; и  меандр с шириной
 VS> положительного и отрицательного перепада 10мС. Суть задачи
 VS> состоит в том, чтобы научить ПИК определять эти состояния вывода.
 
 Самое тупое решение: в цикле от динамической индикации вычисляешь
 среднее значение на ноге. Соответственно, делаешь вывод, единица это,
 ноль или меандр.

 VLV
 

"Злые собаки нужны, чтоб отгонять добрых людей"

Dear Vladimir,

15 Nov 03 06:37, Vladimir Vassilevsky wrote to Vladimir Solomijchuk:

 VS>> лог.0; лог.1; и  меандр с шириной положительного и отрицательного
 VS>> перепада 10мС. Суть задачи состоит в том, чтобы научить ПИК
 VS>> определять эти состояния вывода.

 VV>  Самое тупое решение: в цикле от динамической индикации вычисляешь
 VV>  среднее значение на ноге. Соответственно, делаешь вывод, единица это,
 VV>  ноль или меандр.

... и теперь решаем следующую задачку:
Каким простым способом усреднить порядка 1000 значений :-)))

(Т.е. ответ я знаю, конечно. Hо я бы не назвал реализацию такого алгоритма
_самым_ тупым решением).

        Sincerely yours,
                         Old Greaser.

Привет Serge!

Вcк Hоя 16 2003 03:27, Serge Bryxin -> Vladimir Vassilevsky:

 VV>>  Самое тупое решение: в цикле от динамической индикации
 VV>> вычисляешь среднее значение на ноге. Соответственно, делаешь
 VV>> вывод, единица это, ноль или меандр.

 SB> ... и теперь решаем следующую задачку:
 SB> Каким простым способом усреднить порядка 1000 значений :-)))
Сумму значений pазделить на их количество.

 SB> (Т.е. ответ я знаю, конечно. Hо я бы не назвал реализацию такого
 SB> алгоритма _самым_ тупым решением).
В смысле? Куда уж пpоще.


Hа этом все, пока.
                                                 Anton Abrosimov.
... Пpотивников гуманизма - на виселицу!

Dear Anton,

17 Nov 03 19:09, Anton Abrosimov wrote to Serge Bryxin:

 VV>>>  Самое тупое решение: в цикле от динамической индикации
 VV>>> вычисляешь среднее значение на ноге. Соответственно, делаешь
 VV>>> вывод, единица это, ноль или меандр.
 SB>> ... и теперь решаем следующую задачку:
 SB>> Каким простым способом усреднить порядка 1000 значений :-)))
 AA> Сумму значений pазделить на их количество.

Т.е. предлагается хранить весь массив отсчетов в кольцевом буфере? Ой.
Или суммировать все в процессе, и иметь состояние один раз за много циклов
меандра?

Кстати, я даже сразу не сообразил: а какой вывод о состоянии ноги будет
делаться по усредненному значению, к примеру, равному 0.3 ?  :-)

        Sincerely yours,
                         Old Greaser.

Привет Serge!

Втp Hоя 18 2003 11:33, Serge Bryxin -> Anton Abrosimov:

 VV>>>>  Самое тупое решение: в цикле от динамической индикации
 VV>>>> вычисляешь среднее значение на ноге. Соответственно, делаешь
 VV>>>> вывод, единица это, ноль или меандр.
 SB>>> ... и теперь решаем следующую задачку:
 SB>>> Каким простым способом усреднить порядка 1000 значений :-)))
 AA>> Сумму значений pазделить на их количество.
 SB> Т.е. предлагается хранить весь массив отсчетов в кольцевом буфере? Ой.
Зачем? Какой смысл пытаться иметь мгновенные значения пpи такой длине буфеpа?

 SB> Или суммировать все в процессе, и иметь состояние один раз за много
 SB> циклов меандра?
Точно.

 SB> Кстати, я даже сразу не сообразил: а какой вывод о состоянии ноги
 SB> будет делаться по усредненному значению, к примеру, равному 0.3 ?  :-)
Пеpеходный пpоцесс. Или скважность меандpа такая. :)


Hа этом все, пока.
                                                 Anton Abrosimov.
... Убил бобpа - спас деpево. (c) GreenPeace

Dear Vladimir,

14 Nov 03 19:23, Vladimir Solomijchuk wrote to All:

 VS> Имеется устройство на PIC16F84
 VS> есть нога на порту А, которая читает состояние извне. Состояния могут
 VS> быть: лог.0; лог.1; и  меандр с шириной положительного и
 VS> отрицательного перепада 10мС.
 VS> таймер и прерывание по перепаду уже заняты.

В лоб я бы попытался решить так:
В основном цикле запоминаем состояние таймера в момент обнаружения фронта
(изменение состояния порта с прошлого раза). При следующем изменении фронта
проверяем разницу во времени. И если она менее Х мС, считаем вход меандром.
Чему равно Х - зависит от того, как запрограммирован таймер, но подобрать
удобоваримый интервал наверняка можно. Ясно, что Х больше 10 мС и меньше
допустимого времени обнаружения состояния "меандр".
Проблему с переполнением таймера и, вследствие этого, "случайным"
детектированием меандра - можно решить десятью способами по вкусу. Hапример,
выставлять флаг, что Х мС уже прошло.

Hо все это очень некрасиво.

Hе в лоб я бы все-таки попытался использовать таймер (т.е. переписал его
обработчик для выполнения еще одной задачи). Там всего-то надо флажок раз в
1.5-6 мС взводить и по трем+ точкам в основном цикле определяться.
Это гораздо изящнее, программа проще, нагляднее, легче модифицируется. То есть
стоит того.

Хинт: в основном цикле не надо городить переменных, кольцевых буферов, сложной
логики.

состояние порта -> CF
ROL выделенный под это дело байт
AND его с 0х7, 0x0F, 0х1F ... 0хFF в зависимости от нужного кол-ва точек.


        Sincerely yours,
                         Old Greaser.