Про датчик скорости, но не совсем.

[B.Mike]

Валентиныч дело говорит! Обновляй экран по каждому импульсу как сейчас, но помни последние штук 8 измерений, и каждый раз перед выводом, их суммируй и дели результат на 8. Это не массив, это простой стэк получается.
Но таймер сброса в ноль паходу нужен всёравно. Да собссно он и сейчас получается нужен, если ты тактируешься входными импульсами, которых может и не быть

[valentinych]

Я пока не умею в массивы

Ну можно и так (ассемблер): Если "0", то значение Х суммой в ячейку счёта, если "не 0", то Х суммой в ячейку счёта и сдвиг (т. е. делёжка впополам). Таким образом каждое предыдущее значение будет иметь как бы интегрированную память всех прошлых измерений. Оно и здесь вижу нюансы, но засорять пока не хочу. Только суть.
А вообще здесь и твой метод подойдёт, но вот -

Чаще 10 (да и на 10 бывает) какая-то дичь с контроллером начинается, подвисает функция измерений при резком изменении скорости. Просто встаёт на каком-то измерении и дальше не меняется. Мозгов не хватает, что ли.

Ну видимо не "мозгов", а может с быстродействием нехватка?
И как происходит измерение, по прерыванию от датчика?
Может контроллер не может вылезти из прерывания при наложении его же или запомнил требование, вылез и опять летит в туда, а обрабатывать некогда? Вот и создаётся впечатление, что висим? Короче считать(хоть прикинуть) надо по мах. операциям в сек. контроллера, частоте прерываний и кол-ву операций в цикле. А желательно, что бы контроллер обгонял на порядок требования от него по быстроте.
Ещё глянуть на меандр импульсов и смотреть чего хочет контроллер, может чего-то там?

До 10 км/ч выдаётся напрямую с датчика Smile

Может это и правильно, но я бы чуток усреднял. Но дальше датчик ведь лупит эти импульсы как "из пулемёта". Там вроде 6 или 10 на 1 метр? Этож обалдеть. И я бы вообще счет вёл по количеству имп. (простой счёт по прерыванию - положил +1 и вышел) за период времени (взял значение и обнулил или усреднил счётчик имп. и обнулил/перезапустил счётчик времени), и никакой обработки, и ничего "заглушать" не надо. Имп. "0" - скорость "0". А дальше (после 10 км.), если контроллер ещё чем-то занят, то я ещё бы на другой вход (или этот же, если контроллер такое может) подал через делитель на 10 и вел бы счёт уже по этому входу.
И вообще вариантов реализации логики программы больше, чем до фига.

[B.Mike]

И я бы вообще счет вёл по количеству имп

Это медленнее, чем у него сейчас. Хотя мне твоё решение тоже первым в голову пришло

простой счёт по прерыванию - положил +1 и вышел

Тада не надо ващще прерывание использовать. Аппаратный счётчик подключить и всё. А прерывание только по его переполнению, что бы не терять насчитанное если чё. Оно бы тада ващще ресурсов не требовало.
Аппаратный счётчик + аппаратный таймер. А от проца требуется только иногда сверять одно с другим. Красота!

[Sync ТС]

И как происходит измерение, по прерыванию от датчика?

При поступлении импульса запускается таймер, при следующем импульсе прошедшее с запуска время отправляется в дальнейший путь, а таймер снова встаёт на ноль и запускается. Тут подумал - можно время не до ближайшего импульса считать, а за сумму, всё проще контроллеру.

что бы контроллер обгонял на порядок требования от него по быстроте.

На 150 км/ч частота импульсов от датчика около 250 Гц кажется. Тактовая частота контроллера - 16 Мгц. Куда уж больше.

Я уже думаю тупо по импульсам в единицу времени считать. Откуда то идут сбои время от времени, скорость принимает какие-то совсем неадекватные значения (пару раз видел даже отрицательные, как это он смог, учитывая, что время естественно не может принимать отрицательных значений - загадка). Последовательности в возникновении не замечено. Возможно у контроллера аппаратные проблемы уже, у него и так 2 ноги не отвечают на внешние раздражители, а сегодня заметил, что индикатор активности UART ведёт себя ненормально, хотя сам UART работает как надо.

И вообще вариантов реализации логики программы больше, чем до фига. Smile

Это точно

[Sync ТС]

Пока всё выглядит как-то так в железе

[Sync ТС]

Ура! Заработало как надо. Спасибо за советы, скрестил ежа с ужом. Считает он скорость всё так же по времени между импульсами, но сделал таймер на 100 мс за которые он суммирует скорость и импульсы. По срабатыванию счётчика делит одно на другое, получает усредненное значение и запускается заново. Идея заменить счётчик импульсов таймером действительно здравая. Как показала практика такого усреднения вполне достаточно. Ноль получается таймером-заглушкой. И все программные таймеры заменил одной функцией, только время срабатывания разное в каждом месте.

Теперь вопрос ещё родился, на границе 2 значений скорость прыгает туда-сюда. Как это по человечески исправить? Это вроде PID называется, но ещё не делал такого.
Я понимаю, что оптимально было бы, чтоб с 20 км/ч переключалось бы не на скажем 21 км/ч, а на 21,2, а обратно возвращалось на 20,8, т.е. как бы расширялся диапазон текущей скорости. Но десятые доли км/ч считать что-то не очень хочется. Это придётся ещё и переменные гонять из float в int, либо кратности править. Вижу как один из способов решения, что если одно и то же значение скорости пришло 2 (или 3) и более цикла подряд, то для его изменения надо, чтоб значения отличные от него тоже пришли больше 2 (3) циклов подряд. Это вроде как должно устранить большую часть дребезга. С другой стороны у меня сейчас есть 2 скорости, усредненная и которую датчик шпарит напрямую. Между ними есть запаздывание в 100 мс, возможно как-то можно это использовать. В общем я в раздумьях.

[valentinych]

Тада не надо ващще прерывание использовать. Аппаратный счётчик подключить и всё.

Решение сильно зависит от применяемого контроллера и его возможностей.

Цитата: valentinych от Сегодня в 01:47:08
"И я бы вообще счет вёл по количеству имп"
Это медленнее, чем у него сейчас. Хотя мне твоё решение тоже первым в голову пришло Smile

Мне тоже понравилось решение ТСа, но по "школьному", в лоб - тоже ничего. Оно медленнее, но посчитаем абсолютное время: предположим датчик 10 имп/метр, для простоты подсчёта берём 100км/час, т. е. 1000000 имп. / 3600 сек. Вот и получается, что интервал времени подсчёта 0,36 сек. (Хотя при 6 имппульсном датчике - 0,6 сек.) Вполне кошерно и перед глазами не мельтешит, и простой счётчик за заданный таймером период времени.

При поступлении импульса запускается таймер, при следующем импульсе прошедшее с запуска время отправляется в дальнейший путь, а таймер снова встаёт на ноль и запускается.

И хто "караулит" и обрабатывает приход импульса? Или ты чего, программно ждёшь этого импульса

Пока всё выглядит как-то так в железе

Вполне прилично, потом оденешь в "костюмчик".

Теперь вопрос ещё родился, на границе 2 значений скорость прыгает туда-сюда

Ведь у тебя, не заботясь об сём, всегда есть (как минимум) два значения параметра, Это которое горит на индикаторе и новое, готовое к показу.  Изменённое на 1-цу перед показом, при двоичном усреднении с предыдущим показанием (+ и сдвигом вправо), полученные "пол единицы" отбрасывается. Это не замедляет цикл и не требует помнить ещё несколько предыдущих измерений. И у тебя всегда должен быть некий "гистерезис", т. е. изменение в 1-цу никак не может привести к мигалке. Видимо ты как-то усредняешь по другому или "болтанка" при измерении выше.

[B.Mike]

вопрос ещё родился, на границе 2 значений скорость прыгает туда-сюда. Как это по человечески исправить?

Если я правильно понял, биение частот возникает между 100мС таймером и входным сигналом. ИМХО перемудрил ты с алгоритмом усреднённых измерений

[Sync ТС]

Хотя при 6 имппульсном датчике

Датчик тазовый, 6 импульсов на метр

При подсчёте через импульсы в секунду слишком медленно считается на малых скоростях. Комфортное время смены скоростей на спидометре - 100 мс, реже уже как тормоза воспринимается. Это прям самый край, 50 мс выглядит намного приятнее. Мерить реже этого числа смысла не вижу, так как цикл обновления экрана не должен быть меньше цикла обновления переменной. Минимальная скорость 1 км/ч, 0,27 м/с. Это и так всего 1 полный импульс в секунду, т.е. даже в моём случае нормальный подсчёт начинается км с 10 в час. Кстати по этой же причине до 10 км/ч идёт без усреднения, там усреднять нечего и так слишком тормозно.

И хто "караулит" и обрабатывает приход импульса? Или ты чего, программно ждёшь этого импульса puzzled

У контроллера есть 2 спецвхода для обработки внешних прерываний не связанные с программными таймерами. Как раз чтоб как раз не пропустить сигнал и при этом не пускать на это все ресурсы контроллера. При событии на них вызывается кусок кода. Они то у меня и являются спидометром и тахометром. Но до тахометра я пока не дошёл

при двоичном усреднении с предыдущим показанием

