sharp memory lcd display free sample

Sharp"s Memory LCD is a lightweight display with 1-bit memory in every pixel allowing high-contrast, ultra-thin and at the time same delivering a relatively high frame rate (20Hz max) at merely microWatt power consumption level.

Install this library to /arduino libraries folder. In Arduino IDE from File->Examples->Custom Libraries you will see 5 examples. We have tested 5 Memory LCD models up to time of writing:

Selection options for which LCD model to use is available in MemoryLCD.h. Listing below shows an example with 2.7" model to use by leaving only #define LS027B7DH01 while other models has been comment out.

Memory LCD is driven with two data update modes: 1-line mode and multiple-lines mode. There is no single pixel write! To get around this problem a frame buffer is declared to store all pixels in a 2D array:

Each byte in the second subscript frameBuffer[0][x] represents 8 pixels in the horizontal direction. On the first horizontal line, pixels 0-7 are represented by frameBuffer[0][0], pixels 8-15 by frameBuffer[0][1] and so forth. Bitwise operation is used to fill up this frame buffer in SRAM of the MCU. After the required pixels have been updated in SRAM, the LCD is refreshed for a complete horizontal line with consecutive SPI transfers.

To illustrate this idea better we have captured the pixels on a 4.4" Memory LCD with a macro lens as below. The red rectangle is a label for the first 8 pixels represented by the byte element at framebuffer[0][0].

Now suppose we need to set the odd pixels to black color for positions 1,3,5,7 we may call the API function GFXDisplayPutPixel(x,y,color) with code snippet:

What"s happening in the for-loop is that, every time GFXDisplayPutPixel() is called for example GFXDisplayPutPixel(0,0,BLACK), it is the pixel position at (0,0) set BLACK with framebuffer[0][0]=0b1111 1111 -> framebuffer[0][0]=0b0111 1111. A pixel is set white with bit set 1 & clear to 0 to set black. After bitwise is finished with GFXDisplayPutPixel_FB()the line will be updated by the local function GFXDisplayUpdateLine(). Interested readers may take a look at the source code for GFXDisplayPutPixel() here:

To extend this concept to 2D, we may partially update a rectangular area with GFXDisplayUpdateBlock() to keep the content at the right unchanged while updating the area at the left. Graphical interface illustrated in the Arduino Sketch BloodPressure_GU.ino shows a counting blood pressure reading at the left with a stood still icon of an up-arrow at the right. Feel free to open this sketch and change the delay constant in loop() from delay(50) to delay(1), or removing it to get an impression on how fast it can go. Another unique features of Memory LCD is partial update as long as it spans a horizontal region. Given the blood pressure reading GUI below this means only the area occupying the font height of the SYS. pressure is changed while the top and bottom regions unchanged when it is the systolic pressure counting.

Many projects benefit from a small display as a user interface. For very low power applications this is usually a no-go as the display needs too much energy. I have used e-paper displays from Kent: while these e-paper displays do not need any power to keep the image, changing the display content is not for free, plus is very slow (around 1 second needed to update the display). So I was looking for something low power and fast for a long time, until Christian (thanks!) pointed me to a display from Sharp: both very low power and fast:

And even better: Adafruit has a breakout board for that display available (https://www.adafruit.com/product/1393) :-). The display on the board is the Sharp LS013B4DN04 with 96×96 monochrome pixel resolution. The display is a cross between a e-paper and normal LCD. The ‘background’ color is a nice silver color. What looks cool with this display is that the pixels show up like little mirror:

The display has no backlight: readability is excellent (although somewhat view angle dependent) under daylight, under darker light conditions an extra illumination is needed. It has a very good contrast between the pixels:

The Adafruit breakout board comes with a level shifter so it can be used with 3.3V-5V. I’m using it with 3.3V, and only need 5 wires connected to the display:

One special thing with the Sharp Memory display is that it needs a special clock signal to generate the VCOM, an alternating signal that prevents a DC bias from being built up within the display panel. Depending on the display used, that signal or clock needs to supplied in the range of 0.5 to 60 Hz. That signal can be supplied either externally or by software, depending on the EXTMODE pin:

On the Adafruit breakout board, EXTMODE is pulled LOW: the clocking has to be provided by software. With software a special ‘VCOM’ command is sent to the display:

The ToggleVCOM() function only needs to be called if there are no other display commands sent, as the VCOM bit can be toggled while writing to the display.

Each line of the display can be updated with a command: sending line number, then the number of bytes (12 for the 96 bits) followed by a trailing 16 zero byte:

Of course I have created a new Processor Expert component for using that display. With it is only a matter of minutes to get the display up and running:

Making full updates of the display every 20 ms (50 images per second) requires 41 μA. Of course the less frequent image updates or the less lines update, the better.

That Sharp Memory Display is a really cool one. The Adafruit breakout board has its price ($39.95). It took me a while to get the protocol right, but now I have very low power display and driver in my inventory :-). There is an example project on GitHub, and the SharpMemDisplaycomponent is available on GitHub and will be part of the next McuOnEclipse component release. If you are interested in the sources only, they are available on the McuOnEclipseLibrary project.

