I am thrilled to have been selected to  roadtest the BT817 chip and while it has only been 4 days since I received it, I wanted to share some information early on as it may help other people working with the evaluation board.

Once I have worked for a longer time with it I will of course submit a thorough review.


In the package we received was the ME817EV evaluation board and a 7 inches display from Riverdi, labeled RiTFT-70-CAP-UX on the packing list.



Plugging the ribbon connectors is quite straightforward, there is only one 50 pin connector for the large one, and the datasheet for the board mentions using CN2 for Riverdi compatible touch layers.


Bridgetek provides extensive demo applications for their EVE family on their website: https://brtchip.com/SoftwareExamples-eve/

It is very nice to find Visual Studio projects inside them, this means I did not have to install a whole new IDE but rather be able to use one that I’m quite comfortable with.

More surprising to me was the presence of projects targeting an emulator. This allowed me to start fiddling with the API even before receiving the board. The sample app showcases many aspects of the chipset and toolchain, as can be seen in this video:



Having now received the board, I decided to try to run the same sample app via the FT4222 USB to QSPI converter available on the board.

Reading both section 5.4 and 5.5 of the datasheet that describe the connection process, I came up with the below set of steps as I want to power using a USB power adapter and connect to my computer via a secondary USB cable:


  • On SW2, set all 8 positions to ON. On SW1 set all positions to OFF
  • Open JP1
  • Plug a USB Type-C cable into USBC1 with the other end into a power adapter delivering at least 1.5A
  • Trim variable resistors VR1-VR4 to get required LCD biasing voltages as: AVDD=9.6V, VGL=-6V, VGH=18V, VCOM=3.8V.
  • Un-plug the USB Type-C cable to remove the power
  • Connect the LCD display 50-pin FPC cable to CN1
  • Connect the LCD touch 10-pin FPC cable to CN2
  • Plug the USB Type-C cable in CN11-USBC2 connector, with the other end plugged to PC USB port
  • Plug the USB Type-C cable in CN6-USBC1 connector to turn on the power


After doing so, you should see your computer react to a newly discovered device.


You can now open the SampleApp_MSVC solution file, that is configured out of the box to talk to the ME817EV board via FT422 as shown in the screen capture inside the datasheet.

Running it directly may fail with the following exception:


FT4222 B not found


But if you go in the OS hardware manager you actually see both FT4222 A and FT4222 B devices.

As it turns out, this comes from the fact that the FT4222 abstraction layer code is looking for both devices but wrongfully assumes that the B device comes after A one inside the list of devices given by Windows itself.
In my case, this is not the case, leading to the above failure.

To fix this, I had to modify the EVE_HalImpl_open method from the EVEHAlImpl_FT4222.c file:


First, make sure deviceIdxB is initialized to s_NumDevsD2XX at line 331

Then, change the loop looking for the B device (line 360) to use a local variable and make it go through all devices, not just those above deviceIdxA, like this:


             for (DWORD candidateDeviceIdx = 0; candidateDeviceIdx < s_NumDevsD2XX; ++candidateDeviceIdx)


                    if (candidateDeviceIdx != deviceIdxA)


                           memset(&devInfoB, 0, sizeof(devInfoB));

                           status = FT_GetDeviceInfoDetail(candidateDeviceIdx,

                               &devInfoB.Flags, &devInfoB.Type, &devInfoB.ID, &devInfoB.LocId,

                               devInfoB.SerialNumber, devInfoB.Description, &devInfoB.ftHandle);

                           if (status != FT_OK)


                           if (!strcmp(devInfoB.Description, "FT4222 B"))


                                  deviceIdxB = candidateDeviceIdx;






With the above fix applied, you can now run with the provided display but you will get this kind of weird rendering, completely different from what we see in the emulator:



Initially, I thought I did not give the proper bias voltage, or that I made a bogus connection on the flex connector. But then I remembered about the third define in the MSVC project properties: EVE_DISPLAY_WVGA

Doing a global search on the project files lead to EVE_Config.h at line 126 which shows us that this define is for a 800x480 display. This value matches the resolution indicated on the webpage for the RiTFT-70-CAP-UX display: https://riverdi.com/product/ritft70capux/


But looking on the back of the panel itself is a technical reference: RVT70ASTFWC00

Riverdi’s website did not give a direct answer for this reference number but the search results gave a first page with only 7 inches displays, all offering a 1024x600 resolution.


Going back to the project options in MSVC, I changed the last define to now be EVE_DISPLAY_WSVGA (notice the additional S) and sure enough, we now have a valid display:



Note that the display may seem a bit blury/glary, that’s because I have not yet removed the protective sheet that it comes with.


What you may notice quite quickly is that the demo behaves a bit differently from what it does in the emulator.

I investigated the first difference (the bouncing ball) and it comes from the demo app itself that appears to have only be tested with a 800x480 display. Adjusting the code to take into account a larger display allowed to fix the issue.

I did not investigate further the other glitches, but I believe they have a similar origin.


Now that I have a working demo, I can now move on to the idea that I submitted in my roadtest application: connect to an ESP32 that retrieves a sitemap from openHAB and displays the appropriate widgets to control various devices.

Progress on that project can be followed via my GitHub repository for this project: EVEopenHAB