|
Бортовой компьютер на мотоцикл
| |
| Вс, 19.02.2017, 21:44 | Сообщение # 11
|
[)еНиС
Постов: 3074
Друзья |
Цитата Тёмыч ( ) чтобы не использовать такие большие переменные, код надо записать так (моё мнение):
Так вот я и хотел избежать такого условия , мне кажется нужно посчитать сколько времени процессорного занимает условие и сколько времени занимает работа с 3мя строчками но большими переменными. (на глаз примерно одинаково получается)
По поводу деления там нет деления символ "\" это div.
Цитата Тёмыч ( )
[)еНиС, по другому никак.
Допустим, но тогда все будет коректно работать (понятно что не стабильно будут выдерживаться паузы т.к. частота может плавать внутреннего гена)? И надо ли как-то ноги под кварц настраивать? Про это вроде не написано но так, на всякий случай
Еще такой вопрос, когда таймер начинает заново счет? Сразу же после того как переполнился и поднял флаг или только после того как опустил флаг.
|
|
| Вс, 19.02.2017, 22:25 | Сообщение # 12
|
[)еНиС
Постов: 3074
Друзья |
Немного поискал по теме счета импульсов и нашел такую интересную статью может тоже полезно будет, вроде доступно и понятно описано как настроить счетчик импульсов. В моей меге есть такие функции. Т.к. у меня все таймеры заняты уже (2 из 3), то счет импульсов (для емкостного датчика) предполагаю сделать так.
(1 таймер - алгоритм вывода на дисплей, 2 таймер - асинхронный под часы)
Сбрасываем значение таймера, запускаем таймер, задержка 1мс, тормозим таймер забираем значение. Так по моему намного лучше будет, все будет аппаратно крутиться и не мешать остальным прерываниям, а зная кол-во импульсов и время (пусть даже время будет плавать, сильно не уплывет. я буду усреднять значение, например 100 замеров, усреднил, вывел на индикатор)
Если по внешним прерываниям делать и учитывать частоту этих прерываний (порядка 30кгц) то там реально трэш получится, основной код не сможет нормально работать
|
|
| Вс, 19.02.2017, 22:52 | Сообщение # 13
|
msmmmm
Постов: 891
Друзья |
[)еНиС, а если не париться с количеством импульсов, а мерить период ? Не нужно ничего постоянно гонять, измерил, посчитал уровень, выдал на индикатор. Цитата [)еНиС ( ) мне кажется нужно посчитать сколько времени процессорного занимает условие и сколько времени занимает работа с 3мя строчками но большими переменными Посмотри прямо в отладчике AVR Studio. Все давно придумано и считать вручную не нужно.
Цитата [)еНиС ( ) там нет деления В майне есть. И не раз. И умножение лонга - тоже не шустрик.
Цитата [)еНиС ( ) когда таймер начинает заново счет? А он и не останавливается, если сам не остановишь.
|
|
| Пн, 20.02.2017, 05:21 | Сообщение # 14
|
[)еНиС
Постов: 3074
Друзья |
Цитата msmmmm ( ) Посмотри прямо в отладчике AVR Studio. А где именно? а то я только МК выбирать, да компилить умею
Цитата msmmmm ( ) а если не париться с количеством импульсов, а мерить период
Неа) в пределах периода частота скорее всего почти не изменится для фиксации. емксотный датчик же будет, в баке штырь изолированный, он выполняет совместно с самим баком роль конденсатора. Уровень топлива меняется (во время езды например, в среднем уровень один будет но во время движения будет очень сильно скакать) емкость меняется.
Конденсатор будет стоять в задающей RC цепочке генератора, отсюда следует что частота генератора будет плавать. Если замерять только пару импульсов - будет оочень большая погрешность, она итак огромной окажется даже с замером нескольких тысяч импульсов, но так она чуточку меньше будет, к тому же если аппаратно сделать, то даже основной код встревать не будет почти
Цитата msmmmm ( ) В майне есть. И не раз. И умножение лонга - тоже не шустрик.
А где там деление, покажи)) Я знаю что с лонг оно тратит несколько тактов на обработку, поэтому и написал в поисках лучшего варианта, но пока что мне хватает быстродействия да и на энергопотребление плевать. Хотя потом подумаю на счет спячки, а так сделать чтоб не опрашивал ничего и не выводил на дисплей при отключенном зажигании и этого хватит, не высосет же аккум 10Ач
На счет таймера это хорошо, что сам шпарит
|
|
| Пн, 20.02.2017, 09:16 | Сообщение # 15
|
msmmmm
Постов: 891
Друзья |
Цитата [)еНиС ( ) А где именно? Debug->Run, а если открыта панель Debug, то в ней кликнуть Run.
Цитата [)еНиС ( ) пределах периода частота скорее всего почти не изменится для фиксации Это о чем? Я о том периоде, который T=1/f. Считать любым счетчиком, обрабатывать в майне. Для того, чтобы говорить предметно, нужно знать пределы изменения параметров входного сигнала.
Цитата [)еНиС ( ) А где там деление, покажи А вот:Цитата [)еНиС ( ) HOUR = CLOCK / 3600; // таким образом получаем кол-во часов из секунд MIN = (CLOCK-(HOUR*3600)) / 60; // тут выделяем из остатка минуты
Цитата [)еНиС ( ) с лонг оно тратит несколько тактов на обработку Очень сомневаюсь, дома посчитаю.
|
|
| Пн, 20.02.2017, 12:07 | Сообщение # 16
|
[)еНиС
Постов: 3074
Друзья |
Цитата msmmmm ( ) А вот:
Ну так я и говорю это 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. У меня есть считающий импульсы таймер и прерывание каждую секунду. Запускаем счетчик импульсов, делаем по нему прерывание, где заводим переменную в которой накапливается кол-во прерываний. Далее часовой таймер, вызывает прерывание каждую секунду. В этом прерывании можно определить сколько раз случилось прерывание счетчика импульсов за одну секунду, здесь же этот накопитель прерываний обнулить, а сами дынные о прерываниях в основную программу передать.
|
|
| Пн, 20.02.2017, 15:07 | Сообщение # 17
|
msmmmm
Постов: 891
Друзья |
Как обещал: входные и выходная переменные long int c=a+b 12 тактов c=a-b 16 тактов c=a*b 59 тактов c=a/b 624 такта (целочисленное деление ldiv() )
|
| |
| Пн, 20.02.2017, 22:42 | Сообщение # 19
|
msmmmm
Постов: 891
Друзья |
По поводу емкостного датчика. Цитата [)еНиС ( ) 1 таймер - алгоритм вывода на дисплей 1 - это "один" или "счетчик1"? Это к тому, что переводить на ДИ шестнадцатиразрядный счетчик как-то не по фень-шую. А если он свободен, то считать им импульсы извне между секундными прерываниями. Таймер настроить нужно будет, конечно. А методика усреднения результатов проста до не могу. Создается массив в котором по кругу последнее значение заменяется измеренным. Количество элементов выбирается из ряда 2, 4, 8, 16, .... 1024 и т.д - сколько оперативки и процессорного времени не жалко. И считаем среднее. Получаем фильтр НЧ. Как сосчитать среднее максимально быстро, думаю, должно быть понятно.
|
|
| Вт, 21.02.2017, 19:08 | Сообщение # 20
|
[)еНиС
Постов: 3074
Друзья |
msmmmm, 1 - один
Если по порядку таймеров то нулевой таймер отвечает за индикацию на дисплее Первый таймер будет какраз считать импульсы с емкостного датчика Второй таймер - асинхронный.
Да не, массив по моему слишком, проще просто накапливать прерывания и все, потом делить на кол-во секунд. Можно даже сделать так - 10секунд копим прервания потом делим на 10 и получаем прерывания в секунду в среднем ну или условное значение остатка топлива
Кстати на счет часов я подумал, поговорил на работе, сказали что тот вариант где я тупо считал секунды более грамотный хоть и работа с long int происходит. Да и у меня часы не всегда будут на дисплее. Часы высчитываются только когда я их вывожу на дисплей в основном цикле, если не вывожу - то ничего не считается и не раскладывается. Только секунды в прерывании.
Тут есть свой плюс- прога быстро с прерывания выйдет, а если условие мутить (если 60 то ++ ... ) то тут приходится все в прерывании делать. А у меня прерываний хватает и не очень хорошо будет если прерывание потеряется
|
|
Внимание! Форум переехал на Tehnodium.ru
|
|