RoadTest: Bridgetek Embedded Video Engine ME817EV + Display
Author: obones
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Electronic Assembly uniTFT: https://www.lcd-module.com/produkte/unitftshigh-end-pcap.html Stone HMI : http://www.stone-hmi.com/industrialtype Nextion Intelligent series : https://nextion.tech/intelligent-series-introduction/
What were the biggest problems encountered?: Somewhat confusing documentation, lack of detailed explanation of demos behavior
Detailed Review:
First of all, I would like to thank Bridgetek and Element14 for selecting my application to roadtest the BT817 chip via its ME817EV evaluation board. It is a great opportunity for me to experiment an advanced display solution.
In the package we received there was the evaluation board and a 7 inches display from Riverdi. While this may not seem much, it’s more than enough to be able to test the various aspects of the BT817 chip functionality. Indeed, here is what is offered by the board itself as taken from the datasheet:
The board comes in euro size 100*160 which may seem quite big, but this allows having the various functionalities clearly laid out and separated, meaning they are easily identifiable.
It also features four corner holes to allow attaching the board to a fitting case, and also four standing pods that I first thought were VESA 75x75. But they are not placed as a square and the datasheet shows they are actually meant to be used with MM900EV development modules, the platform used to evaluate Bridgetek own FT9xx RISC CPU family. It is nice to see a convergence of usage in two different products from the same manufacturer, as this is not always the case.
The only thing that was missing is a compatible speaker to plug into the board. The CleO-SPK1 is mentioned in the datasheet but its specifications are not quite easy to figure out. It appears to be an 8Ohm 1/8W speaker which is in line with what the datasheet is saying about the audio output. And while all connectors are described in details, the audio one is missing the pins pitch. Reading the fine print on the schematics leads to the following reference: JST ZH 4-pin
This is a 1.25mm4 pin connector and is quite easily found, allowing to create a speaker out of spare one that I had.
After having made sure to follow the setup steps laid out in the datasheet, especially the LCD bias voltage checks, we are all set and can start using the provided software.
But first, a bit of background on how an LCD panel is made and what that implies on the way we must “talk” to it:
The full transcript is available here: https://en.wikipedia.org/wiki/File:Lcd-engineerguy.ogv
As we have seen here, to light up a given subpixel, we must turn on the appropriate row and column with the right amount of power. And this is to be repeated often enough that our eye does not see the refresh happen. If we stop refreshing, the pixels go back to their default state, and the image disappears.
Because the LCD panel itself does not have any memory of its own, there must be a source for that information which a routine will constantly read from to activate the appropriate pixels in due time. This memory is usually called the “frame buffer” as it contains the currently displayed content, or frame. Specialized chips exist to perform just this, such as ILI9341 from Ilitek
Now that we have a buffer for the LCD to pick subpixel data from, we must fill that information with values. Using the specialized chip above, we see that it accepts data in the form of RGB values which means we have to create the graphics pixel by pixel to then transfer it to the LCD driver. One of the first application for LCD panels was televisions and computer monitors, which explains why there are chips that take VGA, NTSC, PAL or SECAM video signal as an input that then gets converted to the appropriate RGB values. For instance, one could have a look at RTD2010 from Realtek.
With the advent of embedded computing, there has been a need for chips that allow driving LCD panels not from analog signals but rather directly from digital signals, while limiting the required pins for communicating between the panel and the controlling chip. This is the role of the SSD1963 from Solomon-Systech for instance.
But this leaves the burden of drawing elements to the main chip. There exists quite a plethora of libraries to perform this, the most common one being OpenGL. But if like me you are looking at a more limited platform like the ESP32, FabGL is a good starting point.
However, these libraries require quite a bit of computation power and available RAM, and also use up quite a large chunk of code memory. This usually does not leave much space left for end application logic.
This is where more advanced chips bring their value because they do not receive RGB pixel data, but rather “orders” that instruct them to draw predefined elements on the screen: dots, lines, shapes, images and even videos.
This moves all the required power off the main chip which is then free to perform all the required application centric tasks.
Such advanced chips need good documentation because their usage can be quite complex, as can be seen from the 207 pages long programming guide.
Fortunately, Bridgetek is providing a plethora of examples: https://brtchip.com/SoftwareExamples-eve/#Sample_App
The main sample shows pretty much all that can be done, in a series of “test sets” that run in a loop:
One very interesting point is that they compile with a regular Visual Studio 2019 installation, no need for a custom IDE that would only work with this manufacturer.
On top of that, it is even possible to run the demos in an emulator, allowing for easier debugging and code inspection.
As mentioned in my Initial findings, you may face some issues when running them, and while Bridgetek support is keen on getting such feedback, I believe it would be much easier for developers if the sources for those sample applications was hosted in a public repository, such as GitHub or Gitlab. This would allow for public merge requests, gradually improving the quality of those demos and benefiting all users.
Another issue I have with the demos, in particular the more advanced ones, is that there is little to no details explaining the techniques used to achieve the desired results. Sure, the code gives the set of display commands that are sent to the BT817 chip, but it’s not always obvious which given line of code triggers a given effect. For instance, I tried to create an outline circle using the same code as shown in the sample application.
I could not achieve it by myself so I went to the Bridgetek community website and asked a question: http://www.brtcommunity.com/index.php?topic=329.0
I received an answer in a reasonable amount of time, that matches my use case, but even then there was no explanation as to what exactly are the various elements doing in the rendering pipeline.
After having fiddled with the demos, I moved to my initial goal and this is where I worked with the most useful tool in my opinion, the EVE Screen Editor, available here: https://brtchip.com/eve-toolchains/
It allows testing display lists out of the final board, saving lots of time because there is no need to wait for the board to be programmed and reset for the display to be rendered. Using it allowed me to confirm that the display list was correct and that any weird rendering was coming from other code that was run before on the ESP32 itself.
The EVE Asset Builder may not appear as useful at first glance, but when you are starting to work with pictures, videos or fonts, it is greatly helping convert those to formats accepted by the BT817 chip. In particular, it offers a streamlined experience when converting pictures to the somewhat exotic ASTC format that is used for images stored in the associated flash chip.
Finally, there is EVE Screen Designer which is a full-blown WYSIWYG environment to develop rich GUIs without requiring any advanced programming knowledge. This allows creating quite complex interfaces, with minimal effort, the video examples are quite impressive. The only downside that I see here is that it only supports very specific hardware, most of them based on Bridgetek own modules. The only exception is the Raspberry Pi Pico plugged to the ME817EV board, but even then, it requires a lot of third-party tool chains to be present.
It would be very nice if this tool was able to target other embedded frameworks like ESP32 or STM modules.
As I did not intend to use the EVE Screen Designer to do my own programming using the ME817EV board, I had to dive into the available documentation.
The first one is obviously the one for the evaluation board itself which gives great details about the various available connectors, in particular the flat ribbon ones. But it misses crucial details about the audio connector which is using a not so obvious part.
It also contains all the schematics for the various parts of the board: power stage, LVDS converter, audio, host connectivity. It would be nice to have those available as a set of files usable in a design package like Altium Designer for instance. As already mentioned earlier, this is on these schematics that one can figure out the part reference for the audio connector: JST ZH 4-pin
A whole section is giving configuration details, one should read them carefully, in particular when it comes to setting up the LCD bias voltages.
What is missing, though, is a reminder that all connectors are laying bare on the board, which means that the flat ribbons may end up touching them. This could lead to a short circuit, graciously handled by the power stage, but a warning would have been nice to have. This is the reason why I placed a business card between the touch ribbon and the board as you can see here:
The next document is the datasheet for the BT817 chip itself.
Inside it, you will find everything that is expected from a chip datasheet, from pin characteristics, to voltage specifications, from landing pattern to solder reflow profile.
There is also a presentation of the graphics, audio and touch engines, which gives some interesting information that could be of use when programming a display list.
But to, the most important document is the BT81X Series Programming Guide (BRT_AN_033) which gives all the information you need about the various commands that can be sent to the BT817. With more than 200 pages, it’s easy to get overwhelmed by it, but after a few days working with it, I feel right at home when looking for some details about a given command.
I would recommend carefully reading chapter 2, which is giving an in-depth presentation of the programming model, in particular the address space usage and the fact that writing directly to the display list memory should be avoided to let the coprocessor do all the heavy lifting, in particular computing the various offsets into this address range.
If you remember the background section of this review, you will know that the TFT display receives the data it needs to draw in the form of RGB triplets for each point in the screen. This is what the BT817 chip is doing, but contrary to many other systems in this domain, it does not precompute this data into its own frame buffer. Rather, at each refresh cycle, it interprets the commands it has received to compute the RGB values for each pixel in turn.
This means the internal clock must be fast enough to process every display list order before the TFT display considers the next line or this would introduce tearing effects.
But this also implies that the BT817 chip can drive large size displays with less memory (8K) than what would be required for an entire frame buffer (3M at 1280x800), thus saving on RAM costs inside the chip.
I then naively concluded that one could directly write into the RAM_DL area to directly modify elements that are used to compute each pixels, thus saving on I2C traffic when moving objects around. After experimenting with this idea to create a star field and seeing no movement at all, I asked a question at the community forum: http://www.brtcommunity.com/index.php?topic=340.0
As it turns out, the display list RAM accessible to the host controller is not the one used for the display, the former gets copied over to the latter when using the special CMD_SWAP command.
But the technical team gave me a good set of advices on how to achieve the same thing using some more advanced commands.
This illustrates my main grief against this programming guide, it’s that some of it is confusing and most advanced commands would need more details about their usage. And this goes hand in hand with the lack of explanations in the demos, as already mentioned above.
For instance, there are new commands introduced by the BT817 like CMD_RETURN where the text says this:
Normally it is not needed by the user, because CMD_ENDLIST appends CMD_RETURN to the command list. However it may be used in situations where the user is constructing command lists offline.
This is quite confusing to me. I mean, if the command is useless, why even mention it? But if it is useful, why not give better details as to what “offline” means here?
Also, when working with fonts or audio commands, the programming guide does not contain the required tables that list accepted parameter values. Sure, they are in the datasheet, but having them right next to their associated command would be easier.
I’m not the only one to have noticed those, there are multiple other issues with the programming guide that have been reported at the public forum: http://www.brtcommunity.com/index.php?topic=321
I understand that this may sound quite negative, but I mention it there in the hopes that it gets improved with time. That being said, I know how hard it is to write proper documentation, and to keep it up to date, so to me it’s great that all this is available, especially when considering that other displays systems do not even offer such a documentation.
After having used the evaluation board for more than a month, I must say that I’m impressed by the ease of use that it provides. Having an onboard USB serial converter makes initial discovery a breeze, especially considering the plethora of demos. Sure, they could benefit from more detailed explanations, but they do provide the “wow” factor that is expected from them.
The price of the evaluation board itself, around 130€, may seem a bit steep, especially from a hobbyist/maker point of view. But this is a large board with a limited production and quite a lot of functionality on it: LVDS, USB power, USB Serial, Audio, Backlight LED voltage bias along with a plethora of connectors.
The chip itself is more reasonably priced at around 5€ and needs roughly 5€ of additional components if you are targeting an RGB TFT display. This is quite impressive when considering that it handles the display, the sound and touch interactions inside the same device. Note that it is near impossible to find a module that only contains the BT817 with connectors for interfacing a TFT display. Rather, the chip is embedded in a larger solution like what Riverdi offers with its screens that already embed it. This means the chip price is blended in the screen cost and you barely notice it.
As I’m also a developer at work, I am used to learn new languages, new frameworks. The BT817 libraries integrate quite well in existing environments like Visual Studio or VSCode with Platform IO. It is a very good point not to force the development team to install yet another custom-made IDE. However, the knowledge gained from using the libraries themselves to get elements displayed on the screen is very specific to the platform which may prove of little value if you don’t work on such projects on a daily basis.
In my main project with this board, I was working with dynamically generated content, based on web hosted resources. In particular, the images come from a remote server, in pretty much any format it deems fit to be displayed in a webpage. The BT817 has some limits in this aspect and while it’s fine with static assets embedded along the screen, it could be a stopping point for my kind of usage.
As a hobbyist, I’m more used to the ready-made modules, of which the RapsberryPi is the prime citizen. Using DPI (Display Parallel Interface: https://pinout.xyz/pinout/dpi) mode, it can even connect to an RGB TFT directly, at the cost of all available GPIO pins.
A RaspberryPi Zero is about three times as expensive as the BT817, and to get touch capability, I would need to use an adapter that plugs on the USB port, for about 10€. This brings the total to roughly 35€ which is way higher, but is much easier to come by for a “one shot” especially when what is to be displayed ends up being just a webpage.
However, if your project is autonomous, with a finite set of graphic items that can fit on a flash chip, the BT817 is an option to seriously consider as it is often embedded on industrial grade displays. Those would easily survive harsh environments and their less than considerate users.
I hope you have enjoyed reading this review as much as I enjoyed working with the ME817EV board, do not hesitate to ask questions in the comments section if you need more details.
