I welcome you to the main part of my Roadtest review about Bridgetek BT817 evaluation board. In this part of review, I will describe BT817 graphics engine itself and I won’t describe evaluation board here because it is described in dedicated chapter. Except these two review parts, there are two articles describing projects which I have done for gathering experiences with board and graphics accelerator and one article designed as tutorial describing operation of coprocessor engine. Finally, there are main page of RoadTest review containing brief summary and final score. Links to all chapters are as part of following table of contents:
- Introduction, contents, summary, and score
- Review of Bridgetek BT817 Embedded Video Engine (this page)
- Review of Bridgetek ME817EV Evaluation Board
- Pacman using Bridgetek BT817
- How does the BT817 coprocessor work?
- ZUSI 3 display (become available in the future)
Bridgetek BT817 is chip that can be controller using SPI or QSPI (QSPI is modified variant of SPI which utilizes more lines to transfer data at parallel) bus and generates signals required by modern high-resolution LCD displays. Chip can accelerate many tasks in hardware. It efficiently offloads large number of bitmap operations and others to the hardware reducing software load. In this blog post I will describe what this chip can do for you, how you can benefit from them, some of its limits, but at beginning I will describe how Bridgetek chips are classified and what are main differences between them.
Classification of EVE
Bridgetek refer this kind of chips as EVE which means Embedded Video Engine, and this briefly describes what are this chip used for. Bridgetek EVE history is long and BT817 is part of 4th generation of these chips. Family is referred as BT81x and contains BT815, 816, 817 (which is reviewed here) and 818. BT515 and BT516 are referend as previous generation but they are very similar to more modern BT817 and BT818. BT515 and BT516 differs in embedded touch screen controller, otherwise they are the same. BT815 has controller for capacitive touch controllers and BT816 has integrated controller for resistive touch controllers. The same pattern also applies for newer family. BT817 has controller designed for use with capacitive touch controllers and BT818 has controller designed for use with resistive touch controllers. So BT817 and BT818 are very similar and almost everything described later in this chapter also apply to BT818. Bridgetek is very nearly tight with company FTDI. At the beginning EVE chips were originally part of FTDI and previous generations of EVE are not referred as BT but they are referred as FT. So, there are second generation of EVE referred as FT81x. As part of this family there are chips FT810, FT811, FT812 and FT813. Finally, the oldest generation of EVE is referred as FT80x and contained two chips: FT801 and FT802. There are improvements between generations. For example, original first generation supported only small displays, has less RAM and has different memory layout, so there is mostly no compatibility except same basic concepts which are shared across all EVEs. But when comparing latest two generations, you will see many similarities. Memory layout is the same, many parameters are the same, SDK is the same, but newer generation supports more features like adaptive HSYNC. Due to nature of small changes, it is possible to migrate between latest two generations easily.
Comparison with MCUs that support display interface
Today, there are two commonly used approaches adding display to your embedded design. One of them is that you buy MCU which have display interface. Second common solution is that you use external chip for generating signals required by display and you command this chip from your MCU using some common bus like SPI. This is a case of BT817. But for now, I want to briefly compare these two approaches because both have some pros and cons.
MCU only solution have some benefits at the first look. The main benefit most probably is that you do not need additional chip and required stuff like crystal, decoupling capacitors and other passives. This is true, but note that when you make design with display, you usually are not space restricted because display itself is large components and boards controlling display are usually also large. The other benefit of this solution is that there are no bottleneck of external serial bus and communicating with MCU internal graphics engine is done using fast internal (parallel) system bus which means that commanding engine takes less time. The disadvantage is that graphics engines integrated within MCUs are usually significantly less complex and usually it is only some kind of DMAs transferring buffer from memory to the display interface. This is case for example of MAX32650 which has been RoadTested (Maxim MAX32650-EVKIT) one year back, so you can read some opinions on using this approach for drawing objects on display. This microcontroller only supports transferring graphics buffer to the display and nothing more. For example, if you need to fill rectangle you must include two loops with filling required memory region in your program. These fills cost you lot of processor time. Often this means, that it cost you much more time than issuing simple command to the external chip over slow serial bus. Some MCUs have accelerator for some basic operations like filling rectangle or pasting bitmap from one point memory to the display buffer. Example of MCU with this accelerator is STM32H7B3 which has been also RoadTested (STM32H7B3I-DK - DISCOVERY KIT). And finally, there are few MCUs with advanced accelerator very similar to engine which is part of currently RoadTested BT817 chip. Example of MCU with so complex graphics engine is Renesas RX72N which has been also RoadTested (Renesas RX72N Envision Kit) recently, so you can review some opinions and reviews of this solution. Note that when going from simple to most advanced MCUs, price grow significantly and when choosing more advanced MCU there are other common caveats like lack of small packages for MCU, lot of unused peripherals and many more. Even there are very complex MCUs nowadays there are still many cases when external chip is better. It is case when you need some advanced features, or you need to achieve better performance. Another case when it is better to choose external chip like BT817 is when you just want (or need) offload tasks from your MCU and releasing its CPU to more important tasks. Controlling serial bus is more deterministic then generating screen manually and when you do real time application, this can be significant simplification of analysis. Lastly, there are usages when you have some existing embedded system with microcontroller, and you want to add display to this design. In case when for example migration to more advanced and performant MCU is not possible, or it is too expensive It make sense to integrate external chip and command it over simple bus from your MCU which is already present in your design.
BT817 Engines
BT817 (and most other chip from Bridgetek’s families) has multiple engines sharing chip infrastructure. BT817 has following engines:
- Graphics Engine
- Graphics Coprocessor
- Touch Controller
- Audio Engine
Engines looks independent but they share some resources like memory. For example, configuration registers of each block are inside single shared region mapped to the same address space. You of course do not need to use all engines at all. Using BT817 without graphics engine usually does not make sense but if you do not want to use coprocessor, or touch inputs, or play music, then you do not need to configure and use them. All engines are very easy to use. You probably will use SDK which contains drivers for all engines implemented but even manual writing to register is very simple. Most engines work out of box and do not require any special configuration and boot procedure. There are two exceptions. Graphics engine has specified boot procedure and need configuration of parameters of display which you use, and second requirement comes from touch controller which needs calibration data to be configured before use. Both procedures are documented well but SDK implement slightly different boot procedure. For example, SDK implementation waits 10ms after switching system clock source from internal to external crystal, but boot procedure described in documentation do not do that.
In following sections I will describe engines mentioned above.
Graphics Engine
Graphics engine is fundamental engine of BT817 chip. It is hardware accelerated engine executing your commands and generating image data signals which are later fed to the display. Graphics engine executes commands from display list. I have described some display list command in the article describing my Pacman project. List of supported commands by graphics engine is not extensive, but this make sense because every display list operation must be hardware accelerable.
There are some nice, interesting features like support for fractional pixels which is used with antialiasing. Antialiasing works well when used naturally, but I found one case when it does not work – when used with stencil buffer. For example, if you draw circle with transparent colour, correctly configured stencil mask and operation and then refill area by rectangle, resulting circle will not be antialiased. I probably understand internal reasons for that, but it would be nice if it would be resolved as part of future EVEs.
Graphics engine can do hardware accelerated operations with bitmaps. It can crop, translate, scale and rotate bitmaps. You can use this feature for drawing some unsupported primitives like eclipse. Graphics engine supports multiple formats for your bitmaps (and colour paletes). You can pass whatever you want, and you combine formats. Engine will recalculate final color of image internally and you do not need to worry about it. You just need to pass correct format code of bitmap format used.
Bitmaps are also used for fonts. Fonts are implemented using bitmap strides and later Unicode formats adds some definition structures. Graphics engine has commands that support extracting and placing one letter from font bitmap stride to the display. There is no display list command for drawing text (because it is hard to hardware accelerate operations with dynamic length data). You can print text just using display list by manual placing every letter but much easier is to use coprocessor which will be described later.
Graphics engine commands are encoded to the 32-bit values. SDK contains macros used for encoding parameter of commands to the 32-bit value that can be later send to the BT817. While you most probably will use macros from SDK, you can also encode them manually. Encoding is intuitive and if you understand hexadecimal numbers, then you can encode them manually. As part of review, I prevented to use SDK much because I always want to see all details and after reviewing time I can safely say, that commands encoding is designed in a very user-friendly way. While you probably will not encode them manually in real life, it is still useful for example when debugging some bugs in complex display lists generated by multiple procedures and so on.
Graphics engine limits
Graphics engine is hardware accelerated and every hardware has some limits. The most significant limit of BT817 graphics engine is size of display list memory. Display list memory is 8 KiB large which means that can hold 2048 display list commands. This looks like enough, but in some cases this could be insufficient. Note that for example rendering string consume one display list command per letter. This means that you cannot (easily) draw text with more than 2048 letters on screen using this engine. In fact, the limit is less than 2048 because there are some overheads with initialization commands.
Some other limitations come from fixed number of some “peripheral” instances. For example, there are MACRO instruction which substitute display list instruction from special function register. But there are only two macro instances – MACRO 0 and MACRO 1. If you need more macros you must manually regenerate display list. It would be nice support more macros.
Graphics coprocessor
Graphics coprocessor is independent microprocessor which can offload lot of tasks from your MCU to the BT817 chip. It supports broad range of instructions. Instructions are passed from your MCU to coprocessor over FIFO. Instructions are more advanced than display list instructions and can have dynamic length parameters. Based on passed instructions, coprocessor drives internal engines. It can control more than graphics engine. For example, it can read touches from touch controller. Most common usage of coprocessor is to draw text. You pass just font number, pixel location and string and coprocessor will calculate required display list command and writes them to the display list at background. But coprocessor is not restricted to drawing operation only. You can for example issue command for calibrating touch controller. Coprocessor draw dots on screen for you, wait for input from touch controller and then calculate required calibration coefficients. Coprocessor can also do some computational tasks for you. Example of these tasks is compression and decompression which you can used for extracting assets like bitmaps and fonts before use. Another task which is handled by coprocessor is video playback. Coprocessor can manage video playback for you. Yet another (very common) use case of using coprocessor is drawing some controls like buttons, progress bars, and so on. This is nice feature. It can speed up development and reduce time to market, but if you need company design template or some designer designed these components for you, then you most probably will render all these components manually. Lastly, coprocessor is used for flashing external flash memory. I will describe memories later. BT817 supports loading assets like fonts, bitmaps, videos, and audio from external serial SPI flash memory connected directly to BT817 (not a your MCU). If you want to erase and program this memory in-place, you can use coprocessor commands for doing this.
If you are interested in more details and examples related to coprocessor, then you can read other part How does the coprocessor work? of this review.
Touch controller
Another interesting engine is touch controller. It is independent engine controlling I2C master (not a slave) interface of BT817. You can connect touch controller of your display to this interface and then BT817 will handle required protocol to you, can generate interrupt for you when touch is detected and finally, can recalculate and expose coordinates of touches. Touch controller is most probably implemented as microcontroller that runs firmware from ROM and RAM. ROM contains firmware implementing communication with most common touch controllers, but it is patchable. There are some patches at Bridgetek forum and there are also some implemented as part of SDK. These patches add support for originally non-supported touch controllers. There is no documentation about instruction set of this engine, but there is simple compiler as part of EVE Assets Compiler tool which I will describe later. It is not a full-featured compiler like GCC, but it can compile small very restricted programs written in C-like syntax. You can use it for adding support for unsupported touch controllers (or other chip which would be funnier) on your own behalf.
If you are interested in more details and examples about touch controller operation, then you can read some more details about it at the end of my Pacman project article. As part of this article there are also diagram showing topology of external MCU, BT817, evaluation board, touch controller and touch panel in more clear way than it was described in this section.
Audio engine
The last engine which I have not described yet is audio engine used for playing embedded tones from ROM or your own sounds from RAM or external FLASH. Because I did not received cable for connecting speaker within RoadTesting period I did not tried this feature yet. I expect that it works well like other parts of BT817. I will check it later and I find some caveats I will update this section later.
Memories
BT817 has lot internal memories including ROM for internal firmware and default embedded fonts and some textures. Except ROM there is general purpose RAM. You can address assets like bitmaps, fonts, videos and audio from this memory. RAM is directly accessible over SPI (and QSPI) bus and is volatile. If you want to place some resources to RAM, you must redeploy them every time at boot time. In most cases this also means that you need to have all resources available in the flash memory of your MCU. BT817 general purpose RAM is 1 MiB large. If you need more than 1 MiB, you can use external FLASH memory. BT817 has QSPI master (not a slave in this case) interface that use for driving external memory. BT817 maps this memory to the address space, and you can reference it similarly as a standard internal RAM, but you can’t write it directly. If you want to write inside this memory you must do it using coprocessor commands. The external FLASH is beneficial because you can use it for storing much larger resources including videos. You can select right external FLASH size depending on your needs. Other benefit of external FLASH is that you do not need to hold content of this memory as part of your MCU. Lastly, external FLASH is non-volatile so you do not need to copy its content every time at boot and its content can be flashed only single time (for example at manufacturing time).
Performance
The BT817 chip is clocked by 12 MHz crystal. This clock can be used as a source, but more common configuration is that this clock is used as a input to the PLL and PLL generates clock up to 72 MHz. Clock speed affect performance but I did not find any performance limit or bottleneck when RoadTesting BT817. All experiments I have done without any performance issues. When running out of box demo (which I will describe later) I seen some lags when playing and decoding video offloaded to BT817 but another approach of playing and decoding the same video worked well, so playing video most probably will require some tweaks and optimalizations, but this is acceptable from this tiny chip. It is still surprise to me how performant this chip is in comparison with MCU only solution when you need to draw every pixel manually using slow algorithm. Playing video is impossible on almost every MCU including MCUs running on much higher frequencies than 72 MHz. In opposition, BT817 can do that without any issues.
Software
Bridgetek provides some software related to BT817 chip. I classify software related to BT817 to the following categories:
- Utilities for designing screens and converting assets to the format understand by BT817
- Software examples
- SDK (which you can get as part of software examples)
- Other small platform specific examples
My first note is that most software is not linked directly at either BT817 or ME817EV page. Most software I found occasionally when browsing over Bridgetek website or other resources. Especially very high-quality SDK is unintuitively part of example projects which are available at separate page. While it is very high quality It is not promoted anywhere. Also note that download link is not highlighted on the mentioned page and it is not easy to find them inside bunch of text at the first look. But when you find it, it will save you a lot of time. Except SDK there are 3 tools (in opposition to SDK they are correctly linked at BT817 page). There are very interesting EVE Screen Designer. This tool allows you to design custom screen in GUI and then generate C code for you. I did not used it very much because I used my own library and SDK which is part of project examples, but these tools look nice and can save you a lot of time when used. The other tool is EVE Screen Editor (the only difference in the name with comparison to previously described tool is Designer vs Editor). It is less complex tool and can give you overview about coprocessor commands and how does coprocessor programmes look like. You can use it for placing coprocessor commands and watching how your commands affects output in real time. The last tool is asset compiler which you can use for converting image, audio and video to the format accepted by BT817. You can use this tool for converting fonts including Unicode fonts to the bitmap stride and descriptor required by BT817. Finally you can use this tool for flashing content to the external FLASH memory when connected with ME817EV board (or compatible). All three tools are nice and work well. Their usage is optional, and you can do manually whole stuff, but using them can save you a lot of time and I recommend using them.
The next provided software is very complex software examples that shows most features of the BT817 chip. It is separated to 15 sets and some sets are split to multiple consecutive examples. When you run this sample app you will see all drawing primitives, bitmap operations, video, lot of animations, touch controller operation, hear sound if you have connected speaker and many other. You will see almost all capabilities of BT817 and this demo gives you nice overview what this platform can do. The software examples are available with SDK as part of Visual Studio C++ project. There are multiple solution files targeting different platforms. Examples are multiplatform and contains lots of ifdefs due to this. There are multiple ways how to run demos. The simplest way is just using ME817EV evaluation board connected to PC over USB. Demonstration software runs on your computer and communicate with onboard BT817 using onboard FT4222 chip that acts as USB-to-QSPI and USB-to-GPIO converter. You do not need to setup any project related to your microcontroller for running these demos and you need just a computer with USB. This is nice. But this is not the only available approach. The other approach is using emulator. When running project configured for using emulator, then you do not need to own any evaluation board or own hardware at all. You can see demo using emulator just now. Emulator pops up window emulating display and you can see the same what you would see on physical display connected to BT817 on screen of your computer. But feeling from watching physical display controller over USB is much better, I think. Finally, there are third option using microcontroller from FTDI. Projects are setup to compile and runs on this platform. If you use FT9xx microcontrollers from FTDI, then you can use board and display in this way. Note that there are FT900 MCU evaluation board MM900EV which is pin and mount hole compatible with RoadTested ME817EV board, so using this microcontroller is one of the simplest ways of using it with external MCU. But if you do not want to use FT900 MCU, then you can still use the SDK and software examples, because they are written in portable way and you must implement just an underlaying hardware layers and then it will work like a charm. While examples are compiled by MSVC using Visual Studio toolchain, code contains only basic variants of preprocessor commands and looks compilable by GCC which would be especially useful when you decide to compile examples for your own platform. I have not tried this, but I did not find any restriction preventing doing this. Except sample project with 15 sets there are more real-life demonstration projects showing for example implementation of display applications possibly used in elevators, washing machines, signal visualizers and many more. They are based on the same SDK and you can use them as another source of valuable examples.
As part of code examples there are complex and comprehensive layered SDK. The SDK is not referred anywhere but you can use it as a base or startup point of your applications. Because it is hardwired to example projects it is very easy to use because you can find example related to almost any functionality of SDK (and BT817 chip). There are multiple layers and functions set. For example, if you want to write to the DL directly you will use different function than you use for writing command to coprocessor FIFO. It is little bit confusing at some points because there are multiple function doing the same thing at the first look, but they do it differently and combining them may not work. For example, there are two ways for swapping display list. One possibility is using following command:
GPU_DLSwap(phost, DLSWAP_FRAME);
And second possibility is using following command:
EVE_CoCmd_swap(phost);
The first command is used when you setup display list commands manually and the second command is used when coprocessor is used for generating swap command. Combining approaches results into non-working code or unexpected behaviour. Support for triggering all actions using all possible approaches are welcome, so this design make sense, but you must pay attention especially when copying codes between examples and make sure that they are compatible.
The last software examples which I found are different platform specific samples. For example, there are small example showing how to use BT817 using PIC microcontrollers. The other example for example shows how to use it with STM32 microcontrollers and so on. There are also Application Notes related to this samples. They are not based on SDK described above and looks that they were implemented from scratch. Most of them is old and website contains note, that some of them still was not ported to support latest EVE family. I had no reason to use them, but if you are using some of these MCU and you do not want to use full featured SDK (for example due to code size restrictions. Sometimes you want to use something with less features resulting into smaller executable code), then you can use them as a starting point.
Documentation and Support
There are multiple PDF documents provided by Bridgetek. The most important documents are datasheet and programming manual. Datasheet mostly describes properties of the chip while programming manual contains detailed description of register, instructions, memories, and much more. Both documents are well written, compact, and easy to read. Both documents contain useful information, and both are very helpful when working with BT817. Both documents are not very long. Lot of information that can be simply deduced are omitted. I like this because documents are shorter while they still contain similar amount of useful information like longer documents from many other vendors. But there is one information which I consider missing. It is describing QSPI protocol. While it looks simple at the first look, there are some strange things like switching direction of wires and turning outputs to high-impedance state. QSPI bus must do this due to nature of bidirectional wires naturally. There are no diagram showing how should protocol be implemented, but it is briefly described in the text. I would like to see some timing diagram describing what BT817 does and what host MCU should do when turning to the QSPI mode like it is visualized for RGB interface at figure 4-6 in datasheet. Similarly, there are briefly discussed possibility for configuring additional wait state in QSPI protocol (SDK does it), but I still do not understand the purpose for doing that, what is benefit of that and what should I do that. It would be nice to describe this details more. But expect this I did not find any other significant issue with documentation. I like it and I think that Bridgetek do this well.
Expect datasheet and programming manual there are lot of application notes. Many notes are pretty old and was not updated to support latest generations of EVE. Most AN are related to one of the oldest EVE generation referred as FT80x. Some documents target newer (but not the latest) FT81x generation and almost no AN is related to the latest BT81x generation. But this is not an significant issue because there are very good datasheet and programming manual which fits almost all needs. I did not used AN a lot, but I browsed over them and I think their quality is similar to other Bridgetek documents.
To the documentation section I also assign software examples which were described in previous section. They are very good and significantly reduces need to search for information in documentation because they demonstrate many things in more friendly way.
Lastly, there are online forum which you can ask your question related to any Bridgetek product and in most cases, you receive high quality professional answer directly from Bridgetek engineers. They can also solve your issues and for example provide patch to you if possible. It is cases of some touch controller blobs which you can find on forum with related discussion. But of course, you can ask there even beginner questions. Most of them is answered very well.
Cost and Availability
At the time of writing this review BT817 is rated at about 8 USD at Newark and between 6 and 12 USD at other distributors for one piece. Prices below 8 USD I consider as good prices for this chip, but 12 USD is little bit overpriced. When buying more pieces, the price usually goes down to about 7 USD at almost all distributors. Stock availability is also good. While it is IC supply chain shortage at the time of writing this review, BT817 is available at some distributors, including distributors offering them for low prices. Similarly to ME817EV, I have seen BT817 available at local European distributors which usually do not offer this kind of advanced chips and they are usually limited to bestsellers only. But Bridgetek chips are available here, so I recommend trying look there when buying BT817 or other chips and evaluation boards from Bridgetek or FTDI.