EVE5 Evolution

A Hands-On Review of the Bridgetek VM820B15A 15” HD Display

Master high-definition embedded graphics with Bridgetek’s EVE5 generation. This hands-on review explores the VM820B15A 15” multi-touchscreen, detailing BT820 integration with Arduino and STM32. Discover powerful design tools and essential troubleshooting for your next high-performance dashboard.

Bridgetek sent me the VM820B15A kit, which included the following items:

• The DP-1561-01A display panel, containing a VM820B15A EVE5 Controller board
• An MM4222-QSPI USB-QSPI Adapter
• An Adafruit Feather ESP32S3 MCU board, mounted in a socket on the MM4222-QSPI
• A 12V 5A power brick with a barrel connector, which powers the VM820B15A controller and display
• USB-C cable to connect the MM4222-QSPI board to your PC (when using the ESE, ESD and EAB PC apps or to power whatever MCU you have plugged into the MM4222-QSPI.
• A set of two plastic supports to hold the display upright in a viewable position.

The kit that I received was pre-loaded with a demo program that emulated a commercial electronic picture frame. While this demo program didn’t really demonstrate the BT820 EVE5 controller’s advanced capabilities, it did display very nice HD images and proved that everything was working. Figure 1 shows a rear view of the VM820B15A display, along with the MM4222-QSPI adapter board and an ESP32S3 board mounted in the MM4222’s Feather socket. The perimeter is covered in double-sided tape to allow it to be fastened to a panel. Just above the DP-1561 label is the backlight cable. It looks to me like you would have to be careful to prevent it from getting damaged, when you mount the display to a front panel.

The VM820B15A is targeted at medical, industrial and other applications. It’s display size is 15.6” with a resolution of 1920×1080, which is standard HD resolution. I found it to be a very bright display—it’s rated for 860cd/m². It’s not a stand-alone “panel-PC”: it must be connected to a host MCU, using SPI (optionally QSPI).

Starting with the first-generation EVE controller, its controller architecture has been unique. Conventional LCD panel controllers rely on a RAM memory array to act as a video frame buffer. The size of this array (in bytes) is calculated as Horizontal Pixel Count×Vertical Pixel Count×Color Depth/8. When the EVE controllers were first introduced, even the smaller LCD panels available at the time needed 32KB of SRAM, which was more expensive than it is now. Also relevant was that conventional controllers needed to have a large number of I/O pins dedicated to the RAM memory device.

EVE controllers eliminated the need for this external video frame buffer in RAM. Instead, they accepted commands from the host MCU to render primitive graphics objects as well as more complex Widget objects (buttons, sliders, etc.). The incoming commands from the host were stored internally in a RAM FIFO array. This FIFO could be much smaller than the requisite video frame buffer used by conventional LCD panel controllers. The EVE controller rendered that portion of the graphics objects, which were contained on each horizontal line and then sent it out to the LCD—line by line.

Each EVE controller generation became more sophisticated, handled larger LCD panels and enhanced the touch capability. The BT820 is a 5th generation EVE controller, which can handle larger LCD panels. It can handle the capacitive touch controllers that work on these large panels and is multi-touch (5 point) capable. It can also be interfaced to resistive touch panels via an external resistive touch panel controller over I2C. Although earlier generation EVE controllers eliminated the need for a large RAM frame buffer, the VM820B15A controller PCB now contains 128Mbyte of DDR3 RAM as well as 128Mbytes of Flash memory and an SD card host.

Fonts, images, video/audio clips, and more can be permanently stored in this Flash memory and then transferred to fast DDR3 RAM, as needed, for display. The BT820 IC has an onboard controller for up to 8Gbit of external DDR.

In the VM820B15A, the BT820 IC and the DDR3 are located on the MN820 mini-module which takes care of all the associated routing and power supplies. The MN820 connects to the main PCB via a 100-pin board-to-board connector and so can be used to simplify and expedite final designs as well as on development kits. From the BT820’s datasheet, the BT820 now uses a conventional RAM frame buffer scheme, which can handle screens up to the 1920×1200 pixel limit.

The BT820 contains audio capabilities as well. Earlier EVE controllers, even the first generation, contained a synthesized sound generator. The BT820 contains this synthesizer, plus an I2S bus that can handle stereo audio at various sample rates. The VM820B15A board supports this I2S bus with:

• A PCM5121 stereo DAC
• Two TPA6205A1 audio power amplifiers capable of 1W into 8Ω speakers

While it may not be immediately obvious from Figure 1, the VM820B15A’s PCB contains the MN820 mini-module (the PCB surrounded by a gold-colored rectangle in this figure). The MN820 contains the BT820 plus DDR3 RAM, and is meant to help designers who wish to incorporate these two components into their own PCB designs.

Using the EVE Screen Editor

The EVE Screen Editor (ESE) is one of three PC applications that Bridgetek provides to assist the development of displays based upon EVE1–EVE5 controllers. I found it to be the most useful and user-friendly of the three applications. What it allows you to do is drag/drop the graphics primitives and Widgets to a Viewport screen. You can adjust all the object’s properties from a Properties window, and the object will immediately reflect this. The Display List and Coprocessor windows will contain the pseudo-code needed to generate whatever you have composed in the Viewport window.

If you have a Bridgetek display plus an adapter allowing it to be controlled by your PC (via USB), you can control your display panel using the ESE. You will then see the objects you have added to the Viewport, in real time, on that display. This application also performs other more complex functions, but the described features are what a newcomer would make the most use of.

You must load the latest ESE, version 5.2.0 (or later) to work with the EVE5 BT820 controller contained on the VM820B15A. Within the ESE application, you can click on the Help menu tab and select Manual for the User’s Guide, or download the PDF file from Bridgetek’s website (see Resources).

ESE and user guide

In this section, when I refer to a window, I am referring to what Bridgetek calls a Tab. When you first launch ESE, there will be many windows open down the left and right hand sides of the screen. In the Menu bar at the top, the View tab allows you to show/hide as many of these windows as you need to design your project. If you keep the default ones, each of them will be small and there will often be more information that is hidden unless you purposefully scroll down through the window.

If you click on the icon that looks like two stacked pages (at the top right of these windows), the window will disappear and will be replaced by a Tab on that side of the screen. Clicking such Tabs, will re-open the window. That is why Bridgetek uses the Tab designator for what I refer to as a window.

The initial Welcome screen allows you to create a New project, load an Example, or open an Existing project. There are tabbed examples for all five EVE generations. Since the BT820 controller is a superset of the earlier devices, you could pick an example from earlier generations, if you found one that you would like to build upon.

I decided to try creating a new project rather than loading an example. After selecting “Create,” I entered a project name. I had already created a Bridgetek folder within my Documents folder, so I selected that folder, rather than letting ESE place the project in Bridgetek’s default “Examples” folder. When this Create dialog box closes, it presents a large blank window in the center of the screen, showing nothing other than horizontal and vertical pixel axes. All the toolbar menus are greyed out, apart from the File menu. I found it counter-intuitive, but you must then use the File > Open menu to call up the project that you have just defined. That takes several seconds, so it initially seems like nothing is happening. You are then presented with a screen resembling the one shown in Figure 2.

The first thing to do is configure your project for a specific EVE device and screen resolution. This is done in the Project window at the right of the screen. Since I had the VM820B15A, I initially chose the BT820 device with a screen size of 1920×1200. The actual screen size of the VM820B15A is 1920×1080 but that was not among the options provided. When that 1920×1200 choice turned out not to work, I was advised by Bridgetek to go to the Registers Window, which contains a place to set a custom display size. There I set the correct 1920×1080 screen size.

Going back to the Project Window, a new Custom (1920×1080) option appeared, so I selected it. I thought that this should be all that was necessary, but again I was wrong. In the Devices Window, there is a small icon at the bottom displaying a wrench and screwdriver. If you hover over it, it will display the help prompt “Device Display Settings.” Here you’ll find two radio boxes and the correct one to choose here is VM820B15B (even though my display is a VM820B15A).

Next, in the Project menu, you would select 128MB for DDR RAM. This is a little tricky as the VM820B15A datasheet shows that it contains 1Gbit DDR3. However, 1Gbit equals 128MB. Underneath is the Flash Image size selector. The VM820B15A datasheet shows a 1Gbit Flash capacity, so pick the MX25L1024 (128MB) selection. This flash memory is predominately used to store image files and such if you use them in your screen design.

The large central window is the Viewport, which, in this case, is emulating the VM820B15A’s display screen. At its default scaling setting (100%), it will not show all the VM820B15A’s screen. Above the Viewport is a scaling window with magnifying glass icons. I switched to 62.5% scale to allow me to visualize the complete VM820B15A screen. Regardless of the Scaling factor you choose, the Navigator Window to the right will always display the full screen size, with a red rectangle outlining the actual area displayed in the Viewport. You can move that rectangle around to “zoom in” on specific areas.

You can readily use the ESE without having an actual BT8xx-controlled display panel available, since you can view the screen objects in the Viewport. However, if you have a display panel with an attached MM4222-QSPI adapter, you should be able confirm its presence when the display panel is powered up and the MM4222-QSPI board is plugged into your PC’s USB port.

The MM4222-QSPI should show up in the Devices Window, but you may have to press the small Refresh icon (an arrow wrapped around in a circle) to see it. It will be labeled FT4222 since an FTDI FT4222 USB bridge chip is mounted on the MM4222-QSPI. Note that before you click Connect, you should have already set the Device to BT820, or the connection will fail with an “unknown ID” error message.

From earlier articles, I still have a Matrix orbital display with a BT816 controller and matching USB2SPI adapter on hand. The USB2SPI board performs the same USB-SPI bridge function as the MM4222-QSPI board. It shows up in ESE v5.2.0 as a USB 2 SPI device and allowed me to connect to that Matrix Orbital display.

Let’s assume you have an example loaded or you’ve added some widgets that are being displayed in the Viewport. If you press the “Write to RAM_G and RAM_DL” button, in the Devices window, whatever is displayed in the Viewport will then be displayed on your LCD panel. The RAM_DL is the RAM area where the Display List resides. That Display List renders what you see on the screen. The RAM_G area holds images, video and/or any custom fonts that you may be using. The VM820B15A controller, with its large 1Gbit RAM memory, may be used for other purposes as well. The BT820 can support up to 8Gbit DDR3.

Also contained within the Devices window is the “Program EVE-connected flash” button. The VM820B15A contains 128MB of flash memory, directly controlled by the BT820 graphics engine. If your screen design contained image files, for example, they could be transferred to this non-volatile memory, using that button. Bridgetek also provides a PC application titled EVE Asset Builder (EAB) which is like a Swiss Army knife and contains many different utility functions as well as allowing for the transfer of images, fonts and animations to the display flash.

There is a window titled Script (Python). The ESE installation on the PC includes Python as well as Qt, a popular Python graphics library. As you populate the Viewport with Widgets, primitives, and such, the Script window will display the necessary Python statements. If you are experienced in Python programming, you may want to use this Script window. Using the Python Interact library, it is possible to execute the resulting script from the PC’s Python interpreter.

The Toolbox window at the upper left contains a list of all the EVE graphic elements available for the selected generation of EVE controller. There are two broad categories of graphic elements available:

• Display List elements (graphics primitives)
• Coprocessor elements (more complex graphics elements such as Widgets)

Assuming you have both the Display List and Coprocessor windows in view, when either of these two windows has the focus, the list of graphics elements in the Toolbox will change to match the graphic elements available in that category. For example, Widgets won’t show up unless the Coprocessor window has the focus.

From the Toolbox, you can drag/drop a chosen graphic element to the Viewport and position it as desired. After placement, if you click on that element, the Properties window will show the default properties for that Widget, and more, and you can edit these properties to suit your needs. This Property window will only show only a small subset of the available properties, unless you scroll through it.

Editing a property will result in an immediate updating of the Viewport to reflect that change. Note that Text fonts are not expressed as Truetype fonts with a size and a descriptive name. EVE5 controllers contain 34 pre-defined fonts of various styles and sizes, only described by font number.

As you add Widgets and primitives to the Viewport, both the Display List and Coprocessor Windows will be populated with EVE statements. In the case of Widgets, the Coprocessor Window will be filled with upper-case statements. These statements are best thought of as pseudo commands. They are not exactly what you would enter into your C program code. In the case of the EVE5 Arduino library, a statement in the Coprocessor Window like CLEAR(1, 1, 1) would be added to your sketch (program) as:

Eve.CLEAR(1,1,1);

I’m not using an STM32 MCU and its STM32CubeIDE toolchain, and the syntax used there may be different.

The ESE can export your user interface design in the syntax of libraries such as EVE-MCU-DEV and EVEApps, which avoids the need for the aforementioned edit, but does not currently include an Arduino format.

The lines of statements that you see in the Coprocessor window, will immediately result in the rendering of those objects in the Viewport. However, these lines are not all that is needed to achieve the same display—when the VM820B15A display is being controlled by your MCU. There are additional statements needed to render the objects. The following is not exhaustive, but here are some of those other statements:

 eve.LIB_BeginCoProList();

 eve.CMD_DLSTART();

[series of Coprocessor statements as displayed in the ESE Coprocessor Window]

eve.DISPLAY();

 eve.CMD_SWAP();

 eve.LIB_EndCoProList();

 eve.LIB_AwaitCoProEmpty();

In addition, you need some other routines to initialize the EVE5 controller at power-up. I can’t cover the architecture and full use of display list and Coprocessor statements here. But the ESE will provide help in writing your program by showing you the pseudo statements that are associated with the primitives and Widgets you have placed in the Viewport. You should refer to examples provided by Bridgetek to “fill in the blanks” between what you get from the ESE application, and what is needed to constitute a complete, working program. Using the ESE export feature will also add these for you.

I noticed that the latest ESE version 5.2.0, available when I wrote this review, didn’t support most of the new Widgets that are described in Bridgetek’s BRT_AN_087 document “EVE Screen Designer 5.1.0 Widget Guide.” Nor were they covered in BRT_AN_086 BT8xx Series Programmer’s Guide.

During my actual host MCU tests, I used the EVE5 Arduino library, which does not yet support the newer Widgets either. These are software-defined widgets whereby the code in ESD creates them using combinations of EVE commands. They (and customized variations of them) can be created in other applications by the developer using combinations of EVE commands.

Bridgetek also has ongoing projects to create and demonstrate creation of custom widgets using EVE graphics techniques. Some other widgets or objects are available through the BT820 extensions.

BT82X Firmware Update and Extension Guide—I received the VM820B15A display prior to its general release and so I was somewhat of a “beta” tester. While I used the 5.2.0 version of the ESE application, the current 5.3.0 version will have updates/improvements.

The EVE Screen Designer

This is the second of three applications that Bridgetek makes available for development purposes. It works with all generations of the EVE controller chips. It allows you to drag/drop graphic primitives and Widgets to a virtual screen on your monitor. You can customize those graphic elements using a Properties window, much like the ESE application. The ESD application looks much different than the ESE app, as it uses a Dark Theme user interface.

Beyond ESE’s capabilities, the ESD application also allows you to make interconnections between the various Widgets that you have selected. These are called Logic Flows and can connect Widget outputs (caused by touching that widget) to the inputs of other Widgets (Properties, etc.). For example, pressing a button could cause other buttons to disappear (if they are no longer a valid option at that point). Or it could take the value of a Slider, and display it within a Label, possibly with some math function applied along the way.

In general, the ESD operates in two distinct modes:

• It can generate x86 code, which runs on your PC (as an .exe file). This code is customized to your display’s EVE-controller. It interacts with your display via USB and the MM4222-USB-QSPI adapter board.
• It can generate C code for specific MCU families.

In the first mode, the screen that you have designed will be displayed on your USB-attached EVE-based touchscreen. You can interact with the display’s touchscreen and whatever Logic Flows you have defined, will show up on that display—just as it would if you had a host MCU connected and running code that replicates the Logic Flows that you have defined.

So, to the extent that you can define the way you want your touchscreen’s GUI to act, using Logic Flows, and others, you can develop that code using ESD—all without actually connecting a programmed host MCU to the display.

Using the second mode, you can generate the program code needed and upload that code to your chosen MCU via USB. The ESD application supports three main MCUs:

• The FT90x 32-bit microcontroller family (originally developed by FTDI)
• The STM32F401 ARM MCU.
• The Raspberry Pi RP2040 MCU (Pico board, etc.)

Bridgetek has designed several different adapter boards. The MM4222-USB-QSPI can host the STM32F401 MCU listed here, as well as various other MCUs that use Adafruit’s Feather format, including the RP2040. Figure 3 shows the MM4222-QSPI adapter board.

The ESD application only directly supports the three MCUs discussed here. It does so by invoking the “C” toolchain (IDE) written/supported by that MCU’s manufacturer. You must install the necessary toolchain on your PC, to fully make use of the ESD application.

At startup, the ESD Welcome dialog offers you three choices:

• Create a New Project
• Examples
• Open an Existing Project

When starting out with a new MCU or Toolchain, I usually load an example first and get familiar with some code that actually works. ESD contains numerous examples, but, unlike the ESE application, these projects are not segregated into tabs, by EVE generation. I only found three BT82x examples. Unlike ESE, these examples only work for the BT8xx device that the example is tagged with. You can’t pick an example, specified for an earlier BT8xx device and just re-configure the project for a newer BT820 device.

If you choose the Create a New Project option, you will have to configure your chosen target environment, using a series of six options. These are all implemented as drop down menu boxes, across the top of the ESD form (Figure 4). This configuration bar may seem confusing to a newcomer, as some menu boxes may appear to be redundant.

There are various EVE BT8xx controllers, PC boards containing various BT8xx controllers as well as complete display units containing both the touch panel and the BT8xx controller itself. Therefore, this configuration menu bar is designed to handle the many product permutations available.

For this article, I’ll just describe the configuration needed for the VM820B15A touchscreen that I received. Starting from the left:

• Build Target: VM820B15A
• Eve Platform: VM820B15A
• LCD Resolution: FHD (1920×1080)—note the final zero doesn’t fit into the window
• Host Platform: Either FT4222 (i.e., the MM4222-QSPI adapter) or the host MCU being used.
• Flash: Designates whatever Flash memory is directly connected to the BT820 controller ( automatically filled in when you select the VM820B15A, and can’t be modified).
• “Hand” Icon: Selects the touch control chip.
• Toolchain: This applies when you are running your display panel from the PC via USB and using the MM4222-QSPI adapter. It is either FT4222_x64 Release or Debug.

Notice that the resolution is specified as FHD. I noticed that this FHD label is used in the CircuitPython demo I received, but you must use FULLHD when specifying it in the EVE5 Arduino library.

The ESD application uses a dark theme and it’s easy to miss the two small icons at the upper right corner of windows like the Property, Library windows. Thexicon will completely close that window, but it can be restored using the View tab of the Menu Bar. The square icon to its left will undock the window. This can give you more working space for other windows, if you move that undocked window outside the ESD’s screen area. This is different from the ESE application, where that same square icon closes the window but places it in a tab on the left or right side of the application/s screen.

Like ESE, the ESD application has a relatively large central window, which roughly corresponds to the ESE Viewport. However, it’s not dedicated to a view of the display screen that you are designing. Instead, this window has several tabs along the top. For the simple examples that I opened, these tabs consist of :

App.main

MainPage.page

AppScreen.page

MainPage.c

The App.main page shows the actual screen widgets and primitives that have been dragged/dropped to this “page” (i.e., the Viewport in ESE). When you load an example, this “page” will be live—any widgets that have been connected to other objects, will respond accordingly. This occurs because a simulation mode is running by default (at least on the example I loaded). Figure 5 shows the part of the toolbar that pertains to this simulation mode. Since simulation is running, the square “Stop” icon is visible here. When the simulation is not running, a green arrow will appear in its place, which starts simulation. You cannot physically move/edit the graphics objects on this page.

The MainPage.page tab shows the display screen you are designing and is where you would compose/edit the graphics objects that you want to display. Unlike ESE, the scaling of this window to match the pixel resolution of your touchscreen, is not done using a scaling tool above the window. Instead, the mouse scroll wheel adjusts this scaling—it can also be done using a small scroll bar at the bottom right of the screen. Whenever you scale up this window, resulting in a portion of the touch panel’s screen being outside the window, scroll bars will appear on the right side and bottom of this window. However, with the ESD’s dark theme, these were barely visible on my monitor.

The AppScreen.page tab also displays the graphic objects that you wish to be placed on the touchscreen. As soon as you select this tab, the simulation process starts automatically. I’m uncertain why this page exists, in addition to the App.main page, as they seem to perform the same function.

The MainPage.c contains a small amount of “C” code. I have no idea what this code refers to, as it doesn’t resemble any code that I have written for EVE-based displays. It seems to be a tiny amount of code compared to all the objects that were present in the example I was checking out.

Regardless of which of the first three “page” tabs you currently have open in the interface, the large central screen is divided into two distinct sections for easier navigation and interaction. In the specific case of the MainPage.page tab, the right-side section will be completely filled with rectangular blocks representing different elements. This screen can be zoomed in or out, using the mouse scroll wheel as well as the scroll bars for precise control. Each rectangle that has a green bar along the top is identified as a Widget. Other rectangles represent various math and logic operations essential for the program’s functionality. All these rectangles contain clearly labelled circles, which indicate input or output “port” connections. When you click on a “port,” it will highlight visually, and you can drag a connection line over to another rectangle’s “port” to establish a link. Those connections are what take a Widget’s output (which is triggered when you touch or adjust it) and couple it to another Widget’s input (which then modifies some property of that Widget). Making these “connections” is what partially defines the “C” program that the ESD application automatically generates for you behind the scenes.

As I mentioned earlier, this generated code is built (compiled/linked) into an executable program that is targeted to either of the following:

• An .exe file that runs on your PC and communicates with your target EVE-based display panel giving you a real-time representation of how your display will operate.
• A binary file (in hex or similar format) that can be directly uploaded to the targeted Host MCU, via USB (at least for MCUs that can be flashed in such a manner).

At the far-right hand side of the screen is the Library window. This contains a dozen or so general hierarchies, such as:

• ESD Widgets
• ESD Utilities
• Logic Flow
• 8 User sections

The various items in each section can be selected and dragged over to the right-hand section of the central, main window (where the above-mentioned Widget rectangles reside). Most, if not all, of the objects that you drag over to the central screen, will end up becoming “C” code for that project.

One thing that I found confusing, came up when I was using the code generated by the ESD, to directly control my VM820B15A display, via the MM4222-QSPI adapter and USB-C. In general, this mode of operation worked as expected. However, whenever I made any edits to the screen layout, or the interconnection “wiring,” and then re-built the code, things didn’t work as expected. When I re-started the program, the VM820B15A display would render the screen, but without any of those edits in effect. My Bridgetek contact later explained that you must Save the project, after any edits, before the re-build process would process those edits. I was not expecting this.

The ESD supports the three host MCUs previously mentioned. While I have/use two of them, I don’t use the IDE toolchains supplied by those manufacturers, instead preferring the Arduino IDE. Since the Arduino IDE is not supported by ESD, I could not try out the ESD application to any extent.

Software Libraries

Apart from using the ESE and ESD applications, if you want to develop code for various host MCUs, to run the VM820B15A, you’ll need to have an appropriate library. I noted that the VM820B15A’s webpage doesn’t mention any documentation or software, apart from a link to the display’s datasheet. There is a software tab on Bridgetek’s landing page, which covers Toolchains, but this only discusses the ESE, ESD, and EAB applications.

Bridgetek provides a series of driver libraries, some of which are generic and can be configured to be used with various MCU families. Bridgetek provides more in-depth support for the STM32 family and RP2040 MCUs as well as Bridgetek’s own FT9xx MCUs. In the Resources section at the end of the article, is a link to Bridgetek’s Github repository where you will find the following:

• EVE Apps: Demo and sample applications.
• EVE-MCU-Dev: A cross-platform library used to provide a simple interface for programming the Bridgetek EVE (FT8xx/BT8xx) devices with various host microcontrollers.
• Ft900-sdk: An SDK for the FT9xxx 32-bit MCUs.
• EVE5-Arduino-Dev: The EVE5 library that I used.
• Arduino libraries for earlier EVE2, EVE3, and EVE4 controllers.
• Python-bt82x-dev: Python development environment for the bt82x based module. Meant for Python development, hosted on a PC connected to the EVE controller via USB/FT4222 (or a related USB-SPI bridge adapter).
• LVGL-EVE: The popular graphics library LVGL ported for Bridgetek Eve Series GPUs.

Connecting the VM820B15A to your Host MCU

The VM820B15A display panel can be connected to your host MCU several ways:

• Using a 20-position 0.5 mm FPC cable—best choice for commercial applications.
• Using a 16 position 0.1” header connector/ribbon cable: great for prototyping.
• Soldering wires to a series of decent-sized pads on the PCB, which are well-labelled and cover all the required signals. Hint: these are good places to connect scope probes, while troubleshooting.
• By mounting Bridgetek’s MM4222-QSPI board. This allows you to connect to a PC via USB or by using one of three sockets meant to host several different MCU development boards.

I like this variety of interconnects, as it makes it easier to connect the board up to the protoboards that I use (Vector, etc.).

Note—when you are controlling the VM820B15A from any MCU board mounted on the MM4222-QSPI extension board, you must provide power to that MCU. Bridgetek says you can do this via the USB-C socket on the MM4222-QSPI board, but I used the USB-C socket contained on the Feather and Nucleo boards themselves which worked well in my testing enviorment. Note that the 12V power brick only provides power to the VM820B15A controller board and touchscreen display.

The ESP32 Feather board that I was supplied with, came with a demo written using Adafruit’s CircuitPython language. This is obvious since Circuit Python emulates a flash drive and pops up Window’s File Explorer, displaying the volume name CircuitPY and a list of Python files in the MCU’s file system for easy access.

Let’s examine the MM4222-QSPI adapter board in more detail. Figure 3 shows the MM4222-QSPI board with all the connectors and switches labelled. There is a switch that can be used to send power from the MM4222-QSPI to certain EVE controller boards. However, the VM820B15A requires much more power than the MM4222-QSPI can provide via USB, so this switch should be left open. The VM820B15A display can accept DC input voltages between 5V and 24V with a minimum power capacity of 20W. In my case, the VM820B15A gets its power from the 12V 5A power brick (12V is recommended).

In the center of the board are three discrete sockets:

• A Feather socket, for various Feather MCU boards.
• A socket for an STM32 Nucleo-F401RE development board.
• A socket for a WeAct STM32H743VIT6 development board.

At the bottom right is an eight-position dipswitch. This is used to select which signals are routed to the VM820B15A:

• (Q)SPI, and others, signals from any of the three MCU development board sockets.
• QSPI signals from the FT4222 USB-SPI bridge chip contained on the board. (See Table 11 in Bridgetek’s MM4222-QSPI datasheet).

Which MCU you use with the VM820B15A is up to you. If you are developing with the MM4222-QSPI board, I think the best choice would be to use the STM32 Nucleo-F401RE development board:

• Bridgetek specifically supports the STM32 MCU family using the STM32CubeIDE.
• Bridgetek’s EVE Screen Designer can compile your screen design into executable code, using the STM32Cube IDE toolchain.
• The Nucleo board’s header pins that plug into the MM4222-QSPI, also extend up from the top of the PCB, allowing you to connect other peripheral devices. It also contains an Arduino Uno footprint.
• Like many Nucleo boards, this one contains a breakaway section containing the ST-Link programmer/debugger. It also has the SWD pins available on a 6-pin header so when it is separated from the main board, it could be used as a general purpose ST-Link device.
• It is very low cost ($18 USD).
• Note that it uses the uncommon Mini-USB socket.

The slightly more expensive WeAct STM32H743VIT6 board would be a better choice if you need its more powerful MCU.

I ordered an STM32 Nucleo F401RE board, based upon the discussed features. I don’t use STM MCU’s very often, instead using five other ARM MCU families, from various companies. All are supported by the Arduino IDE, which I find user-friendly.

I’m a big Adafruit fan and while I was waiting for the Nucleo board to arrive, I tried out the two Adafruit Feather boards that I had on hand. I ruled out re-programming the supplied Feather ESP32S3, containing the CircuitPython demo. I wanted to keep it intact, so that I could always revert to it, in case I needed a “sanity check” if things stopped working.

One issue complicated my test process; The Arduino EVE5 library contains two examples, which I used for my testing. Both examples contain the following line:

eve.setup(wuxga);

This isn’t in the example’s .ino file, but in another #include file “eve_example.ino”. This is odd way of doing things as Arduino ino files do not normally call another ino file.

I assumed that the wuxga was the correct match for the VM820B15A display, since wuxga is 1920×1200 pixels. However, the VM820B15A has a resolution of 1920×1080. I recalled seeing a reference to FHD in the supplied CircuitPython demo program. After some searching, I discovered that in the EVE5 library, FHD is called FULLHD. Therefore, this line must be changed to

eve.setup(FULLHD);

During my initial testing, nothing I tried worked until I finally realized the above line had to be modified. I had the following Feather MCU boards on hand from other projects:

• Adafruit Feather ESP32C6 MCU
• Adafruit Feather RP2040 MCU
• Blues Cygnet Feather MCU (STM32L433)

I started out by running one of the examples supplied with the EVE5 Arduino library out on the Feather ESP32C6. Unfortunately, that did not work. The MM4222-QSPI Feather socket pins that are connected to the VM820B15A’s SPI port, correspond to the Feather ESP32S3’s SPI2 port (HSPI port), which is its higher-speed SPI port. It’s not possible to re-map the ESP32C6’s SPI0 port to the pins that are used by the MM4222-QSPI board. If you mounted the ESP32C6 Feather module on a separate board and connected the pins marked SCK,MO,MI and RX to the 16-pin header on the VM820B15A, it should work, using the default SPI port used in the EVE5 Arduino library.

I ran into a similar issue with my Feather RP2040 board. The MM4222-QSPI Feather socket’s SPI pins connected to the VM820B15A, are GPIO10-13. On the RP2040 MCU you can map these pins to SPI1. However, they are all defined differently, see Table 1.

You cannot map the SPI1 pins to properly match up with the connection to the VM820B15A. However, if you used an external RP2040 Pico or Feather RP2040 you could wire up its SPI0 port to the VM820B15A, and it should work (the EVE5 Arduino library uses the default SPI port which is SPI0 on the RP2040).

Finally, I tried my Blues Cygnet Feather MCU (STM32L433). This Blues STM32 board is specifically supported by the STM32duino board support package in the Arduino IDE and I have successfully used it for a few projects. However, when I attempted to compile the same simpleEVE5.ino program that I had used for the other 2 MCUs, the Arduino compiler reported pages of errors, so I ruled out using this board.

My conclusion is that having a Feather-based MCU board is no guarantee that it will work seamlessly with the MM4222-QSPI daughterboard. Even the supplied ESP32S3 Feather board, which works using CircuitPython, would need changes made to the EVE5 Arduino library to use the HSPI port, rather than the default VSPI port defined in the Arduino IDE.

Later, I received the STM32 Nucleo-F401RE board that I had ordered. I expected this board to work right away, given that Bridgetek has provided a socket for it on the MM4222-QSPI adapter board. That wasn’t the case. Here are the two issues I discovered.

The EVE5 Arduino library contains the EVE_MCU.cpp file, where you define the SPI pins to match your MCU. This is supposed to be done in the following code snippet (line 64):

/// Standard SPI pinouts 10(CS), 11(COPI), 12(CIPO), 13(SCK)

#define PIN_SPICLOCK 13
// SCK

#define PIN_DATAOUT 11
// MOSI (COPI)

#define PIN_DATAIN 12 /
/ MISO (CIPO)

#define PIN_CHIPSELECT 10 // CS

The numbers 10–13 are the standard Arduino pin designations for the default SPI port pins. These settings did not work with the VM820B15A display. I also tried using the actual STM32 pin numbers that are called out in Table 6 and Table 7 of the MM4222-QSPI user’s guide. The compiler accepted them but that didn’t work either. Later, I found out that it doesn’t matter what you enter on the lines following line 64, for the SCK, MOSI, MISO pins—these #defines are not used by this library. It turns out the EVE5 library just uses the default SPI pins, so the only thing that must be specifically defined is the CS# pin (i.e., PIN_CHIPSELECT). On the MM4222-QSPI board, the CS# pin is connected to PA4. PA4 is not what Arduino labels pin 10 (PB6 is). Therefore, change line 68 to:

#define PIN_CHIPSELECT PA4
// CS# was originally 10

I thought for sure that the display would come alive after I corrected this, but it did not. The only signal left to check was the -RST pin. In the two EVE5 library examples, there is no code to toggle the VM820B15A’s -RST line, and I assumed that the VM820B15A looks after the -RST line itself, at power-up. However, when I ‘scoped the VM820B15A’s -RST line, using the Nucleo board, it showed a 1V level with a small amount of digital signal superimposed on it. That’s low enough to keep the VM820B15A in a reset state. Using the Nucleo board, the VM820B15A’s -RST line is connected to the STM32F401’s PA1 pin. I don’t know why PA1 was sending this odd signal. But, I added code to the example program to place PA1 in Output mode, then toggled it high, low, and then left it high. Success—the display came to life.

I thought of a possible project using the VM820B15A to do after finishing this review. That project lent itself to the Teensy 3.6 MCU module, which has excellent Arduino support. So, I built up a board containing a Teensy 3.6 module and used a 16-pin ribbon cable/header to connect it to the VM820B15A directly.

The Teensy 3.6 uses an NXP MK66FX1M0VMD18 MCU and I used the default SPI port, defined in the Teensy Arduino board support package.

Figure 6 is a photo of the VM820B15A running that project’s code. While it is not evident from the photo, this is a very bright display. The BT820 has a register to control backlight brightness using PWM, so both the brightness and power consumption could be customized.

The VM820B15A display can handle a QSPI interface at clock rates up to 60MHz, when used with the MM4222-QSPI daughterboard and the WeAct development board. The Feather ESP32S3 board can run at an SPI clock rate up to 40MHz. The CircuitPython demo program on the supplied ESP32S3 Feather board, used QSPI. I observed the extended QSPI signals on my scope but didn’t think to measure the clock speed at that time.

The Bridgetek EVE5 Arduino library only uses the standard SPI interface. The default SPI speed used by that library is 8MHz. This is set in line 101 of the EVE_MCU.cpp file. I ran it up to 20MHz using the Teensy 3.6 MCU. Whether or not the EVE5 Arduino library uses QSPI, is moot because Teensy boards reserve QSPI for PSRAM and Extended Flash memory.

For anyone used to Arduino C++ programming, the structure of the two EVE5 example programs supplied, will be confusing. They don’t take advantage of Arduino’s compiler pre-processing in terms of forward routine recognition. Therefore, the setup() and loop() routines are at the end. Also, the loop() function, calls a routine contained in another .ino file, which is quite unusual. The EVE5 library consists of 13 individual .c/.cpp/.h files and uses a hardware abstraction layer (HAL). Even though the EVE5 Arduino library and examples do not follow many Arduino conventions, the two included examples do work when modified as I’ve previously outlined.

Miscellaneous Observations

There is one feature of the BT8xx EVE controllers that may trip you up if you are not familiar with it. When you are using Display List functions like the LINE and RECTS (rectangle) commands, you must be aware of a limitation on how you specify the X, Y co-ordinates. Early EVE controllers were dealing with smaller LCD panels—in the order of 480×320. Bridgetek decided to structure all commands as 32-bit words. Certain instructions, like those used to produce lines and rectangles, contain 14-bit fields for each of the X and Y co-ordinates. This field size, in conjunction with the fact that EVE defines their X and Y resolutions in 1/16th pixel steps, means that your co-ordinate values (multiplied by 16) must fit into a 14-bit field size.

This is obviously an issue with the VM820B15A’s much larger 1920×1080 pixel display. To handle this, you must use one or both of the following commands:

eve.VERTEX_TRANSLATE_Y(500 * 16);

eve.VERTEX_TRANSLATE_X(800 *16);      

Here, I am defining a new coordinate origin of 800 (X) and 500 (Y). Following these statements, subsequent LINE or RECTS functions will be offset by this amount, allowing you to cover an area up to ±512 pixels away from that 800,500 origin. You may have to redefine these offsets several times, to completely cover a large screen like that found on the VM820B15A. You can also change the coordinate range in exchange for precision via the VERTEX_FORMAT instruction. This allows the precision of VERTEX2F coordinates to be set to 1, 1/2, 1/4, 1/8, and 1/16 pixel. A precision of 1 provides a range of -16384 to 16383 (allowing the full set of coordinates to be used without translating) compared to -1024 to 1023 for 1/16th pixel.

Note that the Coprocessor functions (i.e., Widgets) handle this coordinate limitation transparently. Exceptions to this, that I’ve noticed, are Circle, Arc and Arc Slider widgets, which can’t have radius > 511 pixels.

EVE-controlled displays require a calibration procedure for their touchscreen. Bridgetek provides a routine to perform this calibration, which is included with the two examples provided with the EVE5 Arduino library.

When you run these examples, the screen shows a sequence of three flashing circles that you must touch, to perform the calibration. Note that this calibration is volatile—it doesn’t persist when you remove power to the display/controller.

The calibration procedure loads six 32-bit registers: EVE_REG_TOUCH_TRANSFORM_A through _F. To make this calibration non-volatile, you must read these six registers:

eve.LIB_RegRead(EVE_REG_TOUCH_TRANSFORM_A,&E.transformA);//for all 6 registers

Here, I am using the structure “E”, which consists of six 32-bit variables (labeled transformA through transformF). Since I am familiar with the Arduino EEPROM library, I use the EEPROM.put statement to save this structure to EEPROM. On subsequent power-ups, I use the EEPROM.get routine to fill up the “E” structure with those six values. Then I use the following to restore the calibration:

eve.LIB_MemWrite32(EVE_REG_TOUCH_TRANSFORM_A,E.transformA);//for all 6 registers

For some unknown reason, the EVE5 library contains a LIB_RegRead function but doesn’t contain a LIB.RegWrite function. As previously seen, I used the MemWrite32 function instead. The two example programs contained routines labeled platform_calib_read and platform_calib_write but they were just stubs, they did nothing. The EVE calibration procedure hasn’t changed since the original FT800 controllers were introduced. I wrote the routines mentioned, while working with the earlier EVE generations.

The DAC and Audio amplifiers present on the VM820B15A are fed solely from the BT820’s I2S bus. The synthesized sound generator provides left/right PWM signals from pins on the BT820 chip that are not accessible on the VM8210B15A. However, the synthesizer can also send its output signals directly to the I2S bus. The code snippet in Listing 1 will play a sound from the synthesizer.

Listing 1
This small code snippet will play a “ding” sound using the VM820B15A’s synthesizer.
  
EVE_LIB_MemWrite32(EVE_REG_I2S_CFG, 0x00);    eve.LIB_BeginCoProList();  eve.CMD_I2SSTARTUP(48000);  eve.LIB_EndCoProList();  eve.LIB_AwaitCoProEmpty();   EVE_LIB_MemWrite32(EVE_REG_I2S_CTL, 0x0A);   EVE_LIB_MemWrite32(EVE_REG_VOL_SOUND, 0x80);   EVE_LIB_MemWrite32(EVE_REG_SOUND, 0x49);// Ding sound- see Bridgetek docs 					  //  for other synth sounds  EVE_LIB_MemWrite32(EVE_REG_PLAY, 1);

You can also play WAV files from the SD card socket on the VM820B15A. Listing 2 is the code snippet that will handle this. I had to manually patch the Eve5 Arduino library to include the I2SSTARTUP routine, but Bridgetek will have the library updated before you read this. You should also note that regular commercial WAV files will not work. You must first import them into the EAB program, and run a conversion program in the Audio Utilities tab. What this does is strip out all the WAV headers apart from the “fmt” and “data” chunks.

Listing 2
This small code snippet will play the WAV file “happy-summer.wav” using the I2S DAC and audio amplifiers. Standard WAV files must first be processed by the EAB program, or they  will not play.

eve.LIB_BeginCoProList();eve.CMD_I2SSTARTUP(44100);eve.LIB_EndCoProList();eve.LIB_AwaitCoProEmpty();EVE_LIB_MemWrite32(EVE_REG_I2S_CTL, 0x0A);EVE_LIB_MemWrite32(EVE_REG_VOL_L_PB, 40);EVE_LIB_MemWrite32(EVE_REG_VOL_R_PB, 40);eve.LIB_BeginCoProList();eve.CMD_SDATTACH((EVE_OPT_4BIT | EVE_OPT_IS_SD),0);eve.CMD_FSSOURCE(“happy-summer.wav”, 0);eve.CMD_LOADWAV(0, 0x2000);//OPT_FS);eve.LIB_EndCoProList();eve.LIB_AwaitCoProEmpty();EVE_LIB_MemWrite32(EVE_REG_PLAYBACK_LOOP, 0);EVE_LIB_MemWrite32(EVE_REG_PLAYBACK_PLAY, 1);

The Speaker connectors are tiny JST 4-pin connectors. A suitable cable is DigiKey 455-4304-ND. The speaker connects to pin 1 and pin 2—these are the two pins nearest to the µSD card socket on the board.

The EAB application contains many useful utility programs for image, video, and sound file conversions. The ones I’ve used are very user-friendly. If you’ve used EAB in the past, you may not notice the labels “BT82X” and “Pre82X” on the left side of the screen. You must select the “BT82X” option for the various conversion utilities to provide the file formats that the BT820 controller expects. Since the BT820 supports and directly controls much greater RAM and Flash memory than earlier EVE generations, the applicable file formats are going to be different from those of earlier generations.

I wrote a program that renders a fairly complex dashboard, and tracks touches to the touchscreen and responding to MIDI signals coming in via the USB port. The screen updates appear instantaneous to my eyes. When I measured the time it took to execute the complete display/touchscreen tracking/MIDI monitor loop, it was 150µs. Figure 6 shows the VM820B15A running this program.

User-Friendly Display

Bridgetek approached me to collaborate on an article about its newest EVE5 controller generation, and the VM820B15A display panel that uses it. This happened very early in the production cycle, so I was working with the EVE5 Arduino support library at a very early stage.

The Arduino IDE is not among the host MCU IDEs that Bridgetek’s is primarily focused on, since it is catering to medical, industrial, and commercial customers. Some of the difficulties that I ran into, when using the ESE and ESD PC applications, are likely attributable to the differences present in the latest EVE5 controller generation. I assume that these will be addressed before you read this.

That said, I was able to get up to speed on the new EVE5 generation fairly quickly. The BT820 certainly handles the large HD display panel and touchscreen very nicely.

Author’s Note: I wish to acknowledge the generous technical support I received from Graham Brown and Aaron Jones (Bridgetek-UK) as well as Vonica Tng (Bridgetek-Singapore) for arranging to send me the VM820B15A kit.

RESOURCES
Bridgetek | www.bridgetek.com
Sparkfun | www.sparkfun.com

SOURCES
Bridgetek VM820B15A Display/associated support components: VM820B15A – IC & Module

Bridgetek Github site (software, etc): Bridgetek Pte Ltd · GitHub

Teensy 3.6 MCU:  The Teensy 3.6 has been superseded by the Teensy 4.1, available from Sparkfun.
Teensy 4.1 | For Sale at SparkFun Electronics – SparkFun Electronics

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • SEPTEMBER 2026 #434 – Get a PDF of the issue

Sponsor this Article