SHARP Memory Display Booster Pack

[greeeg 460]

Thanks guys, I've dusted it off a little around the edges. and created this demo application.

 

Sorry, Chicken, I've actually never used Energia, I guess I'm not good with change, and my text editor/terminal setup is working fine for me.

 

 

This shouldn't be considered a finished piece of software. It does work. But if you wanted to change the USCI module, there are like 2/3 files you need to change register names in, the CPU isn't being put to sleep during the DMA xfer, etc. 

 

 

src_sharplcd_demo_FR5969.zip

 

The demo displays an analog watch face, but no attempt to maintain actual time.

 

You should be able to open and "make" in the src directory.

"make upload" will use mspdebug and tilib to flash the FR5969 launchpad.

 

 

 

I have some 168x144 pixel sharp mem displays, When I get some time I'll document and implement the code changes between the 2 display sizes. 

[greeeg 460]

@@greeeg Could you post pics/videos of it working? You can also send it to admin at 43oh.

 

Give me a use for my new macro lens

I should be able to post a video over the weekend, but I think I should write more code before I do that.

 

If you run the code, you'll get this. but moving like an actual clock would.

 

@@chicken let me know how this runs with your boosterpack.

[chicken 630]

@@greeeg between work and Seattle Maker Faire I won't have time to give it a try this week.

 

I will also have to port it to MSP430F5529 as I don't have the new LaunchPad. Well, maybe I can take a stab during slow times at Maker Faire.

[pabigot 355]

FWIW, there's a driver for the Sharp Memory LCDs in bsp430 too; see this source file.  There's also a bridge from it to u8glib.
 
This was mostly proof-of-concept and to give me something to use if I suddenly needed a white-on-mirror display for something (dunno what y'all are using for this effort, but TI's boosterpack is pretty hard to read).

[bluehash 1,581]

@@pabigot Good to know!

[RWB 4]

I have been playing around with these Sharp Memory LCD's also. I like how sharp the 128x128 pixel & 2.7 Inch TFT versions have the black pixel color instead of the mirror silver finish which I don't like.

 

The ultra low power consumption is awesome. 

 

They require lots of SRAM so its taken me as a newbie to all this a long time to find some solutions that have enough memory to actually run the 128x128 pixel 1.28 inch screen and especially the 2.7 Inch 400x240 pixel screen that takes 12,000 bytes of memory. 

 

Looking at the ultra low power consumption of this screen + FRAM + the new MSP430FR5969 + Sharp LCD screen combo for the killer price of $30 ! 

 

I hear that the FRAM can be partitioned so if you need more SRAM you can just adjust your FRAM allocations to meet your needs like increasing the SRAM size. Is this possible? Or is it possible to runs Sharps 2.7 Inch screen with the the new MSP430FR5969?

 

And one last question is about the current best library for the Sharp Memory LCD's & the new MSP430FR5969. Is the library that comes with the new the new MSP430FR5969 + LCD Screen combo being sold by TI considered a full featured library? 

 

 

[greeeg 460]

I have been playing around with these Sharp Memory LCD's also. I like how sharp the 128x128 pixel & 2.7 Inch TFT versions have the black pixel color instead of the mirror silver finish which I don't like.

 

The ultra low power consumption is awesome. 

 

They require lots of SRAM so its taken me as a newbie to all this a long time to find some solutions that have enough memory to actually run the 128x128 pixel 1.28 inch screen and especially the 2.7 Inch 400x240 pixel screen that takes 12,000 bytes of memory. 

 

Looking at the ultra low power consumption of this screen + FRAM + the new MSP430FR5969 + Sharp LCD screen combo for the killer price of $30 ! 

 

I hear that the FRAM can be partitioned so if you need more SRAM you can just adjust your FRAM allocations to meet your needs like increasing the SRAM size. Is this possible? Or is it possible to runs Sharps 2.7 Inch screen with the the new MSP430FR5969?

 

