The project started in 2020, during Corona time. After some talks with a local company the idea was growing to use a display for making data from vehicles visible on the dashboard. To make it more universal, I was investigating how it could made more generic and ordered some Asian display modules from Nextion, Topway and Eastrising.
The module contained a graphical chip which was commonly used in a lot of demo projects and of wich some demo code was already available. This was a perfect start to do some experiments with a ST Nucleo kit.
It resulted in the development of two proof of concepts where I used two 3, 4 inch TFT panels, one with resistive and one with capacitive touch interface. The Nucleo boards were mounted together with the Eastrising boards in two housings that were milled to contain openings for the displays. There was a piëzo buzzer and a small gap to ensure that the sound could leave the case.
I programmed a demo with 3 pages. The first page was an automotive application to drive signalization patterns in vans and trucks. The second demo was an industrial interface to show a progress bar, some data and alarms and the third one was a home automation system to put on/off lamps, TV and mains, change heating level and drive window shutters. I used Mbed which was a populair OS at that time. It worked together with a Python script that sends serial data to a command interpreter to provide the neccesary feedback and interaction as it was a real hardware application interface.
I presented this solution as an eye-catcher two times on Abbis Kortrijk, Belgium (2020 and 2022) and gathered some feedback. I heard that most applications need bigger screens and that flexibility is an important advantage. In 2023/2024 I had a meeting with some additional companies and they showed some interest in such product.
Potential applications during the different talks were:
- Home automation to visualize the level of water tank, shutters, etc.
- Presentation of syndic counters in appartments
- Interface of a fogger device for desinfecting the air
- Payment panel for an outdoor waste dump solution
- Touch panel for a cup collecting machine
I started creating a BOM list and I drawed a schematic to develop a novel prototype. There was a firmware update needed in order to use a recent microcontroller with more memory, a different touch panel controller chip and a lot of hardware changes. I introduced the concept of a dual bord solution with a connector on the graphical board. It resulted in a PCB with a 3D printed case to show the concept of a multi purpose console solution.
Because Mbed was meanwhile and unexpected abandoned by ARM, I had to perform additional work to get my MCU adopted in the new Mbed CE edition as one of the few and new project maintainers. The graphical board was called HMC-20 (Human Machine Controller - 2020) and the Application board got the name UAB-23 (User Application Board - 2023). The UAB-23 was finished for about 90% as a schematic.
During the development, I invested in some appliances (like vapor phase reflow oven, paste dispenser, etc.) to produce a Minimum Viable Product (MVP) for the HMC-20. A new demo application was introduced: The fogger interface with RTC and some limited different menu's accessed by a PIN code.
The HMC-20 is a flexible multi purpose, low cost HMI-interface board that is suited to contain an add-on board to extend communication interfaces. The choice for a hardware splitup enables re-usability of the graphical board into multiple end-applications and reduces the cost in term of production quantities. Both boards communicate by means of a real time serial command interpreter, which makes it possible to quick-start creating demo's by implementing a Python script that communicates trough an FTDI-cable on the extension connector, before developing additional hardware.
The solution aims to reduce design complexity by abstracting the graphical part from the application part. The graphical layout can be determined by means of a json file and a range of images (bmp/jpg) that are initially loaded from the SD-flash card into an on-board flash chip. The graphical controller can then read-out the chip directly with DMA (Direct Memory Access) to speedup image loading trough SPI-bus. The memory chip is also used to save internal parameters like a pin code or a user setting.
Button actions are predefined as commands and are defined in the json-file. It means that the graphical board also works independently when the interfaces are not the limiting factor. The graphical board has standard 5 digital inputs, 5 digital outputs, a USB-C 2.0 connector and a touch matrix connector. There is also a RTC battery and a 24bit TFT RGB connector with touch controller interfaces for capacitive and resistive touch panels. Next to the graphical controller, there is a STM-32U575 processor that is programmed trough an SWD-connector thats connects to a ST-Link V2 programmer. An internal boot loader enables programming over USB without using the programmer.
On the board there is also an auditive piëzo buzzer and a graphical font-chip that contains character maps for more than 150 languages. The power supply creates a stable internal 5VDC rail for its internals and the add-on board. A PWM-driver enables backlight dimming in the full range. The I/O voltage range is configurable by jumpers.
A red case has been 3D-printed with PLA that fits both boards to show the housing posibilities. It delivers a console that could be wall-mounted for applications in buildings, automotive environments or green-houses.
Currently there is a functional graphical board that contains a demo application (part of fogger interface), together with a datasheet and a short presentation. There is also a 3D printed housing which makes it possible to show a demo of a console when presenting the product in companies.
Because ARM stopped officially the Mbed project(1), there is a need to shift towards a more popular OS environment like Zephyr because support for Mbed CE is currently too limited. The definition of a graphical layout is currently still hardcoded, but adopted as separate files in the source code. This makes it unpractical to let the customer define a layout by itself when source code is not available. The idea is to use json to import an object stucture from a file copied from the SD card into the flash with a serial command. The images (jpg/bmp) are also loaded once from SD card to flash chip and are refered in the layout description by means of a unique ID. All interactions between buttons, widgets and IO are defined by sequential commands and are executed by the internal command interpreter.
There are also limitations because of the current (cheap) graphical chip. It's a Taiwanese controller which is already about 10 to 15 years on the market with RGB interface. With the current application where the dual layer option is used, the resolution is limited to 800x480 pixels in 8bit RGB colors. There is also no possibility to use moving graphics unless you create animations with different fixed images. This chip is still available but it is non trivial to order the original versions in Europe. There is a German distributor that only delivers with MOQ of 900. It means that mounting that chip is better done where PCB's are produced in China. There are websites to order smaller quantities but orginality is never guaranteed.
There are currently more advanced graphical chips on the market like those of FTDI, Nuvoton, or using a STM32 with MIPI interface. (2) However, this is a more complex solution with drivers and needs additional investigation to check for the size of screens, etc. The advantage should be that you can use more popular frameworks like Qt, but I see this more as a successor of the current product because of the concept change. It is also possible to test with the successors of the current chip with minimal firmware adaptation.
(1) https://os.mbed.com/blog/entry/Important-Update-on-Mbed/(2) https://www.st.com/en/evaluation-tools/stm32h747i-disco.html
Another point is the bootloader. Currently you need an ST-LINK V2 programmer with a small cable to the SWD program interface. It should be desirable that the user can upload a new firmware bu using an USB cable in a secure and signed way. There is a project mcu-boot(3) that could be used for that. It is supporting Mbed and Zephyr as well.
Furthermore it is important to check for potential customers. Currently the project is considered to be OEM and targets integration in other devices in bigger amounts with support services. But with some adaptations it could become an end solution for a specific group of customers. For example for horticulture green-houses or a console in buildings. This is fully defined of what kind of customers are willing what kind of such product and it should be developed along with them to maximize the adoption degree. Such talks can be done along the way.
There is a schematic of the add-on board (UAB-23) with standard interfaces described above, but there is still some work to bring this to a prototype. The idea is that this part will become fully open source, so that the user can create his own application. It is also possible that the user develops his own PCB that fits on the HMC-20 with specific IO for his application.
Comments
Please log in or sign up to comment.