Looking to enhance your product with a stunning graphical user interface (GUI) without overhauling your entire design? Discover Bridgetek's Embedded Video Engine (EVE) – a game-changing solution that brings high-resolution graphics, touch, and audio to any microcontroller.

In this video: https://youtu.be/Fh01VzJFz30

We explore how EVE simplifies GUI development, allowing you to choose the most cost-effective MCU for your application while still delivering a professional and intuitive user experience. Learn about EVE's evolution, its latest features (including support for large LVDS displays and live video input), and how its object-oriented graphics engine streamlines your design process.

Whether you're working on automotive displays, medical devices, or smart appliances, EVE offers a flexible and powerful way to integrate advanced GUIs. We'll also highlight our comprehensive design tools and code examples to help you get started quickly.

What you'll learn:

• How EVE enables advanced graphics, touch, and audio with any MCU.
• Key features of the EVE family, including the latest BT820B.
• The benefits of using EVE over traditional MCU-based graphics.
• An overview of Bridgetek's design tools and resources.

Ready to create amazing user interfaces?
Watch now to see how Bridgetek's EVE can transform your product!

Connect with us:

• Website: https://brtchip.com/
• Getting Started with EVE: https://brtchip.com/getting-started/
• BRT Community Forum: http://www.brtcommunity.com/
• Bridgetek GitHub (Code Examples): https://bridgetek.github.io/

Choose Wisely. Choose Simply.
Our Credit Card Size Module #VM820C and Mini Module #MN820 offer distinct pathways to visual innovation.
Which one is right for you?

Link to our full FAQ page for more details: https://brtchip.com/faqs/

Share with us your thoughts in this thread about what you would like to learn next about the Mini-Module MN820.

Hi Jori,

Good to hear you have used previous EVE series IC`s. To aid with quick BT820 design we have brought out MN820 Mini Module.

The module includes the BT820 BGA and on-board 1Gbit DDR3L memory.

Developers can also seamlessly integrate the BT820B into their products by using the MN820 and connecting it via a 100-pin board-to-board connector to their application PCB. This approach reduces development time and eliminates the complexity of designing the high-speed DDR3 subsystem, allowing for a low-cost PCB implementation.

best regards

Community Admin

I don't have a specific project in mind. Just for testing. For now, I'm using FT800, BT815 and BT817 in my projects. I'm asking because BT820 is a BGA package and needs additional external RAM, which complicates the creation of the board itself, it will most likely have to be at least a 4-layer board. According to the specifications that came out some time ago, BT822 will have a built-in 1Gbit RAM, which will significantly simplify the creation of the board. Most likely, the package will not be BGA either, since it will not need the additional pins for communication with external RAM.

Hi Jori,

We currently don't have a schedule for the BT822 as we have just released the BT820

Do you a specific Project/Application in mind?

best regards

Community Admin

When can we expect the sale of BT822 to begin?

The prototypes are not what I am looking for, I am looking for what the functions are supposed to do,
hence the extract with the "prototype" and the "layout".

But the important part of my post is, at least BRT_AN_086_BT82X-Series-Programming-Guide_1.0.pdf and BRT_AN_033_BT81X_Series_Programming_Guide_2.6.pdf are not consistent enough to have ChatGPT successfully write a python script to extract function requirements.
I even reached the point now that ChatGPT can no longer fix the script further, the script changes, but the result stays the same.

The data really is not an issue, I get about 95% extracted fine and can fix the rest manually.

Hello,

Thank you for your post.

I will enquire with the software team to see if they have a document which covers the C prototypes for each support EVE command.

Best Regards,
BRT Community

I am trying to extract requirements for the commands from the programming guides, I am thinking about doing unit tests for my library and I need requirements for these that are not derived from my code.
The least I could do with such a list of requirements would be to check it against my header file.

After a number of iterations with ChatGPT the resulting .json starts to look ok:


   {
    "prototype": "void cmd_swap( );",
    "layout": [
      "+0 CMD_SWAP(0xFFFF FF01)"
    ]
  },
  {
    "prototype": "void cmd_append( uint32_t ptr, uint32_t num );",
    "layout": [
      "+0 CMD_APPEND(0xFFFF FF1E)",
      "+4 ptr",
      "+8 num"
    ]
  },


I ran into several issues though and I could not fix them all, yet.

First of all, the layout of the document, there a couple of "C prototype" that cross page boundaries so I end up with this:


  {
    "prototype": "void cmd_mediafifo ( uint32_t ptr, 119 Product Page Version 2.6 Document Reference No.: BRT_000225 Clearance No.: BRT#129 uint32_t size );",
    "layout": [
      "+0 CMD_MEDIAFIFO (0xFFFF FF39)",
      "+4 ptr"
    ]
  },



Then consistency.
Commands that need to be followed by data like cmd_inflate should have a pointer for that data as parameter and also a parameter for the amount of bytes.
But the real issue is how the "Command layout" looks like.

CMD_INFLATE: +8 ...n byte0 ... byten
CMD_INFLATE2: +9....+n byte1...byten (which is plain wrong since options is 32 bit wide and data starts at byte 0)
CMD_LOADIMAGE: +12 byte 0 / +13 byte 1 / ... ... / +n byte n - creative, but why so different?
CMD_PLAYVIDEO: +8~ +n byte1 ... byten - even more creative and also wrong with byte1
CMD_FLASHSPITX: byte1...byten the data to transmit - does not state the offset
CMD_FLASHWRITE: +12...n bytes1 ...byten
CMD_MEMWRITE: +12 ...n byte0 ... byten


BT82x:
CMD_INFLATE: +12....+n byte1...byten - also not correct as data does not start at byte 1.
CMD_LOADASSET: +12 byte1 ... byten
CMD_LOADWAV: +12~ +n byte1 ... byten

And for text we have these:
CMD_BUTTON: +16 s / +17 ... / ... ... / +n 0
CMD_KEYS: +16 s / ... ... / +n 0
CMD_TOGGLE: +16 s
CMD_TEXT: +12 s / .. .. / .. 0 (null character to terminate string)
CMD_TEXTDIM BT82x: +12 s / .. .. / .. 0


That is nothing that can't be fixed with a little manual editing and/or perhaps a couple more exceptions for the parser,
but a good specification should be correct and consistent across the board.

And I just noticed for example that for BT82x CMD_COPYLIST, CMD_SAVECONTEXT and CMD_RESTRORECONTEXT are skipped, the function prototypes for these do not have the ";" at the end.

My take on this was that the .raw file is just stripped of the header: https://github.com/ARM-software/astc-encoder/blob/main/Docs/FileFormat.md

But, I just found out that while this is true for EAB v3.0.0, this is not the case for EAB v2.13.0.
No idea what is going on there, but the .astc and .raw of EAB v2.13.0 are not the same when you strip the header.

The images from 2.x worked fine, but this is strange.
Both are using the same ASTC encoder which is v4.5.0 from June 2023 (why this old?)

Anyways, skipping the header when saving the file should be fine.

However, given previous experiences with ASTC encoding, especially font conversion, I wonder if running the ASTC encoder on anything that still can be called a micro-controller is even possible, even more so at 1280x800.
My desktop CPU merely blinks with the current EAB when converting stuff, but it has AVX-512 SIMD instructions and plenty of memory.

Quote
Regarding Q2, yes I presume resolution 1100x700 by itself is not a problem. The problem is my image. Find attached original and converted image, encoded with ASTC 4x4 and 6x6.

The issue really is with the memory layout of the format, the compression works in blocks of pixels.
1100 / 4 = 275
1100 / 6 = 183,333 -> needs 1104