Свежие обсуждения
Микроконтроллеры

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

1 70 99

В аттаче

64155.txt

 

В предыдущей программе много странностей и лишностей.
В последнем куске программы вроде все записано, как надо. К сожалению отследить работу программы, а тем более найти ошибки, глядя на ее обрывок невозможно. В обрывке синтаксических ошибок нет. Об этом наверное и мплаб говорит при ассемблировании.
А в восьмиразрядных счетчиках после 0 всегда бывает FFh. Вы другие то регистры своего счетчика отслеживаете? Может просто не замечаете, как программный вектор перескакивает?

picmanicу. Усреднять значение периода будем? Или будем по одному значению работать. Просто, если будем, надо сразу в прграмму закладывать.

 

Будем усреднять конечно.
На работе много дел, пока участвовать активно в обсуждении не могу.

 

picmaniac: На работе много дел, пока участвовать активно в обсуждении не могу.
Да и у меня тоже самое. Хотелось бы забросить ее к едрене-фене и попрактиковаться именно в написании кода, а не в составлении алгоритмов, но... характер не позволяет.
Просто висит эта задачка дамокловым мечом на совести. Хочется разделаться с ней побыстрее, а то, когда паузы делаешь, забывается все ранее обсуждаемое.

Тут вот у меня идейка одна возникла. Сразу, после измерения периода, вычислять ошибку Тном. - Тизм., где Тном.=40мс. Если Тизм. > Тном., т. е. флаг С устанавливается в 0, инвертируем результат (дополнение).
А дальше, усреднять ошибку а не абсолютное значение периода! Для этого может хватить однобайтового регистра. Процедуры будут проще.
Можно пойти еще дальше по пути упрощения. Наш счетчик подсчета периода с приходом фронта устанавливать в значение, соответствующее Тном. (40мс). Затем его в прерываниях декрементировать. При приходе следующего фронта, сразу будем считывать значение ошибки. Точно также, анализируем флаг С, и инвертируем, если результат отрицательный.

Вот тут встает вопрос, а не пора ли нам "в рабочем порядке" скорректировать ТЗ. Дело в том, что, например, Fном. +/-10% не тоже самое, что Тном.+/-10%, а если быть точным, то Тном. +11% / -9%. Разница невелика, но она есть. Но мне думается, что для тех целей, для которых мы делаем данное устройство, зта разница несущественна. Предлагаю скорректировать пороги, и привязать их к длительности периода. Конкретно: 40мс +/- 2мс (5%), и 40мс +/-4мс (10%). В этом случае нам надо будет сравнивать только с двумя пороговыми значениями, а не с четырьмя! Процедуры упростятся. Учитывая также, что абсолютная точность измерения периода сигнала при периоде прерываний 500 мкс, составляет +/- 500 мкс, а относительная 0.5/40 = +/- 1.25%, становится совсем смешно крахоборничать в цифрах ТЗ.

А теперь о самом главном и страшном!

Встает такой вопрос. Если подсчитать суммарные цифры, то получится, 40мс +/- (3.75-6.25)% и 40 +/- (8.85-11.25)%. Такова точность наших измерений. Мне думается, что такая точность совсем "не в трубу"! Как можно повысить точность? Можно уменьшить период прерываний до 256 или 128 мкс или еще меньше. Если не будем укладываться во время между прерываниями, можно поднять тактовую частоту. А можно поднять точность другим способом. Не обнулять (устанавливать) счетчик при приходе очередного фронта, а продолжать считать в течении фиксированного значения количества периодов, организовав, например двухбайтный счетчик. Затем, или работать с этим числом, либо поделить на константу, либо просто откинуть старшие разряды, это смотреть надо, как лучше.

В противном случае, при нашей точности измерения, усреднение бессмысленно, т. е. не прибавит точности, если конечно не усреднять, например по 100 отсчетам.

Короче, начал я программу писать, но, чувствую, что рано! Много еще проблемных и несогласованных с МК-сообществом на форуме, моментов.

А мой алгоритм не смотрели? Правда в силу вышеизложенного все наверное переделывать надо.

 

Так, в общем я за этот вечер наваял черновой вариант программы на асме. t = 250 мкс. Пока это лишь набросок. Немного погонял в MPLAB5 и чуть-чуть в PIC Simulator IDE.
Вопрос ко всем участникам: выложить код сюда на обсуждение, или будем совместно с нуля писать?

 

picmaniac: Вопрос ко всем участникам: выложить код сюда на обсуждение, или будем совместно с нуля писать?
Да в принципе, как хотите. В любом случае, буду пытаться писать сам. А как насчет моих вопросов, недоумений и предложений?

 

Ну всё!!!Казалось бы отладил цикл,но тут вылезла ещё одна трабла.Как например сделать так чтобы '01111111' после RLF '0' появлялся в первом бите сразу ,а не после двух тактов.И только один ,а не два?
Это уже не надевается мне на шею

 

Zandy, некоторые моменты я попытался учесть в программе. Вечером выложу, обсудим детально. Программа на домашнем компе.

Nikus: Ну всё!!! Задавайте вопросы точнее. Я же сказал - телепаты в отпуске! Например: условие такое-то, получить хочу то-то и то-то, как это сделать? Не следует выдёргивать мысль из контекста.
Что нужно - одной ассемблерной командой превратить 01111111 в 11111110 ? А зачем именно так??? Сдвига напрямую, не через С - в PIC16 нет.

 

Привет picmaniac
в принципе условие именно такое:получить ротацию байта(влево и вправо с переносом) без пропуска битов.Только не обязательно одной коммандой.Дело в том что я пытаюсь сделать бегущие огни и биты пропускать нельзя.
Вот такая закавыка

 

Ну вот, другое дело. Теперь задача понятна. Это просто. Например так. Сдвигаем регистр влево. Затем сбрасываем младший бит в 0. Тестируем С, и если там 1 - то устанавливаем младший бит в 1.
rlf MYREG,F
bcf MYREG,0
btfsc STATUS,C
bsf MYREG,0

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