C language implementation of the simple portable GUI Control Library

from the beginning of the first contact with a single-chip microcomputer (MCU), has always felt very fun. From the 8-bit 51 microcontroller to the 16-bit TI MSP series of single-chip microcomputer have tried to learn. It feels good, but it's been a long time ago that 32-bit ARM processors are far away. Fortunately, I do have a chance to touch a 32-bit processor right now. Of course the Cortext M4 core is used, one of the TI Stellaris series processors.
In these days of study, found that the high-end processor is indeed very powerful, whether it is memory, flash storage space, or the internal hardware resources are extremely rich. And I was at a loss for a moment. In addition, we also learned the operation of the next TFT color screen. To be sure, the previously exposed monitors are just digital tubes or 1602 LCD screens that can only display ASCII code (and also dynamically refresh). Since the contact with the color screen, it is necessary to play a happy.
In the lab, it's a big hassle to draw a "button" or a progress bar when you see teammates writing small programs every time they need a display. They did it eventually, but I always thought that wasn't particularly good. There are two reasons, first, that the code is not portable enough; second, the code structure is not clear enough. I am quite taboo in these two points. If you see MAIN.C with so much code just to draw a few "buttons", it looks pretty uncomfortable. So, I think in the process of using, why do I not like to write programs under Windows, such as "button", "Progress bar" what kind of package it? This allows us to easily recreate these objects later in the use.
As a result, we decided to create a simple GUI control library for these small color screens to use.
Let's talk about the general idea. Tall man seems to think that my practice is really clumsy, and not always particularly ideal. But anyway, this is the first time I have tried to use a C language library, I think I can learn a lot of things. Young people always make mistakes!

OK, let's take a look at the directory structure of my guilib library file:

In order to facilitate the later transplant, it is generally divided into 3 layers:

1, the interface related to the bottom part:

In this layer, mainly with the display driver to deal with. The folders associated with this layer are primarily "lcddriverlibs" and provide the underlying driver for direct operation of the display. You can see that there are several functions in the file "grahic.h":

1 voidLcdinitialize (void);2 voidLcdpixeldraw (int32_t x, int32_t y, uint32_t color);3 voidlcdpixeldrawmultiple (int32_t x, int32_t y, int32_t x0, int32_t count,4int32_t BPP,Constuint8_t *pui8data,Constuint8_t *Pui8palette);5 voidLcdlinedrawh (int32_t xstart, int32_t xstop, int32_t y, uint32_t color);6 voidLCDLINEDRAWV (int32_t x, int32_t Ystart, int32_t ystop, uint32_t color);7 voidLcdrectfill (int32_t xstart, int32_t Ystart, int32_t xstop, int32_t ystop,8 uint32_t color);9uint32_t lcdcolortranslate (uint32_t color);

View Code

These function interfaces need to be re-implemented when porting, and can be redefined in the file "GRAHIC.C". In general, you need to replace the driver in the folder "Lcddriverlibs", and then, based on the driver, rewrite several interfaces in "GRAHIC.C". The naming of these interface functions is actually modeled after the TI stellaris graphics library. They provide the basis for drawing points, drawing lines, filling, and other operations. In addition, these functions are not able to change their interfaces, such as parameters, function names, when they are re-implemented. Otherwise, the upper control will not draw properly. This is a rule that must be adhered to.

Yes, the last function is mainly used to convert 24 bits of true color to the color supported by the monitor. Since not all TFT color screens support 24-bit color, they must be converted appropriately.

2. Basic drawing layer:

In this layer, because of the current time is limited, just implemented a few simple basic drawing functions. such as commonly used to draw points, draw lines, draw rectangles, fill rectangles and so on. This layer is isolated from the hardware layer, and they actually invoke those functions defined in the previous layer. Therefore, it is necessary to ensure that the hardware-related layer of a number of function interfaces are working properly. In general, if you only need to draw some simple graphics in the program, you just need to use the function interface provided inside.

3, "Control" layer:

This layer is the topmost layer, providing some common controls: rectangular buttons, selection boxes, progress bars, sliders, labels and so on (the time is ample may continue to improve, because it is only necessary to do so, we do not do too complex program). For these control objects, there are corresponding struct type definitions, such as Trectangle, and so on.

To be able to manage these controls, I used a sequential table to store each pointer to a control object that was drawn to the screen. Of course, you can also use a linked list to implement, but do not want to be too troublesome, temporarily use the sequential table instead, although the occupied control slightly more points, but also can receive. Then, when I remove a control object from the screen, the pointer to the object is removed from that list. For security reasons, I have provided a separate sequential table for each control object to store. That is, each table stores only a single kind of control object.

There are two reasons to do this, first, to make the table definition static in the implementation file, so that when users use the library, they cannot access the table that I used to manage the control object, which means that the table is not modified. In addition, the user does not need to know how I manage the objects displayed on the screen. is transparent to them. Second, because each table manages only one control object, we don't have to judge the type of the control when we work with the table. For example, in the case of touch detection, we do not need to use the type identification flag to determine whether the button was pressed or the option box was pressed. Because we only detect one type of control at a time. In addition, we can easily invoke the correct refresh function when we refresh all the controls as a whole (of course, if it's in C + +, it doesn't have to be so troublesome).

Summing up, the general three-storey structure is the case, of course, there is nothing new layering, just to facilitate the description and implementation. In addition, the implementation also borrowed some of the methods on the Internet.

A simple calculator based on the control library, but the computational function is not implemented.

PostScript: this age, want to original something out too difficult, but can draw on other people's thought. Since I do not have the ability to create ideas, then you should learn to mature ideas, in the learning of other people's mature thinking progress, that is also very good. Yes, for each "control" of the specific code implementation, wait for time to add it. That's all I've written.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

C language implementation of the simple portable GUI Control Library