Dream Team:

•

Published November 28, 2025 © GPL3+

Building a Wordle Game on the Renesas HMI Board

We created Wordle game which tests how well the processor handles graphics and game logic at the same time while responding to touchscreen.

BeginnerFull instructions provided1 hour73

Building a Wordle Game on the Renesas HMI Board

Things used in this project

Hardware components

Renesas IoT Enabler

Flash Memory Card, SD Card

Memory Controller, Nonvolatile SRAM

Itead Nextion NX8048T070 - Generic 7.0" HMI TFT LCD Touch Display

Software apps and online services

RT-Thread IoT OS

Story

1. Executive Overview

We built a Wordle-style game on the Renesas HMI-Board to show that small embedded systems can now have smooth, touch-friendly screens like consumer devices. This project is a stress test for the RA6M3 microcontroller, the RT-Thread real-time operating system, and the LVGL graphics library, checking if they can handle fast game logic and a responsive GUI at the same time. In this report, we explain how we managed tight memory, created better randomness using the OS, and fixed tricky UI styling issues, so other engineers can reuse these ideas on similar HMI projects with limited hardware resources.2. The Hardware Foundation: Renesas HMI-Board

Before we started coding, we needed to understand the Renesas HMI-Board. This board mixes a small microcontroller with features usually found in more powerful processors, giving us fast graphics display and touch screen capabilities without needing a lot of power.

2.1 The Core: Renesas RA6M3 Microcontroller

At the center of our system is the Renesas RA6M3 chip, which uses an Arm Cortex-M4F core running at 120 MHz. In embedded systems, this is plenty of speed to handle real-time work like reading input and updating the screen. The “F” means it has a Floating Point Unit, which helps with heavy math for animations and scrolling so the main game logic can run smoothly.

2.2 Memory Architecture and Constraints

Memory is the biggest challenge in our project. The RA6M3 has 2MB of storage for code and data, and 640KB of working memory.

One full screen needs about 255KB of memory. If we used double buffering (two screens at once to avoid flicker), that's 510KB—leaving only 130KB for everything else like the operating system, game data, and touch input. So we had to be very careful about what we put on screen and how we built the UI to avoid running out of memory.

1. Memory Architecture and Constraints

The Visual Interface

The board has a 4.3-inch screen with 480x272 pixels, using 16-bit color to save memory. The RA6M3 has two special pieces built in for graphics:

Graphics LCD Controller (GLCDC): This automatically sends the picture from memory to the screen without using the main processor.

2D Accelerator: This handles drawing tasks like filling shapes or copying images, which frees up the main processor to focus on game logic and reading touch input instead of pushing pixels.

2.4Connectivity and Peripherals

The board has extra features built in for future projects. It includes an RW007 Wi-Fi module that can download data from the internet, audio support for sound, and Arduino expansion ports so you can add more features later. These features are designed for smart home devices like thermostats or voice-activated controls.

For our Wordle game, we used the touch screen (connected by I2C) to read finger taps and the debug port to load our code onto the board.

3. The Software Ecosystem: RT-Thread and LVGL

We used the RT-Thread real-time operating system as the base for our Wordle game. It is open-source, built for small embedded devices, and has many ready-made components, which makes it easier to organize our code into separate threads instead of one big loop.

3.1 Why RT-Thread?

In a system with no operating system, the whole program runs in one endless loop, so if it is busy drawing an animation it can miss a screen tap.

With RT-Thread, we split the work into separate threads: one for the UI, one for touch input, and one for background tasks.

RT-Thread quickly switches the CPU between these threads, so the input thread can interrupt lower-priority work and make sure touches are handled right away, which keeps the game feeling responsive.

3.2 The LVGL Graphics Library

We use LVGL (Light and Versatile Graphics Library) to draw everything on the screen. It is written in C, uses little memory, and still supports smooth edges, transparency, and scrolling, which makes it a good fit for small embedded devices. In this project we use LVGL 8, which adds a CSS-like styling system so we can customize the look of the Wordle game in detail, though this also made some things like button borders harder to fine-tune.

4. Project Architecture and Build Setup

We set up the project so it’s easy to change and grow in the future. RT-Thread uses the SCons build system (written in Python), which helps automatically manage project files and configuration, so we spend less time on build setup and more time on code.

4.1 Directory Structure

We organized our code into separate folders to keep it clean and easy to work with:

rt-thread/: The operating system kernel itself, which we don't change

rt-thread/: The operating system kernel itself, which we don't change

packages/: Outside libraries like LVGL, downloaded automatically

packages/: Outside libraries like LVGL, downloaded automatically

drivers/: Low-level code that controls hardware pins and connections

drivers/: Low-level code that controls hardware pins and connections

applications/: Our custom code including:

main.c: Starts the program and creates threads

main.c: Starts the program and creates threads

wordle_game.c: The game rules and logic

wordle_game.c: The game rules and logic

wordle_ui.c: The screen display built with LVGL

wordle_ui.c: The screen display built with LVGL

wordle_dict.h: The list of valid words

wordle_dict.h: The list of valid words
applications/: Our custom code including:main.c: Starts the program and creates threadswordle_game.c: The game rules and logicwordle_ui.c: The screen display built with LVGLwordle_dict.h: The list of valid words

This structure makes it easy to find code and add new features later.

4.2 Configuration via rtconfig.h

We control the build through a configuration file called rtconfig.h. The RT-Thread Studio IDE has a tool that makes it easy to turn settings on and off:

RT_USING_LIBC: Turned on so we can use standard C functions like rand(), strcpy(), and memset()

RT_USING_LIBC: Turned on so we can use standard C functions like rand(), strcpy(), and memset()

PKG_USING_LVGL: Turned on to compile the graphics library

PKG_USING_LVGL: Turned on to compile the graphics library

LV_COLOR_DEPTH: Set to 16-bit color to save memory

LV_COLOR_DEPTH: Set to 16-bit color to save memory

BSP_USING_LCD: Turned on to activate the screen driver

BSP_USING_LCD: Turned on to activate the screen driver

BSP_USING_TOUCH: Turned on to activate the touch input driver

BSP_USING_TOUCH: Turned on to activate the touch input driver

These settings tell the build system which parts to include and how to set them up for our board.

4.3 The Build Process

When we click "Build" in the IDE, here's what happens:

SCons looks for Python script files called SConscript that tell it which C files to compile

SCons looks for Python script files called SConscript that tell it which C files to compile

The GCC compiler (for Arm) translates our C code into machine code

The GCC compiler (for Arm) translates our C code into machine code

The linker combines our game code, the RT-Thread kernel, and the LVGL graphics library into one file that fits in the 2MB Flash memory

The linker combines our game code, the RT-Thread kernel, and the LVGL graphics library into one file that fits in the 2MB Flash memory

The final result is a binary file (.elf or.bin) ready to load onto the board.

5. Game Logic: Rules and State Management

We kept the game rules separate from the screen code. This means the game logic (wordle_game.c) doesn't know anything about graphics—it just handles the word checking, guesses, and win/loss conditions. Because of this separation, we could even run the game in a text-only terminal on a regular computer, which makes the code cleaner and easier to test.

5.1 Finite State Machine (FSM)

The game has five states that control what happens:

STATE_INIT: Starting up, loading the word list

STATE_INIT: Starting up, loading the word list

STATE_PLAYING: User is typing letters

STATE_PLAYING: User is typing letters

STATE_ANIMATING: Tiles are flipping after pressing Enter (no new input allowed)

STATE_ANIMATING: Tiles are flipping after pressing Enter (no new input allowed)

STATE_WIN: User guessed the word correctly

STATE_WIN: User guessed the word correctly

STATE_LOSS: User ran out of tries

STATE_LOSS: User ran out of tries

We use an enum (a list of named values) to track which state the game is in, plus a structure that stores the secret word, past guesses, and current position. This way, the game always knows what mode it's in and what actions are allowed.

2. Finite State Machine (FSM)

5.2 The Rules Engine

The most complex part of Wordle is the feedback logic—determining if a letter is Green, Yellow, or Grey. We implemented a robust algorithm to handle duplicate letters, a common source of bugs in naive implementations.

The Algorithm Strategy:

We process the guess in two distinct passes.

Pass 1 (Green / Exact Match):We iterate through the 5 letters of the guess. If guess[i] == secret[i], we mark the result as RESULT_CORRECT (Green). Critically, we also mark that specific position in the secret word as "consumed" using a temporary boolean array. This prevents a letter that has already been matched exactly from triggering a "Yellow" match elsewhere.

Pass 1 (Green / Exact Match):We iterate through the 5 letters of the guess. If guess[i] == secret[i], we mark the result as RESULT_CORRECT (Green). Critically, we also mark that specific position in the secret word as "consumed" using a temporary boolean array. This prevents a letter that has already been matched exactly from triggering a "Yellow" match elsewhere.

Pass 2 (Yellow / Partial Match):We iterate through the remaining letters (those not marked Green). For each letter guess[i], we search the secret word to see if that character exists at any other index j.The condition for a Yellow match is strict:

Pass 2 (Yellow / Partial Match):We iterate through the remaining letters (those not marked Green). For each letter guess[i], we search the secret word to see if that character exists at any other index j.The condition for a Yellow match is strict:

secret[j] must equal guess[i].

secret[j] must equal guess[i].

Position j in the secret word must NOT have been "consumed" by a Green match in Pass 1.

Position j in the secret word must NOT have been "consumed" by a Green match in Pass 1.

Position j must NOT have been "consumed" by a previous Yellow match in this pass.

Position j must NOT have been "consumed" by a previous Yellow match in this pass.

If all conditions are met, we mark guess[i] as RESULT_PRESENT (Yellow) and mark secret[j] as consumed.If the letter is not found or all instances are consumed, we mark it as RESULT_ABSENT (Grey).

This logic ensures that if the secret word is "ABBEY" and the user guesses "BABES":

The first 'B' (index 0) is Yellow (matches index 1 or 2 of secret).

The first 'B' (index 0) is Yellow (matches index 1 or 2 of secret).

The 'A' (index 1) is Yellow (matches index 0 of secret).

The 'A' (index 1) is Yellow (matches index 0 of secret).

The 'B' (index 2) is Green (matches index 2 of secret).

The 'B' (index 2) is Green (matches index 2 of secret).

The 'E' (index 3) is Green (matches index 3 of secret).

The 'E' (index 3) is Green (matches index 3 of secret).

The 'S' (index 4) is Grey.

The 'S' (index 4) is Grey.

6. The "True Random" Fix: Generating Entropy

One of the significant challenges in embedded game development is randomness. Computers are deterministic; they follow instructions. Without an external source of unpredictability (entropy), a function like rand() will produce the exact same sequence of numbers every time the device is powered on. This would mean the "Secret Word" would be the same every day—a disastrous user experience.

Most desktop systems use the current time (e.g., milliseconds since 1970) as a seed. However, the HMI-Board does not have a battery-backed Real Time Clock (RTC) initialized by default. Every time we turn it on, the system time starts at 0.

6.1 Leveraging rt_tick_get

We solved this by exploiting the unpredictability of human behavior. We utilize the RT-Thread kernel's system tick counter.

The function rt_tick_get() returns the number of system ticks (usually milliseconds) that have elapsed since the board was booted.5 This variable is maintained by the OS kernel and incremented by a hardware timer interrupt.

Our implementation introduces a "Start Screen." When the board powers up, it sits on this screen waiting for the user to press "Play."

The time it takes for a user to tap that button is variable. It might be 1543 milliseconds, or 5092 milliseconds. This variance is our entropy.

When the "Play" button is pressed, we execute:

3. Leveraging rt_tick_get

6.2 Why This is Robust

We analyzed the RT-Thread source code for clock.c to ensure this was safe. The function rt_tick_get uses rt_atomic_load to read the tick variable.

4. Why This is Robust

This atomic load is crucial. Since rt_tick is a 32-bit (or potentially 64-bit) variable updated by an interrupt, reading it directly without atomicity could result in a "torn read" if an interrupt occurred exactly while we were reading the variable. The atomic load guarantees we get a valid integer.

By using this human-derived seed, we ensure that rand() % DICTIONARY_SIZE produces a different index each session, making the game feel "truly random" to the player.

7. Graphics Implementation: LVGL Optimization

Implementing the UI on the HMI-Board required a deep understanding of LVGL's internal mechanics. The RA6M3's 2D accelerator helps, but we still must be efficient.

7.1 The Keyboard: Button Matrix

For the on-screen keyboard, we had two choices:

Create 28 individual "Button" widgets (lv_btn), each with its own "Label" widget (lv_label).

Create 28 individual "Button" widgets (lv_btn), each with its own "Label" widget (lv_label).

Use a single "Button Matrix" widget (lv_btnmatrix).

Use a single "Button Matrix" widget (lv_btnmatrix).

We chose the Button Matrix. In LVGL, a standard button widget consumes significant RAM (roughly 100-150 bytes plus the label overhead).7 Creating 30 of them would fragment the heap and waste memory.

The Button Matrix is a "virtual" widget. It takes a string array (the "Map") and draws the buttons on the fly.

5. The Keyboard: Button Matrix

This approach uses only a fraction of the memory, as the button coordinates are calculated dynamically during the render loop rather than stored permanently.

7.2 The Grid: Container Layout

For the 5x6 grid of letter tiles, we used a Flex layout (lv_obj_set_layout(cont, LV_LAYOUT_FLEX)). We created a container for each row, and added 5 label objects to each row.

