Создание прошивки/платы дисплейного модуля Kugoo S2/S3/F3/Aovo.

[inetchik]

Конечно можно без "триподы".
Но, т.к. это основной дисплей у меня, то хотелось бы ещё и температуру критическую мотор-колеса видеть и слышать бипер автоматически, и когда она зашкаливать начнет за 80-99°C, то уже не до Тока будет, пущай температура моргает и бипер бипкает. Ну, а когда температура обмоток ниже критической отметки, то можно и уличную Т чередовать с Током автоматически.

Второй и последний дисплей у меня - эт Ач аккума оставшиеся.
Вот в него бы и сделать чередование оставшихся Ач (естественно с надписью Ah) и  Trip, конечно с Км и Км/ч на время отображения пробега и времени заезда. И чтоб, через секунды три-четыре, второй дисплей сам вернулся в первый мой основной, а не кнопочкой его переключать.

Справится камушег ?

[Sonar]

[user]inetchik[/user], первое уже сделано. В меню можно выставить критическую температуру, после которой начинает пищать бипер и вместо трипа отображается какая температура вышла за пределы.
Чередование тока и температуры тоже реализовано в настройках меню.

По второму, думаю, будет отдельный пункт меню "номер экрана при нулевой скорости".

[inetchik]

Спойлер

Спойлер

Спойлер

[13_chip_13]

Если интересно, я вообще на esp32 думаю себе замутить пульт (софт более менее для старта написал, теперь как лень переборю платку сделать хочу), заместо дисплея смартофон через вафлю (если пойдёт, то можно и дисплей поставить) и т.п. https://electrotransport.ru/index.php?topic=61156.90

[Angor11]

Никто не знает, для чего разьёмы CN7, CN8 на желтой плате  дисплея?

[13_chip_13]

Вопрос по алгоритмам (тем кто писал прошивку именно): с контроллера мотора приходит период вращения колеса, как посчитать скорость понятно, а как рассчитывать пройденный путь от этой величины? С ходу придумал типо такого: за сколько то секунд (скажем 2,4,8 и т.п. чтобы легче считалось) считаем средний период вращения колеса, потом считаем сколько оборотов (т.е. длин окружности -> пройденный путь) сделало колесо за время выборки среднего значения периода (те же 2,4,8 и т.п.) согласно этому среднему значению.  Но чё-то как то с точностью не знаю как тут, может делали по другому как то? Пересчитывать скорость в путь показалось будет с большой погрешностью.

Еще одну очевидную, но забавную штуку обнаружил про описание посылок по UART для восьми битной передачи и CRC по методу "исключающее ИЛИ" (может и другие варианты, но меня только этот пока интересует). Старт кадра всегда должен начинать с последовательности как минимум 2 байт, потому что если старт начинается только с одного байта и в посылке появляется еще такой же байт (но он не стартовый, а просто так звёзды сошлись что какая то величина стала равна столько же), то на принимающей стороне можно неправильно принять посылку приняв за стартовый не то и CRC при этом сойдётся как надо. Конечно если передача без сбоев, то такого не будет, но мало ли. А обнаружил как всегда случайно (имитировал обрывы по линии данных, чтобы данные подхватывало в любой момент), казалось бы очевидную вещь.

Еще на схеме дисплея 2R2 это не шунт, это варистор или термистор у него защитная функция скорее всего. Что то вроде - при увеличении нагрузки больше какого то значения он будет увеличивать сопротивление, подобная фигня в TF-100 курках стоит.

[Sonar]

то на принимающей стороне можно неправильно принять посылку приняв за стартовый не то и CRC при этом сойдётся как надо

Как это CRC то сойдется? Если случайно за стартовый байт принимается другой, то в конце предполагаемой длины пакета окажется не байт CRC, а другой. Естественно в этом случае ничего не сойдется и пакет надо проигнорировать.
Добавлено 20 Окт. 2020 в 15:19

как рассчитывать пройденный путь от этой величины

Скорость делим на количество секунд в часе (3600) = пройденный путь за секунду. Далее то, что получается просто накапливаем в переменной ровно раз в секунду - это и будет TRIP.

[13_chip_13]

