Coffee machines are evolving beyond brewing - they’re about interaction.
Watch this video summary on how our Embedded Video Engines (EVE) can help design engineers with your design process in Graphical Touch Displays for Coffee Machines.

It’s time to upgrade your coffee machines! See video here: https://www.linkedin.com/feed/update/urn:li:activity:7194233698609725440

Learn more about EVE in relation to coffee machine graphical touch display interface designs here: https://bit.ly/EVE-Upgrade-Displays-for-Coffee-Machines

#Bridgetek #EVE #EmbeddedVideoEngines #CoffeeMachines #DisplayControllers

Coffee machines are no longer just about brewing; they’re about interaction.
 
The art of brewing a perfect cup of coffee is a precise science and art, hinging on factors such as the weight of the beans, the fineness of the grind, the pressure profile and temperature of the water during extraction, and the duration of the extraction process.
 
With EVE in advanced touch displays, you can now take control of these variables and monitor the entire coffee extraction process in real-time, ensuring every cup is brewed to perfection – with a touch of a screen.
 
That’s why most manufacturers are ditching old-school buttons, dials and gauges in favour of vibrant colour touch screens for a premium experience.
 
With EVE-enabled displays, you get:
🌟 Attractive User Interface: Familiar icons and animations make your coffee machine a joy to use.
☕ Coffee Pouring Animations: Watch your brew come to life!
🌎 Global Appeal: Multilingual support and currency symbols for a worldwide audience.
📏 Flexible Screen Sizes: From compact to large (up to 10.1"), EVE fits all designs.
🎨 Custom Widgets: Create dials, gauges, and more. 🔊 Audio Alerts: Easy acknowledgment of user input.
 
It’s time to give coffee machines an upgrade! ☕🔥
 
Learn more about EVE for Coffee Machine Graphical Touch Displays here: https://bit.ly/EVE-Upgrade-Displays-for-Coffee-Machines
 
#Bridgetek #EVE #EmbeddedVideoEngines #CoffeeMachines #DisplayControllers

Ok. fine, I guess I have to check what it actually looks like on the display. :-)
Unfortunately I have no idea so far what I need to display, I only have a very vague project description.
It is even possible that font 34 is not big enough.

The image has been magnified to 200% and captured from the ESE.
The upper text is ROM font 34.
The lower text is EAB converted font: Roboto, 94 points, ASTC 8x8 exhaustive.

It is difficult to find any different from these two converted character. The parts encircled in red indicate that the EAB conversion appears slightly better, although this might not be noticeable to the naked eye without zooming in.

*** Extended Font conversion is intended to be versatile and adaptable for various use cases. It may not necessarily align perfectly with the built-in font.

I am reading REG_UNDERRUN now and it just sits at zero.

And it should be as there is hardly anything to display, yet.
The external flash is also not in use.
Also tried my current playground app which puts significantly more stress on the pixel engine,
does not change though that the value for REG_UNDERRUN is printed out as zero.
Well, untill it crashes for good but there is a good chance that this is my software. :-)

I just tried using 78MHz pixel clock which is below the maximum for the panel.
And with REG_PCLK_2X set the distortion is the same.
But without setting REG_PCLK_2X it is rather unstable.

Using 66MHz without setting REG_PCLK_2X might be my only option, at least this is almost within spec.
And the drop to 54.7Hz is ok as well, I hope.

Hi Rudolph,

Are you seeing REG_UNDERRUN count up in the cases where you see the issue?

Best Regards, BRT Community

I played some more with ESE and these might be the font sizes:

#26 -> 15
#27 -> 17
#28 -> 21
#29 -> 24
#30 -> 31
#31 -> 42
#32 -> 55
#33 -> 70
#34 -> 94

The ROM fonts in all versions of EVE are the same, and the same data is used to render these fonts from EVE to EVE4,"

The BT817/8 datasheet states though:
"Fonts 31-34 are large ROM fonts encoded in ASTC 8x8 format."

And:
"Using ASTC for the large ROM fonts can save considerable space. Encoding the four largest fonts in
ASTC 8x8 formats gives no noticeable loss in quality and reduces the ROM size from 1 Mbytes to
about 640 Kbytes."

So at least these four should have been converted later for the BT817, like 2019?

Knowing the original settings for the font conversion probably is not enough?
At least I am not seeing a dithering option with "eab_tools.exe font -h" in EAB 2.11.0

Hello,

I'm just double checking what the exact font size conversions are for the inbuilt fonts with the development team.

But the difference between the fonts relates to when the conversion was done, as you have alluded too. The ROM fonts in all versions of EVE are the same, and the same data is used to render these fonts from EVE to EVE4, as such this conversion was performed during the initial EVE release with an older version of the font converter. Since this time there have been several updates to the font conversion utility and its aliasing settings which accounts for the changes you have noted between these versions of the font in ESE.

Best Regards,
BRT Community

I am using a RVT101HVBNWC00-B from Riverdi which is a BT817 with a 1280x800 panel.
And to rotate the screen does not work properly, just flipping it with either REG_ROTATE set to 1 or using CMD_SETROTATE(1) causes major distortion.

When I use CMD_SETROTATE(5) it curiously works fine though, I have no use for a mirrored image though.

0 - image is fine, just for reference
1 - image is distorted
2 - image is fine
3 - image is distorted
4 - image is distorted
5 - image is fine
6 - image is fine
7 - image is distorted

And right now it does not have to display much at all, it looks like this with more empty pixels:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/CFAF800480E0_050SC_Arduino_Uno.jpg

Pixelclock is 72MHz with REG_PCLK_2X set to 1.

Hmm, I dropped the pixel clock to 51MHz with REG_PCLK_2X set to 0 and now the flipped image is fine.
But this dropped the frames/s as well and the pixel-clock is now well below the minimum of 66.3MHz that is listed in the datasheet.

I set REG_PCLK_2X to 1 while still using 51Mhz -> image is distorted when flipped.
I set REG_PCLK_2X to 0 while using 72MHz -> image is fine.
I set REG_PCLK_2X to 0 while using 66MHz -> image is fine.

Any more advice on this why REG_PCLK_2X = 1 with REG_ROTATE = 1 leads to a distorted image?

At 72MHz pixel-clock with 72Mhz system clock the datasheet says that REG_PCLK_2X needs to be set to 1.
And 66MHz is out of spec for the panel, although barely, it is not possible though to set PLL2 to anything between 66MHz and 72MHz.

I reduced the pixel clock to 38MHz and it still works, here at my desk.
But there is no way to tell what will happen out in the field with -20°C....+60°C.

Hi,

No problem, we'll post an MCU to RAM_G example first and then provide a flash one too,

Best Regards, BRT Community