To optimize rendering, we explicitly set the style of these tiles to be simple. We avoided using heavy effects like blurs or gradients, which are computationally expensive. The RA6M3's 2D accelerator is excellent at filling solid colors, so we stuck to a flat design language (Solid Green, Solid Yellow, Solid Grey) which aligns perfectly with the hardware's strengths.

8. The User Interface: Addressing the Border Artifact

During our development, we encountered a persistent visual glitch that serves as an excellent case study in LVGL styling.

8.1 The Problem

When we rendered the Button Matrix keyboard, we wanted a "flat" look—clean keys floating on the background. However, we noticed a persistent outline or border around each key, and sometimes a strange artifact where the background color would "bleed" or double-draw when a key was pressed.

This is a known complexity in LVGL v8's default theme.4 A Button Matrix is composed of two "Parts":

LV_PART_MAIN: The background rectangle of the entire keyboard area.

LV_PART_MAIN: The background rectangle of the entire keyboard area.

LV_PART_ITEMS: The individual virtual buttons (keys).

LV_PART_ITEMS: The individual virtual buttons (keys).

A common mistake—which we initially made—is to try to remove the border from the main object:

6. The Problem

This removes the box around the outside of the keyboard. It does not affect the keys inside. The keys have their own style defined by the default theme, which often includes a 1px border and a shadow to give a 3D effect.

8.2 The Solution: Targeted Styling

To fix this, we had to create a specific style that targets LV_PART_ITEMS. We also had to ensure this style applied to all states, especially the PRESSED state.

We implemented the fix as follows:

7. The Solution: Targeted Styling

By explicitly targeting LV_PART_ITEMS, we told the renderer: "When you draw the individual 'Q' or 'W' buttons, do not draw a border." This resulted in the clean, flat aesthetic we required.

9. Input Processing and Threading Model

The responsiveness of the game depends on how we handle the capacitive touch inputs.

9.1 The Driver Stack

Hardware Layer: The capacitive touch panel detects a change in capacitance at coordinates (X, Y). The controller chip (often a FocalTech or Goodix IC) triggers an interrupt line connected to the RA6M3.

Hardware Layer: The capacitive touch panel detects a change in capacitance at coordinates (X, Y). The controller chip (often a FocalTech or Goodix IC) triggers an interrupt line connected to the RA6M3.

Driver Layer (drivers/): The RT-Thread driver handles the interrupt. It reads the X/Y coordinates over the I2C bus.

Driver Layer (drivers/): The RT-Thread driver handles the interrupt. It reads the X/Y coordinates over the I2C bus.

Input Device Layer: LVGL has a concept of "Input Devices." We registered a pointer device (lv_indev_drv_t) that points to our touch driver's read function.

Input Device Layer: LVGL has a concept of "Input Devices." We registered a pointer device (lv_indev_drv_t) that points to our touch driver's read function.

9.2 The Threading Loop

In main.c, we created a dedicated thread for the GUI:

8. The Threading Loop

The lv_task_handler() function is where the magic happens. It calculates new animations, redraws dirty areas of the screen, and polls the input device.

The rt_thread_mdelay(5) call is vital. It puts the GUI thread to "sleep" for 5 milliseconds. This yields the CPU back to the RT-Thread scheduler. During this sleep time, the scheduler can run the Idle thread or other background system tasks. If we removed this delay, the GUI thread would consume 100% of the CPU cycles, potentially starving the touch interrupt handler or causing the processor to overheat unnecessarily.

10. Performance Analysis

We closely monitored the performance of our implementation.

Frame Rate: Thanks to the RA6M3's 2D accelerator, we achieved a steady frame rate (approx. 30-60 FPS) during tile flip animations. The accelerator handles the buffer clearing and solid color fills effectively.

Frame Rate: Thanks to the RA6M3's 2D accelerator, we achieved a steady frame rate (approx. 30-60 FPS) during tile flip animations. The accelerator handles the buffer clearing and solid color fills effectively.

Memory Usage: By using the Button Matrix and RGB565 color depth, we kept our RAM usage well within the 640KB limit. We did not need to resort to external SDRAM, which simplifies the hardware design.

Memory Usage: By using the Button Matrix and RGB565 color depth, we kept our RAM usage well within the 640KB limit. We did not need to resort to external SDRAM, which simplifies the hardware design.

Touch Latency: The combination of RT-Thread's preemptive scheduling and the high priority of the touch interrupt resulted in imperceptible latency. The game feels snappy and responsive.

Touch Latency: The combination of RT-Thread's preemptive scheduling and the high priority of the touch interrupt resulted in imperceptible latency. The game feels snappy and responsive.

11. Conclusion and Future Outlook

