Привет вместе,

Потому что мне нравится использовать программы Arduino на разных платформах, я понял проблему: многие примеры написаны для ILI9341 TFT. Но иногда я использую дискотеку F746 или дискотеки F429, а иногда и чертеж с ILI9341.

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

Даже на Сайт Arduino для библиотеки TFT Сама они делают эти ошибки дизайна программного обеспечения:
#include // Hardware-specific library #include #include void setup(){ EsploraTFT.begin(); EsploraTFT.background(0,0,0); // clear the screen with black delay(1000); // pause for dramatic effect } void loop(){ EsploraTFT.stroke(255, 0, 0); // set the stroke color to red EsploraTFT.line(0, 10, EsploraLCD.width(), 10); // draw a line across the screen delay(1000);

К сожалению, это происходит также в других библиотеках.

Но Esplora позволяет использовать старые команды The Arduino TFT library extends the Adafruit GFX, and Adafruit ST7735 libraries that it is based on. ..... The library is backwards compatible, which means you can still use the Adafruit functions described here.

Красота C ++ в том, что вы можете наследовать классы. эн.глин. Многие библиотеки TFT, OLED, GLCD наследуют все методы ADAFRIT_GFX, которые, в свою очередь, наследуют методы печати.

Так что я могу ожидать TFT.println ("Hello World"), чтобы работать так же, как сериал.println ("Привет, мир");
Или tft.Наритка (0, 10, 5, 20, белый), чтобы работать как любой другой рисунок ()

В соответствии с соглашением вы можете назвать объект TFT в любую библиотеку контроллеров TFT, которую вы используете.
Так же, как большинство объектов 16x2 называются ЖК -дисплей.

Кажется немного странным называть объект Esploratft, но он выглядит так, как будто он из «инсульта» класса графики, а не класса ADAFRIT_GFX.

Да, вы, как правило, получаете несколько аномалий. эн.глин. Некоторые библиотеки TFT начинаются (void), а некоторые начинаются (uint16_t id)
Но большая часть графической программы TFT будет работать на SPI ST7735 или параллельном ILI9341, если конкретные библиотеки совместно используют методы GFX. я.эн. Вам просто нужен конкретный включение и конструктор.

Дэйвид.

[Дэйвид.Прентис - Ср 21 июня 2017 г. 15:28] - Так что я могу ожидать TFT.println ("Hello World"), чтобы работать так же, как сериал.println ("Привет, мир");
Или tft.Наритка (0, 10, 5, 20, белый), чтобы работать как любой другой рисунок ()

Я сомневаюсь, даже если вы всегда использовали библиотеки в той же компании E.глин. Adafruit, будь то TFT.println () будет работать одинаково для всех их либеров или он работает так же, как сериал.println

Из того, что я могу сказать, Libs от той же компании E.глин. Адафрут часто пишут разными людьми и не подтверждают ни одного руководства по стилю.

В своей повседневной работе я использую LIBS на различных платформах из разных источников, и все они ведут себя по -разному

Я думаю, что единственный раз, когда вы можете ожидать, какая последовательность с фиксированным стилем и функциональностью API - это если вы остаетесь в SDK / API / LIBS от одной компании в качестве коммерческого продукта E.глин. Все Apple iOS API решительно следуют стилю, но это коммерческая команда с широко финансируемой командой.

Я хочу сделать простую в использовании и простую библиотеку GUI, которая поддерживает несколько дисплеев TFT.
Какой метод интерфейса вы рекомендуете прикрепить разные драйверы?

[Rogerclark - Чт 22 июня 2017 1:18] -

[Дэйвид.Прентис - Ср 21 июня 2017 г. 15:28] - Так что я могу ожидать TFT.println ("Hello World"), чтобы работать так же, как сериал.println ("Привет, мир");
Или tft.Наритка (0, 10, 5, 20, белый), чтобы работать как любой другой рисунок ()

Я сомневаюсь, даже если вы всегда использовали библиотеки в той же компании E.глин. Adafruit, будь то TFT.println () будет работать одинаково для всех их либеров или он работает так же, как сериал.println

Из того, что я могу сказать, Libs от той же компании E.глин. Адафрут часто пишут разными людьми и не подтверждают ни одного руководства по стилю.

В своей повседневной работе я использую LIBS на различных платформах из разных источников, и все они ведут себя по -разному

