The idea of remote screen capture is very simple, that is, direct access to the device's video memory data, reproduced by the PC screen. Since we have implemented the Custom channel, we can complete the data acquisition by adding a custom_command_screenshots command on the basis of the original program. But what's more troublesome is that for different LCD devices, the same display screen, video memory data may be different, for embedded devices, the common LCD display is 16-bit color (also has 1 or 8-bit color, but relatively rare), for simplicity, we only consider 16-color display screen screenshot.
16-bit color map based on the value of RGB components, there are generally the following modes: 1555,565,555, the first highest bit of transparency, we have it and 555 classified as a class, the second and third is more common.
For 565 and 555来 said, the middle must be g (green), its component value or 5-bit or 6-bit, there is no disagreement. The trouble is, low 5 bits (or high 5 bits) may be red, or it may be blue, if confused, the display of the screen will appear biased, so you must get the configuration information exactly.
After getting the data and configuration, we can completely draw the captured data one point at a time, but doing so not only causes the screen to slow down, but also causes us to lose an opportunity to delve into the C # Bitmap rendering technology.
Below we will delve into the bitmap display technology for the. Net framework, first declaring a bitmap (new Bitmap) that is the same size as the device display. Luckily, we found that pixelformat.format16bpprgb565 and pixelformat.format16bpprgb555 parameters could be set. But whether it is RGB or BGR mode can not be set, if regardless of this parameter, our final screenshot, you will find and display the picture on the device bias (thanks to the display device's default 16-color mode and windows are different, otherwise this problem may be masked). There are two solutions, one is to modify the device display driver (I developed CORTEX-M3 Development Board display driver, found that its display mode RGB/BGR can be configured), the second is to solve this problem by the host computer. To make the program more versatile, I chose the latter.
Check the relevant data, we found that in the Bitmapinfoheader (bitmap information header) has a bicompression, the meaning is as follows:
BI_RGB: No compression
Bi_rle8: A RLE compression encoding of 8 bits per pixel with a compressed format consisting of 2 bytes (repeating pixel count and color index);
BI_RLE4:4 bits per pixel RLE compression encoding, compressed format consists of 2 bytes
Bi_bitfields: bits per pixel are determined by the specified mask.
If the parameter of our bitmap is set to pixelformat.format16bpprgb555 mode, then the Bicompression value is Bi_rgb, then we will not be able to set the RGB/BGR, because after that the structure is the bitmap data.
If we set the parameter to pixelformat.format16bpprgb565, then the bicompression value is the Bitfields,bitmapinfoheader struct, which adds 12 bytes of data, respectively, 4 The R-value mask for bytes, a 4-byte G-value mask, and a 4-byte B-value mask, the default data is 0xf800, 0X07E0, 0x001f.
Well, our problem has been solved, by configuring the above data, we can solve our problem.
In addition, where does this configuration parameter come from? The device developer must be clearer than the top software developer, so this parameter configuration is provided by the code on our device.
After the program is implemented, the working screen is as follows: