чтобы не использовать такие большие переменные, код надо записать так (моё мнение):
Так вот я и хотел избежать такого условия , мне кажется нужно посчитать сколько времени процессорного занимает условие и сколько времени занимает работа с 3мя строчками но большими переменными. (на глаз примерно одинаково получается)
По поводу деления там нет деления символ "\" это div.
ЦитатаТёмыч ()
[)еНиС, по другому никак.
Допустим, но тогда все будет коректно работать (понятно что не стабильно будут выдерживаться паузы т.к. частота может плавать внутреннего гена)? И надо ли как-то ноги под кварц настраивать? Про это вроде не написано но так, на всякий случай
Еще такой вопрос, когда таймер начинает заново счет? Сразу же после того как переполнился и поднял флаг или только после того как опустил флаг.
Немного поискал по теме счета импульсов и нашел такую интересную статью может тоже полезно будет, вроде доступно и понятно описано как настроить счетчик импульсов. В моей меге есть такие функции. Т.к. у меня все таймеры заняты уже (2 из 3), то счет импульсов (для емкостного датчика) предполагаю сделать так.
(1 таймер - алгоритм вывода на дисплей, 2 таймер - асинхронный под часы)
Сбрасываем значение таймера, запускаем таймер, задержка 1мс, тормозим таймер забираем значение. Так по моему намного лучше будет, все будет аппаратно крутиться и не мешать остальным прерываниям, а зная кол-во импульсов и время (пусть даже время будет плавать, сильно не уплывет. я буду усреднять значение, например 100 замеров, усреднил, вывел на индикатор)
Если по внешним прерываниям делать и учитывать частоту этих прерываний (порядка 30кгц) то там реально трэш получится, основной код не сможет нормально работать
А где именно? а то я только МК выбирать, да компилить умею
Цитатаmsmmmm ()
а если не париться с количеством импульсов, а мерить период
Неа) в пределах периода частота скорее всего почти не изменится для фиксации. емксотный датчик же будет, в баке штырь изолированный, он выполняет совместно с самим баком роль конденсатора. Уровень топлива меняется (во время езды например, в среднем уровень один будет но во время движения будет очень сильно скакать) емкость меняется.
Конденсатор будет стоять в задающей RC цепочке генератора, отсюда следует что частота генератора будет плавать. Если замерять только пару импульсов - будет оочень большая погрешность, она итак огромной окажется даже с замером нескольких тысяч импульсов, но так она чуточку меньше будет, к тому же если аппаратно сделать, то даже основной код встревать не будет почти
Цитатаmsmmmm ()
В майне есть. И не раз. И умножение лонга - тоже не шустрик.
А где там деление, покажи)) Я знаю что с лонг оно тратит несколько тактов на обработку, поэтому и написал в поисках лучшего варианта, но пока что мне хватает быстродействия да и на энергопотребление плевать. Хотя потом подумаю на счет спячки, а так сделать чтоб не опрашивал ничего и не выводил на дисплей при отключенном зажигании и этого хватит, не высосет же аккум 10Ач
Debug->Run, а если открыта панель Debug, то в ней кликнуть Run.
Цитата[)еНиС ()
пределах периода частота скорее всего почти не изменится для фиксации
Это о чем? Я о том периоде, который T=1/f. Считать любым счетчиком, обрабатывать в майне. Для того, чтобы говорить предметно, нужно знать пределы изменения параметров входного сигнала.
Цитата[)еНиС ()
А где там деление, покажи
А вот:
Цитата[)еНиС ()
HOUR = CLOCK / 3600; // таким образом получаем кол-во часов из секунд MIN = (CLOCK-(HOUR*3600)) / 60; // тут выделяем из остатка минуты
Ну так я и говорю это div Целая часть от деления, это не просто деление. Хотя возможно МК div как деление рассматривает, не буду спорить
Цитатаmsmmmm ()
Это о чем? Я о том периоде, который T=1/f. Считать любым счетчиком, обрабатывать в майне. Для того, чтобы говорить предметно, нужно знать пределы изменения параметров входного сигнала.
Ну я понял, о каком периоде. Частотный диапазон пока что сказать не могу, но предполагаю 30-40кГц меандра. Хотя чем выше частота тем лучше, поэтому надо экспериментально. Не могу грамотно сформулировать, почему не гуд замерять только один период, а не какойто диапазон (1мс например).
В общем попробую, как я понимаю. Учитывая что частота будет не очень сильно меняться, то в пределах одного периода МК сложнее будет без ошибки определить период. То что было при первом измерении f, при втором уже f+df (df небольшое увеличение частоты, совсем не существенное 20-30Гц к примеру, утрирую) и в силу (возможно) не большой разрешающей способности, МК определит период таким же как в случае f, возможно из-за округления.
Если же считать импульсы в течение 1мс, то даже эти 20-30Гц никуда не денутся из поля зрения МК. Даже если МК определяет с некой погрешностью, то относительно полученного значения при счете импульсов погрешность будет меньше
Например считая импульсы погрешность будет меньше
10 000+- погрешность измерения
Или же при измерении периода
0.0000001 +- погрешность измерения.
Вообще я тут подумал, полностью сделать аппаратно, даже без счета импульсов за 1мс, так возможно даже хватит обойтись переменной типа char. У меня есть считающий импульсы таймер и прерывание каждую секунду. Запускаем счетчик импульсов, делаем по нему прерывание, где заводим переменную в которой накапливается кол-во прерываний. Далее часовой таймер, вызывает прерывание каждую секунду. В этом прерывании можно определить сколько раз случилось прерывание счетчика импульсов за одну секунду, здесь же этот накопитель прерываний обнулить, а сами дынные о прерываниях в основную программу передать.
1 - это "один" или "счетчик1"? Это к тому, что переводить на ДИ шестнадцатиразрядный счетчик как-то не по фень-шую. А если он свободен, то считать им импульсы извне между секундными прерываниями. Таймер настроить нужно будет, конечно. А методика усреднения результатов проста до не могу. Создается массив в котором по кругу последнее значение заменяется измеренным. Количество элементов выбирается из ряда 2, 4, 8, 16, .... 1024 и т.д - сколько оперативки и процессорного времени не жалко. И считаем среднее. Получаем фильтр НЧ. Как сосчитать среднее максимально быстро, думаю, должно быть понятно.
Если по порядку таймеров то нулевой таймер отвечает за индикацию на дисплее Первый таймер будет какраз считать импульсы с емкостного датчика Второй таймер - асинхронный.
Да не, массив по моему слишком, проще просто накапливать прерывания и все, потом делить на кол-во секунд. Можно даже сделать так - 10секунд копим прервания потом делим на 10 и получаем прерывания в секунду в среднем ну или условное значение остатка топлива
Кстати на счет часов я подумал, поговорил на работе, сказали что тот вариант где я тупо считал секунды более грамотный хоть и работа с long int происходит. Да и у меня часы не всегда будут на дисплее. Часы высчитываются только когда я их вывожу на дисплей в основном цикле, если не вывожу - то ничего не считается и не раскладывается. Только секунды в прерывании.
Тут есть свой плюс- прога быстро с прерывания выйдет, а если условие мутить (если 60 то ++ ... ) то тут приходится все в прерывании делать. А у меня прерываний хватает и не очень хорошо будет если прерывание потеряется
Моб. версия
© 2010-2020, "Радиосхемы". Все права защищены. Почта
, мне кажется нужно посчитать сколько времени процессорного занимает условие и сколько времени занимает работа с 3мя строчками но большими переменными. (на глаз примерно одинаково получается)
? Не нужно ничего постоянно гонять, измерил, посчитал уровень, выдал на индикатор. 
