stm32 tft lcd controller pricelist

MCU– STM32F103ZE - high-performance ARM® Cortex™-M3 32-bit RISC core operating at a 72 MHz frequency, high-speed embedded memories (Flash memory - 512 Kbytes and SRAM - 64 Kbytes), and an extensive range of enhanced I/Os and peripherals connected to two APB buses.

What makes you say that/where did you read it? I can’t find anything about a touch controller or touch support, in either the part datasheet or the board’s.

Ahh yeah look at that! If you look closely, top right of the LCD, that’s obviously a flex connector for a resistive touch overlay (4 contacts running to the 4 sides of the LCD overlay).

Agreed! I will be picking one up. I’ve been happy developing for the stm32f4discovery (and other stm32 chips) with gcc, openocd and gdb. It is all free.

The STM32F4 cores are pretty well supported by libopencm3 and Code Sourcery and summon-arm-toolchain both build working toolchains and openOCD supports the stlink natively now.

A fair number of inexpensive baseboards/motherboards/accessories have also appeared for earlier versions. I hope Olimex puts out a couple nice STM32F429/427 boards.

I can see there is only a STLINK usb connector on board, so there is even no FS to expect. beside HS, I suppose does mean High Speed (480mbps). but HS anyway needs a separate physical layer USB chip for addition to STM32F4 chip and most likely this is chip is not present on this board anyway, because this is STM32F4+LCD+SDRAM demoboard and there is no need for USB at all.

The data brief bullet-points “USB OTG with micro-AB connector”. Looks like the micro-usb is on the underside, sticking out at the bottom of the photo. With matching T/H mounting tabs on the topside, labelled USB USER. But like you said, the STM32F4 requires an external PHY for HS, and it seems unlikely they’d include one on this board.

I think Farnell’s 21€ will be accurate, as ST’s suggested USD price is $24. The placeholders for the STM32F429I-DISCO on element14 (a division of Farnell) and mouser show $42, which I think predates the later ST announcement. I think the ST announced $24 will hold, and the distributor prices will match that, as they have in the past.

I wouldn’t expect TI to hack profits from their calculator range, and HP have always been expensive, but ST could easily change their format to calculator-friendly. Clamshell design, LCD & battery in top half, CPU & keypad in bottom half, expansion pins to left / right of keypad makes a self contained unit.

HP Palm – Love the idea, hate the baguette (french bread loaf) layout. If I could get custom key covers, and surface-mount key switches, I’d be designing my own low-profile keypad to go with an LCD module. Top side keypad, bottom side CPU / RAM / USB / LCD driver / power regulation / expansion port.

Great find, thanks! Man, could they have buried the details on that guy any farther down into the document? I can’t help but feel like a quick pointer in the LCD section to “oh by the way there’s a touch screen, here’s how to talk to it” would have been a good idea.

It’s certainly useable in any other project where you have an onboard LCD controller. Especially any other project that happens to use a STM32F4. What difference would it have made if it had an external controller? Surely it’d have been on the same PCB. Were you hoping for a removeable SPI-interfaced module?

Look in the UM1670 user manual, paragraph 4.8: the tft includes an ILI9341 controller. The ILI9341 has it’s own graphics ram inside, it is not mapped into the STM32 address space. It is connected to the STM32 via a parallel bus. The ILI9341 and similar controllers are common on cheap chinese tfts. So it is no problem to source similar tfts for your final product after developing on the discovery board.

UM1670 in paragraph 4.8 also says that “The TFT LCD is a 2.41″ display of 262 K colors. Its definition is QVGA (240 x 320 dots) and is directly driven by the STM32F429ZIT6 using the RGB protocol”. ILI9341 has multiple modes of operation including direct RGB/HSYNC/VSYNC mode which bypasses internal GRAM. I don’t have the board yet but I assume display buffer is located in external SDRAM which is also on the board. The whole point of this kit is to show TFT and SDRAM interface in new STM32F4x9.

I’ve checked this discovery board firmware available from ST’s site (“STM32F429 discovery firmware package UM1662” number: STSW-STM32138, btw. finding it is a bit difficult – ST’s site is terrible):

They are using FreeRTOS, FatFs, STemWinLibrary which is ST’s version of Segger’s emWin graphic library and STM32F4xx_StdPeriph_Driver v1.2.1 which includes F429/439 support (FMC, LTDC and DMA2D added).

Check again martin. Those lines have pullups to vdd and are connected to cpu pins. I have this board for some time and I can confirm that lcd is driven by lcd controller from cpu and frame buffer is in external dram which is also on the board.

Description:Here"s a very cool TFT LCD display with 128 x 160 resolution and 18-bit color depth. The most unique feature of the screen is the ability to read back the display memory across the bi-directional data lines. This solves a big problem with most displays - the need for a lot of memory to create effects like transparency or overlapping windows. This is an ideal component to include in your next custom project to advance your embedded hardware/software skills.