Я думаю, что единственный раз, когда вы можете ожидать, какая последовательность с фиксированным стилем и функциональностью API - это если вы остаетесь в SDK / API / LIBS от одной компании в качестве коммерческого продукта E.глин. Все Apple iOS API решительно следуют стилю, но это коммерческая команда с широко финансируемой командой.

Мусор. Если один класс наследует от печати.H это будет наследовать все печати.H Методы.
Это особенность C ++ и большинство языков OO.

Да, новый класс может реализовать новые методы. Это может даже перезаписать некоторые из наследственных методов. Но, как правило, вы расширяете методы или добавляете новые методы, а не изменяете поведение.

эн.глин. Вы можете добавить TFT.BlueCircle (x, y, радиус), чтобы нарисовать круг в синем.
эн.глин. возможно, что вы перезаписываете существующий TFT.DrawCircle (x, y, Radius, Color) Метод для рисования треугольников. Но крайне маловероятно.

Да, я полагаю, что недовольный бывший сотрудник Apple может попытаться изменить стиль.

Таким образом, библиотеки, которые наследуют от adafruit_gfx, легко используются существующими владельцами Arduino.
Это облегчает жизнь автору библиотеки.
Но любая библиотека может изобретать любой новый класс с любыми названными методами, которые не следуют каким -либо логическим шаблону.

Дэйвид.

Я не понял твой пост

Я думал, что вы имели в виду, что все библиотеки с функцией Println (всегда должны реализовать ее одинаково)
Не только адафрут, которые наследуют от одного и того же базового класса

Без проблем!

Да, я согласен, что println () - просто имя. Это не обязательно означает наследство печати.час
Но я утверждаю, что большинство авторов библиотеки попытаются имитировать поведение, даже если они реализуют без наследования.

эн.глин. Марекб и Бодмер реализуют свои собственные графические методы, которые ведут себя идентично методам ADAFRIT_GFX.

Каким -то образом, println (), скорее всего, будет вести себя как печатный.час
Я подозреваю, что Print () с меньшей вероятностью соответствует.

Дэйвид.

С чем не так class GUI { public: GUI(Adafruit_GFX &gfx): gfx(gfx) {}; Adafruit_GFX &gfx; void button() { gfx.drawPixel(...); } }; //Use as: Adafruit_ILI9341 tft(); // or other display GUI(tft);

Я пробую это с помощью вашей реализации TFT F746, но, похоже, это не является производной adafruit_gfx.
Так что мне пришлось бы переписать это на class GuiPittixObject { public: GuiPittixObject( LTDC_F746_Discovery &gfx ): gfx(gfx) { }; private: LTDC_F746_Discovery &gfx; }; LTDC_F746_Discovery tft; GuiPittixObject myObject(tft);

[Chismicro - Пт 23 июня 2017 г. 5:18] - Я пробую это с помощью вашей реализации TFT F746, но, похоже, это не является производной adafruit_gfx.

Да, это.

о нет, это не так
извини
Стивен

Целью моих усилий по созданию графического интерфейса является максимально достижимая простота ... Ардуино нравится ...
Это должно быть просто в использовании. Все API -интерфейсы, которые я видел, на мой взгляд, сложные.

Итак, вот мое предложение показало примером «виртуальные» светодиоды на экране и мигает:
Adafruit_ILI9341 * Display; // this pointer is needed from the GUI driver GUI_Led Led1("up "); GUI_Led Led2("down"); void setup() { tft.begin(); tft.fillScreen(LTDC_BLACK); tft.setRotation(1); Display = &tft; Led1.setColor(COLOR_GREEN); } void loop(void) { Led1.on(); Led2.off(); delay(1000); Led1.off(); Led2.on(); delay(1000); }

Я только что добавил Пример кода на GitHub для BluePill и ILI9341.
Это очень начальное состояние, которое я планирую расширить. Есть ли у вас предложения для любых улучшений?

[Chismicro - Солнце 25 июня 2017 г. 5:31] - Я только что добавил Пример кода на GitHub для BluePill и ILI9341.
Это очень начальное состояние, которое я планирую расширить. Есть ли у вас предложения для любых улучшений?

Пока нет предложений, но пока это выглядит хорошо, я очень заинтересован в этом проекте.

Пока нет предложений, но пока это выглядит хорошо, я очень заинтересован в этом проекте. Спасибо за ответ

Тем временем я пришел к выводу, что лучше всего провести класс «tft_adapter» для каждой конфигурации оборудования.

В этом адаптере должна быть сделана вся аппаратная конфигурация (например, назначение PIN -код) для каждой аппаратной платформы.
Остальная часть программного обеспечения остается прежней.

Я сделал Пример для 3 различных аппаратных платформ:

- Arduino uno с ILI9341 Параллельный дисплей Shield
- BluePill с ILI9341 SPI
- STM32F746 Discovery

Что вы думаете?

Теперь он преобразуется в библиотеку.
Теперь есть разные адаптеры, которые должны быть выбраны до включения графического интерфейса.
// choose your hardware: #define TFT_Adapter_ILI9341_BluePill //#define TFT_Adapter_SPFD5408_UNO //#define TFT_Adapter_STM32F746_Discovery #include "Gui.h" GUI_Led Led1("up "); GUI_Led Led2("down"); ....

Тем временем я сделал несколько графических элементов

- кнопка
- слайдер
- Номер дисплей

Первоначально я хотел сделать демонстрации на маленьких 2.4 '' ILI9341 и чертежи, но я привык к удобству «Большого» 4 '' TFT из дискотеки F746.

Вот демонстрационная картина



Это выглядит немного простым по сравнению с GUI, которые рядом.

Но примите во внимание: я сосредоточен на простоте API программистов.

Что вы думаете?

Вы слишком сильно ограничиваете себя этими адаптерами. Просто скажите пользователю позвонить в TFT.начинать(...) перед графическим интерфейсом.начинать(). В любом случае это стандарт.
И теперь ваш код работает на любом Arduino/Teensy/EPS/AWALE, и в каждой библиотеке GUI, которая расширяет Adafruit GFX. Без необходимости ничего делать.

Даже если вы этого не сделаете, создайте пример для Arduino Uno и сделайте пост на форуме общего Arduino. Вы получите там больше отзывов.

(Вам понадобятся «адаптеры» для прикосновения, а не для экрана, потому что у них нет общего родительского класса, я думаю. Но если у них есть один и тот же метод (tspoint getPoint ()), сделайте это с одним классом шаблонов C ++, и не так много разных.)
(Не звоните SetRotation (). Пусть пользователь решит, что.)

Спасибо ваш подробный ответ
Даже если вы этого не делаете, создайте пример для Arduino uno, Я купил щит ILI9341 для Uno. Дисплей сработал, но прикосновение не. Похоже, у него есть дефект, потому что только ADC AUF, направление Y немного изменяется по оси x. Поэтому я бросил это ...

Что касается вопроса о прикосновении: (Вам понадобятся «адаптеры» для прикосновения, а не для экрана, потому что у них нет общего родительского класса, я думаю. Но если у них есть один и тот же метод (tspoint getPoint ()), сделайте это с одним классом шаблонов C ++, и не так много разных.) Это действительно какая -то проблема. На данный момент я решил его, прочитав прикосновение и написав ценности в графический интерфейс.

