tontec 7 inch lcd touch screen driver supplier
Place the largest green board in front of you below the screen. The power plug, HDMI port, VGA port, and composite video port should face the bottom edge (nearest you). The "TTL OUT" port should be at the top edge (furthest from you). It will be upside-down. Connect the screen"s ribbon to the TTL OUT port, lining it up as is. (To connect, gently pull the 2 black tabs slightly out from the port, gently slide the ribbon"s edge into it, and gently squeeze the black tabs back into place.)
Place the touchscreen in front of you with the wire ribbon towards the bottom edge. It should be right-of-center. Using the 4 color wire cable, connect the smaller end into the touchscreen"s ribbon. The grooved side of the cable should be face-up to line up correctly with the touchscreen"s ribbon.
Good blog on getting this working on Raspberry Pi Model B under Linux: http://karuppuswamy.com/wordpress/2013/01/17/how-to-get-evtouch-touch-screen-kit-working-in-linux/
I recently got a Tontec 2.4-inch TFT LCD 240x320 RGB Pixels Touch Screen Display Monitor For Raspberry Pi from Amazon, and I have no idea how to get it set up. There were no directions included with the touchscreen when it arrived, and the directions given online at Amazon only tell you how to run the software (I think) and give no mention of hooking the display up itself. Any ideas? Should I just plug it in on top of the Pi"s GPIO pins and plug in a power cable in, or do I need to do something else? And can I just run the program, or do I have to do something else? I am fairly new to the Raspberry Pi. Thanks!
Sorry I haven"t replied- I"ve been very busy. I have managed to get this working- I used an external power supply. The first time I looked, I couldn"t find one. I think the reason it didn"t work being powered via USB was because I haven"t been able to find a 2 amp USB power supply, and so I am using a 1 amp power supply, not enough to power the Pi and the touchscreen at the same time. The person on Amazon probably had a 2 amp USB power supply. However, the power supply I found for the touchscreen was 2 amps.
The next problem I have is how to get the touchscreen part working. It just doesn"t do anything when I touch it. And is there any way to add real-time clock capability to it?
Hitechcomputergeek wrote:Sorry I haven"t replied- I"ve been very busy. I have managed to get this working- I used an external power supply. The first time I looked, I couldn"t find one. I think the reason it didn"t work being powered via USB was because I haven"t been able to find a 2 amp USB power supply, and so I am using a 1 amp power supply, not enough to power the Pi and the touchscreen at the same time. The person on Amazon probably had a 2 amp USB power supply. However, the power supply I found for the touchscreen was 2 amps.
The next problem I have is how to get the touchscreen part working. It just doesn"t do anything when I touch it. And is there any way to add real-time clock capability to it?
The manual.txt in the zip file says that the TSC2003 driver (TSC2007) should be in the kernel. It is on the/an i2c bus. (http://www.ti.com/lit/ds/symlink/tsc2003.pdf is the chip handling the touch functionality)
It"s said the touchscreen using a tsc2003 chip could make use of this driver. However, when starting "make" it takes a whole day and night for the RPi for compiling all the modules. But at the end there"s no tsc2007.ko and no tsc_raspi.ko where it should be.
...unfortunately, I got some errors (after around 7 hours of compilation) ;vchi_
It"s said the touchscreen using a tsc2003 chip could make use of this driver. However, when starting "make" it takes a whole day and night for the RPi for compiling all the modules. But at the end there"s no tsc2007.ko and no tsc_raspi.ko where it should be.
...unfortunately, I got some errors (after around 7 hours of compilation) ;vchi_
I just (checked "Misc devices" and) added "videocore VCHIQ" (BCM2708-VCHIQ) as hardlink (but maybe module is enough (?)) in the config (still using "make xconfig") and compilation went further (with no undefined symbols this time). I got a zImage and .ko files (including a tsc2007.ko).
(This post just to say that it is probably not necessary to use a bleeding edge kernel with some special pixie dust to have tsc2007/tsc2003 support. The "normal way" (if there is one) should do : get some sources->configure->build->install)
((In case tsc2007.ko doesn"t work (who knows?) http://osdir.com/ml/linux-kernel/2009-06/msg07628.html was trying to make a tsc2003 driver but it didn"t make its way to the kernel))
( http://kernelnewbies.org/Linux_3.10 -some-release is post jun 2013; the kernel running on 2014-01-07-wheezy-raspbian.zip is more recent; you can "git clone" the latest one if you dare)
(it will copy the .ko files in /lib/modules/
( http://kernelnewbies.org/Linux_3.10 -some-release is post jun 2013; the kernel running on 2014-01-07-wheezy-raspbian.zip is more recent; you can "git clone" the latest one if you dare)
(it will copy the .ko files in /lib/modules/
On 2014-01-07-wheezy-raspbian, apt-cache search linux-source offers 3.2, 3.6, 3.10 (...) kernel sources (but I did not find the running one... (?) - as I remember, linux-source is 3.2)
The building process takes around 7 hours on my machine (and not 10 as I wrote; it is a good idea to check it is still running from time to time; as I power my DHCP server down and the DHCP-lease is not long enough, sometimes, it takes time to recover the ssh link (ssh pi@pi); only the Raspberry Pi and my Ethernet switch/hub stays up, it is silent and low power; curiously I cannot power the switch/hub off without reseting the Raspberry Pi (?) - I don"t know the reason of this)
A detected touchscreen will also cause the fbheight and fbwidth parameters in /proc/cmdline to equal 480 and 800 respectively (the resolution of the screen). You can verify this by running:
Depending on your display stand, you might find that the LCD display defaults to being upside-down. You can fix this by rotating it with /boot/config.txt.
If some windows in X are cut off at the side/bottom of the screen, this is unfortunately a side-effect of developers assuming a minimum screen resolution of 1024x768 pixels.
At the moment you can’t use HDMI and the LCD together in the X desktop, but you can send the output of certain applications to one screen or the other.
Frequently Asked Questions About Tontec 7 Inches Raspberry Pi LCD Touch Screen Display TFT Monitor AT070TN90 with Touchscreen Kit HDMI VGA Input Driver Board in INDIA
Where can I buy Tontec 7 Inches Raspberry Pi LCD Touch Screen Display TFT Monitor AT070TN90 with Touchscreen Kit HDMI VGA Input Driver Board online at the best price in the INDIA?
desertcart is the best online shopping platform where you can buy Tontec 7 Inches Raspberry Pi LCD Touch Screen Display TFT Monitor AT070TN90 with Touchscreen Kit HDMI VGA Input Driver Board from renowned brand(s). desertcart delivers the most unique and largest selection of products from across the world especially from the US, UK and India at best prices and the fastest delivery time.
Is Tontec 7 Inches Raspberry Pi LCD Touch Screen Display TFT Monitor AT070TN90 with Touchscreen Kit HDMI VGA Input Driver Board available and ready for delivery in INDIA?
desertcart ships the Tontec 7 Inches Raspberry Pi LCD Touch Screen Display TFT Monitor AT070TN90 with Touchscreen Kit HDMI VGA Input Driver Board to and more cities in INDIA. Get unlimited free shipping in 164+ countries with desertcart Plus membership. We can deliver the Tontec 7 Inches Raspberry Pi LCD Touch Screen Display TFT Monitor AT070TN90 with Touchscreen Kit HDMI VGA Input Driver Board speedily without the hassle of shipping, customs or duties.
Is it safe to buy Tontec 7 Inches Raspberry Pi LCD Touch Screen Display TFT Monitor AT070TN90 with Touchscreen Kit HDMI VGA Input Driver Board on desertcart?
Yes, it is absolutely safe to buy Tontec 7 Inches Raspberry Pi LCD Touch Screen Display TFT Monitor AT070TN90 with Touchscreen Kit HDMI VGA Input Driver Board from desertcart, which is a 100% legitimate site operating in 164 countries. Since 2014, desertcart has been delivering a wide range of products to customers and fulfilling their desires. You will find several positive reviews by desertcart customers on portals like Trustpilot, etc. The website uses an HTTPS system to safeguard all customers and protect financial details and transactions done online. The company uses the latest upgraded technologies and software systems to ensure a fair and safe shopping experience for all customers. Your details are highly secure and guarded by the company using encryption and other latest softwares and technologies.
A user process (mztx06a) watches changes in the frame buffer and sends them through the SPI bus to the screen. The refresh rate is not intended to display video but is correct for classical GUI. The source code is available on GithubloadFrameBuffer_diff_320(); theimmc proposed the introduction of µsleeps in the loop
To test the touchscreen, commands like evtest (tests the Linux input driver mechanism) and xev (test the touchscreen in the "X" environment) are usefull. xinput-calibrator could be used to calibrate the touchscreen but the result does not seem correct when used with an TransformationMatrix option in /etc/X11/xorg.conf.d/99-calibration.conf.
The "handmade" quick and dirty "calibration" is not perfect but usable in the center of the screen (xinput-calibrator makes things worse; I"ll have to make it by hand, checking left/righ top/bottom and deduce some linear combination. The "TransformationMattrix" is for the original mztx06 code (like a "TV set" with the connectors below and on the left).
It is probably easier to write a "user mode driver" like https://github.com/xofc/tsc2uinput : one reads the tsc2003"s xy(z) through i2c functions and writes "events" in /dev/uinput (you won"t need to care about kernel updates). And it is probably better to emulate a touchpad with relative events as pin-pointing small controls on a resistive tablet is not easy.
In these videos, the SPI (GPIO) bus is referred to being the bottleneck. SPI based displays update over a serial data bus, transmitting one bit per clock cycle on the bus. A 320x240x16bpp display hence requires a SPI bus clock rate of 73.728MHz to achieve a full 60fps refresh frequency. Not many SPI LCD controllers can communicate this fast in practice, but are constrained to e.g. a 16-50MHz SPI bus clock speed, capping the maximum update rate significantly. Can we do anything about this?
The fbcp-ili9341 project started out as a display driver for the Adafruit 2.8" 320x240 TFT w/ Touch screen for Raspberry Pi display that utilizes the ILI9341 controller. On that display, fbcp-ili9341 can achieve a 60fps update rate, depending on the content that is being displayed. Check out these videos for examples of the driver in action:
Given that the SPI bus can be so constrained on bandwidth, how come fbcp-ili9341 seems to be able to update at up to 60fps? The way this is achieved is by what could be called adaptive display stream updates. Instead of uploading each pixel at each display refresh cycle, only the actually changed pixels on screen are submitted to the display. This is doable because the ILI9341 controller, as many other popular controllers, have communication interface functions that allow specifying partial screen updates, down to subrectangles or even individual pixel levels. This allows beating the bandwidth limit: for example in Quake, even though it is a fast pacing game, on average only about 46% of all pixels on screen change each rendered frame. Some parts, such as the UI stay practically constant across multiple frames.
Good old interlacing is added into the mix: if the amount of pixels that needs updating is detected to be too much that the SPI bus cannot handle it, the driver adaptively resorts to doing an interlaced update, uploading even and odd scanlines at subsequent frames. Once the number of pending pixels to write returns to manageable amounts, progressive updating is resumed. This effectively doubles the maximum display update rate. (If you do not like the visual appearance that interlacing causes, it is easy to disable this by uncommenting the line #define NO_INTERLACING in file config.h)
The result is that the SPI bus can be kept close to 100% saturation, ~94-97% usual, to maximize the utilization rate of the bus, while only transmitting practically the minimum number of bytes needed to describe each new frame.
This driver does not utilize the notro/fbtft framebuffer driver, so that needs to be disabled if active. That is, if your /boot/config.txt file has lines that look something like dtoverlay=pitft28r, ..., dtoverlay=waveshare32b, ... or dtoverlay=flexfb, ..., those should be removed.
This program neither utilizes the default SPI driver, so a line such as dtparam=spi=on in /boot/config.txt should also be removed so that it will not cause conflicts.
Likewise, if you have any touch controller related dtoverlays active, such as dtoverlay=ads7846,... or anything that has a penirq= directive, those should be removed as well to avoid conflicts. It would be possible to add touch support to fbcp-ili9341 if someone wants to take a stab at it.
If you have been running existing fbcp driver, make sure to remove that e.g. via a sudo pkill fbcp first (while running in SSH prompt or connected to a HDMI display), these two cannot run at the same time. If /etc/rc.local or /etc/init.d contains an entry to start up fbcp at boot, that directive should be deleted.
-DPIRATE_AUDIO_ST7789_HAT=ON: If specified, targets a Pirate Audio 240x240, 1.3inch IPS LCD display HAT for Raspberry Pi with ST7789 display controller
-DKEDEI_V63_MPI3501=ON: If specified, targets a KeDei 3.5 inch SPI TFTLCD 480*320 16bit/18bit version 6.3 2018/4/9 display with MPI3501 display controller.
-DBACKLIGHT_CONTROL=ON: If set, enables fbcp-ili9341 to control the display backlight in the given backlight pin. The display will go to sleep after a period of inactivity on the screen. If not, backlight is not touched.
-DSTATISTICS=number: Specifies the level of overlay statistics to show on screen. 0: disabled, 1: enabled, 2: enabled, and show frame rate interval graph as well. Default value is 1 (enabled).
Here is a full example of what to type to build and run, if you have the Adafruit 2.8" 320x240 TFT w/ Touch screen for Raspberry Pi with ILI9341 controller:
Perhaps a bit counterintuitively, underclock the core. Setting a smaller core frequency than the default turbo 400MHz can enable using a smaller clock divider to get a higher resulting SPI bus speed. For example, if with default core_freq=400 SPI CDIV=8 works (resulting in SPI bus speed 400MHz/8=50MHz), but CDIV=6 does not (400MHz/6=66.67MHz was too much), you can try lowering core_freq=360 and set CDIV=6 to get an effective SPI bus speed of 360MHz/6=60MHz, a middle ground between the two that might perhaps work. Balancing core_freq= and CDIV options allows one to find the maximum SPI bus speed up to the last few kHz that the display controller can tolerate. One can also try the opposite direction and overclock, but that does then of course have all the issues that come along when overclocking. Underclocking does have the drawback that it makes the Pi run slower overall, so this is certainly a tradeoff.
On the other hand, it is desirable to control how much CPU time fbcp-ili9341 is allowed to use. The default build settings are tuned to maximize the display refresh rate at the expense of power consumption on Pi 3B. On Pi Zero, the opposite is done, i.e. by default the driver optimizes for battery saving instead of maximal display update speed. The following options can be controlled to balance between these two:
The main option to control CPU usage vs performance aspect is the option #define ALL_TASKS_SHOULD_DMA in config.h. Enabling this option will greatly reduce CPU usage. If this option is disabled, SPI bus utilization is maximized but CPU usage can be up to 80%-120%. When this option is enabled, CPU usage is generally up to around 15%-30%. Maximal CPU usage occurs when watching a video, or playing a fast moving game. If nothing is changing on the screen, CPU consumption of the driver should go down very close to 0-5%. By default #define ALL_TASKS_SHOULD_DMA is enabled for Pi Zero, but disabled for Pi 3B.
The CMake option -DUSE_DMA_TRANSFERS=ON should always be enabled for good low CPU usage. If DMA transfers are disabled, the driver will run in Polled SPI mode, which generally utilizes a full dedicated single core of CPU time. If DMA transfers are causing issues, try adjusting the DMA send and receive channels to use for SPI communication with -DDMA_TX_CHANNEL=
If your SPI display bus is able to run really fast in comparison to the size of the display and the amount of content changing on the screen, you can try enabling #define UPDATE_FRAMES_IN_SINGLE_RECTANGULAR_DIFF option in config.h to reduce CPU usage at the expense of increasing the number of bytes sent over the bus. This has been observed to have a big effect on Pi Zero, so is worth checking out especially there.
The option #define RUN_WITH_REALTIME_THREAD_PRIORITY can be enabled to make the driver run at realtime process priority. This can lock up the system however, but still made available for advanced experimentation.
A pleasing aspect of fbcp-ili9341 is that it introduces very little latency overhead: on a 119Hz refreshing ILI9341 display, fbcp-ili9341 gets pixels as response from GPIO input to screen in well less than 16.66 msecs time. I only have a 120fps recording camera, so can"t easily measure delays shorter than that, but rough statistical estimate of slow motion video footage suggests this delay could be as low as 2-3 msecs, dominated by the ~8.4msecs panel refresh rate of the ILI9341.
Unfortunately a limitation of SPI connected displays is that the VSYNC line signal is not available on the display controllers when they are running in SPI mode, so it is not possible to do vsync locked updates even if the SPI bus bandwidth on the display was fast enough. For example, the 4 ILI9341 displays I have can all be run faster than 75MHz so SPI bus bandwidth-wise all of them would be able to update a full frame in less than a vsync interval, but it is not possible to synchronize the updates to vsync since the display controllers do not report it. (If you do know of a display that does actually expose a vsync clock signal even in SPI mode, you can try implementing support to locking on to it)
The codebase captures screen framebuffers by snapshotting via the VideoCore vc_dispmanx_snapshot() API, and the obtained pixels are then routed on to the SPI-based display. This kind of polling is performed, since there does not exist an event-based mechanism to get new frames from the GPU as they are produced. The result is inefficient and can easily cause stuttering, since different applications produce frames at different paces. Ideally the code would ask the VideoCore API to receive finished frames in callback notifications immediately after they are rendered, but this kind of functionality does not exist in the current GPU driver stack. In the absence of such event delivery mechanism, the code has to resort to polling snapshots of the display framebuffer using carefully timed heuristics to balance between keeping latency and stuttering low, while not causing excessive power consumption. These heuristics keep continuously guessing the update rate of the animation on screen, and they have been tuned to ensure that CPU usage goes down to 0% when there is no detected activity on screen, but it is certainly not perfect. This GPU limitation is discussed at raspberrypi/userland#440. If you"d like to see fbcp-ili9341 operation reduce latency, stuttering and power consumption, please throw a (kind!) comment or a thumbs up emoji in that bug thread to share that you care about this, and perhaps Raspberry Pi engineers might pick the improvement up on the development roadmap. If this issue is resolved, all of the #define USE_GPU_VSYNC, #define SAVE_BATTERY_BY_PREDICTING_FRAME_ARRIVAL_TIMES and #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES hacks from the previous section could be deleted from the driver, hopefully leading to a best of all worlds scenario without drawbacks.
Currently if one resizes the video frame size at runtime, this causes DispmanX API to go sideways. See raspberrypi/userland#461 for more information. Best workaround is to set the desired screen resolution in /boot/config.txt and configure all applications to never change that at runtime.
At the moment fbcp-ili9341 is only likely to work on 32-bit OSes, on Raspbian/Ubuntu/Debian family of distributions, where Broadcom and DispmanX libraries are available. 64-bit operating systems do not currently work (see issue #43). It should be possible to port the driver to 64-bit and other OSes, though the amount of work has not been explored.
By default fbcp-ili9341 builds with a statistics overlay enabled. See the video fbcp-ili9341 ported to ILI9486 WaveShare 3.5" (B) SpotPear 320x480 SPI display to find details on what each field means. Build with CMake option -DSTATISTICS=0 to disable displaying the statistics. You can also try building with CMake option -DSTATISTICS=2 to show a more detailed frame delivery timings histogram view, see screenshot and video above.
The fbcp part in the name means framebuffer copy; specifically for the ILI9341 controller. fbcp-ili9341 is not actually a framebuffer copying driver, it does not create a secondary framebuffer that it would copy bytes across to from the primary framebuffer. It is also no longer a driver only for the ILI9341 controller. A more appropriate name might be userland-raspi-spi-display-driver or something like that, but the original name stuck.
I don"t know, I don"t currently have any to test. Perhaps the code does need some model specific configuration, or perhaps it might work out of the box. I only have Pi 3B, Pi 3B+, Pi Zero W and a Pi 3 Compute Module based systems to experiment on. Pi 2 B has been reported to work by users (#17).
If fbcp-ili9341 does not support your display controller, you will have to write support for it. fbcp-ili9341 does not have a "generic SPI TFT driver routine" that might work across multiple devices, but needs specific code for each. If you have the spec sheet available, you can ask for advice, but please do not request to add support to a display controller "blind", that is not possible.
Displays that have a 16-bit wide command word, such as ILI9486, do not currently work in 3-wire ("17-bit") mode. (But ILI9486L has 8-bit command word, so that does work)
No. Those are completely different technologies altogether. It should be possible to port the driver algorithm to work on I2C however, if someone is interested.
At the moment one cannot utilize the XPT2046/ADS7846 touch controllers while running fbcp-ili9341, so touch is mutually incompatible with this driver. In order for fbcp-ili9341 to function, you will need to remove all dtoverlays in /boot/config.txt related to touch.
Yes, fbcp-ili9341 shows the output of the HDMI display on the SPI screen, and both can be attached at the same time. A HDMI display does not have to be connected however, although fbcp-ili9341 operation will still be affected by whatever HDMI display mode is configured. Check out tvservice -s on the command line to check what the current DispmanX HDMI output mode is.
At the moment fbcp-ili9341 has been developed to only display the contents of the main DispmanX GPU framebuffer over to the SPI display. That is, the SPI display will show the same picture as the HDMI output does. There is no technical restriction that requires this though, so if you know C/C++ well, it should be a manageable project to turn fbcp-ili9341 to operate as an offscreen display library to show a completely separate (non-GPU-accelerated) image than what the main HDMI display outputs. For example you could have two different outputs, e.g. a HUD overlay, a dashboard for network statistics, weather, temps, etc. showing on the SPI while having the main Raspberry Pi desktop on the HDMI.
double check that the display controller is really what you expected. Trying to drive with the display with wrong initialization code usually results in the display not reacting, and the screen stays white,
This suggests that the power line or the backlight line might not be properly connected. Or if the backlight connects to a GPIO pin on the Pi (and not a voltage pin), then it may be that the pin is not in correct state for the backlight to turn on. Most of the LCD TFT displays I have immediately light up their backlight when they receive power. The Tontec one has a backlight GPIO pin that boots up high but must be pulled low to activate the backlight. OLED displays on the other hand seem to stay all black even after they do get power, while waiting for their initialization to be performed, so for OLEDs it may be normal for nothing to show up on the screen immediately after boot.
fbcp-ili9341 runs a clear screen command at low speed as first thing after init, so if that goes through, it is a good sign. Try increasing -DSPI_BUS_CLOCK_DIVISOR= CMake option to a higher number to see if the display driving rate was too fast. Or try disabling DMA with -DUSE_DMA_TRANSFERS=OFF to see if this might be a DMA conflict.
This suggests same as above, increase SPI bus divisor or troubleshoot disabling DMA. If DMA is detected to be the culprit, try changing up the DMA channels. Double check that /boot/config.txt does not have any dtoverlays regarding other SPI display drivers or touch screen controllers, and that it does NOT have a dtparam=spi=on line in it - fbcp-ili9341 does not use the Linux kernel SPI driver.
Double check the Data/Command (D/C) GPIO pin physically, and in CMake command line. Whenever fbcp-ili9341 refers to pin numbers, they are always specified in BCM pin numbers. Try setting a higher -DSPI_BUS_CLOCK_DIVISOR= value to CMake. Make sure no other fbcp programs or SPI drivers or dtoverlays are enabled.
The Frame Rate column shows the worst case frame rate when full screen updates are being performed. This occurs for example when watching fullscreen video (that is not a flat colored cartoon). Because fbcp-ili9341 only sends over the pixels that have changed, displays such as HX8357D and ILI9486 can still be used to play many games at 60fps. Retro games work especially well.
All the ILI9341 displays work nice and super fast at ~70-80MHz. My WaveShare 3.5" 320x480 ILI9486 display runs really slow compared to its pixel resolution, ~32MHz only. See fbcp-ili9341 ported to ILI9486 WaveShare 3.5" (B) SpotPear 320x480 SPI display for a video of this display in action. Adafruit"s 320x480 3.5" HX8357D PiTFTs is ~64% faster in comparison.
The ILI9486L controller based maithoga display runs a bit faster than ILI9486 WaveShare, 50MHz versus 31.88MHz, i.e. +56.8% bandwidth increase. However fps-wise maithoga reaches only 13.56 vs WaveShare 12.97 fps, because the bandwidth advantage is fully lost in pixel format differences: ILI9486L requires transmitting 24 bits per each pixel (R6G6B6 mode), whereas ILI9486 supports 16 bits per pixel R5G6B5 mode. This is reflected in the above chart refresh rate for the maithoga display (marked with a star).
The KeDei v6.3 display with MPI3501 controller takes the crown of being horrible, in all aspects imaginable. It is able to run at 33.33 MHz, but due to technical design limitations of the display (see #40), effective bus speed is halved, and only about 72% utilization of the remaining bus rate is achieved. DMA cannot be used, so CPU usage will be off the charts. Even though fbcp-ili9341 supports this display, level of support is expected to be poor, because the hardware design is a closed secret without open documentation publicly available from the manufacturer. Stay clear of KeDei or MPI3501 displays.
The Tontec MZ61581 controller based 320x480 3.5" display on the other hand can be driven insanely fast at up to 140MHz! These seem to be quite hard to come by though and they are expensive. Tontec seems to have gone out of business and for example the domain itontec.com from which the supplied instructions sheet asks to download original drivers from is no longer registered. I was able to find one from eBay for testing.
Improve support for 3-wire displays, e.g. for 1) "17-bit" 3-wire communication, 2) fix up SPI_3WIRE_PROTOCOL + ALL_TASKS_SHOULD_DMA to work together, or 3) fix up SPI_3WIRE_PROTOCOL + OFFLOAD_PIXEL_COPY_TO_DMA_CPP to work together.
This driver is licensed under the MIT License. See LICENSE.txt. In nonlegal terms, it"s yours for both free and commercial projects, DIY packages, kickstarters, Etsys and Ebays, and you don"t owe back a dime. Feel free to apply and derive as you wish.
I recently got a Tontec 2.4-inch TFT LCD 240x320 RGB Pixels Touch Screen Display Monitor For Raspberry Pi from Amazon, and I have no idea how to get it set up. There were no directions included with the touchscreen when it arrived, and the directions given online at Amazon only tell you how to run the software (I think) and give no mention of hooking the display up itself. Any ideas? Should I just plug it in on top of the Pi"s GPIO pins and plug in a power cable in, or do I need to do something else? And can I just run the program, or do I have to do something else? I am fairly new to the Raspberry Pi. Thanks!
Sorry I haven"t replied- I"ve been very busy. I have managed to get this working- I used an external power supply. The first time I looked, I couldn"t find one. I think the reason it didn"t work being powered via USB was because I haven"t been able to find a 2 amp USB power supply, and so I am using a 1 amp power supply, not enough to power the Pi and the touchscreen at the same time. The person on Amazon probably had a 2 amp USB power supply. However, the power supply I found for the touchscreen was 2 amps.
The next problem I have is how to get the touchscreen part working. It just doesn"t do anything when I touch it. And is there any way to add real-time clock capability to it?
Hitechcomputergeek wrote:Sorry I haven"t replied- I"ve been very busy. I have managed to get this working- I used an external power supply. The first time I looked, I couldn"t find one. I think the reason it didn"t work being powered via USB was because I haven"t been able to find a 2 amp USB power supply, and so I am using a 1 amp power supply, not enough to power the Pi and the touchscreen at the same time. The person on Amazon probably had a 2 amp USB power supply. However, the power supply I found for the touchscreen was 2 amps.
The next problem I have is how to get the touchscreen part working. It just doesn"t do anything when I touch it. And is there any way to add real-time clock capability to it?
The manual.txt in the zip file says that the TSC2003 driver (TSC2007) should be in the kernel. It is on the/an i2c bus. (http://www.ti.com/lit/ds/symlink/tsc2003.pdf is the chip handling the touch functionality)
It"s said the touchscreen using a tsc2003 chip could make use of this driver. However, when starting "make" it takes a whole day and night for the RPi for compiling all the modules. But at the end there"s no tsc2007.ko and no tsc_raspi.ko where it should be.
...unfortunately, I got some errors (after around 7 hours of compilation) ;vchi_
It"s said the touchscreen using a tsc2003 chip could make use of this driver. However, when starting "make" it takes a whole day and night for the RPi for compiling all the modules. But at the end there"s no tsc2007.ko and no tsc_raspi.ko where it should be.
...unfortunately, I got some errors (after around 7 hours of compilation) ;vchi_
I just (checked "Misc devices" and) added "videocore VCHIQ" (BCM2708-VCHIQ) as hardlink (but maybe module is enough (?)) in the config (still using "make xconfig") and compilation went further (with no undefined symbols this time). I got a zImage and .ko files (including a tsc2007.ko).
(This post just to say that it is probably not necessary to use a bleeding edge kernel with some special pixie dust to have tsc2007/tsc2003 support. The "normal way" (if there is one) should do : get some sources->configure->build->install)
((In case tsc2007.ko doesn"t work (who knows?) http://osdir.com/ml/linux-kernel/2009-06/msg07628.html was trying to make a tsc2003 driver but it didn"t make its way to the kernel))
( http://kernelnewbies.org/Linux_3.10 -some-release is post jun 2013; the kernel running on 2014-01-07-wheezy-raspbian.zip is more recent; you can "git clone" the latest one if you dare)
(it will copy the .ko files in /lib/modules/
( http://kernelnewbies.org/Linux_3.10 -some-release is post jun 2013; the kernel running on 2014-01-07-wheezy-raspbian.zip is more recent; you can "git clone" the latest one if you dare)
(it will copy the .ko files in /lib/modules/
On 2014-01-07-wheezy-raspbian, apt-cache search linux-source offers 3.2, 3.6, 3.10 (...) kernel sources (but I did not find the running one... (?) - as I remember, linux-source is 3.2)
The building process takes around 7 hours on my machine (and not 10 as I wrote; it is a good idea to check it is still running from time to time; as I power my DHCP server down and the DHCP-lease is not long enough, sometimes, it takes time to recover the ssh link (ssh pi@pi); only the Raspberry Pi and my Ethernet switch/hub stays up, it is silent and low power; curiously I cannot power the switch/hub off without reseting the Raspberry Pi (?) - I don"t know the reason of this)
A user process (mztx06a) watches changes in the frame buffer and sends them through the SPI bus to the screen. The refresh rate is not intended to display video but is correct for classical GUI. The source code is available on GithubloadFrameBuffer_diff_320(); theimmc proposed the introduction of µsleeps in the loop
To test the touchscreen, commands like evtest (tests the Linux input driver mechanism) and xev (test the touchscreen in the "X" environment) are usefull. xinput-calibrator could be used to calibrate the touchscreen but the result does not seem correct when used with an TransformationMatrix option in /etc/X11/xorg.conf.d/99-calibration.conf.
The "handmade" quick and dirty "calibration" is not perfect but usable in the center of the screen (xinput-calibrator makes things worse; I"ll have to make it by hand, checking left/righ top/bottom and deduce some linear combination. The "TransformationMattrix" is for the original mztx06 code (like a "TV set" with the connectors below and on the left).
It is probably easier to write a "user mode driver" like https://github.com/xofc/tsc2uinput : one reads the tsc2003"s xy(z) through i2c functions and writes "events" in /dev/uinput (you won"t need to care about kernel updates). And it is probably better to emulate a touchpad with relative events as pin-pointing small controls on a resistive tablet is not easy.
Thanks for bringing this to my attention. It appears that the upgrade package overwrites the FBTFT drivers, in particular, the Raspberry Pi bootloader. This seems to solve the problem:
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait fbtft_device.custom fbtft_device.name=waveshare32b fbtft_device.gpios=dc:22,reset:27 fbtft_device.bgr=1 fbtft_device.speed=48000000 fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo dma.dmachans=0x7f35 console=tty1 consoleblank=0 fbtft_device.fps=50 fbtft_device.rotate=0
Unfortunately, their “driver” is an SD card image containing a complete installation of Raspbian which has been preconfigured to use their display. Which is fine if you’re setting up a brand new system that doesn’t need to be a specific distro, but if you’re trying to add the display to an existing Raspberry Pi, already configured the way you want it, with software installed and data present, or if you want to use a specific distro such as Octopi, then it’s not terribly helpful.
Hello..I tired to interface this lcd “https://www.crazypi.com/raspberry-pi-products/Raspberry-Pi-Accessories/32-TOUCH-DISPLAY-RASPBERRY-PI” to my Raspberry pi model B+.I got a DVD containing image for LCD in the package.I burned it to the SD card and plugged in the display.But my lcd is completly blank.But green inidcation led (ACT LED) in board is blinking.Why my LCD is Blank ?
If you have tried using the manufacturers image and the screen doesn’t work, it could be that the screen has a hardware malfunction. If the process above doesn’t work either, I would contact the manufacturer
Is your RED (POWER) LED on? I had the same problem. Green Led was blinking and screen was white. Then I noticed RED Led is off, indicating there’s something wrong with the power. I plugged into different port and it started
Yes, it may be that the screen isn’t supported. Newer screens might not have drivers yet. I do know it is possible to make your own driver but that’s above my level of knowledge :)
My Touchscreen is now working fine.The problem was for the ribbon cable on the back side of LCD.It was not connected properly.I just tighted the cable and it worked fine.Hope it will be useful tip.
Thank you for this great tutorial. I looked everywhere for this information. I have an eleduino 3.5 version A. I was able to get it working on my Pi 2 by following your tutorial and using flexfb as the screen type. I got the other settings from the image that came with the product. I did find that the ts_calibrate didn’t recognize the screen so I installed xinput-calibrator and it worked fine.
Just got my Pi2 running Wheezy, working with the Eleduino 3.5 LCD without running the OEMs image… kinda. I didn’t want to rebuild the application environment again, so was avoiding flashing the SD.
I tried the steps in this tutorial. It’s very clear and easy to follow, thank you. But it didn’t work for me, I tried setting my device to flexfb. Only got white screen.
[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa21041 bcm2709.serial=0x631a4eae smsc95xx.macaddr=B8:27:EB:1A:4E:AE bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fbtft_device.custom fbtft_device.name=flexfb fbtft_device.gpios=dc:22,reset:27 fbtft_device.bgr=1 fbtft_device.speed=48000000 fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo dma.dmachans=0x7f35 console=tty1 consoleblank=0 fbtft_device.fps=50 fbtft_device.rotate=0
thank you for your great tutorial, it got me on the right way. unfortunataly i only see some boot messages on the lcd and then it turns black. maybe you could give me a hint on how to get it working entirely.
Did you check to see if your device is supported yet? The device name should be specific for your screen, as listed in the fbtft file linked to in the beginning of the post
I too have a raspberry pi 2, and a waveshare spotpear 3.2 RPi lcd (v3) and I just can’t get it to work! I suspect I have a faulty LCD, but thought I’ll try this forum for help before I sent it back.
Soon as the pi is powered, the LCD lights up all white, with a few vertical pixels coloured at one of the edges, and nothing else. I don’t think that should happen – not at least before the BOIS has started up.
[ 0.000000] Linux version 3.18.5-v7+ (pi@raspi2) (gcc version 4.8.3 20140106 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.01 – Linaro GCC 2013.11) ) #1 SMP PREEMPT Fri Feb 6 23:06:57 CET 2015
It seems all appears to be working – just the LCD is still all white with a single line of coloured pixels on edge) and nothing else. Is there a way to output, like jeff G script, of touch points?
I had the same one, I finally found a driver for it here: http://www.waveshare.net/wiki/3.2inch_RPi_LCD_(B) you will need to translate the page, but unpack the driver then run sudo ./LCD-show/LCD32-show. It should reboot and all will be good with the screen :)
Can anyone let me know if the default OS image sent with the screen works with pi2 or just Pi B/B+ as i think my screen maybe broken but can’t confirm it yet as i have not had it working at all
My system: Raspberry Pi 2 Model B with Raspian Wheezy from Febuary 2015. LCD display of Sainsmart 3.2 http://www.conrad.de/ce/de/product/1283498/Raspberry-Pi-Display-Modul-Touch-Display-81-cm-32/?ref=home&rt=home&rb=1
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 cgroup_enable=memory elevator=deadline rootwait fbtft_device.custom fbtft_device.name=sainsmart32_spi fbtft_device.gpios=dc:24,reset:25 fbtft_device.bgr=1 fbtft_device.speed=48000000 fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo dma.dmachans=0x7f35 console=tty1 consoleblank=0 fbtft_device.fps=50 fbtft_device.rotate=90
sainsmart32_spi width=320 height=240 buswidth=8 init=-1,0xCB,0x39,0x2C,0x00,0x34,0x02,-1,0xCF,0x00,0XC1,0X30,-1,0xE8,0x85,0x00,0x78,-1,0xEA,0x00,0x00,-1,0xED,0x64,0x03,0X12,0X81,-1,0xF7,0x20,-1,0xC0,0x23,-1,0xC1,0x10,-1,0xC5,0x3e,0x28,-1,0xC7,0x86,-1,0×36,0x28,-1,0x3A,0x55,-1,0xB1,0x00,0x18,-1,0xB6,0x08,0x82,0x27,-1,0xF2,0x00,-1,0×26,0x01,-1,0xE0,0x0F,0x31,0x2B,0x0C,0x0E,0x08,0x4E,0xF1,0x37,0x07,0x10,0x03,0x0E,0x09,0x00,-1,0XE1,0x00,0x0E,0x14,0x03,0x11,0x07,0x31,0xC1,0x48,0x08,0x0F,0x0C,0x31,0x36,0x0F,-1,0×11,-2,120,-1,0×29,-1,0x2c,-3
ads7846_device model=7846 cs=1 gpio_pendown=23 speed=2000000 keep_vref_on=1 swap_xy=1 pressure_max=255 x_plate_ohms=60 x_min=300 x_max=3800 y_min=700 y_max=3400
The LCD display shows the raspberry correctly. However, the touch screen input does not work. The mouse pointer can I move correctly with your finger, but I can not select things (function of the left mouse button).
Can someone upload SD card image that works with RBP2 ? My idea is to use Eleduino TFT as additional screen and play movies via HDMI.. is it possible?
Do not follow this article when you don’t know what kind of LCD module. In my case, I follow all of this and my raspberry pi cannot boot anymore. I will try to recover, but I think I should format my SD card and reinstall OS.
Expecting this would builtin driver module within kernel and help with avoiding mistakenly overwriting anything. But with this is cause LCD screen to go blank white and no boot activity. Also noticed on HDMI it get stuck on Initial rainbow screen and stuck on that.
Does anyone tried splash boot screen with waveshare v4 LCD and Rpi2? I tried to follow some example from https://github.com/notro/fbtft/wiki/Bootsplash but no success.
Great tutorial thanks; got an X session working great 1st time. Has anybody managed to get Kodi/XMBC working on the LCD either Kodi standalone, Raspbmc or Xbian?
fbtft_device name=waveshare32b gpios=dc:22,reset:27 speed=48000000 width=320 height=240 buswidth=8 init=-1,0xCB,0x39,0x2C,0x00,0x34,0x02,-1,0xCF,0x00,0XC1,0X30,-1,0xE8,0x85,0x00,0x78,-1,0xEA,0x00,0x00,-1,0xED,0x64,0x03,0X12,0X81,-1,0xF7,0x20,-1,0xC0,0x23,-1,0xC1,0x10,-1,0xC5,0x3e,0x28,-1,0xC7,0x86,-1,0×36,0x28,-1,0x3A,0x55,-1,0xB1,0x00,0x18,-1,0xB6,0x08,0x82,0x27,-1,0xF2,0x00,-1,0×26,0x01,-1,0xE0,0x0F,0x31,0x2B,0x0C,0x0E,0x08,0x4E,0xF1,0x37,0x07,0x10,0x03,0x0E,0x09,0x00,-1,0XE1,0x00,0x0E,0x14,0x03,0x11,0x07,0x31,0xC1,0x48,0x08,0x0F,0x0C,0x31,0x36,0x0F,-1,0×11,-2,120,-1,0×29,-1,0x2c,-3
ads7846_device model=7846 cs=1 gpio_pendown=17 speed=1000000 keep_vref_on=1 swap_xy=0 pressure_max=255 x_plate_ohms=60 x_min=200 x_max=3900 y_min=200 y_max=3900
After following this tut to the letter on a brand new image of Raspian, I find that the touch driver does not function. Anyone experience the same? Basically all I did was image a current copy of rasping, did a apt-get upgrade, and then did this tutorial. Then the touch driver does not work, meaning the pointer does not respond.
The reason I did this was because on a production version of my system I added the 3.2 screen and it worked great except for the x-axis. So I wanted to see if there was something in my system that was interfering or if this is another error. Now with a raw rasping the driver does not work at all. I wonder if the touch pin has changed since the kernel is using BCM pins instead of GPIO pin numbers?
I have exactly the same problem. I also installed a new version of Raspbian, and the LCD part works fine (except all the windows are way too large), but the touch part doesn’t work at all… I’m using Waveshare Spotpear 3.2″ V4.
I remember that I plugged in the screen wrongly one time, before configuring any of the GPIO pins. Can this have damaged the screen? Still it’s weird that the display part works well and the touch part not at all.
Touch actually goes through one of the SPI pins I think. Either the driver is toast with the required kernel update or the driver is using the wrong pin. It is very likely the this works well with previous raspian versions, but not with the new B+ and with the new kernel.
I am trying to use the sainsmart 2.8″ lcd sold through microcenter, using the sainsmart32_spi … seems to have the same pinouts, should I be able to get this to work? I am stuck at the white out screen on the lcd, doesn’t seem to recognize the module either.
The SainSmart 3.2 sold by MicroCenter (20-111-971) is actually the exact same WaveShare SpotPear v3 documented here. So maybe your 2.8 would work if you tried a WaveShare driver?
Unfortunately I’ve tried that ( a few times actually) but the file still doesn’t exist. Thanks very much for the assistance anyway. I must be doing something wrong. My Raspian came from a Noobs installation, I’m wondering if I should try installing the OS from somewhere else. My LCD screen didn’t come with a CD or any docs so I’m completely in the dark here.
I have just found a way to get this file on my system! Apparently its part of the fbturbo installation. I found it here http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=45746&start=75 (under experimental enhanced x driver (rpifb).. Sorry if this is obvious to everyone but I am SUCH a noob at this!!
I have the waveshare 3.5 and what to use it only as a secondary screen by putting measurement data with a c program on the screen. Is there any solution?
Ok, what am I doing wrong. I am using a fresh install of the newest raspbian, on a Pi 2. After doing the first two steps and rebooting I get the rainbow screen, then the boot up process, and then my screen just goes black with a flashing cursor in the top left. I am not able to enter any commands or anything…like the pi is halting just after boot up. Any thoughts/suggestions would be greatly appreciated. Thanks.
Well figured out that step 1 was causing my problems. I’m guessing it is shutting off my hdmi feed and trying to switch it over to the SPI, am I guessing right? If so, not sure how I’m suppose to complete the rest of the steps if my hdmi output gets turned off before the LCD is actually set up to work…that sounds kind of smartass-like, which is not my intention, just looking for some clarification on what is going on in that first step as I am fairly new to this stuff. Thanks.
Anyway, I was able to do the rest of the steps with no problem. LCD didn’t work, but I am using a Waveshare 3.5, which doesn’t look to be supported yet. Mostly I am trying to play around and see if I can get it working somehow. Anyone found a way to do this yet?
Here is a link to an updated image from waveshare. Upon install it got the display up and running, but I still do not have touch functionality. I’ve been playing around with it, but it has been to no avail…hopefully someone better at this stuff from me can get the touch working.
I am having an issue with getting the GUI back. Every time I use startx my pi just sits there for about two minutes saying “No protocol specified”, and then it just gives up. I went through this tutorial about four times now and am not certain why it is doing this. I have the exact same LCD as is in the tutotial (WaveShare 3.2b). any help would be great.
Hi I am making a project for school,using the raspberry pi b+ and waveshare spotpare 3.2b. Everything works except the touch input doesn’t work. Any help would be appreciated very much.
Thanks for the tutorial. It works, but I get the boot/command line stuff on the HDMI monitor and the LCD only comes on when I do startx. Is there a way to get everything to appear on the LCD screen?
I am trying to get this same screen to work with the image of RetroPie 2.6 and it won’t work. I have followed all the steps and nothing, please help I an kinda a noob.
I have a Tontec 7 inch touchscreen with a Raspberry Pi 2 B. After following the instructions the touch screen is functioning but not properly… The only are that works is the upper left (and only a small area of that). I tried changing the width and height in the modules but it didnt change anything. Also the xy seems to be reversed, I changed the swap_xy to 1 but again no change on the screen.
Now the OS freezes at the emulation station loading screen, and if I connect my lcd it gives me a lot of error messages which I can only see on the 3.2 inch screen.
hi i have the same screen with a raspberry pi 2 im trying to run retro pie but it wont show ..however it shows all the commands …but i cant get it to show the gui …if u guys can make an image or something please i have been in this pain for two weeks already thank you
Damn.. I thought I was kickin ass haha. I am using the SainSmart 3.2″.. the backlight is lit up and the pi was booting and everything just fine but on the final reboot it gets hung and says “nonblocking pool is initialized” ?? No idea what that means. But it’s def just frozen at this point.. on my main screen, and just the backlight is on the SainSmart.
This was an excellent tutorial. I have gotten an output to the screen, but no touchscreen usage . I have the Waveshare SpotPear 3.2 Inch LCD V4 screen, but using Raspberry PI 2 with wheezy. Any ideas?
Thanks a lot for this article. Very clear and easy . I am new in pi’s world and my 3.2″ screen is working fine. I rotate 90 º and works. I can use mouse and so on.Not problems.
I filed the steps to calibrate the screen but it did not work.I think because it did not find the TFT pin, because I think the touch problem is the assigned pin to control it changed.
I actually used the driver from here http://www.waveshare.com/wiki/3.2inch_RPi_LCD_(B) , from a new wheezy build, did nothing except enable SPI in config, install driver, and change mmcblk0p2 to mmcblk0p6 in cmdline.txt and it all worked, no drama.
Hi I managed to set up my touch screen ok but I now have the issue that everything desktop fits fine but the windows I open are all huge and I can’t remember how to change the size and cannot see the option in desktop preferences any idea what I have to do and is it at all possible to install kodi to run through the raspbian is as this would be a lot my useful than having to keep swapping os on every boot up many thanks in advanced hope you can help me
Advice to all who have the drivers from the (touch)screen manufacturer and cannot obtain those otherwise: you can skip everything and go to the update steps skipping the kernel and kernel modules update (as mentioned by the author) so that you don’t override the preinstalled drivers. I have a Waveshare 3.5″ RPi v3 (not the 3.2″ supported by notro’s drivers) and actually managed without any problems to get notro’s drivers make it work. However I am still reading about the xinput and xinput-calibrator to figure out how to include it as a kernel module so that I can compile my own kernel and add it there.
i have raspberry pi 2 with 3.2 inch rpi lcd v4 waveshare spotpear.i have done as per your instructions.the display is working but touch screen not working.error shows waveshare32b module not found as well as touch screen module not found messages.
Unfortunately I have lost the Touch facility on my Waveshare 3.5″ LCD Touchscreen? Can you offer any reasons as to why? I copied the Raspbian image to my Raspberry Pi from the Waveshare website first of all. The Touchscreen displays but is not reactive with any touch
Hi great article thanks. I am trying to get a waveshare 7 inch LCD with capacitive touch running it works with the suppled image but if you upgrade it breaks the capacitive touch. I have a sense-hat and GPS which require the latest kernel and RASPIAN image and the install program for the screen replaces the /lib/modules directory and the kernel with older ones. I need to be able to install the touch drivers into a new clean OS can anyone give me some pointers? Thanks
I should add that the screen is plugged into the HDMI port and always works. The capacitive touch is driven from the USB port which also supplies power.
For anyone who have those unbranded cheap TFT touch modules and cannot get it to work with this guide, I had success on my 3.5″ with the following steps: http://pastebin.com/89qmFbPB
So I have the original image that came with my screen and it works fine with the LCD but my problem is that I want to use my LCD screen with other distros (at this time I am trying to use it with Kali Linux with TFT support by default https://www.offensive-security.com/kali-linux-vmware-arm-image-download/) What do I have to do to transfer the needed files from the original image that WORKS with the screen and use them with another image?
I originally bought this bundle http://www.amazon.com/gp/product/B013E0IJUK?psc=1&redirect=true&ref_=oh_aui_detailpage_o02_s00 with an RPi LCD V3 and no extra documentation on the specifics on the chipset. I tried with the bftft drivers but since I have no idea what to call this screen I just suppose it isn’t supported.
After 4 lost days I just decided to get another screen, a Waveshare 3.2 (just like the one on this tutorial), I’ll follow these steps and see if it work for me.
I’ve followed your instructions and am only getting a white screen stil. I am using the Osoyoo 3.5 inch touchscreen from Amazon. http://www.amazon.com/gp/product/B013E0IJVE?psc=1&redirect=true&ref_=oh_aui_detailpage_o01_s00
I’m not sure if the Jessie kernel is compatible – can anyone please confirm or not ?? Adafruit states that their setup for TFT screens are Wheezy only ; is this a different setup ??
I am using the same LCD and followed your tutorial. Have your tested the guide lately? Are you certain that it works? I see the boot messages on console but I get white screen as GUI starts.
Oct 16 17:38:48 spare kernel: [ 12.544859] graphics fb1: fb_ili9340 frame buffer, 320×240, 150 KiB video memory, 4 KiB DMA buffer memory, fps=50, spi0.0 at 48 MHz
After I rebooted in step 3, my raspberry pi won’t boot up again. It goes thru the process of booting and the text scrolls down and every thing says “ok”. Then instead of going to GUI it just guys to a black screen on my monitor with a blinking underscore in the top left corner. Anyway to get around this? or should I start over with a fresh disk image??
I have tried to set up waveshare 32b on my Pi B using the latest Raspian download. I learned a lot in the process using Windows Putty, Nano etc. I have repeated the setup process several times from scratch and included the corrections for possible overwriting. My Waveshare SpotPear 3.2 inch RPi LCD V4 just shows a white screen. Any suggestions?
I’d suggest that you use the included installation disk to make a clean install on another SD card to see if the screen itself works fine or not, then try to repeat the process of installation after upgrading
There was no disk included. I asked for drivers and was given a download link to the image file. After down loading this I tried it and still got just a white screen. The HDMI monitor locks partway though the boot. I can still log in to pi using putty from my PC.
This process worked for me except for two things. The screen only shows 25* of any page so the most important buttons are inaccessible, and now the Wifi does not work and cannot be activated where it worked fine before the reboot. Any suggestions?
Hi, I am using raspberry pi 2 with raspbian jessie installed. I the waveshare spotpear 3.2 v4. The above instructions are not working. and after completing the steps there was no display from hdmi or lcd. One things to notify is.: the etc/modules files only had i2c-dev and not snd-bcm2835.
I am trying to get this to work with Retro Pie 3.3.1 and the Waveshare3.2″ v4 but I only get the terminal on the lcd and emulation station starts on hdmi. to get it working with retro pie i just replaced startx with emulationstation. how do i get this to work?
Sir, Your post has very useful to me. i am using Tinylcd. but i cant get display. i am performing all the steps in your post. i cant get touch controller information from the product website and also i am using RASPberryPi B+ model. could u please give me best solution to my work. Than you.
Hi, what if you dont know the make of your screen, i purchased via Ebay, and it is unbranded, the contact speaks barely any English and keeps linking me to a custom kernal download.
what if OS is not Raspbian, any other distro like Yocto project, etc.? Could you please specify process without “rpi-update” that makes driver installation process more generic, not dedicated to Raspbian.
i installed android OS in raspberry pi 2. can i use same LCD touch screen set up for android installed raspberry pi 2 which you are used for raspbian.
Is it normal the white back light during the whole process of initializing (I suspect that during the transportation trere is a deffect)? The problem is that I missed the step #1 and I performed it at the end. Unfortunately I don’t have any monitor available right now – neither “normal”, neither LCD :))))). Is it possible turning back the system or the only option is reinstallation of the Raspbian?
I have KeDei 3.5 inch TFT version 4.0 by Osoyoo. (released after January 1 2016) how do i get it working with vanilla Raspbian Jessie (do not want to install the image sent by the seller)
I’m trying to use an original Raspberry Pi model B with a cheap 3.5 inch 320×480 LCD which allegedly was manufactured to work with the Pi and has the correct fittings to fit over the GPIO pins. The operating system is the latest, downloaded yesterday and installed with NOOBS. I can’t get past step 2 of this guidance. When I reboot after using raspi-config I can see text generated as the Pi boots, then the HDMI fed screen goes blank apart from a flashing cursor in the top left hand corner. The LCD just remains white with nothing else on it. I have missed out step 1 and rebooted after step 2 and the screen functions as I would expect. Does anyone have any ideas please?
Thanks for the great tutorial. I do have a question. Once you install the drivers for the lcd are you effectively disabiling the hdmi port or is it still available to use and will the pi function with both displays. I have a pi 3
once you install the drivers it replaces the kernel by disabling hdmi output and enables it for LCD. i don’t think we have a solution to get em both working at the same time. ( you are encouraged to search for it )
Thanks for the guide, have been doing this with my son but once we leave raspi config and reboot all we get is a black screen with a flashing white horizontal line (dash). Can you help? I have looked in the comments at the end of the article but no one else appears to have this issue.
I have a raspberry pi 2 with waveshare screenn 3.5 inches. Isn’t it the same instructions. But it isnt working, all i get is a white screen, and the red led on the pi is on. The green LED isnot working.
My Rpi3 gets “ERROR: could not insert ‘spi_bcm2708’: No such device” after I enable SPI in the raspi-config.My Rpi3 is freezing on the rainbow screen after I reboot at the end of step 3. I’ve tried adding boot_delay=1 to config.txt.
if any interested, now i have a raspian image working on raspberry 3 with Waveshare 3.5, also with sdr support for dongles and FreqShow working perfectly on touch
I tried following your tutorial but I got stuck right at the first step… I enter sudo nano /usr/share/X11/xorg.conf.d/99-fbturbo.conf the whole screen is blank except for the command list at the bottom…
waveshare32b width=320 height=240 buswidth=8 init=-1,0xCB,0x39,0x2C,0x00,0x34,0x02,-1,0xCF,0x00,0XC1,0X30,-1,0xE8,0x85,0x00,0x78,-1,0xEA,0x00,0x00,-1,0xED,0x64,0x03,0X12,0X81,-1,0xF7,0x20,-1,0xC0,0x23,-1,0xC1,0x10,-1,0xC5,0x3e,0x28,-1,0xC7,0x86,-1,0×36,0x28,-1,0x3A,0x55,-1,0xB1,0x00,0x18,-1,0xB6,0x08,0x82,0x27,-1,0xF2,0x00,-1,0×26,0x01,-1,0xE0,0x0F,0x31,0x2B,0x0C,0x0E,0x08,0x4E,0xF1,0x37,0x07,0x10,0x03,0x0E,0x09,0x00,-1,0XE1,0x00,0x0E,0x14,0x03,0x11,0x07,0x31,0xC1,0x48,0x08,0x0F,0x0C,0x31,0x36,0x0F,-1,0×11,-2,120,-1,0×29,-1,0x2c,-3
<
Ms.Josey 
Ms.Josey