The reason that we"re reselling this part rather than using it on a new product is because of a misunderstanding about the interface details. It uses a 3-wire SPI interface with 9-bit transfers. The first bit is used to indicate if the following byte is data or a command. While 9-bit transfers are supported by many modern microcontrollers (like the K66 or STM32 families), making that work with vanilla Arduino is unlikely to happen any time soon. Since SparkFun products need out-of-the-box support for Arduino the interface had to be restricted to bit-banging - just too slow for a display with this resolution!

So we"re handing off this cool part to people willing to stretch their comfort level and move beyond basic Arduino functionality. Using a modern microcontroller of your choice and taking advantage of 9-bit SPI transfers - or a full parallel bus - you can unlock the full power of this display. Not only are we giving this to you at the cost you"d expect from a manufacturer but we"re passing along some of the work we"ve done so far: You can find the mating FPC connector here and some SW/HW work in the documents tab.

It’s been so long since I had the idea for this project that I can’t remember why I had the idea in the first place. At least I blame it on the passage of time although this engineer is getting on a bit now so it could easily be memory rot on my part. So here we are then, a reflow oven controller. Let’s quickly recap what a reflow oven is for those that are new around here.

I’m not the first to build an MCU-based reflow oven controller and I’m probably not going to be the last. A quick google around throws up the following results, and these are just the guys that have put virtual pen to paper and taken the time to publish their work.

There’s more. There’s a lot more, so why another one? The commercially available controllers didn’t look particularly inspiring to me so a self-build was going to be the way to go. I could either follow someone else’s schematic or come up with my own. Well I felt up to the challenge of doing it myself and bringing my own bit of flair to the presentation as well as making it highly cost-effective.

A solid state relay (SSR) is designed to allow you to switch mains voltages on and off using low voltage DC control, i.e. a microcontroller. They do this by using an optocoupler to internally isolate the two sides from each other. When you trigger the photodiode the mains current is allowed to flow. However, it’s not quite as simple as that. The relay will only change the state of the AC output at the two points in the AC sine wave where it crosses zero so that the input and output waveforms are maintained, the zero-crossing. That imposes limits on the frequency we can use to switch it on and off, something which I will tackle in the firmware design.

All of the components listed above need to be linked together with an MCU-based controller board. The basic requirements of the controller board are as follows:

I decided to integrate a Cortex M0 MCU with the 640×360 TFT LCD from the Sony U5 Vivaz mobile phone. If you haven’t already done so then you can read all about my prior efforts in reverse engineering that display in this article. The graphical user interface will be supported by an 8Mbit SPI flash device from Spansion.

When I started this design there were a couple of aspects where I was operating on a hunch that things would work out. Firstly, the STM32F051C8T7 MCU comes with 64Kb flash. I wasn’t sure whether that was going to be enough to hold the debug builds of the firmware that I would need to do in-circuit debugging with my ST-Link/V2 debugger.

Secondly, I wasn’t certain that the SPI flash interface was going to be fast enough to create a responsive user interface. I really dislike sluggish user interfaces, only instant responses are acceptable to me. The killer feature here is the DMA channels linked to the SPI interface in the STM32F0. If I run the SPI interface at 24MHz (the fastest available) then I should be able to get a 1.5 megapixel/sec sustained transfer rate using DMA because each pixel is 16-bits wide. That should be enough for a responsive UI but I will only know for sure after it’s too late to go back.

This is a direct copy of the connector schematic from my Vivaz reverse engineering article. It’s a proven design so the decision to drop it into this schematic is an easy one to make. The Vivaz backlight is a string of six white LEDs in series. We have to provide the power for that string but the R61523 controller in the Vivaz LCD has a programmable PWM output that we can use to provide a programmable brightness by connecting that PWM output to the enable pin of the voltage boost converter.

TFTs always need two voltage inputs, one for the digital interface and one for the analog display driver. If you’re lucky they’re both the same and fit the same range as your MCU. We’re not so lucky with the R61523. The digital interface will take 3.3V but the analog voltage requires 2.8V. That’s no problem, we just drop in this small and cheap regulator.

3.3V power is provided by an AMS1117 3.3V regulator. The maximum current output, 1A, is way above what we will need but the main reason for selecting this regulator is its high input range of up to 15V. I’ve bought some illuminated panel buttons for the physical case that require a 12V input to light up so I’ll be able to use a single 12V input to power the controller board and illuminate the panel buttons.

The PWR SEL jumper allows me to isolate the AMS1117 from the controller board. Why would I want to do that? When I need to program the SPI flash with the graphics for the UI I will connect up an STM32 development board and use it to program the flash. When I do this I will need to power my board from the same supply as the STM32 development board. The 3-pin MCU header allows me to do this but I must also isolate the AMS1117 because voltage regulators don’t like to receive a reverse current on their output pin. The 3-pin header also has an MCU_RES pin that is connected to the RESET pin of the Cortex M0. When I’m programming the flash using an external MCU I will connect this pin to ground so that the Cortex M0 is held in a reset state and does not try to initialise and interfere with the programming session.

Here’s the heart of the system, the STM32F051C8T7 MCU in an LQFP-48 package. These MCUs are extremely competitively priced. For £2.60 + tax at Farnell you get a 48MHz 32-bit ARM MCU with 64Kb flash, 8Kb SRAM, loads of on-board peripherals and a DMA controller. You don’t even need an external oscillator as long as you can accept up to 1% deviation from the stated clock speed. They’re even available for less than a pound at Future Electronics and if it wasn’t for their punishing international delivery charges that’s where I’d get them from.

We’ll use all of port B for the LCD 16-bit data bus. That means with the help of an optimised assembly language stm32plus driver I’ll be able to push pixels to this device at 12MHz because the Cortex M requires 2 clocks to write to a GPIO pin and we need to do that twice per pixel write-cycle. 12MHz, or 83ns is very close to the maximum supported by the R61523 LCD driver which is very handy for us.

PA0..2 are mapped to the LCD control signals. PA5..7 correspond to the SPI1 MCU peripheral pins and PA3 and PA4 are the chip select signals for the SPI flash and the MAX6675, respectively. We will share the SPI1 bus between the flash and the 6675 and use the chip-select signals to choose which one we are talking to at any one time.

With the schematic compiled and ready it’s time to start laying down the PCB footprints and traces. The LCD panel measure 80x45mm and I want the PCB to double as a mounting base for the LCD so I’m going to work on a 100x100mm PCB board size. Here it is.

On one side there is the LCD and its connector. The physical layout of the LCD panel is such that when the LCD is facing upwards the connector is facing downwards which makes it easy to mount on to the board. This is the side of the board that is designed to be pressed up against a window cut out from the box in which the board will be mounted. The other side of the board contains all the components and connectors. This will face down into the box and therefore be accessible for debugging purposes.

The highest frequency signals are going to be between the MCU and the flash and the MCU and the LCD therefore these signals are kept as short as possible. The MAX6675 needs to be kept safe from noise so it’s placed away from the digital components and its power line takes as direct a route from the regulator as possible and there is an unbroken ground plane beneath it.

Most of my vias are large and untented because you never know when you’re going to need an impromptu probe test point on your board but there are some tented vias around the LCD connector where there would be a danger of the FPC tail coming into contact with the circuit board.

The way I dealt with that problem is to reflow the board in stages using my hotplate. The LCD connector on the reverse side went on first as it’s probably the most troublesome with its 0.4mm pin pitch. After that was down I divided the top of the board into sections containing ICs that could be reflowed one section at a time by holding the board partially on the hotplate so the part with the LCD connector fitted to the back hung off the edge.

The STM32F051C8T7 MCU and the 4.7µF electrolytic capacitor recommended by ST. This MCU does not require an external oscillator, the clocks are generated from an internal 8MHz oscillator trimmed by ST to around 1% accuracy. Soldering the LQFP-48 part was remarkably easy. To most people the legs on these ICs look the same but having soldered so many different ICs I can tell you for sure that some are made of metal that attracts solder much more readily than others. This IC is one of them. Just add flux, touch the legs and the solder runs up those legs like its magnetically attracted. I’ve seen the same with Xilinx FPGAs and it’s a real relief when a device behaves like that.

Time to write the firmware and for me that’s definitely the fun part. I decided to use my own stm32plus C++ library to take the strain out of interacting with the hardware and to allow me to just get on with producing a good interface.

This full size 640×360 mockup allowed me to extract and save the individual graphics, including all the numeric characters saved as graphics against their correctly coloured backgrounds. These graphics will be converted to a raw format by the stm32plus

The tiled format, with apologies to Microsoft, gives a nice and clear UI that I will be able to navigate around using the three buttons on the controller. The SnPb and SnAgCu tiles allow me to select between lead and lead-free profiles. The mockup shows both tiles checked because I’ll need to save out both those check-boxes to flash due to the different coloured backgrounds (the graphics are anti-aliased by photoshop against the background colours and I need to preserve that).

My implementation is realised by a FlashGraphics class that initialises the SPI interface on construction and de-initialises it on destruction. This allows me to freely write graphics or read a temperature from the oven even within the same function without having to care much about who owns the SPI bus. The bus is owned by whichever controller class happens to be in scope at that time.

The logo graphic is DMA’d from flash to the LCD whilst the backlight is switched off and then I fade up the backlight, hold for a few seconds then fade back out, construct the ‘Control’ screen and fade back in again. The end result is a smooth transition between states.

I decided to mount the controller inside an ordinary black project box. A rough hole was cut in the front panel where the LCD would show through. The rough edges were then masked with a black square of thin plastic film with an accurate cutout for the LCD visible area. Then I placed a 10x10cm square of clear acrylic over the top and the four screws go all the way through the panel and the PCB mounting holes.

Here it is switched on. The front panel buttons are illuminated and the control page is being displayed. It’s notoriously difficult to photograph an LCD display and this photograph does little to convey just how bright and colourful it is in reality. The controller box feels very light in the hand, maybe I should glue a brick inside to give it that ‘quality’ feel