And one last question is about the current best library for the Sharp Memory LCD's & the new MSP430FR5969. Is the library that comes with the new the new MSP430FR5969 + LCD Screen combo being sold by TI considered a full featured library? 

 

I'd say that the TI library is fully featured. But it also takes up ~10kb on the new FRAM board. 

 

You don't increase SRAM size per say. As long as your running < 8MHz FRAM Read/Write is just as fast as SRAM. It is very easy to use the FRAM as a frame buffer. I've done this in all my projects. For security you should read up how to enable the memory protection unit, in-case some buggy code wants to rewrite your program :S

The FRAM buffer approach is used in the code I've linked above. I admit it could be prettier. Assuming you don't run out of FRAM you could easily use 12Kb for a screen buffer.

 

I to much prefer the black and grey sharp panels. I wonder if the inclusion of the white/silver is because sharp sold them to TI cheaply?

[RWB 4]

I'd say that the TI library is fully featured. But it also takes up ~10kb on the new FRAM board. 

 

You don't increase SRAM size per say. As long as your running < 8MHz FRAM Read/Write is just as fast as SRAM. It is very easy to use the FRAM as a frame buffer. I've done this in all my projects. For security you should read up how to enable the memory protection unit, in-case some buggy code wants to rewrite your program :S

The FRAM buffer approach is used in the code I've linked above. I admit it could be prettier. Assuming you don't run out of FRAM you could easily use 12Kb for a screen buffer.

 

I to much prefer the black and grey sharp panels. I wonder if the inclusion of the white/silver is because sharp sold them to TI cheaply?

 

How does your code size compare with the ~10kb for TI's library? 

 

If I want to run the 2.7 inch screen with the MSP430FR5969 will I be forced to use the Frame Buffer option considering there is not enough SRAM on the board to store the 12,000 bytes required to display a full 2.7" sharp memory lcd screen? 

 

Also you said "As long as your running < 8MHz FRAM"  You used the less than sign. Does that mean I have to run the FRAM at 8mhz or less to use it to frame buffer? Or is 8 Mhz the minimum speed? 

 

What would you say your Sharp Memory LCD library is lacking compared to TI's Sharp Library? 

 

Thanks for your feedback! 

[greeeg 460]

My "library" only has 1 fixed font. Pixel onoff functions. Line/circle functions.

 

But its all very specialized for this display. To change to your 2.7" display modifications would be made.

 

Framebuffer option? Both the things you are describing are frame buffers, makes no difference that it is in FRAM or in SRAM.

 

FRAM has a max speed of 8 MHz. This is not a problem with sharp displays, as their max serial clock is specified as 1Mhz.

 

The TI Grlib. Has a lot of things going for it. You'd have to make a driver of sorts for any display you use. But it has multiple fonts. And a PC application to generate bitmaps that the library can display.

 

Sent from my Nexus 5 using Tapatalk

 

 

[RWB 4]

My "library" only has 1 fixed font. Pixel onoff functions. Line/circle functions.

 

But its all very specialized for this display. To change to your 2.7" display modifications would be made.

 

Framebuffer option? Both the things you are describing are frame buffers, makes no difference that it is in FRAM or in SRAM.

 

FRAM has a max speed of 8 MHz. This is not a problem with sharp displays, as their max serial clock is specified as 1Mhz.

 

The TI Grlib. Has a lot of things going for it. You'd have to make a driver of sorts for any display you use. But it has multiple fonts. And a PC application to generate bitmaps that the library can display.

 

Sent from my Nexus 5 using Tapatalk

 

Thanks for the info. 

 

I have the 1.28 inch 128x128 pixel TFT & 2.7 Inch memory displays coming so I'll be needing to get both of them up and running soon. 

 

Sounds like the TI library is perfect as long as the 10kb file size doesn't take up memory needed to run my applications. 

 

It sounds like FrameBuffer is just bytes of memory that gets refreshed any time the screen changes. 

 

I learned that FRAM has a max speed of 8 MHz. 

 

I will be needing to generate or converter bitmaps I have already made to work on the Digole LCD displays so knowing they already have PC software to do this good news. 

