2014-08-12 01:30 PM
Hi:
I am using STM3221G-EVAL board, with the demosntration builder firmware.There are multiple icons on the initial screen, and I would like to replace one of those, with one of my own icons. I have tried emWin BmpCvt and LCD Image Converter to get the C code corresponding to the image, without success.My initial image is a bmp 360x369 pixels, that I have reduced to several sizes but nothing seems to work. The icon is showing at the screen but just streaks.What is the procedure I have to follow to do this?Thanks, #an3128 #emwin #icon #bmpcvt #lcd-image #rgb565 #rgb565 #image-converter2014-08-12 02:29 PM
ST is using a 16-bit BMP format, you'll probably need GIMP or PhotoShop
________________ Attachments : clive1_16bit.bmp : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I00D&d=%2Fa%2F0X0000000bRz%2FncZoSoEEoZ2KY4HysGLd66yJUs3CdlsZSdOWiO4Ax1g&asPdf=false2014-08-13 03:04 AM
I have an M24SR-Discovery board:
http://www.st.com/m24sr-discovery
I'm also trying change some of the images/icons. ''ST is using a 16-bit BMP format'' That much is documented in the image source comments:/**
******************************************************************************
* @file vcard_icon.h
* @author MMY Application Team
* @version V0.1.0
* @date 08/13/2013
* @brief data array of the bmp picture (RGB565).
:
:
*/
/* Image format {Width, Height, Bit Depth, Byte Count , Max Frame, ... */
const
char
uVcard[] = {
0x3B, 0x3B, 0x05, 0x02, 0x0,
0xFF, 0xFE, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF7, 0xFE, 0xF7, 0xFE, 0xFF, 0xFF, 0xFF, 0xDF, 0xFF, 0xFF,
:
:
The ''
RGB565
'' format of the 16-bit pixel data is described, eg, here: The ''Width, Height, Bit Depth, Byte Count, Max Frame
'' header seems to be proprietary - I don't know what ''Max Frame
'' means (it always seems to be zero), and having a single ''Bit Depth
'' value seems inconsistent with RGB565 ?! But I'll see how I get on...2014-08-13 09:00 AM
I found this ''
BMP to C image conversion utility'':
http://www.lpcware.com/content/nxpfile/bmp-c-image-conversion-utility
It creates an array of 16-bit values:/*
* BMP image data converted from 24bpp
* to RGB565
*/
#define COLOR_BPP 16
#define COLOR_STORAGE_SIZE 2
#define BMPWIDTH 239;
#define BMPHEIGHT 65;
const
unsigned
short
image16[] = {
0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xe69a,
0xab6d, 0x9a69, 0xb3ae, 0xeefb, 0xffff, 0xffff, 0xffff, 0xffff,
0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff,
0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff,...
I just used a quick regular-expression search & replace to split into bytes:
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xe6, 0x9a,
0xab, 0x6d, 0x9a, 0x69, 0xb3, 0xae, 0xee, 0xfb, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
The Width & Height values seem to need to b reduced by two each to work with the ST stuff.
But I end up with the image appearing ''wrapped'' in the display:
2014-08-13 10:59 AM
STSW-STM32098
STM32 embedded GUI library (AN3128)
http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF257934#Includes a Resource Editor - which can convert a BMP file to a 'C' array.But the result is upside down (actually, reflected in the horizontal axis).2014-08-13 11:10 AM
What I found is actually a software tool from STMicorelectronics that worked perfectly:
Resource Editor For Embedded GUI Library version 2.0.0.0you go to Tools menu, then Image 565 Converter. Load the image and click on convert and the tool will open a Word file with the actual C code that you need. There're a couple of options if you want your code with the header or not. Copy and paste into your code and your are done.This is part of the STM32 embedded graphic objects/touchscreen library AN3128.2014-08-13 12:21 PM
Yes, that's the one I used - but, as I said, the result is ''upside down'':
But then it's not actually stated that theM24SR-Discovery is using the same graphics format...
2014-08-14 11:16 AM
''the result is 'upside down'''
I can fix that by inverting the bitmap before converting it.Also had to modify the LCD_WriteBMP_FAT() function to get the bytes in the correct order for the right colour - blue, not green:2014-08-14 11:18 AM
''it's not actually stated that the
M24SR-Discovery is using the same graphics format''
Evidently, it is not!Would be helpful if they would document this!2014-08-14 12:24 PM
Video displays (since TV) generally raster left-to-right, top-down. Microsoft BMP files left-to-right, bottom-up. The 16-bit format is not one Microsoft supports (at least not in Paint or Viewer).
Some of the example in ST's code actually have a ''BM'' 0x42,0x4D header, whilst others don't. STM32F2-F4_Demonstration_Builder_V1.3.0\Libraries\Embedded_GUI_Library\src\images.c/**
******************************************************************************
* @file images.c
* @author MCD Application Team
* @version V2.1.0
* @date 31-July-2012
* @brief Hex dumps of the 16-color 565 RGB images used by Graphics Library.
******************************************************************************
...
/**
* @brief A bitmap for the RadioButton Button Selected. This logo is 20x20 px.
*/
const uint8_t RButtonA[866] =
{
0x42, 0x4D, 0x62, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x42, 0x00, 0x00, 0x00, 0x28, 0x00,
0x00, 0x00, 0x14, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00, 0x01, 0x00, 0x10, 0x00, 0x03, 0x00,
0x00, 0x00, 0x62, 0x03, 0x00, 0x00, 0x12, 0x0B, 0x00, 0x00, 0x12, 0x0B, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8, 0x00, 0x00, 0xE0, 0x07, 0x00, 0x00, 0x1F, 0x00,
0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x5C, 0xE7,
0x51, 0x8C, 0x08, 0x42, 0x00, 0x00, 0x00, 0x00, 0x08, 0x42, 0xB2, 0x94, 0x3C, 0xE7, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
...