SHARP Memory Display Booster Pack

[RafasS 0]

thanks @@chicken

[Deepak01 0]

Hello @@greeeg,

 

I have seen your contribution towards sharp lcd boosterpack..recently i have also purchased new sharp lcd and have my MSP430F5529 board...so i wanted to interface sharp oled with my board..can you please tell me modifications which i have to make in your analog watch code to get it executed on my msp board...

[greeeg 460]

Hello @@greeeg,

 

I have seen your contribution towards sharp lcd boosterpack..recently i have also purchased new sharp lcd and have my MSP430F5529 board...so i wanted to interface sharp oled with my board..can you please tell me modifications which i have to make in your analog watch code to get it executed on my msp board...

Hey @@Deepak01

 

From your message am I correct in assuming you want to run my sharp memory LCD code on a sharp OLED display?

 

Firstly you will need to confirm the pinouts of the oled display. If it required a parallel interface or a serial interface. Code should be written to transfer byte/word wise to the display.

 

Then the display will likely require initialization on startup. Something which memoryLCDs don't require. OLEDs usually have dozens of config registers for duty cycle, refresh rate, gamma, power control etc.

 

If your OLED is colour then you will need to adjust all the display functions, because they're are designed for B/W displays. If not then you might be able to reuse a little.

 

The internal screen buffer size will need to be adjusted to match your screen resolution, and finally the DMA settings will need to be adjusted to this new buffer size and to your interface method.

 

If this seems like a daunting task, it is. But don't be discouraged, OLEDs are beautiful to program with once up and running. You just have to take some time, get your feet wet with some low level things first

[Deepak01 0]

Hello @@greeeg,

 