[timb 15]

Thanks for the info. 

 

I have the 1.28 inch 128x128 pixel TFT & 2.7 Inch memory displays coming so I'll be needing to get both of them up and running soon. 

 

Sounds like the TI library is perfect as long as the 10kb file size doesn't take up memory needed to run my applications. 

 

It sounds like FrameBuffer is just bytes of memory that gets refreshed any time the screen changes. 

 

I learned that FRAM has a max speed of 8 MHz. 

 

I will be needing to generate or converter bitmaps I have already made to work on the Digole LCD displays so knowing they already have PC software to do this good news. 

 

The code for doing graphics primitives is poorly done in TI's library, in my opinion. Though (if I remember correctly) it does support some type of basic (RLE maybe?) encoding for bitmaps, to reduce their size. That said, you're not going to be displaying a lot of large or detailed bitmaps on a Sharp Memory LCD, so I don't think it really matters. The best way to display graphics is just to dynamically draw them; that's why a good, easy to use and fast set of primitive functions is so important. Aside from maybe a company logo (which can be a single bitmap) all UI elements can be drawn from primitives. (Such as WiFi/Signal Strength Meters, Battery Gauges and so forth.

 

By the way, check your PMs over on the Spark Core forums! I messaged you a few days back.

[RWB 4]

I received my FR5969 demo board with Sharp LCD yesterday! 

 

Its amazing how long the processor and display can run the clock app off just the capacitor. Its been showing time for 17 hours straight now. 

 

I loaded the MSP-EXP430FR5969 with Graphics Library  from MSP430ware in Code Composer Studio. 

 

I then found the HAL_MSP-EXP430FR5969_Sharp96x96.h  file and changed the Pixel x Pixel data to 128 x 128 pixels. Next I'll try the 400 x 240 pixels for the 2.7 inch screen. 

 

Looks like they are using a frame buffer in the demo code above. 

 

So the they are using Frame Buffer for in the example code in MSP430ware which should also allow me to use the 400x240 pixel Sharp Memory Display but when I try to use 400 horizontal x 240 vertical pixels and then built it I get over size errors like this:

 

error #10324-D: BOUND section ".TI.bound:DisplayBuffer" spans the boundary of an existing memory range FRAM

<Linking>

 

>> Compilation failure

error #10099-D: program will not fit into available memory.  run placement with alignment fails for section ".TI.bound:DisplayBuffer" size 0x3520 

error #10010: errors encountered during linking; "MSP-EXP430FR5969_Grlib_Example.out" not built

gmake: *** [MSP-EXP430FR5969_Grlib_Example.out] Error 1

gmake: Target `all' not remade because of errors.

 

**** Build Finished ****

 

So I'm sure something needs to be changed in the display buffer size setting to get it working. 

 

I think something needs to be changed in the code below to work with the 400 x 240 pixel size possibly. Take a look. 

 

//*****************************************************************************

//

// IMPORTANT NOTE: The following driver file supports using either RAM or

// non-volatile memory(Flash or FRAM) to store the LCD DisplayBuffer.

//

//*****************************************************************************

 

//*****************************************************************************

//

// Sharp96x96.c

//

//*****************************************************************************

//

//! \addtogroup display_api

//! @{

//

//*****************************************************************************

 

#include "grlib.h"

#include "Sharp96x96.h"

#include <msp430.h>

#ifdef __MSP430FR5969

#include "HAL_MSP-EXP430FR5969_Sharp96x96.h"

#include "driverlib.h"

#elif defined(__MSP430G2553)

#include "HAL_MSP-EXP430G2_Sharp96x96.h"

#endif

#include <stdint.h>

 

 

static void Sharp96x96_InitializeDisplayBuffer(void *pvDisplayData, uint8_t ucValue);

 

//*****************************************************************************

//

// If flash is used as non-volatile memory, the DisplayBuffer will have 32 extra

// vertical lines to create a buffer size which is a multiple of 512 Byte

// (this is the default size of flash memory segments in MSP430 device). It is

// required that the display buffer is a multiple of 512 Bytes to be able to

// initialize the buffer using the FLASH segment erase feature of the FLASH

// controller.

//

//*****************************************************************************

 

#ifdef NON_VOLATILE_MEMORY_BUFFER

#pragma location=NON_VOLATILE_MEMORY_ADDRESS

#endif

 

#ifndef NON_VOLATILE_MEMORY_BUFFER

uint8_t DisplayBuffer[LCD_VERTICAL_MAX][LCD_HORIZONTAL_MAX/8];

#else

#ifdef __ICC430__

__no_init uint8_t DisplayBuffer[LCD_VERTICAL_MAX +32][LCD_HORIZONTAL_MAX/8];

#else

uint8_t DisplayBuffer[LCD_VERTICAL_MAX +32][LCD_HORIZONTAL_MAX/8];

#endif //__ICC430__

#endif //NON_VOLATILE_MEMORY_BUFFER

 

uint8_t VCOMbit= 0x40;

uint8_t flagSendToggleVCOMCommand = 0;

 

****************************************************************************************************************************************

 

Any ideas? 

• Quote
• MultiQuote
• Edit
•  
•  

 

I'm learning. 

[greeeg 460]

I don't own CCS. so I can't give you a definite solution to your problem. However I would advise you follow the reccomendation in the comment block you posted above  

// It is required that the display buffer is a multiple of 512 Bytes

Given the size of your array 0x3520 (13600 bytes) I think that should be a starting point, since that is not a multiple of 512.

[RWB 4]

I don't own CCS. so I can't give you a definite solution to your problem. However I would advise you follow the reccomendation in the comment block you posted above  

// It is required that the display buffer is a multiple of 512 Bytes

Given the size of your array 0x3520 (13600 bytes) I think that should be a starting point, since that is not a multiple of 512.

 

So how would I fix that? I'm clueless with my minimal knowledge base.  I can't change the pixel dimensions or the screen will not display properly right? 

 

Is there a way to change the display buffer size so it works? 

 

There is enough FRAM to do this right? 

 

I can see how 96x96 divides evenly into 512, and the same goes for 128x128 pixels. 

 

I tried 400 x 256 since it divides into 512 by a even 200 but that gives me this error on building:

 

error #10324-D: BOUND section ".TI.bound:DisplayBuffer" spans the boundary of an existing memory range FRAM

<Linking>

 

>> Compilation failure

error #10099-D: program will not fit into available memory.  run placement with alignment fails for section ".TI.bound:DisplayBuffer" size 0x3840 

error #10010: errors encountered during linking; "MSP-EXP430FR5969_Grlib_Example.out" not built

gmake: *** [MSP-EXP430FR5969_Grlib_Example.out] Error 1

gmake: Target `all' not remade because of errors.

 

**** Build Finished ****

[greeeg 460]

 

So how would I fix that? I'm clueless with my minimal knowledge base.  I can't change the pixel dimensions or the screen will not display properly right? 

 

Is there a way to change the display buffer size so it works? 

 

There is enough FRAM to do this right? 

 

I can see how 96x96 divides evenly into 512, and the same goes for 128x128 pixels. 

 

I tried 400 x 256 since it divides into 512 by a even 200 but that gives me this error on building:

error #10099-D: program will not fit into available memory.  run placement with alignment fails for section ".TI.bound:DisplayBuffer" size 0x3840 

 

 

Okay, you're still thinking in bits. 96x96 divides into 512 bits. but the memory is arranged in 512 BYTE blocks. that's why they had to make the actual buffer 96*128

 

400X256 would work fine, it divides by 25x 512 byte sections. Did you remove the "+32" in sharp96x96.c?

 

The compiler is saying that your buffer is 0x3840 (14400 bytes) which works out to a 400x288.

 

 

If you change the "+32" to "+16" and then set

LCD_VERTICAL_MAX to 240

LCD_HORIZONTAL_MAX to 400

 

Since they might be used internally, and would be better if they were the actual screen size.