Итак, я не был уверен, где это поместить, «проекты» кажется такими же хорошими, как и в любом месте.

У меня есть существующее устройство, которое вы можете купить на коммерческих целях, что в основном работает. Похоже, это:
http: // www.Dfrobot.com/index.PHP?маршрут = ... 5F9BFL96KW





Здесь есть драйвер Linux с открытым исходным кодом:
https: // github.com/robopeak/rpusbdisp

Наряду со схемой доски:
http: // www.Robopeak.com/data/doc/rpusbd ... ал.1.0.PDF

И описание USB -протокола:
http: // www.Robopeak.com/data/doc/rpusbd ... НАС.1.0.PDF

У меня также есть план проекта DIY для STM32, который делает то же самое (и у меня есть подлое подозрение, что коммерческий продукт основан на коде в этом блоге, хотя у меня нет доказательств). Это на русском, но переводится приемлемо с Google Translate. Сообщения в блоге здесь:
https: // habrahabr.ru/post/139601/
https: // habrahabr.ru/post/163689/
https: // habrahabr.ru/post/163861/
https: // habrahabr.ru/post/164635/

По сути, это STM32 (F103VET6 для обоих), который получает данные пикселей по USB и блиняет их до 320x240 TFT через 16-битный параллельный интерфейс. Из моего ограниченного понимания драйвер Framebuffer Linux предоставляет «окно» пикселей, которые должны быть обновлены, и затем эти данные отправляются на экран, чтобы быть переписанным (это означает, что вы переписываете только разделы экрана по мере необходимости).

Моя причина этого расследования состоит в том, что у меня есть несколько идей для продукта, который я хотел бы разработать (что я создаю прототип с дисплеем Robopeak). К сожалению, дисплей Robopeak несколько дорогой и имеет несколько раздражающих «функций», таких как жестко -кодированный брызговой экран и серьезные проблемы с некоторыми USB -центрами, которые я хотел бы иметь возможность улучшить. Он больше не разрабатывается (нет основных обновлений GitHub за 2 года), и источник STM32 недоступен.

Итак, мой вопрос на этом этапе: может быть что -то подобное перенести в STM32Duino? Я знаю, что у нас уже есть библиотека TFT. USB -сторона этого необоснованно жестко? У кого -нибудь здесь есть какие -либо знания о том, как можно начать?

Я, наверное, должен добавить, я скорее аппаратный парень, и я просто балуюсь программным обеспечением (поэтому я здесь держусь здесь). Если бы я собирался что -то вместе и работал, я был бы более чем рад создать несколько печатных плат, собрать их и отправить несколько, кто может помочь мне с этим с этим

@C_d

Вы можете сделать что -то довольно похожее на себя.

Я думаю, что хитрость заключается в том, чтобы подключиться через 16 -битный путь данных, так как ILI9341 будет намного медленнее, поскольку он использует SPI.

Я зависит, если скорость такая важна для вас.

Если нет, вы можете построить что -то, используя таблетку ILI9341 + Blue за 10 долларов.


Тем не менее, вам может потребоваться написать свою собственную USB -систему для отправки данных. У нас есть сериал, HID и мини -USB, который работает нормально, и я думаю, что где -то есть демо -версия USB -хранения.
Я понятия не имею, однако, какое USB -устройство будет отображаться как ??

Редактировать. Я вижу USB -протокол

Они писали своего собственного драйвера для этого,?

Вам нужно будет написать свой собственный USB -код, если вы хотите, чтобы ваша доска точно такая же.

Я работал с 16-битными параллельными TFT-экранами перед. Я действительно работал, используя arduino uno, хотя он использует каждый PIN -код, который есть

Я считаю, что и русский парень, и дисплей Robopeak используют свои собственные драйверы Linux. Учитывая, что я понятия не имею, как написать драйвер Linux, я бы, вероятно, хотел бы использовать один из их драйверов и просто повторить их прошивку на STM32?

