tft lcd screen fritzing quotation

I don’t think inkscape is quirky, I get along with it quite well considering I am a newbie at it. I think the inkscape to Fritzing interaction needs work and I think most of the problems can be solved on the inkscape side of things.

This is slightly misleading in that copper1 is actually under copper0 not silkscreen, but the order should be silkscreen, copper1 with copper0 as a group under copper1 (at present copper1 and copper0 are reversed.) I don’t know of any problem this causes other than Fritzing will prefer to select silkscreen if it is the lowest group (thus a warning rather than an error.)

While this shows as an error (because in schematic it likely is one), in this case it is ignorable, because Fritzing will use the center of the pin as the termination point as was intended. Technically you can and should remove the connectorxterminal elements in breadboard, but it won’t hurt anything. repeats for all the pins on breadboard.

With that done and no major problems, load the part in to Fritzing and test it. This is to catch errors that the script can not (such as a terminalId existing but being in the wrong place). Here is a sketch of a typical test:

Started with the pcb svg by grabbing the pcb svg for a Uno and stripping out the silkscreen leaving only the connectors. resize the drawing and rescale it to standard. Used vi (text editor) to change the pads to standard .1 header size. Edited it in Inkscape and removed the unwanted connectors (two from the left end on both sides of the board) and added the missing dual row connector on the right of the board (the position is just a guess and needs to be checked against a real board, their mechanical drawing doesn’t have position info for that connector). Renumbered all the pins to start at 0 and increase linearly as they should. Put in a board outline on silkscreen. Resize again, group silkscreen and both coppers save and done.

Resize and rescale to the proper scale. Copied in the connectors from pcb view via copy/ paste in Inkscape. Resized the tft display to fit inside the connectors (In real life it doesn’t but the connectors won’t work in breadboard that way). Added a rectangle as the underlying board. Resize regroup save and done.

Ungroup, resize rescale. Changed the pin designations to match the board and arrange them to match breadboard. Run the part through the part checking script to catch any typos or errors, zip it to an fzpz and test it in Fritzing (including generating and checking the gerber output). Looks fine, so post it.

In this Arduino touch screen tutorial we will learn how to use TFT LCD Touch Screen with Arduino. You can watch the following video or read the written tutorial below.

For this tutorial I composed three examples. The first example is distance measurement using ultrasonic sensor. The output from the sensor, or the distance is printed on the screen and using the touch screen we can select the units, either centimeters or inches.

The third example is a game. Actually it’s a replica of the popular Flappy Bird game for smartphones. We can play the game using the push button or even using the touch screen itself.

As an example I am using a 3.2” TFT Touch Screen in a combination with a TFT LCD Arduino Mega Shield. We need a shield because the TFT Touch screen works at 3.3V and the Arduino Mega outputs are 5 V. For the first example I have the HC-SR04 ultrasonic sensor, then for the second example an RGB LED with three resistors and a push button for the game example. Also I had to make a custom made pin header like this, by soldering pin headers and bend on of them so I could insert them in between the Arduino Board and the TFT Shield.

Here’s the circuit schematic. We will use the GND pin, the digital pins from 8 to 13, as well as the pin number 14. As the 5V pins are already used by the TFT Screen I will use the pin number 13 as VCC, by setting it right away high in the setup section of code.

I will use the UTFT and URTouch libraries made by Henning Karlsen. Here I would like to say thanks to him for the incredible work he has done. The libraries enable really easy use of the TFT Screens, and they work with many different TFT screens sizes, shields and controllers. You can download these libraries from his website, RinkyDinkElectronics.com and also find a lot of demo examples and detailed documentation of how to use them.

After we include the libraries we need to create UTFT and URTouch objects. The parameters of these objects depends on the model of the TFT Screen and Shield and these details can be also found in the documentation of the libraries.

Next we need to define the fonts that are coming with the libraries and also define some variables needed for the program. In the setup section we need to initiate the screen and the touch, define the pin modes for the connected sensor, the led and the button, and initially call the drawHomeSreen() custom function, which will draw the home screen of the program.

So now I will explain how we can make the home screen of the program. With the setBackColor() function we need to set the background color of the text, black one in our case. Then we need to set the color to white, set the big font and using the print() function, we will print the string “Arduino TFT Tutorial” at the center of the screen and 10 pixels  down the Y – Axis of the screen. Next we will set the color to red and draw the red line below the text. After that we need to set the color back to white, and print the two other strings, “by HowToMechatronics.com” using the small font and “Select Example” using the big font.

