0
\$\begingroup\$

I have a project in mind to create a GUI using a STM32F4 microcontroller. I am currently working/playing with a STM32F469I-DISCO board that embeds a MIPI Display. I understood how to display images and others stuffs but I was wondering what are the solutions to store icons more "efficiently". What solutions are commonly used.

For now when I want, for example, display a specific icon, I create two files :

  • a source file icon.c that contains an array in which each element describes a pixel ;
  • a header file icon.h that simply contains the array prototype.

Then I include the header and use my icon when I need it. But I noticed that icons are not negligible in terms of space requirements (depends of course on the icon size, color format...).

Anyway, generally, in an embedded system (using a STM32 for example), what are the most "efficient" solutions to store everything that is related to the GUI itself ? Is an EEPROM correct ? SD Card or something else ?

Thank you !

EDIT : By efficient I mean a solution that takes the less space possible (physically). I don't have any requirements on the power consumptions side.

|improve this question
\$\endgroup\$
  • \$\begingroup\$ What is "efficient" for you? \$\endgroup\$ – Eugene Sh. Jul 12 '17 at 19:08
  • \$\begingroup\$ Right, I did not specify this. Well the most integrable solution, taking the less space (physically) possible. I will edit the post. \$\endgroup\$ – vionyst Jul 12 '17 at 19:17
  • \$\begingroup\$ As far as saving some eeprom/flash space, don't overlook applying some crude compression in the icon c file. You can implement this yourself using various schemes. It can be as simple as <number of adjacent pixels><color> as you construct the icon array. This can save a significant number of bytes. Then perhaps you will have enough flash space where an additional EEProm won't be necessary. It's trivial to use a Python script to import a bitmap and spit out a compressed byte array that would be copied to your source code. \$\endgroup\$ – Chris Knudsen Jul 12 '17 at 19:53
  • \$\begingroup\$ You're "EDIT" on efficiency tells us the definition of efficient LOL. Eugene wants to know how you want to be efficient, not what efficiency meant. \$\endgroup\$ – KingDuken Jul 12 '17 at 21:28
  • \$\begingroup\$ An external serial (SPI) flash memory comes to mind, like this one. \$\endgroup\$ – JimmyB Jul 18 '17 at 22:18
0
\$\begingroup\$

If you have a number of graphics and they are taking up lots of space, then you'll need space to put them somewhere and more space to work with them.

If you are simply compiling them as c or h files, then they are likely falling into your internal Flash space. So the question is if they are taking up too much space and need to be kept elsewhere. Note that even if you are setting the compiler to keep them in RAM, then they will still have an image in Flash that is loaded to RAM at startup.

So then you have off-board options. This could be an EEPROM chip, which are relatively cheap and easy to work with. An SD card brings more space but also more overhead - you'll need to get a FAT system working. I am assuming you are not using an external memory bus with Flash on your processor, but if you were, then that would be a good place.

If you take this route, you have three obstacles to overcome:

  1. The driver and API. Depending on what you choose, you may have to write your own. From wherever the driver came from, you'll have to get it working and validated in your setup.

  2. Initialization of the memory. You'll need to get your images into the memory device somehow. If it is an I2C EEPROM or an SD card, you'll have to figure out how to get your images in there in a way that your processor will recognize.

  3. Local copies in RAM. When you pull an image out of memory, you'll need enough RAM space to hold it while you work with it.

I don't know enough about your application and specs to make a recommendation. If the graphics are likely to be modified a lot for aesthetics before they are done, then SD card may be most convenient as you can update it easily with your PC. But this will have a significant scope impact on your software project. If you are under a cost target and the images are simple and not going to change, then maybe I2C EEPROM is the best way, but if the images are large, there may be some time lag. If you can suffer the internal Flash space, then that may be easiest in the long term. If you have control over processor selection and PCB design, then you could get an external memory bus with tons of Flash.

There is also the option of image compression, which can be done in embedded systems, and while I've seen it done I don't know enough of the pros and cons right now to comment intelligently.

|improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.