sainsmart 3.2 tft lcd display raspberry pi 2 free sample

The 3.2 inch TFT LCD module is a special design for Raspberry Pi for portable application. It features a 3.2” display with 320x240 16bit color pixels and resistive touch screen. The LCD is well mated with Pi board and interface with Pi via the high speed SPI port, and support console, X windows, displaying images or video etc. It also provides 4 press buttons for user defined functions.

RPi LCD needs to use a SPI interface, but in the original image file of Raspberry Pi, the displayer is driven via a HDMI port. So the original image is not applicable for RPi LCD, and you should install the LCD driver to your Pi or use the Ready-to-use image file provided by Sainsmart,click here.

Download the LCD driver and extract it to your Raspbian OS (e.g. copy the driver to your Pi by sftpor using U disk). Then run the following command via putty:

This LCD can be calibrated using a program called xinput_calibrator which is pre-installed on the offer image. However, it was not pre-installed on original Raspbian OS. So in this case, you should get and install the program manually with

After running these commands, there will be a prompt for four-point calibration shown in the LCD screen. Click the points one by one to finish the touch calibration. Then, the new calibration data will be displayed in the terminal, as shows below. Please get these data for future use.

The 3.2 inch TFT LCD module is a special design for Raspberry Pi for portable application. It features a 3.2” display with 320x240 16bit color pixels and resistive touchscreen.

The 3.2 inch TFT LCD module is a special design for Raspberry Pi for portable application. It features a 3.2” display with 320x240 16bit color pixels and resistive touchscreen.

The 3.2 inch TFT LCD module is a special design for Raspberry Pi for portable application. It features a 3.2�display with 320x240 16bit color pixels and resistive touch screen. The LCD is well mated with Pi board and interface with Pi via the high speed SPI port, and support console, X windows, displaying images or video etc. It also provides 4 press buttons for user defined functions.

Our Raspberry Pi team have therefore developed a lot of accessories for Pi, if you need it, please search from our store. All of our products you purchased from our store will be followed by our technical team and services.

Sooner or later, most hobbyists will buy a touchscreen. The smaller touchscreens are already available from 10-20€, but the advantages are big (especially with regards to a GUI for home automation, for example) and the effort is relatively low, as I’ll show.

If someone, like me, would like to solder the whole thing together and make an attachable shield on the TFT, needs a 2×20 socket strip, a breadboard and soldering tools.

The other pins of the display must be connected via the blocks. Some pins of the Pi (like MOSI, SLCK, …) are used more often, this should be considered when connecting. The connections are as follows (on the left are the pins of the Pi, on the right those of the display).

Dieses Bauteil hat mehrere Inverter. Wir benötigen nur eines davon. Zum Beispiel kannst du Pin 1 (1A) als Eingang nehmen (Ausgang von 74HC4040) und Pin 2 (1Y) als Ausgang zum Pin 5 (WR) des Displays.

sudo modprobe flexfb debug=3 width=240 height=320 regwidth=16 setaddrwin=2 init=-1,0x00,0x0001,-1,0x03,0xA8A4,-1,0x0C,0x0000,-1,0x0D,0x080C,-1,0x0E,0x2B00,-1,0x1E,0x00B7,-1,0x01,0x2B3F,-1,0x02,0x0600,-1,0x10,0x0000,-1,0x11,0x6068,-1,0x05,0x0000,-1,0x06,0x0000,-1,0x16,0xEF1C,-1,0x17,0x0003,-1,0x07,0x0233,-1,0x0B,0x0000,-1,0x0F,0x0000,-1,0x41,0x0000,-1,0x42,0x0000,-1,0x48,0x0000,-1,0x49,0x013F,-1,0x4A,0x0000,-1,0x4B,0x0000,-1,0x44,0xEF00,-1,0x45,0x0000,-1,0x46,0x013F,-1,0x30,0x0707,-1,0x31,0x0204,-1,0x32,0x0204,-1,0x33,0x0502,-1,0x34,0x0507,-1,0x35,0x0204,-1,0x36,0x0204,-1,0x37,0x0502,-1,0x3A,0x0302,-1,0x3B,0x0302,-1,0x23,0x0000,-1,0x24,0x0000,-1,0x25,0x8000,-1,0x4f,0x0000,-1,0x4e,0x0000,-1,0x22,-3

sudo modprobe ads7846_device debug=1 cs=1 speed=2000000 model=7846 swap_xy=1 x_min=300 x_max=3800 y_min=700 y_max=3400 x_plate_ohms=60 pressure_max=255 gpio_pendown=23 keep_vref_on=1

