РАДИОСХЕМЫ



СТАРЫЙ ФОРУМ

Форум на ЭЛВО


РАДИОФОРУМЫ


СХЕМЫ И СТАТЬИ



  • Страница 2 из 8
  • «
  • 1
  • 2
  • 3
  • 4
  • 7
  • 8
  • »
Архив - только для чтения
Бортовой компьютер на мотоцикл
Сообщение # 11        
[)еНиС
аватар
  Постов: 3074   Друзья 
Цитата Тёмыч ()
чтобы не использовать такие большие переменные, код надо записать так (моё мнение):


Так вот я и хотел избежать такого условия biggrin , мне кажется нужно посчитать сколько времени процессорного занимает условие и сколько времени занимает работа с 3мя строчками но большими переменными. (на глаз примерно одинаково получается)

По поводу деления там нет деления символ "\" это div.

Цитата Тёмыч ()


[)еНиС, по другому никак.


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

Еще такой вопрос, когда таймер начинает заново счет? Сразу же после того как переполнился и поднял флаг или только после того как опустил флаг.
Сообщение # 12        
[)еНиС
аватар
  Постов: 3074   Друзья 
Немного поискал по теме счета импульсов и нашел такую интересную статью может тоже полезно будет, вроде доступно и понятно описано как настроить счетчик импульсов. В моей меге есть такие функции.
Т.к. у меня все таймеры заняты уже (2 из 3), то счет импульсов (для емкостного датчика) предполагаю сделать так.

(1 таймер - алгоритм вывода на дисплей, 2 таймер - асинхронный под часы)

Сбрасываем значение таймера, запускаем таймер, задержка 1мс, тормозим таймер забираем значение. Так по моему намного лучше будет, все будет аппаратно крутиться и не мешать остальным прерываниям, а зная кол-во импульсов и время (пусть даже время будет плавать, сильно не уплывет. я буду усреднять значение, например 100 замеров, усреднил, вывел на индикатор)

Если по внешним прерываниям делать и учитывать частоту этих прерываний (порядка 30кгц) то там реально трэш получится, основной код не сможет нормально работать
Сообщение # 13        
msmmmm
аватар
  Постов: 891   Друзья 
[)еНиС, а если не париться с количеством импульсов, а мерить период wink ? Не нужно ничего постоянно гонять, измерил, посчитал уровень, выдал на индикатор.
Цитата [)еНиС ()
мне кажется нужно посчитать сколько времени процессорного занимает условие и сколько времени занимает работа с 3мя строчками но большими переменными
Посмотри прямо в отладчике AVR Studio. Все давно придумано и считать вручную не нужно.
Цитата [)еНиС ()
там нет деления
В майне есть. И не раз. И умножение лонга - тоже не шустрик.
Цитата [)еНиС ()
когда таймер начинает заново счет?
А он и не останавливается, если сам не остановишь.
Сообщение # 14        
[)еНиС
аватар
  Постов: 3074   Друзья 
Цитата msmmmm ()
Посмотри прямо в отладчике AVR Studio.

А где именно? а то я только МК выбирать, да компилить умею biggrin

Цитата msmmmm ()
а если не париться с количеством импульсов, а мерить период


Неа) в пределах периода частота скорее всего почти не изменится для фиксации. емксотный датчик же будет, в баке штырь изолированный, он выполняет совместно с самим баком роль конденсатора. Уровень топлива меняется (во время езды например, в среднем уровень один будет но во время движения будет очень сильно скакать) емкость меняется.

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

Цитата msmmmm ()
В майне есть. И не раз. И умножение лонга - тоже не шустрик.


А где там деление, покажи)) Я знаю что с лонг оно тратит несколько тактов на обработку, поэтому и написал в поисках лучшего варианта, но пока что мне хватает быстродействия да и на энергопотребление плевать.
Хотя потом подумаю на счет спячки, а так сделать чтоб не опрашивал ничего и не выводил на дисплей при отключенном зажигании и этого хватит, не высосет же аккум 10Ач biggrin

На счет таймера это хорошо, что сам шпарит happy
Сообщение # 15        
msmmmm
аватар
  Постов: 891   Друзья 
Цитата [)еНиС ()
А где именно?
Debug->Run, а если открыта панель Debug, то в ней кликнуть Run.
Цитата [)еНиС ()
пределах периода частота скорее всего почти не изменится для фиксации
Это о чем? Я о том периоде, который T=1/f. Считать любым счетчиком, обрабатывать в майне. Для того, чтобы говорить предметно, нужно знать пределы изменения параметров входного сигнала.
Цитата [)еНиС ()
А где там деление, покажи
А вот:
Цитата [)еНиС ()
HOUR = CLOCK / 3600; // таким образом получаем кол-во часов из секунд
MIN = (CLOCK-(HOUR*3600)) / 60; // тут выделяем из остатка минуты

Цитата [)еНиС ()
с лонг оно тратит несколько тактов на обработку
Очень сомневаюсь, дома посчитаю.
Сообщение # 16        
[)еНиС
аватар
  Постов: 3074   Друзья 
Цитата msmmmm ()
А вот:


Ну так я и говорю это div biggrin biggrin
Целая часть от деления, это не просто деление. Хотя возможно МК div как деление рассматривает, не буду спорить dry

Цитата msmmmm ()
Это о чем? Я о том периоде, который T=1/f. Считать любым счетчиком, обрабатывать в майне. Для того, чтобы говорить предметно, нужно знать пределы изменения параметров входного сигнала.


Ну я понял, о каком периоде. Частотный диапазон пока что сказать не могу, но предполагаю 30-40кГц меандра. Хотя чем выше частота тем лучше, поэтому надо экспериментально.
Не могу грамотно сформулировать, почему не гуд замерять только один период, а не какойто диапазон (1мс например).

В общем попробую, как я понимаю. Учитывая что частота будет не очень сильно меняться, то в пределах одного периода МК сложнее будет без ошибки определить период.
То что было при первом измерении f, при втором уже f+df (df небольшое увеличение частоты, совсем не существенное 20-30Гц к примеру, утрирую) и в силу (возможно) не большой разрешающей способности, МК определит период таким же как в случае f, возможно из-за округления.

Если же считать импульсы в течение 1мс, то даже эти 20-30Гц никуда не денутся из поля зрения МК. Даже если МК определяет с некой погрешностью, то относительно полученного значения при счете импульсов погрешность будет меньше

Например считая импульсы погрешность будет меньше

10 000+- погрешность измерения

Или же при измерении периода

0.0000001 +- погрешность измерения.

Вообще я тут подумал, полностью сделать аппаратно, даже без счета импульсов за 1мс, так возможно даже хватит обойтись переменной типа char.
У меня есть считающий импульсы таймер и прерывание каждую секунду. Запускаем счетчик импульсов, делаем по нему прерывание, где заводим переменную в которой накапливается кол-во прерываний.
Далее часовой таймер, вызывает прерывание каждую секунду. В этом прерывании можно определить сколько раз случилось прерывание счетчика импульсов за одну секунду, здесь же этот накопитель прерываний обнулить, а сами дынные о прерываниях в основную программу передать. biggrin
Сообщение # 17        
msmmmm
аватар
  Постов: 891   Друзья 
Как обещал: входные и выходная переменные long int
c=a+b 12 тактов
c=a-b 16 тактов
c=a*b 59 тактов
c=a/b 624 такта (целочисленное деление ldiv() ) smile
Сообщение # 18        
[)еНиС
аватар
  Постов: 3074   Друзья 
Ну блин biggrin в условиях явно меньше будет. Ладно тогда переделаю под условия

Вот кстати в паинте набросал схему компа на данный момент

Файлы: 9375238.jpg (174.6 Kb)
Сообщение # 19        
msmmmm
аватар
  Постов: 891   Друзья 
По поводу емкостного датчика.
Цитата [)еНиС ()
1 таймер - алгоритм вывода на дисплей
1 - это "один" или "счетчик1"? Это к тому, что переводить на ДИ шестнадцатиразрядный счетчик как-то не по фень-шую. А если он свободен, то считать им импульсы извне между секундными прерываниями. Таймер настроить нужно будет, конечно.
А методика усреднения результатов проста до не могу. Создается массив в котором по кругу последнее значение заменяется измеренным. Количество элементов выбирается из ряда 2, 4, 8, 16, .... 1024 и т.д - сколько оперативки и процессорного времени не жалко. И считаем среднее. Получаем фильтр НЧ. Как сосчитать среднее максимально быстро, думаю, должно быть понятно.
Сообщение # 20        
[)еНиС
аватар
  Постов: 3074   Друзья 
msmmmm, 1 - один biggrin

Если по порядку таймеров то нулевой таймер отвечает за индикацию на дисплее
Первый таймер будет какраз считать импульсы с емкостного датчика
Второй таймер - асинхронный.

Да не, массив по моему слишком, проще просто накапливать прерывания и все, потом делить на кол-во секунд. Можно даже сделать так - 10секунд копим прервания потом делим на 10 и получаем прерывания в секунду в среднем ну или условное значение остатка топлива

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

Тут есть свой плюс- прога быстро с прерывания выйдет, а если условие мутить (если 60 то ++ ... ) то тут приходится все в прерывании делать. А у меня прерываний хватает и не очень хорошо будет если прерывание потеряется biggrin
  • Страница 2 из 8
  • «
  • 1
  • 2
  • 3
  • 4
  • 7
  • 8
  • »
Поиск:

Внимание! Форум переехал на Tehnodium.ru



© 2010-2022 "Форум Радиосхемы". All Rights Reserved  Почта  PDA