Our development of Wordle for the Renesas HMI-Board has successfully demonstrated the viability of this platform for sophisticated HMI applications. We have proven that:

Complexity is Manageable: By separating game logic from UI code, we created a robust and testable system.

Complexity is Manageable: By separating game logic from UI code, we created a robust and testable system.

Resource Constraints Foster Creativity: The memory limits of the RA6M3 forced us to use efficient widgets like the Button Matrix, resulting in a leaner, faster application.

Resource Constraints Foster Creativity: The memory limits of the RA6M3 forced us to use efficient widgets like the Button Matrix, resulting in a leaner, faster application.

The Ecosystem Works: The combination of RT-Thread's kernel utilities (like rt_tick_get) and LVGL's styling engine provides a comprehensive toolkit for solving real-world embedded problems.

The Ecosystem Works: The combination of RT-Thread's kernel utilities (like rt_tick_get) and LVGL's styling engine provides a comprehensive toolkit for solving real-world embedded problems.

Looking forward, this project lays the groundwork for more advanced features. With the board's Wi-Fi capabilities, we could easily add a "Daily Challenge" mode that downloads a word from a server. The audio capabilities could be used to add sound effects for winning or losing. The foundation we have built—a modular, multi-threaded, hardware-accelerated application—is ready to support these expansions.

We believe this report provides a complete blueprint for engineers looking to leverage the Renesas HMI-Board for their own interactive products.

12. Technical Appendix

Table 1: Hardware Specifications Summary

9. Hardware Specifications Summary

Table 2: Game Logic State Table

10. Game Logic State Table

Table 3: Logic Evaluation Truth Table (Example: Target "SPEED")

11. Logic Evaluation Truth Table (Example: Target "SPEED")

Works cited

1. HMI-Board OTA Upgrade Reference. Hardware Platform | by RT-Thread IoT OS | Medium, accessed November 28, 2025, https://rt-thread.medium.com/hmi-board-ota-upgrade-reference-f7d9bb9034a2

2. $25 Renesas "HMI Board" features RA6M3 microcontroller for RT-Thread & LVGL development - CNX Software, accessed November 28, 2025, https://www.cnx-software.com/2023/05/17/25-renesas-hmi-board-features-ra6m3-microcontroller-for-rt-thread-lvgl-development/

3. RT-Thread, Renesas Electronics RA6M3 HMI board - board certification review, accessed November 28, 2025, https://blog.lvgl.io/2023-06-14/ra6m3-hmi-board-review

4. btnmatrix buttons don't respond to border_color when in `LV_STATE_CHECKED` state · Issue #1687 · lvgl/lvgl - GitHub, accessed November 28, 2025, https://github.com/lvgl/lvgl/issues/1687

5. RT-Thread RTOS: Clock and Timer Management, accessed November 28, 2025, https://www.rt-thread.org/download/rttdoc_1_0_0/group___clock.html

6. Button matrix (lv_btnmatrix) — LVGL documentation, accessed November 28, 2025, https://docs.lvgl.io/8.3/widgets/core/btnmatrix.html

7. Button styling to fully remove border - How-to - LVGL Forum, accessed November 28, 2025, https://forum.lvgl.io/t/button-styling-to-fully-remove-border/1365Works cited

8. HMI-Board OTA Upgrade Reference. Hardware Platform | by RT-Thread IoT OS | Medium, accessed November 28, 2025, https://rt-thread.medium.com/hmi-board-ota-upgrade-reference-f7d9bb9034a2

9. $25 Renesas "HMI Board" features RA6M3 microcontroller for RT-Thread & LVGL development - CNX Software, accessed November 28, 2025, https://www.cnx-software.com/2023/05/17/25-renesas-hmi-board-features-ra6m3-microcontroller-for-rt-thread-lvgl-development/

10. RT-Thread, Renesas Electronics RA6M3 HMI board - board certification review, accessed November 28, 2025, https://blog.lvgl.io/2023-06-14/ra6m3-hmi-board-review

11. btnmatrix buttons don't respond to border_color when in `LV_STATE_CHECKED` state · Issue #1687 · lvgl/lvgl - GitHub, accessed November 28, 2025, https://github.com/lvgl/lvgl/issues/1687

12. RT-Thread RTOS: Clock and Timer Management, accessed November 28, 2025, https://www.rt-thread.org/download/rttdoc_1_0_0/group___clock.html

13. Button matrix (lv_btnmatrix) — LVGL documentation, accessed November 28, 2025, https://docs.lvgl.io/8.3/widgets/core/btnmatrix.html

Code

#ifndef GAME_H
#define GAME_H

#include <stdint.h>
#include <stdbool.h>

#define WORD_LENGTH 5
#define MAX_ATTEMPTS 6

typedef enum {
    CELL_EMPTY,
    CELL_FILLED,
    CELL_ABSENT,    // Gray
    CELL_PRESENT,   // Yellow
    CELL_CORRECT    // Green
} cell_status_t;

typedef enum {
    GAME_PLAYING,
    GAME_WON,
    GAME_LOST
} game_state_t;

typedef struct {
    char letter;
    cell_status_t status;
} game_cell_t;

typedef struct {
    game_cell_t grid[MAX_ATTEMPTS][WORD_LENGTH];
    char target_word[WORD_LENGTH + 1];
    int current_row;
    int current_col;
    game_state_t state;
} wordle_game_t;

void game_logic_init(void);
void game_logic_input_char(char c);
void game_logic_backspace(void);
void game_logic_enter(void);
void game_logic_reset(void);
wordle_game_t* game_get_context(void);

#endif /* GAME_H */

#include "game.h"
#include <string.h>
#include <stdlib.h>
#include <rtthread.h> 

static wordle_game_t game;
static bool has_seeded_random = false;

/* Dictionary of 50 words */
static const char* word_list[] = {
    "ROBOT", "BOARD", "RESET", "FLASH", "STACK",
    "CLOCK", "POWER", "DEBUG", "LOGIC", "INPUT",
    "PIXEL", "TOUCH", "DRIVER", "BUILD", "LAYER",
    "SMART", "WATCH", "APPLE", "SMILE", "BRAIN",
    "ALARM", "BEACH", "CANDY", "DREAM", "EAGLE",
    "FLAME", "GRAPE", "HEART", "IMAGE", "JUICE",
    "KNIFE", "LEMON", "MOUSE", "NIGHT", "OCEAN",
    "PIANO", "QUEEN", "RADIO", "SHEEP", "TIGER",
    "UNCLE", "VIDEO", "WATER", "XEROX", "YACHT",
    "ZEBRA", "ALPHA", "BREAD", "CHAIR", "DANCE"
};

#define WORD_COUNT (sizeof(word_list) / sizeof(word_list[0]))

void game_logic_init(void) {
    game_logic_reset();
}

void game_logic_reset(void) {
    memset(&game, 0, sizeof(wordle_game_t));
    game.state = GAME_PLAYING;
    
    // Pick temporary word until user provides random seed
    int idx = rand() % WORD_COUNT;
    strcpy(game.target_word, word_list[idx]);
    
    rt_kprintf("Target Word: %s\n", game.target_word);
}

wordle_game_t* game_get_context(void) {
    return &game;
}

void game_logic_input_char(char c) {
    // --- TRUE RANDOM FIX ---
    if (!has_seeded_random) {
        srand(rt_tick_get()); 
        has_seeded_random = true;
        
        int idx = rand() % WORD_COUNT;
        strcpy(game.target_word, word_list[idx]);
        rt_kprintf("True Random Word: %s\n", game.target_word);
    }
    // -----------------------

    if (game.state != GAME_PLAYING) return;
    if (game.current_col >= WORD_LENGTH) return; 

    game.grid[game.current_row][game.current_col].letter = c;
    game.grid[game.current_row][game.current_col].status = CELL_FILLED;
    game.current_col++;
}

void game_logic_backspace(void) {
    if (game.state != GAME_PLAYING) return;
    if (game.current_col <= 0) return;

    game.current_col--;
    game.grid[game.current_row][game.current_col].letter = '\0';
    game.grid[game.current_row][game.current_col].status = CELL_EMPTY;
}

void game_logic_enter(void) {
    if (game.state != GAME_PLAYING) return;
    if (game.current_col < WORD_LENGTH) return; 

    char target_copy[WORD_LENGTH + 1];
    strcpy(target_copy, game.target_word);
    
    // 1. Check Green
    for (int i = 0; i < WORD_LENGTH; i++) {
        char guess = game.grid[game.current_row][i].letter;
        if (guess == target_copy[i]) {
            game.grid[game.current_row][i].status = CELL_CORRECT;
            target_copy[i] = 0; 
        } else {
            game.grid[game.current_row][i].status = CELL_ABSENT; 
        }
    }

    // 2. Check Yellow
    for (int i = 0; i < WORD_LENGTH; i++) {
        if (game.grid[game.current_row][i].status == CELL_CORRECT) continue;

        char guess = game.grid[game.current_row][i].letter;
        for (int j = 0; j < WORD_LENGTH; j++) {
            if (target_copy[j] == guess) {
                game.grid[game.current_row][i].status = CELL_PRESENT;
                target_copy[j] = 0; 
                break;
            }
        }
    }

    // Check Win
    int correct_count = 0;
    for (int i = 0; i < WORD_LENGTH; i++) {
        if (game.grid[game.current_row][i].status == CELL_CORRECT) correct_count++;
    }

    if (correct_count == WORD_LENGTH) {
        game.state = GAME_WON;
    } else {
        game.current_row++;
        game.current_col = 0;
        if (game.current_row >= MAX_ATTEMPTS) {
            game.state = GAME_LOST;
        }
    }
}

#include "ui.h"
#include "game.h"
#include "lvgl.h"
#include <stdio.h>

static lv_obj_t * scr;
static lv_obj_t * grid_container;
static lv_obj_t * cell_objs[MAX_ATTEMPTS][WORD_LENGTH];
static lv_obj_t * kb_matrix;
static lv_obj_t * msg_label;

#define COLOR_CORRECT lv_color_hex(0x6aaa64) // Green
#define COLOR_PRESENT lv_color_hex(0xc9b458) // Yellow
#define COLOR_ABSENT  lv_color_hex(0x787c7e) // Gray
#define COLOR_EMPTY   lv_color_hex(0xffffff) // White
#define COLOR_BORDER  lv_color_hex(0xd3d6da) // Light Gray

static const char * kb_map[] = {
    "Q", "W", "E", "R", "T", "Y", "U", "I", "O", "P", "\n",
    "A", "S", "D", "F", "G", "H", "J", "K", "L", "\n",
    "Enter", "Z", "X", "C", "V", "B", "N", "M", "Bksp", ""
};

static void update_ui_grid(void) {
    wordle_game_t *g = game_get_context();
    
    for(int r=0; r<MAX_ATTEMPTS; r++) {
        for(int c=0; c<WORD_LENGTH; c++) {
            lv_obj_t * btn = cell_objs[r][c];
            lv_obj_t * label = lv_obj_get_child(btn, 0);
            
            /* --- FIX: RESET DEFAULTS --- */
            lv_obj_set_style_border_width(btn, 2, 0);
            lv_obj_set_style_border_color(btn, COLOR_BORDER, 0);
            lv_obj_set_style_bg_color(btn, COLOR_EMPTY, 0);
            lv_obj_set_style_text_color(label, lv_color_black(), 0);

            /* Text */
            if(g->grid[r][c].letter != 0) {
                lv_label_set_text_fmt(label, "%c", g->grid[r][c].letter);
            } else {
                lv_label_set_text(label, "");
            }

            /* Colors */
            lv_color_t bg_color = COLOR_EMPTY;
            if (g->grid[r][c].status == CELL_CORRECT) bg_color = COLOR_CORRECT;
            else if (g->grid[r][c].status == CELL_PRESENT) bg_color = COLOR_PRESENT;
            else if (g->grid[r][c].status == CELL_ABSENT) bg_color = COLOR_ABSENT;

            /* Final Style Apply */
            if (g->grid[r][c].status >= CELL_ABSENT) {
                lv_obj_set_style_bg_color(btn, bg_color, 0);
                lv_obj_set_style_border_width(btn, 0, 0); 
                lv_obj_set_style_text_color(label, lv_color_white(), 0);
            } 
            else if (g->grid[r][c].status == CELL_FILLED) {
                lv_obj_set_style_border_color(btn, lv_color_hex(0x878a8c), 0); 
            }
        }
    }
    
    if (g->state == GAME_WON) lv_label_set_text(msg_label, "SPLENDID! PRESS ENTER");
    else if (g->state == GAME_LOST) lv_label_set_text_fmt(msg_label, "LOST! WORD: %s", g->target_word);
    else lv_label_set_text(msg_label, "GUESS THE WORD");
}

static void kb_event_cb(lv_event_t * e) {
    lv_obj_t * obj = lv_event_get_target(e);
    uint32_t id = lv_btnmatrix_get_selected_btn(obj);
    const char * txt = lv_btnmatrix_get_btn_text(obj, id);
    wordle_game_t *g = game_get_context();

    if(txt == NULL) return;

    if (g->state != GAME_PLAYING) {
        if(strcmp(txt, "Enter") == 0) {
            game_logic_reset();
            update_ui_grid();
        }
        return;
    }

    if(strcmp(txt, "Enter") == 0) game_logic_enter();
    else if(strcmp(txt, "Bksp") == 0) game_logic_backspace();
    else game_logic_input_char(txt[0]);
    
    update_ui_grid();
}