Э... Нет у меня усреднения с предыдущим показанием. Только по текущему циклу. Так что и "гистерезиса" нет. Пока всё же написал с float (переключение на следующую скорость происходит только при превышении или понижении текущей скорости на 1,5 (может потом и уменьшу до 1,2 скажем, тут надо смотреть по месту) км/ч, а не на 1.

Но вариант с прибавлением предыдущей скорости и "ручным" увеличением счётчика усреднения на 1 мне нравится. Я бы даже сказал нравится куда больше. Единственное, что с ростом скорости это будет всё менее и менее заметно. Но там и болтанки меньше.

[valentinych]

Датчик тазовый, 6 импульсов на метр
При подсчёте через импульсы в секунду слишком медленно считается на малых скоростях.

Ты просто зациклился на своём методе (против метода ничего не имею), вот и не можешь от него отойти.
При подсчёте через импульсы - время измерения (и если хочешь, то и смена показаний) при ЛЮБОЙ скорости (при твоём датчике 6 имп.) ВСЕГДА 0,6 сек. При скорости 1 км/час ты просто получишь один импульс за это время. Можно сократить время вдвое, но шаг показаний тогда будет 2 км/час.

переключение на следующую скорость происходит только при превышении или понижении текущей скорости на 1,5 (может потом и уменьшу до 1,2 скажем, тут надо смотреть по месту) км/ч, а не на 1.

Перемудрил с алгоритмом однозначно. Да то же самое получишь усреднением "на лету" всего двумя командами не заморачиваясь анализом.

У контроллера есть 2 спецвхода для обработки внешних прерываний не связанные с программными таймерами. Как раз чтоб как раз не пропустить сигнал и при этом не пускать на это все ресурсы контроллера. При событии на них вызывается кусок кода.

Прерывание - ты меня успокоил, а то я про "нехорошее" подумал.
Кол-во и качество входов умеющих "ловить" события зависит от типа контроллера. И слава богу, что они в твоём случае есть.
Таймер везде самостоятельная часть и "привязывается" к чему-либо только по воле программера.
"Кусок кода" это есть программная обработка прерывания.
Всё у тебя получиться и так, но путём усложнения программы (благо задачи совсем не велики, а тактовая у проца хорошая). И я понял, что ты хочешь чаще считывать и менять показания.
Выбор варианта логики процесса и алгоритма подсчёта всегда за тобой и это не обсуждается. Но хочется что бы ты пришёл к этому чётко представляя и другие варианты подхода к решению поставленной задачи.
Сорри, дальше просто сильно упрощённое пояснение к тому, чего имел в виду я (про одну из задач):
Проц пашет и вертится в кольце показа параметра (допустим, что в зависимости от приказа кнопи чего и как казать). При входе в кольцо запускается таймер и по истечении времени (или по прерыванию, или по выставленному признаку - идём на подпрограмму) считывается ячейка счёта, сколько пришло имп. пути и в "лоб", т. е. прям чего есть, кладётся (с усреднением с предыдущим показанием) в яч. показа, сброс/запуск таймера, обнуление яч. счёта, возврат. (Т. е, мин. обработки).
По прерыванию от имп. датчика пути летим на его обработку, где : просто +1 в яч. счёта имп. Всё! Возврат из прерывания.
В яч. счёта по срабатыванию таймера всегда РЕАЛЬНОЕ число для показа.
Как ты заботишься о представлении параметра в десятичном виде, это тоже вопрос вкуса.
Я вообще за минимализм программного кода и даже после написания программы - обоими руками за оптимизацию алгоритма.
Удачи в проекте.

[Sync ТС]

В общем я допилил сегодня это чудо. Сделал и по совету Валентиныча, т.е. включил в округление предыдущее значение скорости (это прям реально намного проще), и своё с расширением диапазона текущего значения (оно просто было уже готово). Всё работает замечательно. Ну а что, раз ресурсы позволяют, чё бы не использовать оба метода? ) Как мне сказали, правда с иронией, процессор железный - пусть считает.
Теперь небольшое вылизывание кода. И слесарные работы на машине. Спидометр с приборкой-то это только промежуточный итог )
Кстати обошёлся без float, просто умножаю на 10 в начале и делю перед выводом. Контроллеру это делать проще, чем дробные тягать.

[valentinych]

В общем я допилил сегодня это чудо. ... Всё работает замечательно.

Ну и прекрасно!

Спидометр с приборкой-то это только промежуточный итог )

Ну дык ждёмс, чего ещё буит? Интересно.

Кстати обошёлся без float

Ну и правильно, в каждом из случаев можно гораздо проще. Чесслово я и не знал, что кто-то вот так про новомодное.
Просто хотел чё-нить написать, а у мну такой вот браузЁр - как увидит какое слово, так сразу внизу услужливо ссылочку. Сначала раздражало, а потом привык и даже пользую иногда.
https://embedderslife.wordpress.com/2012/12/14/no-float/
Сам думаю так же.