bascom avr tft lcd free sample

Included in this sample is a tutorial how you cam make your own characters with my converter tool. This tool converts the Maxim mcm files to Bascom data lines.

In Part 1 of this series I covered the basic features and advantages of the FTDI FT800 EVE graphics controller chip. In doing so, I mentioned several other methods of obtaining color TFT touch-screen functionality, including both “dumb” TFT displays that interface to your MCU via an 8/16 bit parallel port, as well as “intelligent” TFT display modules such as those sold by 4D Systems. I feel that FTDI"s EVE solution is both cost-effective and lends itself well to being interfaced with modest 8-bit MCUs, like the Atmel Mega328P that is found on many of the popular Arduino boards (i.e. the Uno). This month I"m going to show the reader how to get started using some of the EVE-powered TFT touch-screen modules that are currently available.

If you think like me, the physical hook-up of TFT display modules to your favourite MCU is probably the least of your worries. My prime consideration is how difficult it will be to write or obtain the necessary software drivers to interface such display modules with the Atmel AVR MCU family that I generally use. This consideration is further complicated by the fact that I generally write programs using Bascom/AVR and not C/C++. While I hate to admit it, it appears that the majority of drivers for peripheral devices/chips are supplied by the vendors in the form of C/C++ libraries. Part of the reason for this is that AVR-based Arduino boards are extremely popular and the Arduino is programmed in C/C++. Arduino programs or “sketches” are basically C/C++ code which has been “wrapped” by a user-friendly IDE which hides a lot of the complexity of C/C++.

To save you from having to “re-invent the wheel”, what I have done is carefully go through FTDI"s example code, remove as much extra code as possible, and simplify what remained as much as possible. If a Bascom/AVR fan like myself can successfully use these FTDI EVE modules in projects, you should be able to do so as well!

So, let"s see how we can hook up our EVE-based display to an AVR Mega328. The interface is just a standard SPI interface, with a couple of extra lines to handle the board Reset/Power-down and an optional interrupt. Depending upon which type of module you have, the logic levels required will be either strictly 3.3V or 3.3/5V switchable. See Table 1 in Part 1 to determine which is applicable to your board. If you have a 3.3V only module, but are using an MCU powered by 5V (i.e. an Arduino Uno), then you will have to use some level-shifting circuitry. I described a simple resistive logic level converter in Figure 1 of Part 1, which is simple and works well for this purpose.

This is a graphics library for the family of small colour TFT displays based on the ST7735 and ST7789 driver chips. These are really nice displays; bright, colourful, available in a variety of useful sizes, and available at low cost from suppliers like Adafruit, AliExpress, or Banggood:

Unlike most other TFT display libraries this one doesn"t require a memory buffer, allowing it to be run on any processor down to an ATtiny85. The displays are SPI and require four pins to drive the display, leaving one pin free on an ATtiny85 to interface to another device, such as a temperature sensor. If you need more pins choose a larger chip, such as the ATtiny84; see Using the library with other AVR chips at the end of the article for information about how to convert the code for different chips.

I"ve published a library for a colour OLED display in a previous article: Colour Graphics Library. The main difference between the colour TFT displays and the colour OLED displays is that the TFT displays are not self-illuminating, and so need a backlight; they therefore have a slightly higher power consumption. However, they are exceedingly cheap, and they are available in larger sizes than the colour OLED displays.

The ATtiny85 and other AVR processors supports toggling of one or more bits in a port, so provided you set all the pins to their disabled state at startup, for speed the display access routines can simply toggle the appropriate pins to enable or disable them.

14th January 2020: Tested the program with the Adafruit 1.3" 240x240 TFT display, and updated the program to correct a problem when rotating the image on that display.

The book is intended for electronics professionals dealing with electronics professionally or amateurishly interested in the practical applications of microcontrollers from the AVR family. It will be especially helpful for those Readers who intend to write programs for AVR microcontrollers in one of the most convenient Bascom language programmers.

The book presents various, complete, exemplary projects, all implemented on microcontrollers from the AVR family. The author has prepared and made available on the Publishing House website complete documentation of all projects described in the book, including printed circuit boards.

Some years ago, Brian wrote an article for Circuit Cellar about his project that generates relaxing sounds—ocean waves, rainfall and such—and inculpating a digital clock to shut off the sounds. At the time, he built it with only Atmel 8-bit AVR MCUs and support chips. In this article, Brian describes his more modern version of the project, this time built with an Espressif ESP32 MCU to provide Internet connectivity.

The design for that project had to be more hardware-intensive 10 years back. At the time, I was using only Atmel 8-bit AVR microcontrollers (MCUs), and I had to choose a model that was close to top-of-the-line to get the functionality I needed (Atmel is now part of Microchip Technology). I also needed five other support chips to complete the design. I re-designed the project once—about 5 years ago—when I started using Arm MCUs. More recently, I decided to build a more modern version, with an Espressif ESP32 MCU to provide Internet connectivity. In this article, I describe this newest version of my project.

It turns out that no low-cost, serial flash EEPROM devices are available that can handle the amount of data that these several files would contain. However, inexpensive SD cards are readily available. Even the lowest-capacity SD cards now available have much more storage capacity than is needed for even 25 such sound files. I chose an LCD display that contained an SD card socket, eliminating the cost and wiring of a separate SD card socket.

One aspect of my earlier designs that wasn’t ideal was the clock display. Initially, I used a common 20×2-character LCD display with an LED backlight. It was easy to dim the LED backlight, so that it was not so bright as to disturb sleeping. However, as with all LCD character displays, the font was small and hard to read at any distance. I designed my own larger font using four adjacent character positions, so it was useable.