Это «интерфейс»:
void loop(void) { // read touch pad and tell the gui TSPoint p = ts.getPoint(); gui.setTouch(p.x, p.y, p.z); value1 = slider1.getInt(); ..

Что касается прикосновения, некоторые TFT имеют резистивные сенсорные штифты на разных выводах отображения. Лучший метод, чтобы выяснить, какие выводы отображаются, накапливается, - это эффективное измерение сопротивления между различными булавками.

Я могу представить собой тонкий слой обертки между Touch Lib и пользовательским API, который может объединить резистив с емкостным прикосновением.

Даниэль написал Вы слишком сильно ограничиваете себя этими адаптерами. Я не знаю, каков лучший способ.
Например, идентификатор вы просто возьмете примеры ADAFRIT_ILI9341:
tft.fillScreen(ILI9341_BLACK);

Стевестронг написал Я могу представить собой тонкий слой обертки между Touch Lib и пользовательским API, который может объединить резистив с емкостным прикосновением. Да, хорошая идея.
Вероятно, лучше всего заселить API резистивного прикосновения ILI9341 в качестве стандартного и сделать для всех других сенсорных экранов слоем преобразования.

За исключением совместимости с графическим интерфейсом, существует проблема с драйверами TFT «низкоуровневого» интерфейсов.
Например, хороший 8 -битный 8 -битный LIB Стива использует 8 -битный подход в его библиотеке. Так что нелегко использовать для 16 -битного..

Q Экспертам: Почему мы не можем создать «уровень драйверов низкого уровня» для Adafruit/UTFT/Whate Lib, где «шина данных» (8/16/SPI/I2C) будет доступна через 2 отдельные функции/методы, которые требуются, например, : uint8_t Write_TFT_Data_Bus(uint8_t mode, uint8_t parH, uint8_t parL); uint16_t Read_TFT_Data_Bus(uint8_t mode);

Быть реалистичным. Никто не собирается меняться с 8080-8 на 8080-16 во время выполнения. Точно так же вы не собираетесь переходить от SPI на параллельно во время выполнения.

Нет ничего особенного, что меняется с высокого уровня точки зрения. эн.глин. DrawCircle (), FillScreen (), ...
Даже rearmid () или writeCommand () одинаково на высоком уровне.

Другими словами, вы выбираете проводку и интерфейс. Ваше решение известно во время компиляции.
Бинарник, который вы построили, будет работать только на правильном проводном TFT.

Adafruit сделал блестящую работу по предоставлению библиотеки adafruit_gfx. Arduino предоставил классы потока и печати.
Авторы библиотек TFT (или OLED, GLCD, ...) просто предоставьте аппаратные методы.
Punters могут перенести программу из Стива, Адафрута, Бодмера, Марека, ... Почти безболезненно.

Да, могут быть небольшие различия в синтаксисе между pushcolors (), pushcolor (), begin (), ...
В идеальном мире они были бы идентичны.

Я только что рассмотрел «популярные» библиотеки стиля GFX, которые наследуют (или имитируют) классы.
Можно привести аргумент для подхода UTFT. я.эн. Нет наследства, неинтуитивные методы.

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

Дэйвид.

Я думаю, что «совместимость» в контексте Arduino означает, что программное обеспечение может легко перенести из другой платформы.

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

Да, я вижу твою проблему (и).

Я вставил дисплей SPI ILI9341 на 3.3V "uno".
Я установил ILI9341_T3 с менеджером библиотеки. Он не поддерживает шрифты.

Итак, я удалил библиотеку ILI9341_T3 и построил для Teensy3.2.
Teensy устанавливает несколько популярных библиотек, которые были настроены на Freescale. Это делает их несовместимыми с обычными ардуносами.

Другими словами, весь принцип Arduino нарушен.

Сказав это, большинство методов ILI9341_T3 довольно портативны. Но как только вы начнете взлом, все падает.
По моему личному мнению, для PJRC можно добавить дополнительные функции, которые относятся к Freescale, но они должны поддерживать совместимость со стандартными Arduinos.

Ваш конкретный пример сочетает в себе некоторые специальные кусочки аппаратного обеспечения. И вы получаете подобную ситуацию. я.эн. Сорт Maplecore для STM32 содержит специальные взломанные библиотеки.
Я был бы намного счастливее, если бы поддержка STM32 была объединена в основные популярные библиотеки. Затем игрок может установить "ILI9341_T3" с менеджером библиотеки. И это будет работать с Arduino, STM32, Freescale, ...

Я не особенно заинтересован в игре «тетриса». Я не обладаю каким -либо звуковым оборудованием.
Но это должно быть довольно простым для переноса графического кода TFT.

Дэйвид.

Быть реалистичным. Никто не собирается меняться с 8080-8 на 8080-16 во время выполнения. Точно так же вы не собираетесь переходить от SPI на параллельно во время выполнения. Я не думаю о «изменении времени выполнения», конечно.
Но я думаю, что изменение интерфейса (всегда будут необходимы усилия для INIT конкретного контроллера TFT и Perihperals MCU, т.е. с 9341-8 бит до 9341-16 бит или до 1289-16 бит, или от 1289-16 до 7735-SPI или до 9341-SPI на уровне «Уровень интерфейсной шины HW» намного проще. Посмотрите, как люди делают это сегодня. И вам нужно только два метода/функции..
Опять же, я не комментирую конкретные функции внутреннего видео контроллера TFT здесь.

Посмотрите на мою библиотеку MCUFRIENT_KBV. Есть только одно место, которое является условным для 16-битного или 8-битного интерфейса. И это оптимизация для FillRect () i.эн. Напишите 16-битную шину данных один раз, много раз колебляйтесь в линию /WR.

Да, макросы низкого уровня для интерфейса становятся грязными, когда у вас есть специальная проводка.
Но если у вас есть обычный щит и обычный Arduino, проводка исправлена.

У меня есть свой собственный ili9341_kbv, ili9163_kbv, hx8347d_kbv , ... Классы SPI. Они используют те же методы. Вы просто измените один включение и один конструктор для запуска одного и того же эскиза на разных оборудовании.

И я часто могу переносить набросок «иностранной библиотеки TFT» с немного большим, чем класс клея.
Например, я сравниваю свой стандартный набросок "graphictest_kbv", запустив его с другими библиотеками E.глин. ILI9341_T3

Легче «приклеить» к классу, с которым вы знакомы, чем попытаться переписать чужой эскиз (или библиотеку).

Дэйвид.

Однажды я хотел сделать шаблон C ++, где протокол, драйвер чипа, где просто шаблоны.
Это было что -то вроде: Display> tft1; Display> tft2;

Тогда я вспомнил https: // xkcd.com/927/, и отбросил идею. Да, это всегда проблема со стандартами. Но, несмотря на это иго, стандарты существуют.

Одним из типов или стандарта является стандарт, разработанный от людей, сидящих за зеленым столом:
Все фантазии включены, и у каждого есть проблемы с внедрением в течение следующих десяти лет.

Другие стандарты развиваются во времена: их огромное число приведет к объявлению его в какой -то момент в качестве стандарта.

Из точки Arduino-view я бы сказал: «близко к стандарту» Adafruit-GFX и его функции рисования и, вероятно, лучший способ адаптации письменного программного обеспечения-это написать небольшие классы, которые Дэвид называет «клей», и я называю «оберткой».
Эффективность может быть проблемой.

Компиляторы C ++ довольно умные. Я бы не стал слишком беспокоиться о эффективности. Это редко заметно.

Шаблоны и наследство работают немного по -другому.

Я дошел до стадии, где у MCUFIENT_KBV так много последовательностей инициализации, что это значимо на ООН.
Что означает, что «менее распространенные» контроллеры условны поддерживаются. Так что у вас больше нет ситуации, когда «что -нибудь» подключится и уйдет.

У Olikraus есть лучшая система с U8Glib. Но вы должны точно знать, какое оборудование у вас есть, прежде чем написать конструктор.

Эй-хо. По крайней мере, у STM32 есть больше вспышки, чтобы поиграть с.

Я думаю, что библиотекам было бы разумно работать на разных платформах. я.эн. Сделайте это безболезненным для мега или программы, чтобы работать из коробки на STM32. Хорошо, у вас всегда будет самый низкий общий знаменатель, но никто не возражает, если дополнительно «колокол или свисток» нуждается в большей вспышке или более быстром процессоре. До тех пор, пока основы работают.

Дэйвид.

Я должен заставить вашу библиотеку работать над моим F411, но мне пришлось #Define STM32L476XX и ARDUINO_NUCLEO_L476RG в верхней части MCUFIENT_SHIELD.час.

Это будет боль, если каждая доска ядер должна быть изложена один за другим. (Плюс пришлось добавить еще один wr_active; в write_delay, чтобы не иметь поврежденного экрана. Какая радость)

привет!
Почему бы не использовать нативную adafruit_gfx вместо ADAFRIT_GFX_AS?
Я пытаюсь изменить Adafruit_ili9341_stm.час
#включать <Adafruit_gfx_as.час> #include <Adafruit_gfx.час>
и Everithing работает нормально с пользовательскими шрифтами.. может я не знаю, что?

Я думаю, что библиотекам было бы разумно работать на разных платформах. я.эн. Сделайте это безболезненным для мега или программы, чтобы работать из коробки на STM32. Хорошо, у вас всегда будет самый низкий общий знаменатель, но никто не возражает, если дополнительно «колокол или свисток» нуждается в большей вспышке или более быстром процессоре. До тех пор, пока основы работают. Когда-либо приходилось переносить или вносить изменения в одну из этих многоплатформенных либеров? Я суммирую свои чувства: P.я.Т.А. Ваш худший кошмар.

Это продвинутый форум, поэтому в отличие от Arduino.CC, где «библиотеки являются основой Arduino»; Библиотеки здесь больше роскоши ... Первоначально несколько часто необходимых либера.

Если вы хотите преуспеть в программировании и расширить свое понимание взаимодействия физического датчика, просто напишите функции, такие как Init, как отдельная вкладка ... Расширить каждую вкладку, чтобы включить связанные функции. Новый датчик? Новая вкладка. Легко следовать. Легко повторно использовать. Легко развиваться, не пробивая использование. Легко застегнуть резервную копию или публикацию.


Луча