7 years, 2 months ago.

DISCO_F746NG DrawBitMap not working with I2C ADC

I have created a simple example that demonstrates my problem with the LCD_DISCO_F746NG library DrawBitMap function.

Import programDISCO-F746NG_LCD_TS_ADC

A simple demonstration of the DISCO-F746NG LCD, TouchScreen and MCP3221 I2C ADC.

DrawBitMap works fine until a MCP3221 read is placed in the code as follows after which no bitmap is displayed:

sprintf((char*)text, " ADC=%.3f ", adc.read()); Read and scale ADC result - stops DrawBitMap from working

The adc.read() works fine.

This problem has got me baffled and I would appreciate any advice.

1 Answer

7 years, 2 months ago.

Could be that that adc and sprintf are OK, but that the problem is in actual writing to the display.

You use

...
int main()
{
...
    uint8_t text[30];
 
... 
        // Read and scale ADC result
        sprintf((char*)text, " ADC=%.3f ", adc.read());
        lcd.DisplayStringAt(0, LINE(8), (uint8_t *)&text, CENTER_MODE);  // <== 'text' is a pointer
...

}

The '&text'' will return the address of the location where the pointer is stored instead of the pointervalue, so somewhere in memory where DisplayString then starts looking for the end of a string (indicated by 0 value) without much luck...

Try

... 
        lcd.DisplayStringAt(0, LINE(8), (uint8_t *) text, CENTER_MODE);  // <== text is a pointer
...

or

... 
        lcd.DisplayStringAt(0, LINE(8), (uint8_t *) &text[0], CENTER_MODE);  // <== text[0] is a char variable, &text[0] is a pointer
...

Hi Wim,

Thanks for your advice on the correct use of pointers; my and your two options all work OK.

I think perhaps I didn't explain my problem clearly. This line

lcd.DrawBitmap(8, 85, (uint8_t *)peter_file); // Display bitmap image

works OK but not when any I2C related function like this

sprintf((char*)text, "ADC = %.3f ", adc.read()); // Read and scale MCP3221 I2C ADC result

is put in the code.

Weird. Any further advice appreciated.

posted by Peter Ampt 04 Feb 2017

Hi Peter, I found some time to look into this problem. It seems to be caused by the Bitmap ''peter_file'' that you have stored in flash. The header size is wrong. It is defined as 54 bytes, which means the DrawBitmap code in the BSP package will try to use an offset of 54 bytes from the pointer to the ''peter_file'' as starting address for the image content. The content is defined as 32 bits per pixel and the code tries to cast the address ''peter_file + 54'' to a 32 bit pointer. That is not a valid address and it seems to cause a crash/exception sometimes.

You can fix that by adapting the ''peter_file'':

//const uint8_t peter_file[10054] =
const uint8_t peter_file[] =
{
 0x42,  0x4d,  0x46,  0x27,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,
// 0x36,  0x00,  0x00,  0x00,  0x28,  0x00,  0x00,  0x00,  0x32,  0x00, // < 0x36 is 54 bytes
 0x38,  0x00,  0x00,  0x00,  0x28,  0x00,  0x00,  0x00,  0x32,  0x00,  // < 0x38 is 56 bytes, valid 32bit address
 0x00,  0x00,  0x32,  0x00,  0x00,  0x00,  0x01,  0x00,  0x20,  0x00,
 0x00,  0x00,  0x00,  0x00,  0x10,  0x27,  0x00,  0x00,  0xc4,  0x0e,
 0x00,  0x00,  0xc4,  0x0e,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,
 //0x00,  0x00,  0x00,  0x00,  0xb3,  0xc0,  0xb8,  0xff,  0xb3,  0xc0,
 0x00,  0x00,  0x00,  0x00,  0x00,  0x00,                                    //< insert 2 padding bytes
                             0xb3,  0xc0,  0xb8,  0xff,  0xb3,  0xc0,
 0xb8,  0xff,  0xb3,  0xc0,  0xb8,  0xff,  0xb3,  0xc0,  0xb8,  0xff,
 0xb3,  0xc0,  0xb8,  0xff,  0xb3,  0xc0,  0xb8,  0xff,  0xb3,  0xc0,
 0xb8,  0xff,  0xb3,  0xc0,  0xb8,  0xff,  0xb3,  0xc0,  0xb8,  0xff,

...

I dont have the MCP3221 I2C device to test your complete code, but the main loops works: I get the Bitmap image, touch works, I see printf messages inside the main loop and a flashing LED.

posted by Wim Huiskamp 07 Feb 2017

Hi Wim,

Thanks so much for investigating my problem; I made your suggested changes and now I too get the Bitmap image. I used various applications to create the Bitmap and C-code and incorrectly assumed that they were producing the correct output. Anyway, thanks again for your help.

Peter

posted by Peter Ampt 11 Apr 2017