flexfb debug=3 width=240 height=320 regwidth=16 setaddrwin=2 init=-1,0x00,0x0001,-1,0x03,0xA8A4,-1,0x0C,0x0000,-1,0x0D,0x080C,-1,0x0E,0x2B00,-1,0x1E,0x00B7,-1,0x01,0x2B3F,-1,0x02,0x0600,-1,0x10,0x0000,-1,0x11,0x6068,-1,0x05,0x0000,-1,0x06,0x0000,-1,0x16,0xEF1C,-1,0x17,0x0003,-1,0x07,0x0233,-1,0x0B,0x0000,-1,0x0F,0x0000,-1,0x41,0x0000,-1,0x42,0x0000,-1,0x48,0x0000,-1,0x49,0x013F,-1,0x4A,0x0000,-1,0x4B,0x0000,-1,0x44,0xEF00,-1,0x45,0x0000,-1,0x46,0x013F,-1,0x30,0x0707,-1,0x31,0x0204,-1,0x32,0x0204,-1,0x33,0x0502,-1,0x34,0x0507,-1,0x35,0x0204,-1,0x36,0x0204,-1,0x37,0x0502,-1,0x3A,0x0302,-1,0x3B,0x0302,-1,0x23,0x0000,-1,0x24,0x0000,-1,0x25,0x8000,-1,0x4f,0x0000,-1,0x4e,0x0000,-1,0x22,-3

ads7846_device swap_xy=1 debug=1 cs=1 speed=2000000 model=7846 x_min=230 x_max=3900 y_min=200 y_max=3700 x_plate_ohms=80 pressure_max=255 gpio_pendown=23 keep_vref_on=1

These are the same commands we previously used. So if you have other GPIOs and/or settings, you should adjust them. Save and exit with CTRL + O and CTRL + X.

Well, documentation isn"t really that much fun, so I skipped ahead and extended the breadboard circuit to try it with my Sainsmart 3.2" display which has a 16-bit bus.

It took me some time to find out that after the script had used the SPI bus lines as GPIOs, I couldn"t just reload the SPI controller driver spi_bcm2708.

Just copy the itdb28fb driver, change all occurences of itdb28fb to sainsmart32fb, add initialization sequence and set_addr_win function. Add section to Kconfig and Makefile and finally add the device to fbtft_device.

Earlier I had extended the FBTFT SD-image with a modified ads7846 driver that can add it"s own device. This makes it ideal for testing different setups.

The touch controller has a SPI interface and an IRQ line that signals when pressure is detected. This makes it easy to hook up, and luckily there"s two Chip Select lines on the Pi.

Sadly this touchpanel didn"t behave as good as the ITDB02-2.8 display. The x values increased as I moved the stylus along the y-axis. The y values was much better.

It was an old version of Henning Karlsen"s library. But, no. The display looked the same. The other displays I have is quite sharp, so this wasn"t good.

Does the Linux driver: ads7846 has built-in calibration?Yes, I know. I have a section about it here: https://github.com/notro/fbtft/wiki/Tou ... alibration

The problem with this display, is that x_min and x_max varies depending on where you are on the panel, whereas y_min, and y_max stays constant. The x values probably need a linear function to calibrate it"s value.

