Всему свое время… Вы все хотите чтоб при первом включении опытный прибор показывал все как надо.. так не бывает… на то он и тестовый прототип…. Я потом расскажу и покажу с чем пришлось столкнуться, почему так работало и что было сделано чтоб все это поправить… и всех подружить… Не все так просто… если напрямую подключить к экрану гироскоп картинка плавнее некуда… но тут замысел, архитектура сети и количество устройств обменивающиеся данными совсем другое… Терпение…. ))))
Смысла отправлять данные гироскопа по CAN шине более 10 раз в секунду (10 Гц) пока нет… можно и 50… но там и без него много каких модулей обеспечивают поток критически важных данных… у CAN протокола есть ограничения с которыми тоже надо считаться… на этапе отладки софта, этого достаточно… Вы вообще про какую структуру говорите? И да, пока вы будете соображать что присходит на экране отправленные секундой ранее данные уже устареют… Вопрос больше не в передаче количества данных а в качестве обработки принятых … вот тут на этих платформах есть над чем работать … на то он и прототип….
Такое ощущение, что у вас экран подключен через софтовую шину. Какую библиотеку для работы с экраном используете? Плюс идея дальнейшего перехода на esp32s3 весьма сомнительна, так как вы потеряете возможность двухъядерной работы.
@@barmaley1980 TFT_eSPI. Сколько у вас стоит таймер на обновление экрана? Я делаю передачу между двумя esp32 через wifi и данные передаются быстро. Сейчас передача у меня работает на 100мс.
@@barmaley1980первое ядро занимается только обработкой CAN шины, второе специально пока не задействовано… пока так… основной код пока в общем loop, там и происходит работа с формированием спрайта и обработка массива данных (отбраковка аномальных значений по последним 10 посылкам), поэтому и задумчивость у экрана … но даже в этом случае частота обновления экрана как я писал 40гц (кадров в секунду) … напомню, сейчас не идет «битва» за плавность картинки… задача на сейчас чтоб все данные принимались, обрабатывались и отображались правильно и всё работало синхронно и как задумано… плавность картинки второй этап, там будут применяться совсем другие методы формирования изображения…
@@barmaley1980как вам уже ответили TFT_eSPI… распределение задач по ядрам есть… пока задача не в плавности картинки… это второй этап… SmartGyro работает с Arduino Nano, там его хватает «за глаза»…
И что…., видел я это… Вы прежде чем это постить почитайте кто это делал и на чем… эти проекты сравнивать не корректно… они вообще разные… хотя по сути у этих устройств задача одна и та же… P.S. Кстати этот PFD (или как его назвал автор EFIS) имеет такой же тормознуты отклик… с чего бы это… !?
В принципе если горизонт не меняется то выглядит хорошо!)
Всему свое время… Вы все хотите чтоб при первом включении опытный прибор показывал все как надо.. так не бывает… на то он и тестовый прототип…. Я потом расскажу и покажу с чем пришлось столкнуться, почему так работало и что было сделано чтоб все это поправить… и всех подружить… Не все так просто… если напрямую подключить к экрану гироскоп картинка плавнее некуда… но тут замысел, архитектура сети и количество устройств обменивающиеся данными совсем другое… Терпение…. ))))
Здравствуйте. Задержку может быть 10 секунд ещё сделать?😂 Структурой данные лучше отправлять. Там до 10мс спокойно можно.
Смысла отправлять данные гироскопа по CAN шине более 10 раз в секунду (10 Гц) пока нет… можно и 50… но там и без него много каких модулей обеспечивают поток критически важных данных… у CAN протокола есть ограничения с которыми тоже надо считаться… на этапе отладки софта, этого достаточно… Вы вообще про какую структуру говорите? И да, пока вы будете соображать что присходит на экране отправленные секундой ранее данные уже устареют… Вопрос больше не в передаче количества данных а в качестве обработки принятых … вот тут на этих платформах есть над чем работать … на то он и прототип….
Такое ощущение, что у вас экран подключен через софтовую шину. Какую библиотеку для работы с экраном используете?
Плюс идея дальнейшего перехода на esp32s3 весьма сомнительна, так как вы потеряете возможность двухъядерной работы.
@@barmaley1980 TFT_eSPI. Сколько у вас стоит таймер на обновление экрана? Я делаю передачу между двумя esp32 через wifi и данные передаются быстро. Сейчас передача у меня работает на 100мс.
@@barmaley1980первое ядро занимается только обработкой CAN шины, второе специально пока не задействовано… пока так… основной код пока в общем loop, там и происходит работа с формированием спрайта и обработка массива данных (отбраковка аномальных значений по последним 10 посылкам), поэтому и задумчивость у экрана … но даже в этом случае частота обновления экрана как я писал 40гц (кадров в секунду) … напомню, сейчас не идет «битва» за плавность картинки… задача на сейчас чтоб все данные принимались, обрабатывались и отображались правильно и всё работало синхронно и как задумано… плавность картинки второй этап, там будут применяться совсем другие методы формирования изображения…
@@barmaley1980как вам уже ответили TFT_eSPI… распределение задач по ядрам есть… пока задача не в плавности картинки… это второй этап… SmartGyro работает с Arduino Nano, там его хватает «за глаза»…
th-cam.com/video/R5oXYOi66VQ/w-d-xo.html
И что…., видел я это… Вы прежде чем это постить почитайте кто это делал и на чем… эти проекты сравнивать не корректно… они вообще разные… хотя по сути у этих устройств задача одна и та же… P.S. Кстати этот PFD (или как его назвал автор EFIS) имеет такой же тормознуты отклик… с чего бы это… !?
Отклик огромный. Такое только на корабле ставить чтобы в шторм горизонт проверять.
Даже на накорабле в шторм с такой задержкой не отработаешь 😅