Different displays have different characteristics, just tell Panox Display your application, and operating environment, Panox Display will suggest a suitable display for you.

But Panox Display is not a school, if customers don`t know the basic knowledge to design circuit boards, we suggest using our controller board to drive the display.

First, you need to check whether this display has On-cell or In-cell touch panel, if has, it only needs to add a cover glass on it. If not, it needs an external touch panel.

If you don`t know or don`t want to write a display program on Raspberry Pi, it`s better to get an HDMI controller board from us, and Panox Display will send a config.txt file for reference.

1.35" 96x96 Sharp Memory LCD Display Module is from Embedded Artists. Refer to the quick start guide from Adafruit, we debug it with arduino MEGA, plus Adafruit examples and GFX library.

Edit: One thing to be aware of - the Sharp display expects each byte of data to be sent with the least significant bit (LSB) first. It also wants pixel data to be sent as a block of 96 bits with the leftmost bit first. That means the leftmost pixel of a row is in the LSB of the first byte of pixel data, rather than the MSB as you might expect. You either need to find a tool that can output in this form, or reverse the bit order when sending the pixels. I do this by setting the USCI to output MSB first, and then reverse the order of the row address and command bytes.

The source files for the DISPLAY device driver stack library resides in the kits/common/drivers directory and follows the naming convention: displaymodule_name.c/h.

The DISPLAY device driver stack implements a common API for different types of display devices. Thus making it easy to port applications between different hardware and software platforms. Additionally the DISPLAY device driver stack implements a Platform Abstraction Layer (PAL) in order to provide abstractions of hardware and software services needed by the specific display device drivers. Thus making it easy to port the DISPLAY device driver stack itself between different platforms.

The stack provides a configuration interface via dedicated configuration files in order to suit various application and platform requirements. Please refer to DISPLAY Device Driver Stack Configuration. for more information.

It is good practice that the user programmer checks the return value of the DISPLAY_Init() call, and for the sake of it, all calls in of the DISPLAY device driver interface. All functions in the DISPLAY device driver interface return an EMSTATUS code which indicates whether the operation was successful or not, and what type of error may have occurred. The possible error codes are listed in display.h.

The second step is typically to retrieve the properties of a DISPLAY device. This can be done by calling thedisplayDeviceNo which is a unique device number of one of the existing display devices in the system. Othen this value is zero because often there is just one display device in the system.

If geometry (DISPLAY_Geometry_t), the colour mode (DISPLAY_ColourMode_t) and the address mode (DISPLAY_AddressMode_t) of the display device. Additionally the

The pPixelMatrixDraw() function is used to move and show the contents of a framebuffer (or pixel matrix buffer) onto the display device. A pixel matrix buffer is a "partial" framebuffer which covers only part, or the whole, of the geometry of the display.

The format of the pixel data in the pixel matrix buffer is defined by the DISPLAY_ColourMode_t. At the time of writing only two colour modi are defined in DISPLAY_ColourMode_t :DISPLAY_COLOUR_MODE_MONOCHROME and

The DISPLAY_COLOUR_MODE_MONOCHROME mode defines a pixel bit value of 0 as white, and a pixel bit value of 1 as black. The DISPLAY_COLOUR_MODE_MONOCHROME_INVERSE mode is the opposite, and thus defines a pixel bit value of 0 as black, and a pixel bit value of 1 as white.

The pixel matrix buffer format for the monochrome modi is defined as a byte array wherebit 0 of the 0th byte is pixel 0 on line 0, top left on the display,

Some device drivers may need/want to support a pixelMatrix allocation function, pointed to by pPixelMatrixAllocate, in order to handle device specific data structures related to the pixel matrix buffers. The pixel matrix buffers allocated with the pPixelMatrixAllocate function may also include control data/padding in order to accomodate for efficient use of the underlying hardware. If the stride member of DISPLAY_Geometry_t structure is bigger than the width member, the pixel matrix buffer contains such control data, and should not be overwritten by the user, unless the user knows how to handle this data (which is usually not necessary).

