Спидометр Для Велосипеда

[my504]

Goodefine, я наблюдаю за процессом со стороны, не любитель АВР..., но был, мягко говоря, удивлен рекомендацией использовать capture. Частота импульсов, по моим прикидкам, с энкодера не более 400 гц... при цикле 1 мкс считывание из счетчика практически СТАЦИОНАРНОЕ. А разрядности хватит и 8. Поэтому не потребуется даже контролировать перенос в старший байт... А разрешение выше 1 км/ч бессмысленно, поскольку вызовет лишь мельтешение десятых в дроби. Скорость движения всегда нестабильна, есть проскальзывание шин при ускорениях-разгонах и т.п. Можно вычислить с высокой точностью СРЕДНЮЮ скорость за дистанцию, но мгновенное значение точнее 1 км/ч знать бессмысленно.

А что касается асинхронизма, то, ясен перец, необходимо использовать СИНХРОННЫЙ режим работы таймера. В ПИКах, по крайней мере в асинхронном режиме захват ВООБЩЕ не функционирует...

Изменено 6 февраля, 2009 пользователем my504

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[Goodefine]

...мягко говоря, удивлен рекомендацией использовать capture...

Захват это просто один из способов получить точный результат. Для данной задачи такая точность, возможно, избыточна, но на будущее таймер1 может пригодится...

... Частота импульсов, по моим прикидкам, с энкодера не более 400 гц...

При скорости 100 км/ч, диам. колеса 66см и одном магните получится примерно 13.5 Гц, со скважностью менее 0.5%...

... при цикле 1 мкс...

При цикле чего?

...считывание из счетчика практически СТАЦИОНАРНОЕ...

Что Вы понимаете под термином "СТАЦИОНАРНОЕ"?

... А разрядности хватит и 8...

В предложенном варианте разрядность и так 8... И там не capture...

...Можно вычислить с высокой точностью СРЕДНЮЮ скорость за дистанцию, но мгновенное значение точнее 1 км/ч знать бессмысленно...

Собственно, по этому поводу я писал:

Цитата(Dimon007 @ 5.02.2009 - 12:33) *

...Скорость определяется после каждого прохода магнита мимо датчика (т.е. после полного оборота колеса)...

Данные, во-первых, не успеют выводиться, во-вторых вы ничего не увидите (будет беспорядочное мельтешение). Надо выводить не чаще двух-трех раз в секунду...

...А что касается асинхронизма, то, ясен перец, необходимо использовать СИНХРОННЫЙ режим работы таймера...

Можно использовать и тот, и другой. Только правильно...

...В ПИКах, по крайней мере в асинхронном режиме захват ВООБЩЕ не функционирует...

Это преимущество?

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[my504]

Начну с конца. Асинхронный таймер может быть захвачен только ПОСЛЕ СИНХРОНИЗАЦИИ, иначе невозможно в принципе - начнутся "гонки фронтов". Поэтому абстрактная возможность захватывать в асинхронном режиме - лишь маркетинговая уловка, а не преимущество.

Проблема разрешения возникает не на скорости 100, а на скорости ОДИН километр в час. Необходимо, чтобы за 0,1 оборот колеса пришел хотя бы один импульс, тогда при этой скорости можно обновить показания 4 раза в секунду(так сделано в автомобилях). А чтобы избежать дрожания единиц, достаточно результат выдавать после усреднения последних 4 промеров и округления суммы 4 измерений путем выделения двух мл.разрядов суммы и их анализа, если модуль разницы с предыдущим результатом не менее b'11' (соответствует 0,75 км/ч), то происходит округление вверх с учетом знака. Иначе, при УВЕЛИЧЕНИИ граница округления вверх = 0,75, а при УМЕНЬШЕНИИ - 0,25 и вниз. При этом шкала становится "резиновой" с гистерезисом и нет мельтешения соседних значений.

Цикл - 1 мкс - это ессно МАШИННЫЙ ЦИКЛ.

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

СТАЦИОНАРНОЕ - на фоне неизменного контекста (в данном случае состояние счетчика неизменно).

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Goodefine]

Для меги8515 (у автора) ни один из таймеров не может работать в асинхронном режиме (от отдельного генератора). В остальных такая возможность есть. Но захват в асинхронном режиме в мегах не работает также.

Я не совсем понял, что речь идет именно об асинхронности ТАЙМЕРА (я подразумевал асинхронность СОБЫТИЯ, приводящего к прерыванию и приращения счетчика).

Теперь о захвате (синхронном ) таймера. Я не знаю способа точнее измерить время между фронтами мегой, чем с применением данного режима. Достижимая точность +/-1 такт процессора. В этой задаче так избыточно, но лучше один раз нормально написать код и использовать в любых измерениях, чем мерять не пойми как...

По поводу разрешения и отображения. Я с Вами в этом согласен, о чем и писал выше:

