Setting Up a small TFT as main display.

Fernando

Hi everybody:

I followed the wiki "TFT Display HATs" and I am able to display a picture on it. Now, In order to get that TFT as main display I am having two issues:

1. Loading fbtft and fbtft_device at startup. Adding the lines to /etc/modules seems do nothing.

2. Setting /dev/fb1 as default display. In other platforms I would add 10-disp.conf to /usr/share/X11/xorg.conf.d, with something like:

Section "Device"
Identifier "DeviceTFT"
Driver        "fbdev"
Option "fbdev" "/dev/fb1"
EndSection

but it doesn't seems to be the way either.

Can you provide me please some help with both issues?.

Thanks.

Fernando

Hi.

Finally I found that the default display can be configured by creating a /usr/share/X11/xorg.conf.d/99-fbturbo.conf.

Thanks.

Ken

I am not sure I get the process here, I am trying to get an AdaFruit PiTFT 3.5" 480x320 working on an UP, and still stuck on how to get the modules to autoload on boot.

I have created an /etc/modules-load.d/fbtft.conf file with the contents:

fbtft
fbtft_device

...and an /etc/modprobe.d/fbtft.conf with the parameter data from the wiki:

options fbtft dma=0
options fbtft_device custom name=fb_hx8357d rotate=270 speed=42000000 buswidth=8 bgr=1 gpios=dc:25 busnum=2

and get these load errors from journalctl -b :

Feb 10 11:54:55 MachineName kernel: fbtft: module is from the staging directory, the quality is unknown, you have been warned.
Feb 10 11:54:55 MachineName kernel: fbtft_device: module is from the staging directory, the quality is unknown, you have been warned.
Feb 10 11:54:55 MachineName kernel: fbtft_device: spi_busnum_to_master(2) returned NULL
Feb 10 11:54:55 MachineName kernel: fbtft_device: failed to register SPI device
Feb 10 11:54:55 MachineName systemd-modules-load[164]: Inserted module 'fbtft'
Feb 10 11:54:55 MachineName systemd-modules-load[164]: Failed to insert 'fbtft_device': Invalid argument

Running it verbatim from the wiki on the command line works fine, but can't seem to get it to autoload this.

WereCatf

At a glance, it looks like the fbtft_device - module is being loaded before the SPI-bus has been brought up. You need to move the loading of the fbtft-modules later in the boot-process. You could try e.g. renaming fbtft.conf into 99-fbtft.conf, which would hopefully postpone it enough.

Dan O'Donovan

Irwin wrote:

...
Feb 10 11:54:55 MachineName kernel: fbtft_device: spi_busnum_to_master(2) returned NULL
Feb 10 11:54:55 MachineName kernel: fbtft_device: failed to register SPI device
...

From this error, I'm guessing that the SPI controller driver hasn't loaded yet (so bus 2 hasn't been registered by the time this module loads).

I suggest inserting the 'spi_pxa2xx_platform' module before fbtft in /etc/modules-load.d/fbtft.conf, to force the SPI controller driver to load first.

I think this one came up in the forum before, but I can't find the post now unfortunately.

Fernando

dan wrote:

I suggest inserting the 'spi_pxa2xx_platform' module before fbtft in /etc/modules-load.d/fbtft.conf, to force the SPI controller driver to load first.

I think this one came up in the forum before, but I can't find the post now unfortunately.

Yes. This way it worked for me. By the way, @Irwin, are you trying to setup the touch functionality?.

Ken

Thx Dan, that did the trick, I know there is a lot translatable between the Pi methods and the Up or Debian methods of doing things, but this is a case where the boot process is kinda hacked up on the Pi, and most of the docs for these things are written about the Pi specifically so they keep referencing things that are Pi specific and not general Debian things, particularly in the boot process.

Ken

ferite wrote:

dan wrote:

I suggest inserting the 'spi_pxa2xx_platform' module before fbtft in /etc/modules-load.d/fbtft.conf, to force the SPI controller driver to load first.

I think this one came up in the forum before, but I can't find the post now unfortunately.

Yes. This way it worked for me. By the way, @Irwin, are you trying to setup the touch functionality?.

I haven't gotten as far as whether touch works or not. Right now I just got my new Up boards and I am working on the first of 3 to replace Pi2s which is what I started with, and frankly found them to be less than ready for more serious applications. So my Pi configuration had the 3.5" hats and the PiFace relay board hats on them, which honestly never got far enough into the project to even get those sorted out. Seemed like all I was doing was replacing purpose hacked kernels all the time. The Up, once, well Up is just another Industrial SBC using off the shelf distributions for the most part, and that is what drew me too them. I want to use these in a couple applications where they really need to be beyond hobby quality parts, like working some Recaro seats for my car project where I want to have them control adjustment servos, work pneumatic valves to inflate lumbar bladders, and handle temperature control for butt warmers. The other project I want to do is replacing flaky electronics in my timed grind and brew coffee maker (of which I have many in queue anticipating failure), which is basically 3 relays and some timers, I want a connected coffee maker that just before my alarm goes off it starts my coffee. So my interest is Driving comfort and Coffee and well as you can see these are mission critical functions and can't be trusted to some cheesy project board oriented towards blinky RPG wear.

Anyway if all goes well there may end up being a dozen of these in my car project, or some combination of these and Up²s and maybe even some of those baby Ups if those happen.

Ken

I updated the wiki with a bunch of stuff if you are interested ferite

Fernando

Hi Irwin.

Thanks for the info. If you spend some time working with the touch functionality in the future, it would be interesting too, if you let us know if you get some advances.

Thanks.