Дисплей Robopeak требует, чтобы драйвер был составлен в ядро, хотя у меня есть весь исходный код для него. Вот что это показывает, когда вы подключите его: [ 4.488307] usb 1-1.4: new full-speed USB device number 6 using dwc_otg [ 4.590147] usb 1-1.4: New USB device found, idVendor=fccf, idProduct=a001 [ 4.598525] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4.607774] usb 1-1.4: Product: rp-usbdisp [ 4.613226] usb 1-1.4: Manufacturer: RoboPeak [ 4.618954] usb 1-1.4: SerialNumber: 48FA716D3432 [ 5.538485] rp-usbdisp 1-1.4:1.0: allocated ticket c646e140 with urb c652be00 [ 5.577310] rp-usbdisp 1-1.4:1.0: allocated ticket c66626c0 with urb c64dfc00 [ 5.608426] rp-usbdisp 1-1.4:1.0: allocated ticket c6694380 with urb c652bc80 [ 5.628315] rp-usbdisp 1-1.4:1.0: allocated ticket c665bcc0 with urb c652bc00 [ 5.648441] rp-usbdisp 1-1.4:1.0: allocated ticket c665bd40 with urb c652bb00 [ 5.668808] rp-usbdisp 1-1.4:1.0: allocated ticket c665bca0 with urb c652bb80 [ 5.668969] rp-usbdisp 1-1.4:1.0: allocated ticket c665b240 with urb c652be80 [ 5.669147] rp-usbdisp 1-1.4:1.0: allocated ticket c665bba0 with urb c652a200 [ 5.669287] rp-usbdisp 1-1.4:1.0: allocated ticket c665bbe0 with urb c64dfe80 [ 5.669733] rp-usbdisp 1-1.4:1.0: allocated ticket c665b200 with urb c73ddf80 [ 5.669752] rp-usbdisp 1-1.4:1.0: allocated 10 urb tickets for transfering display data. 65024 size each [ 5.669767] rp-usbdisp 1-1.4:1.0: RP USB Display found (#1), Firmware Version: 1.05, S/N: 48FA716D3432 [ 5.688599] usbcore: registered new interface driver rp-usbdisp

Если вы просто используете его в качестве сенсорного дисплея на PI, их сотни около 15 долларов?

http: // www.aliexpress.com/item/best-pri ... 51978.HTML

Они принимают кадр и отражают их через SPI.

У меня есть цифровая рама для изображения Samsung, которая может использоваться в качестве монитора с использованием той же системы (USB), но работает только для Windows. Мне удалось написать какое -то программное обеспечение на PI для использования, в качестве дисплея данных, отправив его JPEGS, оно было довольно эффективно, пока карта данных на моем PI не повреждена.

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

Iteadstudio также имеет большой ассортимент такого рода дисплеев

https: // www.Itead.cc/display/nextion.HTML

Re: Скомпилирование драйверов в ядро ​​Linux

Вау, это звучит довольно твердо. Разве нет более простого способа сделать это ?

Rogerclark написал:
Вау, это звучит довольно твердо. Разве нет более простого способа сделать это ?

Как протокол интерфейса известный, Вы можете просто перенаправить функции высокого уровня исходного драйвера USB на последовательные команды, как предложил Simonf.

В идеале мне бы хотелось иметь интерфейс HDMI, но я никогда не нашел контроллер HDMI, который мог бы обрабатывать экран на этом маленьком. 320x240 находится за пределами спецификации HDMI. Есть несколько причин, по которым я получил USB -дисплей для своего проекта:

• Приложение требует разнообразных монтажных устройств потенциально в нескольких метрах от основного компьютера. SPI на длинные расстояния в шумных условиях просто просит неприятности.
• Я хотел, чтобы мои варианты были открыты в отношении основного компьютера. В настоящее время я использую Raspberry Pi, но я не хотел заблокировать себя ни на чем. Если в дальнейшем будет новый Beaglebone, Odroid или ??? Это более экономически эффективное или имеет лучшие функции, я не привязан к интерфейсу, которого альтернативная плата может не иметь (я предполагаю, что USB будет уже дольше).
• Есть и другие USB -устройства (Wi -Fi Dongle, Bluetooth Dongle и т. Д.) казалось логичным использовать общую шину для всего.
• Некоторые из отчетов, которые я видел из этих дисплеев SPI, предполагают, что они не обновляются очень быстро, SPI кажется немного узким местом. Я надеялся, что USB даст мне большую пропускную способность данных (хотя я на самом деле не знаю, правда ли это или нет).

Создание экрана последовательным устройством - интересная идея. Сможете ли вы передавать достаточно данных через USB CDC, чтобы не отставать от дисплея?

Если CDC достаточно для передачи данных, можете ли вы написать программное обеспечение для пересылки Linux Framebuffer на устройство CDC? Я думаю, что это драйвер, на самом деле не так, но, возможно, вы могли бы сделать это в коде пользовательского пространства, а не на уровне ядра?

У меня уже есть несколько 16 -битных параллельных экранов под рукой и много синих таблеток. Если кажется, что есть идея, которую стоит испытать.

5 " - это самый маленький HDMI, который вы, кажется, сможете получить, я подозреваю, что разъем PI на этом предназначении для сенсорного экрана SPI, который у меня появится на этой неделе, я дам вам знать.


http: // www.aliexpress.com/item/5 дюймов-8 ... 75543.HTML

Этого http: // www.aliexpress.com/item/800-480- ... 12688.HTML HDMI и USB Touch. Это будет работать с чем угодно с HDMI и USB.

Что касается USBCDC, вы должны получить около 200 кб /с в хороший день. Полный экран несжатый составляет 320*240*2 байта = 153k ****. Если вы отправляете только изменения (например, MPEG) и вы делаете необработанное сжатие, вы должны быть в порядке, если вы не хотите отображать видео с полным движением.

**** Я не проверил глубину пикселя на этом дисплее

Nextion хорош, если вы не хотите отображать буфер рамки, вы просто разработаете свой собственный графический интерфейс.

Саймонф написал:...Я подозреваю, что разъем PI на этом предназначен для сенсорного экрана SPI ...

С STM32DUINO мы можем сделать композитное устройство, которое показывает в качестве скрытого для сенсорного экрана, а также CDC для отправки данных экрана?
Саймонф написал:5 " - самый маленький HDMI, который вы, кажется, можете получить

C_D написал: Саймонф написал:Что касается USBCDC, вы должны получить около 200 кб /с в хороший день. Полный экран несжатый составляет 320*240*2 байта = 153k ****.

То, как работа Raspberry Pi (я предполагаю, что это, вероятно, специфично RPI, но может быть не), GPU подключен только к FB0, кадру для выхода HDMI. Невозможно выполнить обработку графических процессоров на чем -либо, кроме FB0. При подключении внешнего дисплея вы получаете новое устройство Framebuffer FB1. Вы можете сказать такие вещи, как консоль и x для вывода на устройство FB1 вместо FB0, но вы теряете ускорение графического процессора, когда делаете это. Если вам нужно использовать GPU (что я делаю), единственный вариант для использования дисплея без HDMI - это использовать программу для копирования необработанных данных из FB0 Accross в FB1. Это относится к любому внешнему дисплее, поэтому этот метод также используется с этими модулями SPI TFT также. Здесь есть какое -то объяснение от парня, который написал модули Spi Tft Kerel для RPI: https: // github.com/notro/fbtft/wiki/fra ... -зеркалирование

Теперь оригинальная программа FBCP была написана этим парнем: https: // github.com/tasanakorn/rpi-fbcp И есть немного лучшая версия (по крайней мере, работает лучше с драйвером Robopeak): https: // github.com/andrewfrommelbourne/raspi2fb

Так куда я направлялся с этим. Поскольку мы уже снимаем снимки FB0 и копируем его, можно ли использовать аналогичную программу, чтобы посмотреть на FB0, сжать и кодировать его, и транслировать ее на наше устройство CDC? Нам вообще не понадобится какого -либо водителя ядра. Что касается RPI.

Мысли?

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

C_D написал:С STM32DUINO мы можем сделать композитное устройство, которое показывает в качестве скрытого для сенсорного экрана, а также CDC для отправки данных экрана?

Саймонф написал:C_D написал: Также вы можете спуститься по маршруту JPEG и использовать этот Декодировать его прямо на дисплей. Я сам не пробовал эту рутину, он говорит, что может декодировать от потока и выводиться на растровое устройство.
Качество не будет слишком скомпрометированным, а средняя рама должна быть около 15 тыс.

На тему серийных дисплеев только что обнаружил это http: // www.Лилипут.com/solution/product ... &pro = 182

Кроме того, я думаю, что понял, почему дисплей Robopeak использует скомпилированный в драйвере ядра. Это очень похоже на метод, используемый USB DisplayLink, отображает драйвер, который уже находится в ядре Mainline. Бьюсь об заклад, они используют некоторые модули, которые уже находятся на месте для вождения, которые отображаются. Это может значительно облегчить поиск x для вывода рабочего стола на экран, что было бы тем, чего хотят большинство конечных пользователей.