FlProg

Как быть в таком случае?

Отправлено спустя 57 секунд:
У меня под этим ID , температура двигателя в 1м байте лежит!

Отправлено спустя 58 секунд:
Но температура то бог с ним! она и раз в секунду отображается норм! Можно её усреднить ко всему прочему!

Отправлено спустя 2 минуты :
А вот обороты и скорость не усреднишь! Они слишком динамичны!
Щас скину видео с чем я борюсь)))
Кстати с оборотами получилось разобраться, а со скоростью никак!
До 30ти км/ч как шёлковая стрелка! а после прыгает как бешеная!

Возьми после сравнения и отправь полученный ID на дисплей - увидишь для начала что там приходит.
Потом измени сравнение со строк на цифры.

[ref=#ff8000]Sancho[/ref], Спасибо!

Отправлено спустя 3 минуты 17 секунд:
Вот видео того что происходит со стрелкой спидометра! Ещё раз напомню что тахо я победил, со скоростью по тому же принципу не выходит! https://youtu.be/14zxm9ACoK0

Отправлено спустя 32 минуты 30 секунд:
У кого какие мысли?

ElectroMechaniC писал(а): 11 май 2018, 10:13 прав! Скорее всего дело в самом преобразовании в строки!

я такого не говорил. речь шла о целесообразности преобразования

[ref=#ff8000]pan[/ref], ок! Согласен! Беру слова назад!

сейчас посетила мысль.
у вас в проекте используются переменные unsigned long. а реально они какого размера? если int , то возможно из за этого мусор

[ref=#ff8000]pan[/ref], не особо большие! Я брал unsigned long. исключительно для того что бы не было отрицательных значений? Сейчас попробую перебить в INT

ElectroMechaniC писал(а): 11 май 2018, 11:16что бы не было отрицательных значений

это определяется типом переменной а не её размером.
http://arduino-diy.com/arduino-tip-dannykh

[ref=#ff8000]pan[/ref], Вот я лошара! Век живи век учись! Сейчас попробую с INT! Спасибо!

[ref]TheDevil[/ref], это для чего? для получения определённых байтов? или для преобразования? Можете подробнее объяснить?

ElectroMechaniC писал(а): 11 май 2018, 09:20первый и второй байты по отдельности в .hex, после чего соединить в одно число .hex, a уже полученое 16е число преобразовать в .dec

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

Отправлено спустя 20 минут 20 секунд:
ради эксперимента можете проверить. пока всё оставить как есть, только соединение двух байт по другому попробовать

[ref=#ff8000]pan[/ref], спасибо! Попробую! Отпишусь! Кстати с int фокус не прокатил! Всё работет конечно, но блин эта еденичка и троечка, будь они не ладны! Единственное понимаю - что облегчил жизнь контроллеру!

Hex - шестнадцатиричная система счисления, только и всего.
0х40 = 64
0xFF = 255
двухбайтный hex:
0x0040 = 64
0x00FF = 255
0xFFFF = 65535 для unsig
Контролеру вообще фиолетово, что сравнивать, он сравнивает побитно!

А по поводу калькулятора, я и сам сидел-переводил! Не выходит аленькай цвятечек! Реальные показания только воо по такому запутанному алгоритму выводить получается!

Отправлено спустя 2 минуты 58 секунд:
Я вот убей не пойму! Плата с оборотами работает распрекрасно! Хотя изначально тоже дёргалась! Пока условий не понавешал! Чем же отличается аналогичное действие со скоростью? Даже пробовал отдельно скорость компилировать без оборотов! Всё равно дёргается!

Отправлено спустя 10 минут 10 секунд:
[ref=#ff8000]Sancho[/ref], вот я и получаю двухбайтное число методом объединения строк, перевожу его в dec. И т.д.
Может байты не полные приходят? Заметил ещё ! Может совпадение:
Когда передача нормальная, без мусора, то и диод rx на уне моргает ровненько, быстренько, практически горит постоянно! Но только скачёк на 1 или на 3 , и диод тоже как будто немного паузу делает, тухнет! Может там delay какой нибудь проскакивает? Иди сдвиг значений? Приходит например пол байта))) я в этом не особо! Так что не умничаю! Что скажете?

[ref]ElectroMechaniC[/ref],
Просто для пробы, для начала.

Отправлено спустя 4 минуты 44 секунды:
352h = 852 dec

ElectroMechaniC писал(а): 11 май 2018, 17:22Когда передача нормальная, без мусора, то и диод rx на уне моргает ровненько, быстренько, практически горит постоянно! Но только скачёк на 1 или на 3 , и диод тоже как будто немного паузу делает, тухнет

так может дело всетаки не в цифрах, а в передаче данных. помеха или отваливается что то.

[ref=#ff8000]pan[/ref], помеха или отваливается что то.
Нет! Я уже сотню раз эту схему проверял! Сначала на проводах, затем платки вытравил, типа шины сделал, упростил везде всё! Пропаял! И у меня когда обрыв в любом месте то данные зависают на пару секунд, а потом прога говорит типа не конект!

Отправлено спустя 1 минуту :
Спецом пробовал кратковременно выключать и быстро включать! Не то всё! Сам голову сломал уже!

А может время чтения посылки из кана не совпадает с её отправкой? Получается читать нечего? Короче таймауты не совпадают...

[ref]Almer[/ref], это наиболее правдоподобный вариант! Вот как забабахать синхронизацию? Сам над этой мыслью колдую! Нужна чёткая привязка по времени и тригер типа байт пришёл-пишем, байт не полный, пропускаем, ждём полного! Там же куча интерфейсов и скоростей задействована! Может где то и не совпадают тайминги!
Есть идеи как это проверить?

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