Меряет нормально от 0.6 м/с (это ограничено длиной окружности колеса и временем обновления дисплея

Как усреднять показания и "обрезинивать" шкалу есть много способов.

СТАЦИОНАРНОЕ - на фоне неизменного контекста (в данном случае состояние счетчика неизменно).

Т.е. можно перефразировать так:

Частота импульсов, по моим прикидкам, с энкодера не более 400 гц... при тактовой частоте 1 мгц показания счетчика (таймера?) практически НЕИЗМЕННЫЕ.

Теперь еще больше непонятно... Счетчик можно и не считывать? Ведь значения постоянные (то бишь стационарные)...

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

Да не за что, я никогда не против конструктивной критики . ИМХО, лучше хорошо измерять, чем плохо, независимо от индикации...

Изменено 6 февраля, 2009 пользователем Goodefine

[my504]

Ну вот и сошлись во мнениях :-)

А по поводу стационарности, то имеется ввиду, что с точки зрения обработчика прерывания (задержки порядка десятка циклов), события инкрементирующие счетчик НЕИЗМЕННЫ. Вот если события соизмеримы в периоде повторения с латентностью прерывания, то среда измерения для обработчика изменчива и есть вероятность временных ошибок.

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

Я бы скажем для подобной задачи скорее выбрал МК с контроллером LCD и поставил крупный двухразрядный дисплей, а не чисто приборный цифробуквенный со встроенным контроллером, который дороже собственно самого девайса.

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

[Goodefine]

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

В целом, конечно, согласен... Но, скажем, у меня (в нашей местности) иногда возникают подобного рода проблемы. С одной стороны, выбор элементной базы ограничен, порой выбирать просто не из чего, особенно в плане дисплеев. С МК чуть попроще - выбор есть. Но если тини2313 стоит 2.3$, а мега8 около 2.7$ (мк у нас дорогие -спрос небольшой). Что я выберу? Конечно мегу. Даже если она для задачи десятикратно избыточная будет. Ведь за тиньку придется уже просто переплачивать. Взять ее может и эстетично, но просто невыгодно.

Другое дело, когда цены адекватные...

[Dimon007]

Насчёт МК - первый раз работаю, взял этот, потому что в нем есть неплохой потенциал для дальнейших разработок, я же не серийный девайс делаю) Насчёт Lcd, брал специально такой, по тем же причинам + хочу выводить сразу несколько параметров (в случае с нынешним устройством).

[akl]

Здравствуйте. Может наведет на какие-то мысли следующий алгоритм, позволяющий без применения "плавучки" быстро получить результат.

V=S/T

S[m]=L*Nx,

где L[m]-длина окружности колеса, Nx-целое число оборотов колеса за время измерения

T=to*nox=Fo/nox,

где to-период частоты тактирования Fo, nox-число периодов частоты тактирования за время прохождения Nx.

V[м/сек]=Fo*L*Nx/nox или

10*V[км/час]=36*Fo*L*Nx/nox.

Зная, что Fo=1'000'000 Hz; L=2.07345м, Nx=1 вводим константу= 74'644'241 и выражение получается простое 10*V[км/час]=74'644'241/nox.

Например:

Измеряется скорость 28.76км/час

Колесо при какой скорости совершит один оборот за 28.76[км/час]/3.6=7.9(8)[м/сек]-> 7.9(8)[м/сек]/2.07345[м]=3.85xxx[1/сек] или 0.259541сек->nox=259541

10*V=74'644'241/259541=287.6

V=28.8 км/час

Если применить входную цепь согласно рисунка, можно переводить спидометр в спящий режим при отсутствии сигнала после ~10 секунд. Выходом из "спячки" будет получение первого спада сигнала датчика.

[my504]

Насчёт МК - первый раз работаю, взял этот, потому что в нем есть неплохой потенциал для дальнейших разработок, я же не серийный девайс делаю) Насчёт Lcd, брал специально такой, по тем же причинам + хочу выводить сразу несколько параметров (в случае с нынешним устройством).

Немного разверну свою мысль.

Спидометр ессно приводит нас к целесообразности встроить в него функцию относительного одометра, причем на пару шкал. Например, что бы отмерять общий путь и засекать некоторый промежуточный интервал. Можно еще просчитать среднюю скорость за некоторое расстояние (например за измеренное этими двумя шкалами одометра.

Но все эти функции легко перекрываются двумя разноразрядными шкалами. Основной - спидометра - 2 крупных разряда (вполне достаточно семисегментного) и для одометра разряда на четыре...пять одна помельче - вспомогательная. Можно конечно все вместить в используемый Вами - это попроще в программной реализации, но результат будет посредственный - использовать однородный строчный дисплей на велосипеде в реальной обстановке неудобно. Любой транспорт требует смотреть за дорогой, а не всматриваться в приборы, пытаясь разгледеть, где путь, а где скорость... ЭРГОНОМИКА, однако...

все это и наводит на мысль использовать МК с встроенным контроллером ЖКИ. Причем эти контроллеры имеют мультиплексированные общие сегменты, что очень удобно и просто реализует описанный выше двухшкальный дисплей из двух дешевых ЖКИ.Можно даже от старого калькулятора.

По поводу перспективного МК.

В этом и состоит порочная, на мой взгляд, практика всюду совать один и тот же камень... к месту и не к месту... Их вообще то даже у Атмела не меряно..., причем ядро общее и доп. изучения матчасти практически не требует...