Как это CRC то сойдется? Если случайно за стартовый байт принимается другой, то в конце предполагаемой длины пакета окажется не байт CRC, а другой. Естественно в этом случае ничего не сойдется и пакет надо проигнорировать.
Добавлено 20 Окт 2020 в 15:19Скорость делим на количество секунд в часе (3600) = пройденный путь за секунду. Далее то, что получается просто накапливаем в переменной ровно раз в секунду - это и будет TRIP.

Про расчёт пути: я наоборот от такого думал погрешность будет, если через скорость посчитать, но раз работает, тогда хорошо.
Про CRC (простой кадр, у вас с первой страницы немного с "правильными байтами"), для наглядности две посылки подряд:

Код Выделить Развернуть


28 - старт протокола (опознавательные данные для дисплея);
00
00
01
28
0B
B8
B2 - CRC8
28 - старт протокола (опознавательные данные для дисплея);
00
00
01
28
0B
B8
B2 - CRC8

А теперь посчитайте CRC8 по XOR, если за старт принять другой байт значение которого 28 (сбой приёма, космические лучи и т.п.), то CRC равно 1 (перед стартовым байтом), ну это ж очевидно, одного стартового байта для надёжной передачи мало, в принципе это вытекает из условия что CRC^CRC = 0 и у вас если только по 8 байт то всегда CRC будет сходиться. В авто диагностике старой (K-LINE которая), на этот счёт механизм колизий придумали (что то типо - дополнять спецсимволами передачу при возникновении битов как и стартовые).

[Sonar]

[user]13_chip_13[/user],
28 00 00 01 28 0B B8 = B2
28 0B B8 B2 28 00 00 = 01
У меня не сошлось
Добавлено 20 Окт. 2020 в 16:34

ро расчёт пути: я наоборот от такого думал погрешность будет, если через скорость посчитать, но раз работает, тогда хорошо.

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

[13_chip_13]

[user]13_chip_13[/user],
28 00 00 01 28 0B B8 = B2
28 0B B8 B2 28 00 00 = 01
У меня не сошлось

, сошлось вообще то, внимательно посмотрите что написали.
В первой посылке CRC равно B2, а во второй 01. Так что не сошлось? (и в первом и во втором случае целостность посылки проверенная по CRC, но во втором случае хоть посылка и правильная вроде бы по критерию CRC, т.е. "небитая", но и в тоже неправильна с точки зрения переданных данных). Такая фигня будет и если старт принимать по нескольким байтам, но в этом случае можно не допускать повтора такой последовательности в кадре на стороне передатчика.

[Sonar]

Так что не сошлось?

А, ну да. Ну... Не ракетой же управляем Подумаешь чуток глюканёт.

[vlad-2015]

а как рассчитывать пройденный путь от этой величины?

Если тупо, то:
R_TRIP_T+=(DIAMETER*422)/RX_TIME; // пройдено сантиметров на пакет для S2
R_TRIP_T+=(DIAMETER*161)/RX_TIME; // пройдено сантиметров на пакет для S3
SPEED=(DIAMETER*29)/RX_TIME; // соответственно км/ч
Но есть еще проще решение... 

[13_chip_13]

Если тупо, то:
R_TRIP_T+=(DIAMETER*422)/RX_TIME; // пройдено сантиметров на пакет для S2
R_TRIP_T+=(DIAMETER*161)/RX_TIME; // пройдено сантиметров на пакет для S3
SPEED=(DIAMETER*29)/RX_TIME; // соответственно км/ч
Но есть еще проще решение... 

В формулах нету привязки к частоте вращения колеса, если она каким то магическим образом не сидит в RX_TIME конечно.

[vlad-2015]

[user]13_chip_13[/user],
#define RX_TIME   *(uint16_t*)(RX_data+5)
RX_data сам пакет от контроллера МК, но можно и сложным путем 

[inetchik]

Что внутри дисплея.

F1

Спойлер

1812  0.2A 30V PTC Resettable Fuse.

[inetchik]

Кошмар, 42 на жёлтой:

Сколько их видов то всего, пока что ?

[Sonar]

[user]inetchik[/user], конкретно для куги я насчитал 3 варианта: https://electrotransport.ru/index.php?topic=55186.msg1887576#msg1887576
Есть ещё LED, но его в расчет не беру, так как он принципиально отличается от стекол.

[inetchik]

 Это я видел,  .
Ню, раз снова увидел...
А зачем дисплей заклеен скотчем термостойким, каптоновым  ?

С "нетерпением" жду V3.
Те, что слева, не в счёт:

Справа: 36Pin.