NOTE: There is an issue with EMWIN that does not allow drawing on framebuffers of size 128x128 which happens to the size of the Sharp Memory LCD model LS013B7DH03. The DISPLAY interface supports a workaround that allows the user to allocate bigger framebuffers (pixelMatrix buffers) by using the userStride parameter which is included in the DISPLAY interface when EMWIN_WORKAROUND is defined. Therefore, in order to use EMWIN on the LS013B7DH03, the user must define EMWIN_WORKAROUND (typically in displayconfigapp.h) and request a userStride of at least 160 bits, not 128 bits which is the real width (in pixels) of the LS013B7DH03.

The pDriverRefresh function should be called if the system resources. e.g. bus clock frequency, has undergone any changes. The pDriverRefresh function will recalibrate internal parameters associated with the display devices.

This section contains a brief introduction to writing device drivers for specific display devices that can run properly in the DISPLAY device driver stack.

If you want to implement a new DISPLAY device driver, basically you need to implement an initialization function that populates a geometry DISPLAY_Geometry_t, the colour mode DISPLAY_ColourMode_t, the address mode DISPLAY_AddressMode_t, and the pPixelMatrixDraw function must be implemented. Whether the rest of the device specific functions may need to be implemented depends on the type of display device and application requirements. Also, the device driver programmer should be aware that the upper layers and examples of the DISPLAY device driver stack does not support all types of display devices and is continually being updated for new display devices. Therefore the upper layers and examples may need to be updated in order for existing software to work with a new display device driver.

We recommend to study the existing DISPLAY device driver(s). At the time of writing this text, there exists only one DISPLAY device driver for the Sharp Memory LCD (model LS013B7DH03) implemented in displayls013b7dh03.c/h.

When the DISPLAY_DeviceRegister function (declared in displaybackend.h) with a pointer to the DISPLAY_Device_t structure as parameter. This will make the display device available via the DISPLAY interface which is used by existing upper layer modules, examples and applications directly.

In order to automatically initialize the new display device driver from withing the DISPLAY_Init function, the driver initialization function can be added to the list of initialization functions in displayconfig.h:// Define all display device driver initialization functions here.

The displayconfig.h file should also include #define inclusion constants for the specific display device drivers included in the system. Typically there is only one display device, however some systems may add more than one display devices if present.

Additionally, we recommended to implement a platform abstraction layer in order to facilitate for easy porting of the display device driver between different hardware and software platforms. The displayls013b7dh03.c. And displaypalemlib.c implements the PAL functions on top of EMLIB. A new device driver may need additional hardware and software services and the displaypal.h can be extended to support any such device.

This section contains a description of the configuration interface of the DISPLAY device driver stack. The configuraion interface consists of a set of configuration files:One for each module in the DISPLAY device driver stack, where the platform default configurations are specified.

One for each application called displayconfigapp.h in which the user can specify application specific configurations and override defaults if desired.

Normally the application programmer just need to deal with the application specific configuration file displayconfigapp.h which typically should be minimalistic and easy to setup. Below is a list of the typical configuration parameters that the application programmer may need to relate to on a given platform/kit:

The rest of this section lists and describes the configuration parameters included in the module configuration files which are set to default values specific for the kit/platform. Each development kit from Silicon Labs that supports the DISPLAY Device driver stack includes a unique set of these configuration files in the kits/kit_name/config folder.

This function requests all DISPLAY device drivers to update their internal state with respect to system resource changes, like a bus clock frequency. This function may need to be called after system changes.

The 1.3" 168x144 SHARP Memory LCD display is a cross between an eInk (e-paper) display and an LCD. It has the ultra-low power usage of eInk and the fast-refresh rates of an LCD.

This model has a gray background, and pixels show up as black-on-gray for a nice e-reader type display. It does not have a backlight, but it is daylight readable. For dark/night reading you may need to illuminate the LCD area with external LEDs.

The bare display is 3V powered and 3V logic, so Adafruit placed it on a fully assembled & tested breakout board with a 3V regulator and level shifting circuitry. Now you can use it safely with 3 or 5V power and logic. The bare display slots into a ZIF socket on board and Adafruit use a piece of double-sided tape to adhere it onto one side. There are four mounting holes so you can easily attach it to a box.

The display is "write only" which means that it only needs 3 pins to send data. However, the downside of a write-only display is that the entire 168x144 bits (3 KB) must be buffered by the microcontroller driver. That means you cannot use this with an ATmega328 (e.g. Arduino UNO) or ATmega32u4 (Feather 32u4, etc). You must use a high-RAM chip such as ATSAMD21 (Feather M0), Teensy 3, ESP8266, ESP32, etc. On those chips, this display works great and looks wonderful.

Developed for Sharp to help test the memory LCD modules in your prototype, see the performance in real-time and check against your specifications and design. Our evaluation kit allows you to understand the final product better and further refine it for perfection.

I looked at this question as I too plan to drive a Sharp Memory LCD manually with my own code at some point. From your question and comments I think you are going about it the wrong way, even if you are already very proficient with the electronics side of the task.

