Pull to refresh

Comments 8

Неплохо, расскажите как к этому чипу подбирали дисплей, что у него с интеграцией в плане кода, как быть с тачем, что там настройкой внутреннего IPU для соответствующих сигналов и формата дисплея. Как обстоит дело с калибровкой на касание и есть ли поддержка емкостных тач. экранов.
Дисплей и графический контроллер, который им управляет, поставляются вместе. Получается TFT-модуль, который управляется простыми командами по SPI.

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

[Часть 1] Обзор использованных программных и аппаратных решений.
[Часть 2] Начало работы с графическим контроллером FT800. Использование готовых mbed-библиотек для периферийных устройств.
[Часть 3] Подключение датчика HYT-271. Создание и публикация в mbed собственной библиотеки для периферийных устройств.
[Часть 4] Разработка приложения: Структура программы, работа с сенсорным экраном.
А кто собственно настроил контроллер на дисплей? Производитель? Что будет когда он передумает заниматься этим, закроется, наложит на Россию санкции? Там все прозрачно в плане использования этого максимально фундаментально на компонентах по отдельности? Какая лицензия на код? Можно ли его потом использоваться кастомно?
Вы же не переходили по моим ссылкам, да?))
А по ссылкам всё это, конечно, описано. Но я могу по вашим вопросам кратко пробежаться:

>> А кто собственно настроил контроллер на дисплей? Производитель?
Да, производитель. Более того, контроллеры FT8xx изначально предназначены именно для управления такими TFT-дисплеями

>> Что будет когда он передумает заниматься этим, закроется, наложит на Россию санкции?
Будет ровно то же самое, как если бы любой другой производитель передумал чем-то заниматься / закрылся / наложил санкции — очевидно возникнут проблемы с поставками. Но вы, наверное, всё равно используете в своей работе импортные компоненты? Или отечественные TFT уже подъехали, а я не в курсе?

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

>> Какая лицензия на код? Можно ли его потом использоваться кастомно?
Какой код имеете в виду? Библиотеку для работы с графическим контроллером? Код для устройства, о котором я пишу в своих статьях? Код, вшитый в графический контроллер?

Спасибо.
Я не зря задал эти вопросы, потому что вы делаете распространенную ошибку — подсаживаете кого-то на сторонние решения без осознания ответственности, которую несете в плане производства и поддержки. Люди, которые выберут этот относительно простой путь, в будущем могут остаться без результата. Что касается кода, речь о библиотеках и примерах. Едем далее, вы говорите намного сложнее, хотя сложность — это тоже код. Гораздо лучше иметь больше кода, чем чье-то частично кастомизированное железно решение, не говоря уже о результате, который можно достичь, имея все максимально по отдельности и на уровне кода.
Я не зря задал эти вопросы, потому что вы делаете распространенную ошибку — подсаживаете кого-то на сторонние решения без осознания ответственности, которую несете в плане производства и поддержки.
Я пишу эти статьи в блоге крупного поставщика электронных компонентов и мы официально представляем в РФ всех производителей, о применении продукции которых я пишу — Riverdi, FTDI, Silicon Labs и IST-AG и т.д.
То есть речь не о взятых с потолка сторонних решениях, а о наших целевых продуктах — о компонентах, которые мы продвигаем, которые мы поставляем, и за поставки которых несем ответственность как перед клиентом, так и перед производителем.

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

Что касается кода, речь о библиотеках и примерах.
FTDI заинтересован в том, чтобы его графические контроллеры было просто внедрить, поэтому бесплатно предоставляет полезные примеры и библиотеки. Собственно так делают все производители микроконтроллеров и специализированных контроллеров, это ж логично.

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

P.S. Извините за такой длинный текст, но мне правда хочется понять вашу точку зрения и донести свою.
TFT-дисплей может поставляться с интегрированным графическим контроллером или без него. С точки зрения разработчика разница в том, что управлять «голым» дисплеем значительно сложнее, чем когда многие операции уже аппаратно реализованы на встроенном контроллере.

Библиотеки для работы с графическим контроллером лежат в открытом доступе. Естественно, Riverdi (производитель модулей) предоставляет и библиотеки для работы со своими моделями, и примеры программ, и разные утилиты типа упомянутого в статье Screen Editor. Как иначе то, простите?
Sign up to leave a comment.