For my latest version, I chose a common and inexpensive 2.8” color TFT display. An LCD display produces no actual light of its own, but merely filters/blocks the light emitted from its LED backlight. I control that backlight using a PWM (pulse width modulation) pin on the ESP32, so users have complete control over how dim they want the display to be. The software adjusts the backlight brightness, depending on whether it’s day or night. The controller library for this display contains the ability to use many different fonts/sizes, and I chose one that displays 0.5″-high characters, which are easily readable even when you’re half asleep!

One consideration that I initially overlooked, when choosing a graphic TFT LCD display, was the amount of time it would take to update the clock display. The TFT display is interfaced via SPI, and the ESP32 can handle high SPI data rates (40MHz). However, there is more to it than that. To simultaneously produce the relaxation sounds, the SD card (also an SPI device) must be accessed at a high enough rate to provide 176,400 data bytes per second. The SD card interface cannot handle the 40MHz SPI rate, however.

The waveform data must be transferred via the I2S bus to the two DACs that provide the 44.1KHz/16-bit stereo sound output. The DACs themselves have no internal buffers, so they must be fed data at a steady rate of 176,400 bytes/s, to produce “glitch-free” sound output. Therefore, the time it takes to update the TFT display must not interfere with the steady data flow needed for the sound output.

I found it interesting to note that on my 10-year-old version of this project, I was able to accomplish this audio streaming with an 8-bit ATMega644 MCU clocked at 20MHz, using a single interrupt service routine and some hand-coded assembly language. The 32 bit ESP32 MCU runs at 240MHz and contains two cores. Its I2S library routine uses DMA transfers. Even with all this MCU horsepower and DMA, it was tricky to accomplish the TFT clock display update, without introducing any glitches into the audio playback. More on this later in the “Software” section.

I mentioned before that it was tricky to stream the audio data from the SD card to the I2S DACs, while also updating the TFT display without introducing audio glitches. Both the TFT display and the SD card interface use an SPI interface. The TFT display can handle SPI transfers at the 40MHz maximum SPI clock rate that the ESP32 can put out. Even at this high rate, I measured the display update time at 9.6ms, and that only involved updating the current time using five large-font characters.

For this project, I decided to use both SPI ports available on the ESP32—a third is dedicated to the DevKitC’s flash memory device. The TFT display is driven by the ESP32’s HSPI port and the SD card is driven by the VSPI port, which is the default SPI port used by most ESP32 libraries that use SPI. I didn’t delve deeply into either the SD card or the TFT display libraries enough to know if using both ports was any faster than using only one SPI port. But early in my coding, I was experiencing audio glitches until I got the code optimized, so it was worth doing it this way.

The display I used is a 2.8” TFT touchscreen display with a resolution of 320 × 240 pixels. As just mentioned, it uses an SPI interface that can handle the high speeds put out by the ESP32’s HSPI port. I generally get these displays from PJRC.com, and they work very well. I recently got one of them from another source, and while it worked, it was too dim for normal use. I decided to use that one in this project, as I need a dim display for nighttime use anyway.

While this display includes a touchscreen, I didn’t use that feature. I know that the touchscreen and the associated XPT2046_touchscreen Teensy library from PJRC work well. I find using touch on such a small display to be awkward, so I decided to use three switches and a rotary encoder for the user interface. This TFT display includes a standard-sized SD card socket. I had seen posts on forums claiming that the SD card interface on this display didn’t work. It turns out that there are three resistors (R1,2,3) on the board that must be jumpered (shorted out). With that taken care of, the SD card interface worked fine, using the ESP32’s VSPI port.

The project uses about 100mA when it is not playing any sound, and about 150mA when it is playing sound. This varies somewhat depending upon what level of dimming you apply to the TFT display. During the day, it contacts an NTP server once every hour to synchronize the time. This is a bit of overkill, and could be reduced to once per day without affecting anything. During synchronization, the current will increase, with short spikes of around 250mA for up to 15 seconds while the ESP32’s Wi-Fi circuitry is operating. The AA alkaline cells are rated around 2,400mA-hours so they should last for 12 or more hours. Figure 5 is a rear-view photo of the project in its case. The AA cells are not visible, because they are mounted on the back cover.

When I switched to using the Arduino IDE from Bascom-AVR for my AVR projects, it was mainly because of the wealth of libraries available from thousands of Arduino enthusiasts. It turned out to be a wise choice, since this IDE has been expanded to handle many different Arm MCUs, of which I use Teensy 3.x and 4.0. It also handles the ESP8266/ESP32—which are not even Arm-based, but rather Tensilica Xtensa. (Tensilica is part of Cadence Design Systems.) Currently, I am using Visual Micro, an add-on to Microsoft’s Visual Studio. This VM/VS combination acts as a “wrapper” around the Arduino C++ toolchain, and provides a much better programming environment.

The Arduino SD card library was originally written for AVR MCUs, but when you add the ESP32 board package to the Arduino IDE, you get a custom SD card library written by Espressif. The TFT touchscreen display uses an ILI9341 controller chip. Adafruit originally wrote the Adafruit_ILI9341 library for the AVR family, and it has been customized more recently to handle Teensy, ESP8266/ESP32 MCUs. It calls the Adafruit_GFX library for its graphics features. Important Note: My program uses the ESP32’s HSPI port for the TFT display’s SPI access, whereas the Adafruit ILI9341 library uses the VSPI port by default. This change is handled in my code as follows: