this is a blueprint of project with 3~6 month time & 2~3 developer resources.Then is there any better solution/ suggestion? WBR. this is my approach: There are a desktop app with virtual screen.User(technician without programming skill) put objects in screen,each object has its own property(place,size,action.),user define properties of each object and save project as state chart diagram(or any other equivalent Sysml-UML diagram),after design finished he/she renders diagrams:desktop app compile designs to a semi-html text,final output consist of descriptor file and resource folder,which deploy to the external memory connected and controlled by MCU.RTOS in running mode handle reading descriptor and controlling LCD. ) library must be as portable as possible to bind to the new hardware in a reasonable time. Imagine this situation: There are technicians without programming skills, Assume this like a simple mini-HMI which usually work on a specific hardware,but if it is required to changes in hardware platform(MCU,LCD,driver chips &. It's free software according to the license statement on the file.įinal hardware is based on the ARM cortex M4/M7 and it must be able to drive a 5' or 7' TFT LCD,hardware independent here means library must run on each standard LCD & cortex m4/m7 MCU and not specific to the special one (like Nextion). The uGUI code is about 7700 lines of C and is probably worth checking out. There is no need to save constant displays. Perhaps there is a menu bar that calls up a specific display into some region and then it calls up a different display. How much memory is available? This doesn't apply to every GUI because, sometimes, the actual display is static. How deep should the stack go? We want to keep those spaces rectangular.

And then there are the frame buffers where regions behind the area currently being displayed are stored so they can be rewritten. And so on up until you put a title on a window. Then you figure out how to flood/fill the shapes. Then you move up a level and draw shapes.

Then you progress to drawing a line by using the pixel drawing routine.

The problem with writing a GUI library is you start with the idea of drawing a pixel of some color at a location. I suspect, but haven't looked, that uGUI does it that way because it advertises hardware independence. It is then up to the programmer to keep the display elements in an area of the virtual space that actually maps to the physical display. It has been this way since the early Tektronix vector graphics terminals (circa '75) and probably a lot earlier than that. At the lowest driver level, the virtual window is clipped to the physical display space. One method for making a GUI library reasonably hardware independent is to draw into a virtual space of some arbitrary size.

C gui library free