Now we need to make the buttons functional so that when we press them they would send us to the appropriate example. In the setup section we set the character ‘0’ to the currentPage variable, which will indicate that we are at the home screen. So if that’s true, and if we press on the screen this if statement would become true and using these lines here we will get the X and Y coordinates where the screen has been pressed. If that’s the area that covers the first button we will call the drawDistanceSensor() custom function which will activate the distance sensor example. Also we will set the character ‘1’ to the variable currentPage which will indicate that we are at the first example. The drawFrame() custom function is used for highlighting the button when it’s pressed. The same procedure goes for the two other buttons.

So the drawDistanceSensor() custom function needs to be called only once when the button is pressed in order to draw all the graphics of this example in similar way as we described for the home screen. However, the getDistance() custom function needs to be called repeatedly in order to print the latest results of the distance measured by the sensor.

Ok next is the RGB LED Control example. If we press the second button, the drawLedControl() custom function will be called only once for drawing the graphic of that example and the setLedColor() custom function will be repeatedly called. In this function we use the touch screen to set the values of the 3 sliders from 0 to 255. With the if statements we confine the area of each slider and get the X value of the slider. So the values of the X coordinate of each slider are from 38 to 310 pixels and we need to map these values into values from 0 to 255 which will be used as a PWM signal for lighting up the LED. If you need more details how the RGB LED works you can check my particular tutorialfor that. The rest of the code in this custom function is for drawing the sliders. Back in the loop section we only have the back button which also turns off the LED when pressed.

Digital Photo frames are usually made up of four main components; a display/screen, a storage device, a microcontroller or microprocessor, and a power supply. For today’s tutorial, we will use the 1.8″ ST7735 based, color TFT as our display and the Arduino nano as the microcontroller. The TFT display is a 1.8″ display with a resolution of 128×160 pixels and can display a wide range of colors ( full 18-bit color, 262,144 shades!). The display uses the SPI protocol for communication and has its own pixel-addressable frame buffer which means it can be used with all kinds of microcontrollers and you only need 4 IO pins.  The display module also comes with an SD card slot which we will use as the storage device for this project.

Beside just building the digital photo frame, at the end of this tutorial, you would have also learned how to use the SD card slot on the 1.8″ TFT display module for other projects.

The ST7735 1.8″ TFT display is made up of two set of header pins. The first one at the top consists of 4 pins and are used to interface the SD card slot at the back of the display.

The second set of headers below the screen represent the pins for driving the display itself. However, the SD card slot and the display, both use the SPI protocol for communications with the MCU so they will be connected to the same pins on the Arduino nano. The only difference will be the CS/SS pin as each of them will be connected to a different pin.

For this schematic, we used the Fritzing model of the ST7735 1.8″ TFT display and the arrangement of the pins is slightly different from that of our display. This model has the pins of the SD card slot and the display merged together breaking out only their CS/SS pins.

Go over the schematics one more time to be sure everything is as it should be. More on the use of the 1.8″ TFT display was covered in a previous tutorial here.

The images that will be displayed on the TFT has to be in a bitmap format, thus before the images are copied to the SD card, we need to convert them to the recognizable bitmap form. To do this, I used the free Paint.net software (for windows) but you can use any other image editing software.

Load the images into the software one by one and use the resize tool to reduce its resolution and size to that (160×128 pixels) of the 1.8″ TFT display.

The code for this project is a slightly modified version of the SPI TFT bitmap example shipped with the ST7735 library by Adafruit. Thus the code for this tutorial is heavily reliant on the Adafruit ST7735 and GFX libraries.

With this done, we declare the pins of the Arduino to which the CS pins of the SD card slot and the TFT are connected and also create an object of the Adafruit ST7735 library with the declared pins passed on as arguments.

Next is thevoid setup() function. We start by initializing serial communication which will be used to debug our code. After this, we initialize the TFT and the SDcard, setting the rotation of the TFT to landscape (represented by 1).

Next is the void loop function. Here we simply invoke the bmpDraw function for each of the images we will like to display, setting a suitable delay time between each of the pictures. The bmpDraw function makes it super easy to display images on the TFT. All we need to do is to provide the name of the .bmp file, starting coordinates and it will use that information to fetch the image from the SD card and display on the screen.

Ensure your connections are correct, then upload the code to your Arduino.  After a while, you should see the pictures being displayed like a slideshow on the TFT.

Background: I"ve built a handheld (paragliding) flight computer using Teensy 3.0, a GPS module, accelerometer/magnetomer, SD card driver, and rotary encoder. I also have 16x2 LCD display, but will probably ditch it for a 2" TFT. I"m currently using a piezo buzzer, but look forward to getting some better audio output capabilities as you keep up development on the Teensy software. I want to use a small amplifier and speaker for better quality. Due to the nature of my project, I want to move toward getting these components on a PCB fairly soon. My soldered modules are working okay, but it"s clearly a sub 1.0 project and not very durable. I"ve got about a month left before I finalize my hardware and should be ready as soon as I figure out which TFT I want to use. I"ll probably power all of this with a li-poly battery. I intend to submit my code and design to your website when I"m finished.

Question: Do have any Fritzing designs for Teensy 3.0? I"m not an engineer and prefer the simplicity. Are there any other tools you recommend. I intend to drill holes to solder Teensy 3 into my project.

I did not buy it at that place, but mine looks the same, and the price was similar. I think it was called Sainsmart ..... They are available from many vendors. I just ordered a larger one for comparison and solving the dependencies of pysical resolution of the LCD vs. logical view at the controller interface.

My first approach was an Arduino Mega and a prebuild interface board. The UTFT Arduino library worked, but the interface board was lousy. I had to do so much rework on that board, that at the end it looked like a warfield.

The general Project: I want to set-up a battery operated info-device, which will be activated by an PIR sensor. Since the standby current of the Arduino board is pretty high, I had to switch it off. So I made a little extra board with an ATTiny, the PIR sensor and a PMOS transistor to switch the power. It worked, and had a standby current of about 150 µA, most of that consumed by the PIR Sensor, but it looked not nice. With PyBoard"s low standby current and fast wake-up times, that all can be combined in a single unit. And, since PyBoard runs at 3.3 V, I just have one power level, compared to the 5V and 3.3 V with the Arduino, even if the TFT has to be switched off for power saving. And the SD card is faster. And ...... I may add an ESP8266 for showing a web page too. I have a handfull of them in my drawer. But thats at the far end. Mechanical design comes first.

This is a little display for the Raspberry Pi, It features a 2.8" display with 320x240 16-bit color pixels. This version has a capacitive touchscreen, you can now use your fingers.

The display and touchscreen uses the hardware SPI pins (SCK, MOSI, MISO, CE0, CE1) as well as GPIO #25 and #24. All other GPIO are unused, there"s 4 spots for optional slim tactile switches wired to four GPIOs, that you can use if you want to make a basic user interface.

Use it for console access or easily pop up X11 onto the PiTFT for a mini monitor, although its rather small at 320x240. Instead, we recommend using PyGame or other SDL-drawing programs to write onto the frame buffer.

Drat. Will do a re-spin with the corrected silkscreen, but the first few units will be like this so make sure you use the alignment shown on the top of the board.

The 500 KHz signal (peak #1) is therefore 10 mW (10 dBm), and the 1 MHz harmonic is roughly 100,000 times as weak at 0.1 µW (-40 dBm). It looks like a huge peak on the screen, but each vertical division down is one tenth of the value. The vertical scale on screen covers a staggering 1:100,000,000 power level ratio.

Whoa! As you can see, the output cannot quite reproduce a 1 MHz input signal faithfully (there’s an odd little ripple), let alone 2 MHz in the second screen, which starts to diverge badly in both shape and amplitude. The vertical scale is 0.5V per division.

Here are the leading edge (MOSFET turns on & starts to draw 2 A) and the trailing edge (MOSFET turns off & breaks the 2 A current) of that cycle again, in separate screenshots:

The circuit will deliver a constant current by varying the voltage drop, even when the load varies. You can see this in the fairly flat curve on the Component Tester screenshot included yesterday: no matter what level positive voltage you apply to this thing, it’ll draw about 2 mA (just ignore the negative end of the scale).

By moving that 10 kΩ resistor away from the load, and tying it directly to “+” the circuit works even better. I’ve simulated it with an external power supply to drive that resistor separately, and get this CT screen:

The thing about power-down mode (arg 3), is that it requires a fuse setting different from what the standard Arduino uses. We have to select fast low-power crystal startup, in 258 cycles, otherwise the ATmega will require too much time to start up. This is about 16 µs, and looks very much like that second little hump in the last screen shot.

This is a current measurement, collected over about half an hour, i.e. over 500 reception attempts. The screen was set in 10s trace persistence mode (with “false colors” and “background” enabled to highlight the most recent traces and keep showing each one, so all the triggers are superimposed on one another.

But hey, enough is enough. I’m going to integrate this mechanism into the homeGraph.ino sketch – and expect to achieve at least 3 months of run time on 3x AA (i.e. an average current consumption of under 1 mA total, including the GLCD).

But the interesting bit starts on the next packet coming in after one has been omitted. The logic in the code is such that the radio will be left on indefinitely in this case. As you can see, every late arrival then comes 100 ms later than expected: same radio-off + power down signature on the right-hand side of the screen capture, just much later.

The code has become a bit long to be included in this post – it’s available as homeGraph on GitHub, as part of the GLCDlib project. I’m still amazed by how much a little 200-line program can do in just 11 KB of flash memory, and how it all ends up as a neat custom gadget. Uniquely tailored for JeeLabs, but it’s all open source and easy to adapt by anyone.

The first obvious step is to turn off the Graphics Board backlight – a trivial change, since it can be done under software control. With the dark-on-light version of the GLCD this is certainly feasible, since that display is still quite readable in ambient light.

That red line is the scope’s calculated derivative of the yellow line (it’s really just a matter of calculating differences between successive points). As you can see, the upward slope is pretty straight from 1.3V to 2.9V. The downward slope less so, IOW the capacitor discharge is not quite as linear. The signal was averaged over 128 samples in this last screen.

If you compare the hex string at the bottom of these two screenshots, you can see that the toggling is working out just fine: both are sending out 96 bytes of data, and the first few bytes are identical.

But that doesn’t quite make sense. Looking at the screen shot again, we can see that the RF12demo greeting (blue line) starts about 800 ms after the RESET pin gets pulled low. Even though OptiBoot is supposed to wait a full second after power-up. And there are two handshake attempts well within that period.

You should see a blank screen, and whatever you type in should show up on the screen. If this is indeed the case, then there is data going out and back into the serial port. To really make sure, disconnect the jumper and the echoing will stop. Excellent. Almost there.

Screen is a very convenient utility, but you need to remember how to get back out of it. The key sequence is CTRL+A followed by “\” (the backslash key).

Right now, the LaOS firmware drives the steppers, using a Gcode interpreter adapted from gbrl, and includes support for Ethernet (TFTP, I believe) and the SD card. It also requires the I2C control panel. As a result, you can send a “job” to this thing via VisiCut, and it’ll save it on the SD card. The I2C-based control panel then lets you pick a job and start it. Quite a good workflow already, although there are still a fair number of rough edges.

The other trick was to use the scope’s “DC offset” facility to lower the signal by 80 mV. This allows bumping the input sensitivity all the way up to 2 mV/div without the trace running off the screen. An alternative would be to use AC coupling on the input, but then I’d lose the information about the actual DC levels being measured.

Hardware might become too bulky or slow or power-consuming to keep using it, or it might mechanically wear out. But I can still hook up a 40-year old scope and it’ll serve me amazingly well. Even when measuring the latest chips or MOSFETs or LCDs or any other stuff that didn’t exist at the time.

This server is connected via wired Ethernet, and I usually only look at the GUI via a VNC-like “Screen Sharing” mechanism built into Mac OSX. It works well, because that connection is re-established even when the machine is in an exclusive “Updating…” mode, so you get to track progress even while the system is busy replacing some of its own bits and pieces. No screen needed, even though part of admin interface sometimes uses the GUI.

I’ll leave it as exercise for the reader to plot the resistance of this particular MOSFET at different gate voltages. With a bit more setup, the scope’s math functions should in fact be able to display that plot on-screen.

I’m not a technocrat. I think our IT world has done its share to rob people of numerous meaningful and competence-building jobs, and to introduce new mind-numbing and RSI-inducing repetitive tasks. Our (Western) societies have become de-humanized as more and more screens take over in the most unexpected workplaces, and our car trips and train rides are turning us into very selectively-social beings, reserving our emotions but even our respect and courtesy for our families and the people we choose as our friends. Technology’s impact on daily life is a pretty horrible mess, if you ask me.

PS. I’ve switched to light oscilloscope screen shots as a trial. The colors are not as pronounced, but it seems to be a little easier on the eyes. Here’s the same info, in the dark version as it shows on-screen:

If you’ve been following this weblog a bit, you’ll have seen quite a few scope screen shots in some of the posts. One of the most important uses for my scope here at JeeLabs is to figure out power consumption while trying to optimize a JeeNode’s ultra-low power mode. Power consumption is an analog thing, so that’s where a scope comes in. And when you look at the amount of detail a modern scope can show, it’s clear that this level of insight really comes from such an instrument.

First of all, visualization isn’t everything. A couple of years ago, I used one JeeNode to measure the power consumption of another JeeNode, see the Power consumption tracker post, and the software for it. Less insight perhaps, and no geeky screen shots, but plenty of info to try and optimize the power consumption by trial-and-error. Just tweak your sketch and measure, over and over again.

Normal “sweeping” analog scopes are ok, but storage scopes (analog or digital) are considerably better because you can “capture” an event and keep it on the screen to investigate. Such a feature will cost more though.

The above screen shows 2 mA and 200 µs per division. The vertical scale could have been zoomed in further, but for the horizontal scale I’m sort of at the limit unless I start using delayed sweeps. Here’s the whole unit:

No storage, no screen capture, no USB, so this was done by darkening the room and holding a camera in front of the scope. It took a couple of tries, but hey – it is possible to estimate power consumption this way!

The top two traces show the SCL and SDA data in analog form, the next group is the color-coded serial data, and at the bottom is the list of packets. As you scroll through the table, the traces adjust to show the related information. Still shown at the bottom are the 6 auto-measured items I configured in the first screen.

The slight drop in noise across the screen from 0 to 200 MHz is probably nothing more or less than the scope’s bandwidth: a 200 MHz scope is specified as having a 3 dB drop at 200 MHz, which fits amazingly well with what all the above screen shots are showing.

As shown in yesterday’s post, once you’re looking at signals in the high MHz range, it’s easy to make mistakes. Looking at that screen shot again, you can see a whole bunch of 90..100 MHz spikes:

I did have to use a small trick to make these graphs comparable: the second one has the scope’s 50 Ω internal terminator enabled, so that the path from signal source to signal destination is now done by the book: a 50 Ω source (in the AWG), feeding a 50 Ω coax cable, terminated by 50 Ω at the destination (in the scope). This does “attenuate” (i.e. reduce) the signal level by half, so I had to raise the baseline by 3 dB on the second FFT screen shot to make the height of the 25 MHz peak identical in both screens.

BTW, if you’re looking for a DIY design which is coming along very nicely, check out the EEVblog episode list, where Dave Jones has over half a dozen fascinating videos about how he is designing a really nice Arduino-compatible power supply, with all the bells and whistles you might be after: finely programmable voltage and current range, an LCD display, rotary switches for adjustment, etc. Here’s the first one in the series.

So what you’re looking at is not a function, but the path of a point in space, racing around a circular path (ok… oval, since you insist). That point in space leaves a trail on the screen, and that’s the resulting image.

Two pins, on which a 50 Hz voltage is applied which varies between +10V and -10V in the form of a pure sine wave. For some reason, the scope won’t let me take screen dumps to USB in this mode, so I’ll use camera shots.

This is a single-beam unit, meaning it can’t show two signals at the same time. Newer and more advanced models are dual-beam, but this one has to either “alternate” between the two beam displays, or “chop” them up and draw bits of one and the other in an interleaved fashion. It’s also not a storage scope, so you’ve got to look very carefully if you want to see one-shot events – the display on the screen shows only as long as the phosphor glow lasts!

A while back, Jeroen mentioned on the forum that he had an ancient GM5655 Philips oscilloscope, and since he lives in Houten we thought it’d be fun to put it side-by-side with my new Hameg scope I keep generating screen shots with in this weblog (ad nauseam for some, I suspect…). Here’s his vintage 1955 hardware (from a web image) – just imagine how attractive that must have looked to geeks back then:

There’s one dirty little secret about most digital storage oscilloscopes (DSOs) which puts them way behind the capabilities of their analog brethren: screen update rate.

For a scope to present a trace on screen, it has to do a lot of signal processing. After all, 1 GSa/s means its acquiring 1 billion data values per second. And although we’re not able to really see that with our eyes, we do see things that stay on the screen for a few milliseconds.

One trick is to turn on persistence. On analog scopes, that’s a pretty nifty feature whereby the image generated from the beam hitting the screen is made to stay visible for a while. Either via a phosphor coating which keeps on glowing for a while, or by constantly re-sending the same beam pattern to keep the visual display going.

Unfortunately, it’s a lot more complicated than that. If you just refresh the screen a few times a second, then you’re still going to miss a huge amount of detail. Let’s take a periodic 1 MHz signal: to display everything measured, the display needs to be updated 1,000,000 times per second, which means each “sweep” would only remain visible for 1 µs. That won’t do – our slow eyes wouldn’t see a darn thing, especially glitches which occur very infrequently.

One glitch every 10,000 pulses at ≈ 1 MHz means there are 100 glitches per second. That should be constantly visible on the screen, right? Well… not so on my scope. I enabled 10s persistence, i.e. sweeps will fade after 10s:

Don’t get me wrong: technically that’s an astonishing achievement. It’s not just copying a few bytes and setting a few pixels. It’s (always!) performing the emulated-persistence trick – because with persistence turned off, I still see a glitch every few seconds, which means that the LCD display is showing the glitch for a substantial fraction of a second – much longer than the 1 µs (or even 500 µs) sweep rate would suggest. Besides, you can see that fading is also implemented, so it’s not just drawing pixels but actually fooling around with color intensities.

After having become reasonably familiar with the new Hameg HMO2024 oscilloscope, I wanted to find out just what its limits are. Came up with this screenshot:

The top was zoomed out as far as I could while still showing the fastest supported 2 ns divisions in the detail window, which ends up being 50 µs/div. Running the scope timebase any slower will cause it to reduce its sample rate so it can still capture the required 12 horizontal divisions full of sampling data. In this case we see 12 x 50 µs = 600 µs of data on the screen, while the detail view is zoomed in to 2 GSa/s (25,000x).

I also added a third probe, the green line monitors output voltage, which is indeed steady at 3.3V (both red and green lines are based at the bottom of the screen). Note the huge peak current draw on the battery: over 290 mA!

In the first screenshot, each blip uses about 900 nanocoulombs (the red line rises 4.5 divisions over the entire width of of the screen). With 6 blips per second, we use 5.4 µC each second, i.e. 5.4 µA average current draw (not quite the 1.6 µA I expected, but still very impressive for an unloaded step-up regulator).

Fritzing is an open-source initiative to support designers, artists, researchers and hobbyists to work creatively with interactive electronics. We are creating a software and website in the spirit of Processing and Arduino, developing a tool that allows users to document their prototypes, share them with others, teach electronics in a classroom, and to create a pcb layout for professional manufacturing.

LCD backpacks reduce the number of pins needed to connect to an LCD. LCDs are a fun and easy way to have your microcontroller project talk back to you. Character LCDs are common, and easy to get, available in tons of colors and sizes. We"ve written tutorials on using character LCDs with an Arduino (or similar microcontroller) but find that the number of pins necessary to control the LCD can be restrictive, especially with ambitious projects. We wanted to make a "backpack" (add-on circuit) that would reduce the number of pins without a lot of expense.

By using simple i2c and SPI input/output expanders we have reduced the number of pins (only 2 pins are needed for i2c) while still making it easy to interface with the LCD. For Arduino users, we provide a easy-to-use library that is backwards compatible with projects using the "6 pin" wiring. The breakout comes with a 2-pin and 3-pin terminal block as shown (you can snap it together to make a 5-pin terminal and then solder it to the backpack for easy wiring)

This backpack will work with any "standard" character LCD, from 8x1 to 20x4 sizes! As long as they have a 16-pin single-line connection header at the top. We carry a few LCDs that work great. We suggest using our blue & white 20x4 or 16x2 LCDs. It does not work with the 16x2 OLED displays. You can try to connect our RGB 16x2 or 20x4 LCDs up but this backpack will not control the RGB backlight so you"ll have to use the backpack only for the 14 digital IO pins (pins #1-14) and connect the backlight pins (#15-#18) directly to your microcontroller with 4 extra wires for color/PWM control as if they were just an RGB LED.