Я бы поспорил, но не на что !!!! Давай лучше обсудим: под точностью измерения скорости я подразумевал точность измерения временного интервала (измеряю же частоту). Так вот, мне необходимо измерять и выводить на ЖКИ скорость с точностью 0,1 км/ч. На скорости 220 км/ч (что соответствует частоте сигнала 421,5 Гц), изменение периода сигнала приблизительно на 1,2 мкс вызывает изменение скорости на 0,1 км/ч.

Но самое трудное организовать измерение с такой точностью в real-time параллельно с такими процессами:
1. Дижением стрелки прибора, используя шаговый двигатель в режиме микрошаге.
2. Организовать вывод на ЖКИ
3. Вести учёт аварийных ситуаций.
4. Вести учёт пройденого расстояния.

Задаю вопрос всем, кто работал с подобными вещами, возможно ли это реализовать на С?

Давайте обсудим эту тему и многое другое за !!!
А то еще поссоримся.

Давай обсудим эту тему здесь, а вот многое другое , кончено, можна и за пивом !



!!!! -

БЛИН если на то пошло всю память 51 контроллера можно забить одинаковой командой инвертировать бит порта - один в том числе написать этот код и в векторах прерываний в смысле в месте которое для них отведено

при этом на обычном 51 с кварцем 12 мегагерц для ровного счёта с выхода этого порта пойдёт 500 килогерц, что в принципе невозможно сделать на си

я даже не уверен что с той же скоростью на си в смысле будет работать

метка "инвертировать бит"
джамп на метка, написанное на асме

извините не писал для 51 больше 5 лет - не помню команды

У как все запущено . Используется аппаратный таймер который за время интегрирования в десятки - сотни миллисекунд считает имульсы. Количество последовательных интервалов интегрирования можно менять в заисимости от скорости для достижения нужной точности. Все оставшееся время можно играть вальсы Шопена.... В чем проблема? В обработке прерываний частотой не более, чем 421,5 Hz?

Насколько мне позволяют понимать мои знания, вы привели пример электроно-счётного частотомера(последовательный метод)?
Диапазон скоростей, которые я измеряю, находится в интервале 3-220 км/ч. Для определения отсутствия сигнала V<3 км/ч(нулевая скорость), мне необходимо поставить ограничения на максимальный период входного сигнала 0.17 с. (прямоуголные импульсы с датчика скорости) Это означает меньше 5 импульсов в секунду, при необходимости обновлять ЖКИ минимум 2-3 раза в секунду(данные для стрелки обновлять ещё чаще), теперь вопрос а возможно ли будет таким методом отличить скорости 3 (Период следования импульсов = 0.177 с.) и 3,1 км/ч (Период следования импульсов = 0.172 с.), это как импульсы прийдётся считать?

Нет. Измерение длительности периода c возможными разборками c переполнения таймера/не срабатывания таймера на низких скоростях (когда времени много) и максимальными требованиями считывания-накопления значений таймера не чаще чем за две с лишним миллисекунды на скорости 220.

Вообще-то в этой теме обсуждается вопрос о применимости в тех или иных задачах Ассемблера или Си. Насколько я понял Калина уже разобрался с методами и алгоритмами измерений промежутков времени. Скорее всего его интересует возможность реализации оных на Си и сравнение с Ассемблером... И вообще я что-то не понял о чем вы толкуете, уважаемый zltigo: то вы считаете импульсы, то уже измеряете период... Не могли бы Вы выразиться более точно, или логически связано... Тут же не все разбираются с особенностями разных жаргонов...

Можно измерять период подсчитывая импульсы аппаратным таймером. Только на вход таймера подавать клоки от внутреннего генератора (например 1 или 8 или 16МГц клок, таймер 16 бит). Сигнал от датчика скорости подавать на вход прерывания, а по прерыванию считывать значения с таймера. Таким образом, двух импульсов с датчика скорости достаточно чтобы с точностью до длительности клока (62,5наносек) определить период импульсов с датчика скорости и сразу пересчитать их в км/час. Считанный счетчик сбрасываем в 0 и ждем следующего прерывания. Вся задача укладывается в двадцать строк на Си.

Если считывать значение из таймера в прерывании - то точность будет сильно ниже. А вот если использовать специально предназначенный для этого режим захвата (capture) таймера, то вполне реально. И на С и даже на Паскале (точно-точно, сам делал, правда, не по своей воле ).


Ну это не смешно. Отряхнул от пыли Кейл uVision 1.24, датированный 97 годом:6 минут вместе с копированием результата в форум. Почти уверен, что можно как-то объявить функцию как noreturn и подавить ret. Ну а уж скопировать одну строчку на всю память что на С что на асме - труда столько же.
Я не писал 6 или 7, команд тоже не помню, но задачу решил не заглядывая в даташит. А вам слабО? ;)

усложню задачу - без использования таймера сложение 4 байтовых чисел с 4 байтовыми с одновременным генерированием того же самого - инверсия бита каждые 4 машинных цикла

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

С алгоритмами-то разбираться не сложно - все уже придумано до нас. А вот с реализацией, похоже, нешуточные проблемы.

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

из своего процессорного опыта - это было по необходимости - так я рассыпушечник 133-164ла3-7 и всё такое ,,,,,,,,,,,,,,,,,CPLD потом FPGA )))) может у меня был такой неправильный подход - все процессы должны выполняться параллельно - в процессоре псевдо параллельно

а именно нарисовать схему = нарисовать эпюры сигналов а далее команды по временной оси - вопрос с чередованием не снят

любые операции можно проредить командами с периферией

сейчас выглядит глупо))) но программы аонов конца 80х начала 90х в 4к пзу возможностями не страдали
сам писал по 400 кбайт на ассемблере под TMS

Уважаемые форумчане, большое спаисбо за тот опыт работы с языками программирования, которым вы поделелись. Кто бы что не говорил, а знать, конечно, необходимо оба языка, иначе никогда не будет права выбора, так как выбирать будет не из чего . Конечным принятым решением было начало освоения С.
P.S. Какую литературу вы могли бы посоветать для начинающего? И ваше мнение о книге "Программирование на языке C для AVR и PIC микроконтроллеров" Шпак Ю.А.?