Once you have a little bit of code running that displays what you want on the screen, try removing the breakout board and wiring the display yourself without changing the code at all. If the display is not what you expect, you know the problem is in the wiring so you don"t waste time looking into your code.

Once the wiring is sorted, start on the driver code. Leave the wiring and your code that makes the display show what you want untouched so that you know any problems are in your driver code. The other advantage of this is that you have the working library as reference for how the screen works and what signals to send with what sort of timing.

As a pointer to why your code is not doing what you expect, I think you may be misunderstanding how the screen works. Your question and code suggest you may be trying to display ASCII characters on the screen which I believe can be done easily with some LCD displays but I"m fairly sure that these LCDs are not character based - you have to manually set or clear each individual dot. I think the minimum number of dots you can set at a time is a full single line of the display.

This is a small (1.3 " x 1.1 ") breakout for Sharp"s LS013B7DH03 128 x 128 pixel Transmissive Memory LCD. This is also known as the memory display since the pixels persist on the display for many minutes as long as the display is powered. The display has the ultra-low power usage of eInk displays and the fast-refresh rates of an LCD. The power usage depends on the refresh rate and 1 Hz is sufficiently fast for most applications. In this case, the average power usage is less than 10 uA!

These are 3V3-only displays so will work with Teensys, ESP8266/85, ESP32, and the STM32L4 family of Arduino-programmable development boards in the Ladybug, Butterfly, and Dragonfly form factors. The displays will not work with the Arduino UNO or other 5 V boards without logic level translation.

Adafruit offers a similar (96 x 96 pixel) display using the LS013B4DN04 (now out of production) and a convenient library to run the displays. In order to make use of the library the pixel sizes have to be changed from 96 to 128, otherwise the library should work with no other modifications necessary. Here is more discussion of this. The 128 x 128 display is not covered with glass like the Adafruit version so it won"t like rough handling and could break if poked or jabbed (it is not a touch display!).

For low-power applications using the STM32L4 family of development boards, the USB can"t run when the cpu clock speed is less than 16 MHz or the STM32.stop mode is used. Both of these are critical to getting applications to run with average power usage in the ~100 uA range. Without access to the serial monitor to display data, what do you do? Well, these Sharp memory displays are the answer. The display is small and can be used in most applications by connecting 3V3, GND, MOSI, CLK, and #CS. This is a 3-wire SPI protocol (the display just receives data from the host) and several combinations of pins (but not all for some reason) can be used in a software SPI mode in addition to the usual hardware SPI ports. The display makes a convenient substitute for the serial port. I can get 15 lines of display of ~20 characters each so there is plenty of information available. The best part is the displays only require ~5 uA of power!

This is a small and inexpensive breakout that will allow you to add lots of data output easily using Adafruit"s fine graphics libraries. I have posted some example sketches where I make use of the Sharp display for data output; you will find it very easy to adapt the display controls to your own applications.

Order the pcb from OSH Park and assemble some of your own or order the fully assembled and tested board from me and see how useful a low-power, high-resolution display can be for your project!

The MSP-BNDL-FR5969LCD (MSP-EXP430FR5969 LaunchPad Evaluation Kit with 430BOOST-SHARP96 LCD Display BoosterPack) kit is an easy-to-use Evaluation Module for the MSP430FR5969 microcontroller. It contains everything needed to start developing on a MSP430 FRAM Technology platform, including on-board emulation ffor programming and debugging. The board features on-board buttons and LEDs for quick integration of a simple user interface as well as a SuperCap allowing standalone RTC operation without an external power supply.

The MSP-BNDL-FR5969LCD development platform is based on the first device in the MSP430 ULP FRAM platform – the MSP430FR5969 device. The MSP430FR5969 device features embedded FRAM, a non-volatile memory known for its low power, high endurance and high speed write access. The benefits of FRAM and the ultra-low power features of this kit can be used in a wide variety of applications ranging from metering and consumer electronics to unconventionally powered sensors.

enabling technologies such as wireless connectivity, graphical displays, environmental sensing, and much more. More information about the LaunchPad, supported BoosterPacks and available resources can be found at TI’s LaunchPad portal and the LaunchPad wiki for design resources and example projects.

The out-of-box experience provided with the MSP-BNDL-FR5969 uses the MSP-EXP430FR5969 LaunchPad and the 430BOOST-SHARP96 LCD BoosterPack. The display enables a better user experience and allows developers to more easily model their end application.

The MSP-EXP430FR5969 LaunchPad and 430BOOST-SHARP96 BoosterPack are available in a bundled package from the TI eStore, with part number MSP-BNDL-FR5969LCD. The MSP-EXP430FR5969 LaunchPad is not available standalone at this time.