void ui_init(void) {
    game_logic_init();
    scr = lv_scr_act();
    lv_obj_set_style_bg_color(scr, lv_color_white(), 0);

    /* Grid Container */
    grid_container = lv_obj_create(scr);
    lv_obj_set_size(grid_container, 230, 272);
    lv_obj_set_pos(grid_container, 0, 0);
    lv_obj_set_style_border_width(grid_container, 0, 0);
    lv_obj_set_style_bg_opa(grid_container, 0, 0);
    
    int cell_size = 38;
    int gap = 4;
    
    for(int r=0; r<MAX_ATTEMPTS; r++) {
        for(int c=0; c<WORD_LENGTH; c++) {
            lv_obj_t * btn = lv_btn_create(grid_container);
            lv_obj_set_size(btn, cell_size, cell_size);
            lv_obj_set_pos(btn, c * (cell_size + gap), r * (cell_size + gap) + 10);
            lv_obj_set_style_radius(btn, 0, 0);
            
            lv_obj_t * label = lv_label_create(btn);
            lv_obj_center(label);
            lv_obj_set_style_text_font(label, &lv_font_montserrat_14, 0);
            cell_objs[r][c] = btn;
        }
    }

    /* Message Label */
    msg_label = lv_label_create(scr);
    lv_obj_set_width(msg_label, 240);
    lv_obj_align(msg_label, LV_ALIGN_TOP_RIGHT, -10, 10);
    lv_obj_set_style_text_align(msg_label, LV_TEXT_ALIGN_CENTER, 0);
    lv_obj_set_style_text_font(msg_label, &lv_font_montserrat_14, 0);

    /* Keyboard */
    kb_matrix = lv_btnmatrix_create(scr);
    lv_obj_set_size(kb_matrix, 240, 200);
    lv_obj_align(kb_matrix, LV_ALIGN_BOTTOM_RIGHT, -5, -5);
    lv_btnmatrix_set_map(kb_matrix, kb_map);
    lv_btnmatrix_set_btn_width(kb_matrix, 21, 2); 
    lv_btnmatrix_set_btn_width(kb_matrix, 29, 2); 
    lv_obj_add_event_cb(kb_matrix, kb_event_cb, LV_EVENT_VALUE_CHANGED, NULL);
    
    update_ui_grid();
}

Credits

KEVIN CHRISTIAN VILLAREAL

1 project • 0 followers

SEAN MARIE RABAGO

1 project • 0 followers

Building a Wordle Game on the Renesas HMI Board

Things used in this project

Hardware components

Software apps and online services

Story

5.2 The Rules Engine

6. The "True Random" Fix: Generating Entropy

6.1 Leveraging rt_tick_get

6.2 Why This is Robust

7. Graphics Implementation: LVGL Optimization

7.1 The Keyboard: Button Matrix

7.2 The Grid: Container Layout

8. The User Interface: Addressing the Border Artifact

8.1 The Problem

8.2 The Solution: Targeted Styling

9. Input Processing and Threading Model

9.1 The Driver Stack

9.2 The Threading Loop

10. Performance Analysis

11. Conclusion and Future Outlook

12. Technical Appendix

Works cited

Schematics

System Block Diagram (High Level)

Visual Representation

Code

The Build Script (src/SConscript)

Game Header (src/game.h)

Game Logic (src/game.c)

UI Header (src/ui.h)

UI Implementation (src/ui.c)

Entry Point (src/lvgl_port.c)

Credits

KEVIN CHRISTIAN VILLAREAL

SEAN MARIE RABAGO

Comments

Embed the widget on your own site

Building a Wordle Game on the Renesas HMI Board

Building a Wordle Game on the Renesas HMI Board

Things used in this project

Hardware components

Software apps and online services

Story

5.2 The Rules Engine

6. The "True Random" Fix: Generating Entropy

6.1 Leveraging rt_tick_get

6.2 Why This is Robust

7. Graphics Implementation: LVGL Optimization

7.1 The Keyboard: Button Matrix

7.2 The Grid: Container Layout

8. The User Interface: Addressing the Border Artifact

8.1 The Problem

8.2 The Solution: Targeted Styling

9. Input Processing and Threading Model

9.1 The Driver Stack

9.2 The Threading Loop

10. Performance Analysis

11. Conclusion and Future Outlook

12. Technical Appendix

Works cited

Schematics

System Block Diagram (High Level)

Visual Representation

Code

The Build Script (src/SConscript)

Game Header (src/game.h)

Game Logic (src/game.c)

UI Header (src/ui.h)

UI Implementation (src/ui.c)

Entry Point (src/lvgl_port.c)

Credits

KEVIN CHRISTIAN VILLAREAL

SEAN MARIE RABAGO

Comments

Related channels and tags