I have made a mistake in my previous post,i do not want to interface sharp oled with msp board but I have to interface Sharp LCD BOOSTERPACK(http://www.ti.com/tool/430boost-sharp96) with msp430f5529 board....but since you have made analog watch code for msp430fr5969 board so i wanted to know suitable changes i have to make in your code to get it executed on my msp430f5529...

[Deepak01 0]

Hello @@greeeg,

 

I have certain changes with the connections   and also commented out 

this line

 

// these didn't like being implemeted in C

 

//__asm__("mov.w %1,%0": "=m" (DMA0SA) :"i" (_buffer));

//__asm__("mov.w %1,%0": "=m" (DMA0DA) :"i" (&USCIB0TX));

 

So my codes get compiled successfully but still not getting analog display on my LCD display...

 

Please help me out related to it...

[greeeg 460]

Hello @@greeeg,

 

I have made a mistake in my previous post,i do not want to interface sharp oled with msp board but I have to interface Sharp LCD BOOSTERPACK(http://www.ti.com/tool/430boost-sharp96) with msp430f5529 board....but since you have made analog watch code for msp430fr5969 board so i wanted to know suitable changes i have to make in your code to get it executed on my msp430f5529...

 

Ports will need to be changed. The F5529 doesn't have the LPM4.5 LOCK feature of the FR5969.

The frame buffer will need to be moved from ROM to RAM. The FR5969's FRAM enabled this to work, the F5529 can't support this.

 

 

Hello @@greeeg,

 

I have certain changes with the connections   and also commented out 

this line

 

// these didn't like being implemeted in C

 

//__asm__("mov.w %1,%0": "=m" (DMA0SA) :"i" (_buffer));

//__asm__("mov.w %1,%0": "=m" (DMA0DA) :"i" (&USCIB0TX));

 

So my codes get compiled successfully but still not getting analog display on my LCD display...

 

Please help me out related to it...

 

These 2 lines are essential to getting the code to work. they set the DMA source and destination addresses. The

DMA moves byte by byte from the frame buffer to the USCI TX buffer automagically after every byte has been transmitted.

 

These assembly snippets are required in gcc. if you're using the TI compiler from CCS you should try the macros that are described in their example code. I haven't tried these out.

__data16_write_addr((unsigned short) &DMA0SA,(unsigned long) &_buffer);
__data16_write_addr((unsigned short) &DMA0DA,(unsigned long) &USCIB0TX);  

Edit, I just tried recompiling, and turns out can just set the DMA registers now, atleast in the new msp-elf gcc.

DMA0SA = _buffer;
DMA0DA = &UCB0TXBUF;

[chicken 630]

Toggling VCOM in hardware (part 1)
 
Everyone who did in-depth experimentation with the SHARP Memory LCD probably remembers this tidbit from the datasheet:

VCOM Inversion
Periodic VCOM inversion impresses a periodic polarity inversion across the panel to keep a latent charge from building up within the Liquid Crystal cell. It can be implemented either through software or through hardware. In either implementation, the positive and negative inversion intervals should be kept as equal as possible, and intervals should not exceed one second.

 
Neglecting VCOM inversion never damaged my display, but according to the documentation, contrast is impacted by inversion.

VCOM inversion is easily implemented in software with a timer interrupt, but that complicates things, especially when one tries to create a simple-to-use library that supports multiple platforms. My own library relies on the user to either update the display at least once a second, or call a dedicated function to trigger VCOM inversion. The latter is not very beginner friendly.
 

VCOM inversion in hardware is done by wiggling the EXTCOMIN pin of the display. The different datasheet versions and sections are a bit contradictory, but the rough requirements are:

1. EXTMODE is tied to GND to enable hardware VCOM inversion
2. VCOM inversion is triggered by a pulse on EXTCOMIN
3. EXTCOMIN pulses have to occur at regular intervals < 1 second (some say 30-60 Hz, some 0.5-30 Hz, some "should not exceed 1 second", and "higher frequency = better contrast")
4. Minimum pulse width for EXTCOMIN is 2 us (some places say "the duty cycle of EXTCOMIN sould be 50%", but I think they mean the duty cycle of VCOM)

As said the datasheets are bit cryptic, but this chart makes pretty clear what is going on:

 

"555 to the rescue!", I thought. But low-power variants like the LMC555 consume 50-100 uA, and that's without the charge/discharge current for the capacitor. Compare that to the 2 uA typical (15 uA max) the SHARP datasheet specifies for displaying a static image.   
 
Enter the Marlow Thermo-Electric Generator (TEG).
 
Say what?!?
 
Well, back in August @@bluehash wrote on the 43oh blog about energy harvesting with a TEG and the related TI application note. The topic of energy harvesting is only mildly interesting to me, but the circuit featured a TPL5100 which was labeled as Nano Power Programmable Timer.
 
Aha!!

 

The TPL5100 is member of a small family of programmable timers which, hold on to your supercaps, consume 30-35 nA while twiddling their imaginary thumbs. Each IC features a different combination of

1. how the timer is programmed (resistor, 3-bit code) (DELAY)
2. what happens when time's up (toggle a pin low or high) (WAKE)
3. how to acknowledge that signal (DONE)
4. watchdog functionality that kicks in when WAKE is not acknowledged in time

The TPL5111 looks like the perfect fit for our purpose:

 

.. to be continued (getting late here.. more tomorrow)

[greeeg 460]

@chicken  Nice research. I always chuckle when people suggest using a 555. While still a handy IC if you have a uC running to keep a RTC alive then toggling a pin with a hardware timer adds ZERO* extra power draw.

 

I noticed on my sharp memory LCD projects that if I had the display inverted, (All black) there was a noticeable contract difference while the EXTCOMIN was toggling. However could not notice it when not inverted, but likely still there.

Incidentally I've just ordered some more displays for a new project, now that digikey stock them. Unrelated, have you seen the RGB model?

 

 

I assume you are going to all this effort so you can deep sleep your MCU?

 

*Not actually zero. but in the order of nA.

[chicken 630]

Hi @@greeeg

 

I don't have a specific low power project in mind. It just bothered me that I have to complicate my software with things that should have been solved in hardware.

 

On the power side, LPM3 is still in the range of 500nA (G2553), an order of magnitude higher than the TPL5111. But assuming that most projects in practice won't go below LPM2 (22 uA), that doesn't really matter. My goal is a hardware solution that adds less than 10% to the typical static power consumption of the display alone (2 uA).

 

And maybe TI will include it in future LaunchPads and BoosterPacks with LCD displays. It's a TI chip after all

 

Haven't seen the color version of the display yet. I've read that contrast and saturation are a bit weak.

[chicken 630]

Toggling VCOM in hardware (part 2)

 

So much for "more tomorrow"

 

This week turned out busier than expected. So a warning in advance: I didn't test this circuit in combination with the display yet.

 

With that out of the way, here's the circuit I came up with (2nd try, I first tried the TPL5010):

 

To power the TPL5111 I use the DISP signal, which is pulled high by the MCU to enable the display. This way the TPL5111 is only generating pulses when the display is in use. The MCU pin driving DISP should have more than enough grunt to provide the less than 1mA of current. I added a 0-ohm resistor for convenience to break the connection if needed, e.g. to measure current.

 

The 4.3K resistor R2 connected to DLY programs the timer interval. I picked the resistor value based on a table in the datasheet, going for an interval under 1 second (4K = 900ms according to the datasheet).

 

So now the DRVn line goes high after a bit more than 900ms. To turn off DRVn and therefore complete the pulse, we need to acknowledge by pulling DONE high. As the display's datasheet specifies a pulse width of at least 2us, this has to happen with a bit of delay.

 

That's what R3 and C4 are doing. When DRVn goes high, the capacitor C4 is "slowly" charged through resistor R3. When the voltage reaches the trigger for a logical high (at least 0.7 * VDD according to the TPL5111 datasheet, so about 2.3V at 3.3V supply voltage).

 

I already use 4.3K for R2 and 0.1uF somewhere else on the BoosterPack. Putting these numbers into a RC time constant calculator, I get 430 microseconds. By the definition of the time constant, this is the time it takes to charge to about 63%, which should get us close to 0.7 * VDD.

 

430us is way above the minimum pulse length of 2us, but good enough to for testing:

 

This test is done without connecting the display or an MCU. I connected DISP directly to regulated 3.3V.

 

The yellow trace is DRVn. The maximum voltage is only about 3.1V. The TPL5111 datasheet tells us on page 5, that the output DRVn can be up to 0.3V lower than VDD when driving 100uA of current. 3.1V through 4.3K of resistance draws about 720uA, so we're lucky with a drop of just 0.2V. What you can't see is, that the pulses occur at 1.1Hz, i.e. every 0.91 second.

 

The blue trace is the voltage on DONE. As expected it starts creeping upwards when DRVn turns on. When DONE reaches about 1.5V, DRVn turns off. This is quite a bit lower than expected (0.7 * 3.1V would be 2.2V). I guess the minimum spec in the datasheet means, that a 1 will be registered at 2.2V the latest. Anyways, the effective pulse width of DRVn is 250us, which is still plenty for our purpose.

 

To measure power consumption of this circuit, we have to look at two elements:

• current while waiting
• current during the pulse

To measure the current while waiting I dug out my Keithley 480 Picoammeter, which measured 37.4nA (0.037uA). Surprisingly close to the typical supply current of 35 nA as specified in the TPL5111 datasheet.

 

Unfortunately the pulse is too short to measure peak current with this instrument. So let's try to estimate the current. I postulate, that the current is dominated by the RC element. Looking at the calculation above, I expect to draw about 720uA through R3 when applying 3.1V to 4.3K.

 

And a bit more math to figure out the average current over a full cycle:

0.00025 s * 720 uA = 0.18 uAs (pulse of 250 microseconds at 720 uA)

0.91 s * 0.0374 uA = 0.034 uAs (0.91 seconds waiting for a pulse at 37.4 nA)

Total 0.214 uAs of energy (?) per cycle

Divided by total time (.91025), we get 235nA of average current.

 

This is pretty close to the stated goal of 10% of what the display alone draws (2uA). That number can be significantly lowered by picking a better RC combination for R3 and C4.

 

For example lowering C4 to 0.01uF theoretically shortens the pulse to 25us. Doing the same math exercise as above, I'd expect an average current of 57nA. That would be less than 3% of the display's power consumption.

 

I could also increase the resistor value to lower peak current, but that would increase the pulse length by the same factor, i.e. a 0-sum game. Still, lower peak current might be desirable in some cases. E.g. 43K resistor and 1nF cap gives a 25us pulse width at 72uA charge current, which pans out to 39nA average current.

 

Another thought is to increase the number of pulses, as some SHARP datasheets ask for more VCOM toggles than 1 per second. This would obviously increase the average current by roughly the same factor.

 

One thing I so far ignored is how much the display draws from DRVn during the pulse. So the real world numbers probably will be higher. Which is the next thing I will have to verify and write about (definitely not tomorrow ).

 

Edit: typos and grammer

[chicken 630]

PS: I just know enough EE to be dangerous. So better double check everything before relying on this approach.

[greeeg 460]

@@chicken You should be able to use a newer launchpad with the energy trace features. (or a FET430.) to measure the current!

That should have the bandwidth to show the current during the pulses.

 

Ironic that the RC circuit uses more current than the IC itself. You could daisy chain two TPL5111's to create a square wave 50% duty cycle pulse train right?

 

I understand this increases the BOM cost more than 1 RC pair, but if we're going for ULP....

[chicken 630]

@@greeeg Using the FET430 is my plan for the next installment.

 

I tried to implement DONE with an ultra low power flip-flop. But I couldn't get the logic to work, and the pulse length would have been hard to control..

[greeeg 460]

@@chicken

I'm interested in the design decision to add the RC feedback into done. From the sharp memory LCD I can see that they show pulses into EXTCOMIN, however since it appears that it's the rising edge that cases the VCOM inversion. They also don't specify a maximum pulse length...

 

The TPL5111, according to the datasheet will automatically de-assert the DRVn pin after 50ms. When in continuous mode. I can see that your RC circuit reduces this down by orders of magnitude, but also consumes a comparatively large amount of current.

 

If the system will work with a 50ms pulse length won't the current be reduced from an estimated 235nA back down to a constant 35nA?

[chicken 630]

@@greeeg that dawned on me during the write-up of part one. I made a note to do tests without R3 once I completed measurements in the current configuration.

 

PS: the RC approach is actually an artefact of the first design with the TPL5010, which would reset when DONE was missing.