Problem with UTFT bitmap buttons and setFont

I have a Mega 2560 with an IO Expansion Shield v2.3 connected to an ITDB32WD LCD. I’m having a problem displaying a bunch of bitmap buttons as well as text. The buttons are .png files that I converted to .c files using the converter included with the UTFT library. I attached some test code that simply displays a bunch of buttons and some text. I cannot display all 7 buttons and the text at the same time. If I comment out the myGLCD.setFont(SmallFont); line then all the buttons work (obviously the text doesn’t display correctly since I didn’t tell it what font to use). If I include the setFont line and comment out any one of the buttons (except the last one), then the text and the included buttons display fine. If I include everything then the program compiles, but the screen is white and nothing shows up in the serial monitor either (I realize I’m not sending anything to the serial port, but in other programs I’ve tried nothing shows up). I’m hoping someone can try this code and figure out what is going wrong. I’ve contacted Henning, but he doesn’t see any reason why it shouldn’t work and doesn’t have any time to test it out. Any suggestions would be appreciated.

test.ino (1.11 KB)

Auto.c (37.2 KB)

Back.c (9.43 KB)

Disabled.c (37.2 KB)

Here are the rest of the files needed to run the program.

Manual.c (37.2 KB)

Off.c (37.2 KB)

On.c (37.2 KB)

Plant.c (97.4 KB)

Using your sketch, except modified to use ITDB32S display…

IMG_20140227_203455_1.jpg

Am I missing something? It appears Henning was right as usual… :wink:

Regards,

Graham

What hardware are you using beside the ITDB32S? I could try connecting the ITDB32WD directly to the Mega to see if there is an issue being caused by the IO expansion shield.

I am very sorry to have got your hopes up =( On further investigation, you are correct, it is not happy on the MEGA2560. But if it is any consolation, it works fine on Arduino DUE. The problem is the address space of all of your images and the font exceed 16bit (i.e. > 0xFFFF) which appears to be a problem on the MEGA2560.

My suggestion is to reduce the size of ‘plant.c’ as that is a fairly enormous 22K… which is more than a third of your total addressable…

I have included here my revised sketch including address dumping to serial monitor should you wish to investigate further.

Very sorry,

Regards,

Graham

(TinyFont is just in case you want to play with all options)

TinyFont.c (4.45 KB)

test.ino (2.81 KB)

I’m so glad you were able to figure this out. I did notice that once the combined size of the images approached 65K the program would no longer run, but I couldn’t figure out why it would be a problem. What do you mean by address space? Is this limitation mentioned somewhere on the spec for the Mega?

My knowledge of these things is not sufficient to explain clearly to someone else, I just know enough to get by and understand why its not working. Try looking at this link and some of the others in this reference document http://www.atmel.no/webdoc/AVRLibcReferenceManual/group__avr__pgmspace_1ga73084a8bbde259ffae72980354b3f027.html.

Someone with a greater understanding of this stuff than me................could possibly tell you how to work around this on the MEGA. If you look inside UTFT.cpp, you will find there are a few uses of

pgm_read_byte

, specifically UTFT::printChar and UTFT::rotateChar both of which are used by UTFT::print. Additionally in UTFT::drawBitmap, you will see

pgm_read_word

is used which is how your images appear on your buttons.

I can't explain why the same code works fine on the DUE but not on the MEGA, my tentative personal suspicion is that maybe 'word' = 32 bit on the DUE but only 16 bit on the MEGA.

Not sure if this is helpful to you, but it is the best I can figure at the moment.........

Regards,

Graham

Thanks for your help Graham. I'm not sure there is a software workaround for this issue because when I Googled it I found a bunch of companies offering SRAM expansion shields. Unfortunately I don't think I can spare the IO pins to do that. If anyone out there has a way to get around the address space limitation with software, please let me know.

I think there is empty space around all my images so I could shrink them so that the icons go right to the edges. This should save some space in case I want to add more images in the future.

The other option, of course, is to switch to another board, but the Mega is perfect for the amount of IO that I need and my expansion shield has slots for XBees, which I am also using. I couldn't find a similar IO expansion board for the Due. I guess I'll just have to make do with what I have. It would be nice if this limitation was giving in the Mega spec, but I guess it probably doesn't come up that often.

Sorry I couldn’t be more help, and I did spend quite a large portion of today working on this to try to make amends for my previous mis-information :frowning: I agree this does seem to be a fairly big problem, with limited successful solutions, and even with what I have read and discovered, I think to implement some of the suggestions would require additional input from Henning, who I know from past dealings is not keen to make big changes for small audiences… So just for information really if nothing else, and if you are committed to the MEGA maybe this will serve you in future projects…

The reason why your sketch works on the DUE and not the MEGA is sort of what I thought(ish)… compare these two pages :-

I do like the idea of multi segmented PROGMEM statements utilizing #include <morepgmspace.h> but I dont see how that could easily be implemented with UTFT…

Best wishes,

Graham

I was reading the first link you sent myself and I think the information to fix the problem is in there - it will probably just take awhile to implement it. In my email exchange with Henning, he thought it could be a memory alignment issue and it turns out he was correct.