Т.е. если конь оказался кубическим и не в вакууме, а в жидкой среде, то аккуратно и правильно писать не надо, можно как попало – и так сойдёт. Позиция понятна, спасибо за разъяснения.
1 лайк
Если нам нужно ООП - делаем ООП, если нам нужно “Си с классами” - делаем “Си с классами”. Не нужно догматизировать. Теоретики считают Си и Си++ разными языками, построенными на разных парадигмах, а, например, практик Шилдт считает Си подмножеством Си++. Сколько людей, столько мнений. Мы сами вольны выбирать то подмножество ЯП, которое нам нужно. Если объект принципиально единственный и создается единственный статический экземпляр, то нет смысла поддерживать те особенности, которые принципиально не могут встретится.
Впрочем, вроде, теории это не противоречит: раз объект единственный и статический, деструктор ему не нужен. И, соответственно, не нужны и лишние конструкторы.
С тезисом согласен. А вот запретить эти особенности необходимо, особенно если пишешь “библиотеку для коллективного пользования”. Всегда найдётся юзер, который с дуру попытается ими воспользоваться. Что мешает их запретить? Четыре строчки лень написать? Или тут что-то с религией?
У меня проблема была в том, что использование скоростного класса который работает в несколько раз быстрее общераспространённого LiquidCrystal_I2C завешивало ардуину. Я пытался копать в сторону подтягивающих резисторов, но безуспешно, а когда прицепил sensor shield и стик геймпада внезапно проблема полностью исчезла.
Не силён в электронике настолько чтобы догадаться что тут произошло - какие то новые нагрузки что-то сгладили или что - но вот получилось так.
Тут безусловно согласен.
Кстати, я выше пытался придумать контрпример, но, как оказалось, контрпримером он не является. В общем, похоже, “контрпример” может быть только в организационной сфере, при одновременном выполнении двух условий: однократное использование не только члена класса, но и самого кода (т.е. без варианта распространения).
Так которая из проблем исчезла? С медленностью кода из стандартной библиотеки или с зависанием “быстрого” кода?
Я давал совет по решению первой проблемы.
Насчёт медленности я быстро нашёл класс hd44780_I2Cexp из библиотеки hd44780 которую автор как раз широко рекламирует как достойную замену в том числе из-за скорости.
Но у меня была какая то нестабильность и с LiquidCrystal и с hd44780 - с ликвид кристал ардуинка зависала в среднем за 5 минут, а с hd44780 за 5 секунд. 
Очевидно скорость передачи играла решающее значение для стабильности, но проблема внезапно полностью исчезла после использования сенсорного шилда и подключения оси геймпада.
Юзал такой дисплей без проблем, с подключением и напрямую, и через sn74hc595 регистр (дешевый самый вариант), и через I2C модуль.
Правда I2C было программное, самодельное и без задержек.
1 раз в секунду обновлял без стирания (чтобы не моргало), просто записью по тем же знакоместам, плюс пробелы в конце - стереть если цифра короче будет.
Ну, дык, “в начале было Слово”, потом уж и картинка нарисовалась
Ну и наконец то могу показать зачем оно мне нужно было. Я уже давненько прикупил робот-манипулятор от Enjoy Robotics, но эта предыдущая их модель не имела блютуз (уже есть новая с другим микроконтроллером с поддержкой блютуз дороже соответственно), а мне хочется управлять ей со смартфона. В силу таких обстоятельств я и затеял сперва развернуть управление с ноутбука с которого удобно программировать и сразу видеть результат.
Очень много возни тут у меня произошло в попытке как то смириться с интерференцией SoftwareSerial и Servo в арудинке Nano, но уже сделав всё рационально возможное я пришёл к выводу, что нет, удовлетворительного результата для мелкой моторики никак не получается - надо задействовать хардварный серийный порт.
Одна из причин почему я еще цеплялся за попытки как то увеличивать скорость и уменьшать размеры пакетов была в том, что в плате-шилде Enjoy Robotics просто не были выведены в доступные пины контакты хардварного серийного порта (RX и TX) - они почему то решили, что это незачем в устройстве для детей. И действительно резонно.
Но мне в итоге они позарез оказались нужны и поэтому обернувшись в мрачную решимость я взялся за нелюбимый паяльник и запаял дополнительные проводки-выводы. Вышло отлично. Поэтому я в начале видео ниже тыкаю в них пальцами.
И… всё заработало идеально и без коллизий. Нубук превосходно цепляется и управляет девайсом.
Результат можно посмотреть на рутубе:
3 лайка
это называется коллизия.
посмотрел, стоит как у молодого. в смысле агрегат на видео видео, не у меня)
Хард сериал, конечно лучше, но если паять очень не хочется, то можно было попробовать связку AltSoftSerial и ServoTimer2
https://rutube.ru/play/embed/bce6f95e5cf8179d25215fe87678b538
С ноутбука через геймпад шпарю, довольный как слон.
