Paul Staron

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

8 years, 11 months ago.

MicroLib?

This is using too much Flash / Ram, is the compiler not set to MicroLib?

Question relating to:

Last updated: 12 Sep 2016
Demo program for driving the memory LCD on the Zero Gecko Starter Kit.

2 Answers

Erik -
8 years, 11 months ago.

The STK3200 and STK3400 seem to be set for MicroLib, the others for the normal one. So the zero should be microlib.

Quick check if that code, it seems to keep a frame buffer in its RAM memory, which I think is 2kB total. So on your 4kB thats quite some RAM.

Steven Cooreman
8 years, 11 months ago.

Yes, the memory LCD driver keeps a frame buffer, since the SPI connection is unidirectional, so you can only write to the display, not read its contents. This indeed means you immediately loose half of the available RAM on Zero Gecko. Add to that half a K of system stack and the RAM usage of mbed itself (giving you printf and other such goodies), and you very quickly run into the limitations of the processor. Should you require more, the new Happy Gecko platform will give you 64k of flash and 8k of RAM (double of what Zero has).

At Silicon Labs, we are very much committed to creating the best mbed experience possible, and mbed's RAM usage is something we do want to cut down on. We have already taken several steps in that direction, and are looking to improve that even more in the near future, insofar it can still be done.

This memory LCD demo should run out-of-the-box though, so tell me if it doesn't. It has primarily been created as a show of what moving to the asynchronous APIs and sleep call can do for your power consumption.

The Mbed memory LCD demo does run as it should.

Is it possible to drive the LCD much the same as Simplicity Studio does? The demo's there are quite large and run okay.

Is it possible to replace the MCU on my board with a Happy Gecko MCU, will this cause a problem with the interface not seeing the original MCU type? (assuming they are pin - pin compatible).

posted by Paul Staron 01 Jun 2015

Paul,

thanks for acknowledging. It should be possible to drive the LCD with just a linebuffer (or an 8-line buffer if only using it for text output), but then your program has to recreate the display information from scratch every single time. That basically means overlaying stuff and doing graphics go out the window.

The samples we provide with Simplicity Studio have been heavily optimized for their use cases, and do not have to deal with the overhead of the mbed library, hence why you can do more advanced stuff when you 'go native' to emlib and/or bare metal code. Since the goal of mbed is rapid prototyping though, we chose to keep the abstraction level high and provide a comfortable interface to the memory LCD for people with little experience.

One of these days, when time allows, I might just make a text-based version of the LCD driver, which should be a lot easier on the RAM. (128 byte buffer instead of 2k)

As for swapping them out, I'm not sure. The debugger will recognize it as a Happy Gecko (as it should), but I haven't checked the schematics to validate whether the two parts are actually pin-compatible. Besides that, it'd be a pretty difficult soldering job considering the caps in very close proximity :)

posted by Steven Cooreman 01 Jun 2015

As for replacing the MCU: All the EFM32s to date are pin-compatible. That means that you can take any Gecko, Tiny Gecko or Zero Gecko in the same package (QFP48) and swap it out with a Happy Gecko and not have to redo your board. They are also code-compatible, but not binary compatible so recompiling your code is all you should have to do when you migrate to a new device.

As for resoldering your board, I think you would be better of getting a second Happy Gecko board, they're only $29 after all..

posted by Alf Petter Mossevig 10 Jun 2015