Официальный сайт компании Arduino по адресу arduino.cc
Тормоза при использовании библиотек Adafruit GFX и Adafruit SSD1306
- Войдите или зарегистрируйтесь, чтобы получить возможность отправлять комментарии
Всем привет. Столкнулся с проблемой. Делаю штуковину-фиговину на базе arduino pro mini, oled дисплея 128х64, куча датчиков, переменные резисторы для установки пользовательских значений, светодиоды ...и в общем не важно. Проблема в том, что в этой штуковине-фиговине я использую три светодиода для индикации состояния, которые в разных состояниях должны красиво мигать с затуханием вот по этой простой формуле int(abs(255.00 * sin(value)));
, где value это величина, которая прибавляется в функции loop
, в которой в конце я вставил delay(1)
, и когда я попытался еще параллельно выводить анимацию на дисплей, частота срабатывания функции loop
резко снизилась. Это приводит к тому, что красивое плавное мигание диодов превращается в жуткое мерцающее зрелище. Вот теперь сижу и думаю либо это библиотека такая тяжелая и может быть есть что попроще, либо в любом случае и с любой библиотекой будет такое происходить, либо я сам дурак и можно как-то по другому реализовать не завязываясь на loop
? Спасибо.
P.S. На Mega 2560 такое же поведение, причем влияет именно вызовы методов очистки и отрисовки экрана.
Ну, как там у Вас всё сделано - ХЗ, Вы не показали. Если вдруг случайно получилось, что сделано нормально, но скорости не хватает, то уберите нафиг синус, а вместо него заранее насчитайте готовые значения, положите в массив и берите оттуда. К тому же храните в массиве уже целые значения, избавьтесь от плавающей точки совсем. Всё будет значительно быстрее - вычисление синуса очень дорогая операция.
Ну, как там у Вас всё сделано - ХЗ, Вы не показали. Если вдруг случайно получилось, что сделано нормально, но скорости не хватает, то уберите нафиг синус, а вместо него заранее насчитайте готовые значения, положите в массив и берите оттуда. К тому же храните в массиве уже целые значения, избавьтесь от плавающей точки совсем. Всё будет значительно быстрее - вычисление синуса очень дорогая операция.
В качестве тестов я использовал только работу с дисплеем, этой библиотекой и вообще без расчета тригонометрических функций. Но при этом все равно производительность падает примерно также, как и в моем проекте.
Заранее расчитать значения конечно можно, но ведь один фиг - подставлять я эти значения буду с тормозами. Мне все-таки кажется, что что-то в библиотеке не так. А времени эксперементировать с другими пока нет, как и уверенности в том, что другие решат проблему.
Ну, тогда я не понимаю зачем Вы это запостили, если Вы и так знаете в чём беда. Чего Вы от нас ждёте? Чтобы кто-то не видя Вашего скетча, и не зная с какой на самом деле скоростью всё работает, подсказал Вам что-то разумное? Ну, хорошо, посмотрите на строку №84, там, кажется, ошибка.
Не сказал бы, что дисплей тормоз :)
Ну, тогда я не понимаю зачем Вы это запостили, если Вы и так знаете в чём беда. Чего Вы от нас ждёте? Чтобы кто-то не видя Вашего скетча, и не зная с какой на самом деле скоростью всё работает, подсказал Вам что-то разумное? Ну, хорошо, посмотрите на строку №84, там, кажется, ошибка.
Ну что Вы сразу утрируете. Просто вещь эта довольно распространенная. И вероятность того, что кто-то с этим столкнулся велика. И быть может даже, собеседник мой возмущенный, кто-то смог это как-то решить. Естественно, если нужна какая-та дополнительная информация, я с радостью ее выложу, чай поделка моя не есть секретная установка.
Не сказал бы, что дисплей тормоз :)
А вот это интересно, надо попробовать использовать OLED_I2C.
Не сказал бы, что дисплей тормоз :)
И действительно, с библиотекой OLED_I2C работает просто замечатеольно и без всяких тормозов. Спасибо за совет :)
Whitefoot-gl, по поводу библиотек сказать не могу т.к. пользуюсь исключительно собственной, но I2C - довольно менделнная шина, а дисплей графический, и запихать на него нужно 1к данных.
Вы там упоминаете про delay(1), а полноэкранный вывод на дисплей занимает в зависимости от установленной частоты 100 или 400 кГц и степени оптимизации кода примерно от 50 до 500 мс, т.е. задержна увеличивется в 50-500 раз. Правда, из-за используемой Вами тригонометрии время прохождения цикла, конечно, существенно больше 1 мс: один синус считается 0.125 мс, ну и арифметика от 0.015 до 0.04 мс на одну операцию. Кстати, на Pro Mini double ничем не отличаются от float. И еще, в том скетче, по поводу которого Вы сомневаетесь в тормознутости дисплея, при подсчете fps учитывается только арифметика, а сама работа с дисплеем остается за кадром (т.е. не входит в подсчет fps).
Т.е. именно о скорости работы дисплея по этому скетчу вообще ничего сказать нельзя.
А не подскажете прочему скачанные с оф. сайта шрифты отображаются некорретно? OLED_I2C (http://www.rinkydinkelectronics.com/r_fonts.php). Сама библиотека http://www.rinkydinkelectronics.com/library.php?id=80.
Whitefoot-gl, по поводу библиотек сказать не могу т.к. пользуюсь исключительно собственной, но I2C - довольно менделнная шина, а дисплей графический, и запихать на него нужно 1к данных.
Библиотека там отстойнейшая, любое изменение изображения, даже одного пикселя путем вывода всего 1КБ. Тормозня и памяти не напасешся. Тоже пользуюсь личной, получается например както - так https://youtu.be/i6ZzAEG1vaE