I have not gotten around to measuring frame rate yet, but what I can say so far is that a CPLD based design using a GuzuntyPi (https://github.com/Guzunty/Pi/wiki) driving the Sainsmart 3.2 LCD module will run with a SPI clock of 32MHz.

There is more than enough logic in the CPLD to bring the "wr" signal up one half SPI clock earlier than the discrete logic is able to do. This may make the circuit a little more stable. In fact, it *almost* runs at 48MHz, albeit with some bad pixel jittering. Quite likely with a properly routed board rather than a nest of jumpers it will be fine.

One thing I have noticed is that, while the cpu load is indeed negligible as noted elsewhere, an ssh session seems sluggish and prone to broken pipes. Likewise, keyboards plugged into the Pi directly seem to exhibit the sticky key syndrome more often. Has anyone else seen this? Is this expected?

I have not gotten around to measuring frame rate yet, but what I can say so far is that a CPLD based design using a GuzuntyPi (https://github.com/Guzunty/Pi/wiki) driving the Sainsmart 3.2 LCD module will run with a SPI clock of 32MHz.That"s cool. I had a quick look through the wiki pages, but I couldn"t find anything on how to program the CPLD. Can it be done from the Pi? And does the CPLD socket fit the holes in a breadboard?

There is more than enough logic in the CPLD to bring the "wr" signal up one half SPI clock earlier than the discrete logic is able to do. This may make the circuit a little more stable. In fact, it *almost* runs at 48MHz, albeit with some bad pixel jittering. Quite likely with a properly routed board rather than a nest of jumpers it will be fine.Which circuit are you referring to? Valdodov"s?

One thing I have noticed is that, while the cpu load is indeed negligible as noted elsewhere, an ssh session seems sluggish and prone to broken pipes.I haven"t noticed this, and I work entirely through SSH.

Likewise, keyboards plugged into the Pi directly seem to exhibit the sticky key syndrome more often. Has anyone else seen this? Is this expected?Yes, I haven"t had this problem at all until the last FBTFT release. Looking at the commits, I can"t see anything that should cause this since the last FBTFT image (2013-02-09-wheezy-raspbian-2013-05-24-fbtft).

sudo gz_load my_new_core.xsvfCreating a new core to your own design, sadly, is not currently possible on the Pi. You need either Windows, RedHat Enterprise or SUSE Enterprise Desktop. I use the last one to host the Xilinx ISE tool which takes VHDL and turns it into a core for you. There"s also a simulator. I have not yet gotten around to providing directions for downloading, installing or running ISE on the Wiki. Too much else to do

And does the CPLD socket fit the holes in a breadboard? The CPLD socket does have 2.54mm pin spacing, but the pins are arranged in a matrix so would not be compatible with most breadboards, I"m afraid. I use M-F Dupont cables to take signals from the Guzunty to a breadboard (except in this case, where I used F-F Duponts to connect the Guzunty pins directly to the LCD). It is also worth noting that a CPLD can often *completely eliminate* the need for a breadboard (as indeed happened in this case).

PCMIIAW, but my analysis of the common design is that the shift register strobes are activated by the ripple counter on the 16th cycle of the SPI clock (or 8th or 4th depending on the design) . This causes a lot of oscillation on the databus outputs as the shift sequence completes. This should not matter so long as the data is latched after shifting is complete. However, I wondered if this could cause ringing at higher data rates.

The CPLD uses a 16 bit SPI design (like yours) with separate signalling for DC and Reset signals. My reading of the SSD1289 interface specification led me to believe that data is latched either on the rising edge of "wr" (if "cs" is low) or the rising edge of "cs" (if "wr" is low). I could be wrong, but there seemed to me to be a potential race condition if "cs" and "wr" are allowed to rise together as they are in some sprite-mod derived circuits. Accordingly, the CPLD design raises the "wr" signal on the falling edge of the SPI clock, which is one half SPI clock cycle before "cs" rises with SPI_CS0. I will post the VHDL shortly below.

I don"t have a HDMI monitor to try with, but I would like to know if the vanilla 2013-05-25-wheezy-raspbian behaves like this?I do. I"ll try to experiment and report back on this. How do I go about being sure I have an exactly vanilla wheezy-raspbian release? Do you just mean an up to date installation according to apt-get?

When I make a proper interface board, I will hardwire many of these piped signals outside of the CPLD and free up some CPLD resources for reading incoming signals. And therein lies another question

Specifically, there are 12 pins left over on the Guzunty which I would like to use as inputs. Since the LCD interface is write only, I would like to transfer the value of these across the SPI0.0 bus as data is clocked out to the display.

Obviously, we don"t want reading these to interfere with the display update, so asynchronously reading the data would get the last clocked in set of pin values.

Has anyone gotten the buttons to work on the SainSmart 3.2" TFT screens for Raspberry Pi? I have some ideas to make them call commands or Python scripts, but don"t have any documentation from SainSmart as to how they work, such as which GPIO pins they are mapped to. I suppose I could experiment and find out, but that"s why I"m asking the forum first.

Reason: The hooks on the backight of ER-TFT032-3.1 is always complained by most customers for inconvenient assembly. So we cancel the hooks in the new version of ER-TFT032-3.2.That"s the only difference for these two versions.

ER-TFT032-3.2 is 240x320 dots 3.2" color tft lcd module display with ILI9341 controller and optional 4-wire resistive touch panel and 3.2 inch capactive touch panel with controller FT6236,superior display quality,super wide viewing angle and easily controlled by MCU such as 8051, PIC, AVR, ARDUINO ARM and Raspberry PI.It can be used in any embedded systems,industrial device,security and hand-held equipment which requires display in high quality and colorful image.It supports 8080 8/16-bit parallel,3/4-wire serial interface. FPC with zif connector is easily to assemble or remove.Lanscape mode is also available.

Of course, we wouldn"t just leave you with a datasheet and a "good luck!".Here is the link for 3.2"TFT Touch Shield with Libraries, Examples.Schematic Diagram for Arduino Due,Mega 2560 and Uno . For 8051 microcontroller user,we prepared the detailed tutorial such as interfacing, demo code and development kit at the bottom of this page.

I have the same LCD as you do. i was wondering if you could help me with the pinout of the LCD… valdodov has a different lcd and his schematic doesn’t transfer well to the one you have i think. is there a schematic that you could post or tell me where BL_CNT is connected from the 4094s to the LCD?

Thanks for the schematic, I will try and see if this works. if not, its probably some issue with the kernel. Also, if it is due to the kernel… was the kernel files just supposed to be copy pasted into the specific folders? was i supposed to enter anything in the command-line/terminal to get the display to start working?Just need to overwrite what is on your SD card.

the Spi (MOSI) is buffering 32 bits (when the strobe is off) then the SPI (MOSI) waits for 32 spi cycles (When strobe is on ) . Am i understanding correctly .

That’s great and all, but is there a way to push raw image data (bitmap images, video, etc) to this display without making it an active tty/X display? Something that can run headless and have data pushed to it from a remote ssh session, cron job, etc?

I’m thinking of a Python or C library, or better yet an optimized binary that you can pipe the raw data to from another process to send it to the screen…yes to all the above. You just need to write to the framebuffer

Where did you find the pin out for the sainsmart touch screen? We were looking at the following data sheet and it has different pin assignments. Please help us clear up this confusion. Thank you!!the display in your datasheet uses ILI9325 driver chip for the display.

If you cant display the image or you get the same error, I would recheck the wiring. Are you using a breadboard?No /dev/fb1 is not present. We are using a breadboard and just rechecked all of the wiring. The wiring looks good, but we are missing the filter capacitors (can’t get them till tomorrow) would that be the issue? It looks like a few people had this same issue but there is no definitive solution. What exactly is error -22?

We were following the instructions on github/notro/fbtft/wiki but I think I just realized that that’s a different method. So in order to install the kernel/modules should we use the compiled files on Voldadov’s site? If so, how do I copy those drivers? I extracted them to the desktop then did:

Finally got it working! (Sort of) Must have had a few dead rails on my breadboard because I purchased an new breadboard, and lo and behold, our screen works. We can see the boot information and there are no errors, but it stops at a blinking command prompt, but I cannot type with the keyboard, and it does not boot into the desktop. So we’re kind of stuck at a blank command prompt. Is there any code I can edit to make it boot into the desktop? Or is there any way to make the keyboard work?Do you have the keyboard directly connected to the Pi? Or are you accessing the Pi via SSH from another PC?

sudo mplayer -vo fbdev2:/dev/fb1 -x 128 -y 160 -zoom fileWe have the keyboard directly conneected to the pi. Should we be using SSH? And we can get it to work by deleting the

I am working for several months with the Raspberry and I also know a few experminete performed. Well me too interested this project. I myself already so bought a 3.2 “touchscreen, but I dunno exactly how to wire the. Could you maybe make a wiring diagram. That would be very nice.For example, with http://fritzing.org/

We are following your circuit for interfacing the raspberry pi with touch screen. We have currently wired on a breadboard and currently working on a better consistent solution like having it on a PCB.

[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 b cm2708_fb.fbheight=416 bcm2708.boardrev=0x100000e bcm2708.serial=0x93fdb0a6 smsc 95xx.macaddr=B8:27:EB:FD:B0:A6 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.me m_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAM A0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fbcon=map:1 fbcon=font:ProFont6x11

[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0xf4a38b4 smsc95xx.macaddr=B8:27:EB:4A:38:B4 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fbcon=map:1 fbcon=font:ProFont6x11

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fbcon=map:1 fbcon=font:ProFont6x11

hae the boot screen with white lines ….. by starting xbmc screen gets smoothy to white and finish….. think its wrong screen size… how can i set the resolution for all in to 320×240?hm…. can see the boot rows…. sometimes…….

sometimes with blue stripes…. sometimes not all letters only a small stripe….. and agter getting message ???52×21??? screen goes slowly white……I think……. i have killed the display :-p … ok next one…

-What driver?I am using the same chips and TFT as you are using. The driver i am using is Raspbian. I am using a breadboard but i have checked the circuit multiple times using a multimeter to confirm the connections so i am not sure if that is an issue.

Thank you for your help. I found a small connection issues with one of the ribbon cables i was using from the raspberry to the breadboard. Now that it is fixed everything works great without any problems. Thanks.

I have a question about kernel: I install the Rpi version 2014-06-20-wheezy-raspbian, kernel version 3.12.25+ #700 after upgrade, but after apply valdodov, kernel come back to 3.6.11 #41 …

Thanks for the Kernel but on my Pi is nothing to go the Display is not working. I have the Sainsmart 3,2 TFT with the Modul that is in the Video (selfmade) but i find no error in my circuit board it is with 3 74HC4094 and 1 74HC4040 . ? Is there a Kernel that Support this Version with no updates.?

anyone a idea where this vertical flashing lines come from?It has been awhile since I have looked at this version of the display with the above SPI interface.

You can also try and force the 4040 to go faster my connecting it to 5vi found the issue…. above GND is a Pin named “VCC” – it was not connected (and looking at your schematics, it didn’t look like it has to be connected to 5v)

I had acquired 2 Novametrix 515C pulse oximeter units that were slightly different versions but both contained a graphic LCD module which has the identification "DMF-50427N" on them and is made by Optrex. The DMF-50427N displays 128 x 64 pixels with each pixel being black and the interface is a parallel type ideal to be connected to a simple CPU or microcontroller although the LCD module only understands a few commands. You can read more about the oximeter at:

The LCD module uses 2 hd61202 column (segment) drivers designed for dot matrix displays and for interfacing with a microcontroller or something similar. For the datasheet please click here:

I used an Arduino Uno to test the LCD and the sketch I wrote you can find for download at the bottom of this page as "Novametrix_515C_LCD_Test.ino". Download it, write the sketch to your Uno and then with the power off connect it to the LCD as follows (LCD pins numbers are included):

Note that there are 2 chip select inputs (/CS1 and /CS2) because the 2 hd61202 drivers handle 64 x 64 pixels each so to update the display we must enable one of the driver chips at a time and then talk to it. With the /RST input, however, that is common to both chips and ignores the state of /CS1 and /CS2.

I have not used the LED backlight but to use it you will need to connect LED+ (19) to 5V via suitable limiting resistor (datasheet specifies maximum LED current of 60mA and forward voltage of 4.1V @ 30mA) and LED- (20) to GND. What you must do is supply the LCD contrast voltage to LCD VLC pin 3 which can be from approx. -7V to -9V, the voltage of which will adjust the LCD contrast. To generate the negative voltage you can use my power supply circuit from:

When you power the Arduino you should see on the LCD 4 rectangles of different sizes, if not, double check your connections and try adjusting the contrast voltage.

Now looking at the Arduino sketch if you go to the setup function you will see that the I/O is set up for communicating with the LCD; because the LCD is always in write mode (R/W is connected to GND) we never have to change the direction of the data pins (D0 to D7) but it is useful to be able to read information from the LCD such as whether it is busy executing an instruction (because of the use of digitalWrite() and its slowness it is not necessary to check if the LCD is still executing an instruction). After we have set up the I/O and set the default state we call LCD_rst() which simply takes RST low for 1ms and then returns it high, waiting another 1ms before exiting (which isn"t really necessary).

Back to setup() and we call LCD_send_command() twice to turn on both displays as after reset the LCD is in the off state. LCD_send_command() takes as inputs the instruction value to write to the LCD and the Arduino pin number of the LCD chip select I/O pin and then calls LCD_send_data() passing the input values and "false" so that LCD_send_data() knows that an instruction is being sent rather than display data. Function LCD_send_data() first sets LCD D/I to instruction mode (low) then sets D2 to D9 to the instruction value by writing to the Arduino ports directly so that we don"t need to use individual digitalWrite() to set each bit. Lastly, E (enable) goes low, the relevant driver chip is enabled by taking the input low and then both E and the chip select inputs go back high.

Returning to setup() again the next function we call is LCD_clr_disp() which clears the display by writing zeros to the entire display memory but the routine simply calls function LCD_write_all_disp() and passes zero as its input. Function LCD_write_all_disp() sets up a loop from 0 to 7 (LCD_max_X = 8) and at the start of the loop we set the X address for both driver chips. Horizontally we can access each pixel across by setting the Y address (which should really be called "X") and with each write to display memory Y will increase by 1 but vertically the X address (would be better called "Y") must be set which selects from 1 of 8 pages (using values 0 to 7). Each page is 64 x 8 pixels and writing a byte will set 8 pixels vertically. I"ll show it visually as the first page only:

For example, if you wanted to turn on the very first pixel you would set the Y address to 0, the X page number to 0 and then output 0x01. Remember that while Y increases by 1 with every write to display memory the X value never changes automatically and must be set yourself.

In LCD_write_all_disp() we set the Y address to 0 before setting up another loop which goes from 0 to 63 so we can write to all 64 pixels horizontally for both driver chips (which will cover the 128 pixels across in total) by calling LCD_send_disp_data() which calls LCD_send_data() but tells it we want to write to display data by passing "true" for the second parameter.

Also in setup(), after LCD_clr_disp(), is the commented out call to function LCD_fill_disp() (un-comment to enable) which like LCD_clr_disp() calls LCD_write_all_disp() but gives it the value 0xFF so all pixels are written to. Toward the end of setup() there are 4 calls to LCD_draw_rect() to draw rectangles of different sizes and in turn LCD_draw_rect() calls LCD_draw_horiz_line() and LCD_draw_vert_line() to draw the 4 sides of the rectangle. Not that I"ve included the horizontal length (horiz_len) and vertical length (vert_len) with the starting pixel (top-left point) rather than the length being added on resulting in an extra pixel as I"ve seen with saw drawing routines. In LCD_draw_horiz_line() we first do some basic checks to make sure the X, Y and len values are valid and then we calculate LCD_disp_value so we can effectively move the line vertically into 1 of the 8 "slots". To get the X address it is just a matter of dividing the Y value by 8 and then we can set that for both driver chips regardless of which one will actually be used. Next, we test to see if the line starts on the left side of the display (chip 1) or the right side (chip 2) by comparing the X start value (X) and then remembering the result by updating variable update_LCD_left. With that out of the way we create a loop to count from 0 to length (len) - 1 so that we can write each pixel of the line horizontally. However, before we update the display we must check if we have moved from the left side of the display to the write by checking if the current coordinate X position (X_pos) if 64 or higher and if so then update_LCD_left is updated. Then we can call LCD_send_disp_data() for the appropriate driver chip with the previously calculated display value in LCD_disp_value.

On to function LCD_draw_vert_line() in which we check X, Y and len are valid and then determine whether we need to update the left or right side of the display and set variable update_LCD_left accordingly. We do a simple calculation to set x_count_limit to the number of line segments, that is, the number of X pages to update. Next we go into a loop to update each X page and at the beginning of the loop we calculate the current Y coordinate value (the pixel at the top of the X page) and then set the X page address value to the coordinate Y position/8 for whichever driver chip we are updating. To actually draw the line we set LCD_disp_value to 0xFF which is then shifted left or right to form the start or end of the line or if it"s a middle segment then 0xFF is outputted untouched as the line segment will be a completed 8 bits. The last thing to do is set the Y address as each display write will increase Y by 1 yet we are drawing a vertical line whose X coordinate value will not change, and we also send the display data by calling LCD_send_disp_data().

A big issue with the line and rectangle drawing routines is that they will overwrite any other display data close by and if a rectangle is drawn with horizontal or vertical length of 8 or less then likely it won"t display correctly as one of the lines drawn will be in the same X page. A workaround to fix the problem would either be to modify the circuit so that the LCD"s display memory can be read or to maintain a display buffer on the Arduino, so that new writes to the display can be combined with whatever is already in display memory. The sketch is only test code and it could do we more boundary checking but at least it shows off a little of what the display can do.

If you have an sd card larger than 8GB, this is the best time to extend the partition using gparted or fdisk (see fdisk howto). Don’t forget to run “resize2fs /dev/mmcblk0p2” on your Pi afterwards to extend the filesystem to match the new partition size.

NOTE: The Universal TFT Setup tool does it’s best to fully configure all screens based on the manufacturers specifications but has only been tested extensively with Adafruit, Raspbery and Waveshare screens. For all other displays, you may have to edit the following files manually to tweak the settings according to your screen:

apt install aptitude curl cmake build-essential mailutils python-dev python-pip libusb-1.0-0-dev python-numpy htop ftp locate screen kismet pure-ftpd tigervnc-standalone-server tmux default-mysql-server darkstat ntopng mana-toolkit beef-xss resolvconf mitmf dnsmasq hostapd

If you have a 16GB sd card or larger and want to have kali in all it’s glory, get yourself a coffee and install the full kali suite (Note: 16GB is very tight, better to use 32GB. Run df -h to make sure you didn’t forget to extend your file system earlier