What LCD is used in the Pixl.js? Datasheet? OSHW?

Posted on
  • Hi everyone,

    Please excuse me if it's not polite to ask, but I wanted to find out more about the neat LCD that is used on the Pixl.js, e.g. pixel size, display dimensions, refresh rate, manufacturer, part number, datasheet?

    I assumed it was OSHW, but the SCH does not show the part number of the LCD:

    The Espruino code only mentions that an ST7567 controller is used.

    Thanks in advance,

  • Hi - it's the JHD12864-G176BSW - the part number is actually in the schematic if you open it in Eagle - it just isn't shown in the PDF.

    Datasheet attached - which should hopefully give you most of what you want :)

    1 Attachment

  • Wow, excellent support: super quick response and exactly what I wanted to know! Thanks for sharing :)

    Kind regards,

  • Hi,
    As a complement, I used the following code on the Pixl.js.
    It allows to switch On/Off the display thus saving the few uA it consumes.
    Unfortunatelly, I do not have an oscilloscope and can't measure the real reduction of power consumption, nor any short peak of power when switched on back from deep sleep.

    It is a very quick C++ to espruino translation and still contains unused constants... I was about to add this to the standard ST7565 module, when I understood that, indeed, the Pixl.js is using an integrated version probably in C++.

    The source github repo is mentionned in the comments.

    // handle lcd on/off deep sleep
    // extracted from 
    // https://github.com/boseji/Rpi-ST7565-SPI­-LCD/blob/master/lcdST7565.c#L729
    /* Commands    */
    BLACK 1
    WHITE 0
    var ST7565_LCD_CMD_DISPLAY_OFF = 0xAE;
    var ST7565_LCD_CMD_DISPLAY_ON = 0xAF;
    var ST7565_LCD_PARAM_BRIGHTNESS = 0x0;
    /* Unused constants from github
    ST7565_LCD_CMD_SET_PAGE  0xB0
    var ST7565_LCD_CMD_SET_ALLPTS_NORMAL = 0xA4;
    var ST7565_LCD_CMD_SET_ALLPTS_ON = 0xA5;
    /* Unused constants from github
    ST7565_LCD_CMD_SET_BIAS_9   0xA2
    ST7565_LCD_CMD_SET_BIAS_7   0xA3
    ST7565_LCD_CMD_RMW    0xE0
    var ST7565_LCD_CMD_INTERNAL_RESET = 0xE2;
    /* Unused constants from github
    var ST7565_LCD_CMD_SET_VOLUME_FIRST = 0x81;
    var ST7565_LCD_CMD_SET_VOLUME_SECOND = 0x0;
    var ST7565_LCD_CMD_SET_STATIC_OFF = 0xAC;
    var ST7565_LCD_CMD_SET_STATIC_ON = 0xAD;
    var ST7565_LCD_CMD_SET_STATIC_REG = 0x0;
    /* Unused constants from github
    ST7565_LCD_CMD_SET_BOOSTER_234 0
    ST7565_LCD_CMD_SET_BOOSTER_5   1
    ST7565_LCD_CMD_SET_BOOSTER_6   3
    ST7565_LCD_CMD_NOP    0xE3
    ST7565_LCD_CMD_TEST   0xF0
     *  Function to control the Contrast and brightness ratio
     *  - This is generally a fixed value for a given LCD.
    function lcd_bright ( bValue ) {
      retcode = 0;
      retcode = Pixl.lcdw(ST7565_LCD_CMD_SET_VOLUME_FIRS­T);
      if(retcode !== 0) return retcode;
      return Pixl.lcdw(ST7565_LCD_CMD_SET_VOLUME_SECO­ND | (bValue & 0x3f));
     * @brief Function to Put the LCD into Deep Sleep mode
    function lcd_sleep ( ){
      // * WORKS displays is wiped, so you have to g.flip() afterward
     * @brief Function to bring back the LCD from Deep Sleep mode
     * All display contents are cleared and need to reinitalize
    function lcd_wakeup ( ) {
      Pixl.lcdw(ST7565_LCD_CMD_SET_STATIC_REG | 0x03);
     * @brief Function to Put and wakup the LCD in Standby mode
     *   In this mode the display contents are not lost
     *   its only not visible
     * @param bWakeUp Used to decide that if we need to enter or exit standby
     *  0 - Enters into the Standby mode
     *  1 - Exits the Standby mode
    function lcd_standby ( bWakeUp ) {
      if (bWakeUp === 0) { /* Enter standby mode */
        Pixl.lcdw(ST7565_LCD_CMD_SET_STATIC_REG | 0x03);
      else { /* Wake from standby */
    var lcdstatus = 0;
    function lcdonoff() {
      if (lcdstatus === 0) lcdstatus = 1;
      else lcdstatus = 0;
    setWatch(lcdonoff,BTN1,{edge:"rising", debounce:50, repeat:true});
  • Nice, thanks! In a really strange coincidence I actually added a function to Pixl.js for this at almost the exact same time as your post! https://github.com/espruino/Espruino/com­mit/87f2ce3e035efb4166ee0dab7805058dc4c7­0ecf

    However it's really interesting that your code has the option to use ST7565_LCD_CMD_SET_STATIC_OFF to save a bit more power by not even having the LCD controller remember what was on it.

    That'd be a really good idea (as Espruino knows the display contents anyway), but I just did some tests and I'm actually struggling to see any difference with/without it.

    It'd be great if someone else could take a look though - it seems unlikely that it has no effect at all

  • I am limited by the Idd functionnality integrated in the 32l476discovery board which is, interestingly, a kind of self ranging ampmeter limited to 50nA - 50 mA at a rather slow rate (1-3 Hz)...
    It has already proven to be too averaging to be satisfying in short bursts of power and not replacing correctly an oscilloscope.

    About the deep sleep, I didn't cared to add the g.setRotate and g.flip(true) but it does work functionally!

    My motivation was to increase the 17 days of autonomy, with a no-name coin cell, by switching off the lcd on a time of day base!

    That brings me to some need about an RTC function surviving to resets and code uploads: The IDE offers the time and date automatic setup at code upload but that doesn't survive a reset() which is "illogical" as time never-ever flows back :)

  • Did you notice a difference between standby/sleep with your discovery board? I guess you could always just use a decent size capacitor on Pixl.js to even out any peaks in power draw?

    RTC function surviving to resets and code uploads

    It should survive code uploads and software reset? A hardware reset is tricky though - there's no backed up RAM on chip as far as I know, and no separate domain for the RTC so it's hard to work around. If all you care about is restoring time you could always do something like:

    var uploadTime = getTime();
    function onInit() {
  • Hi again,

    Edit: some partial conclusions:
    While beeing unable to measure some uA situations, I can infer from the figures below that:
    a- the "normal" power consumption when no code is beeing executed and display is ON is rather like 300 - 350 uA.
    b- switching off the display does save around 70 uA or 20 % from normal power consumption,
    c- going to deep sleep saves may be 130 - 140 uA or 40 % from normal power consumption,
    d- the Idd from the 32L476DISCOVERY is totally unappropriated to measure varying uAs as it switches from on range to another and interrupts power supply precisely at the amperages in normal power consumption mode with LCD OFF.

    Original post:
    So my measures are as follow:

    Display BLE uart Measure Comment
    ===== ======= ======= ========

    ON connected 570 uA figures are fluctuating ??? BLE UART influence ?
    OFF connected 500 uA figures are fluctuating ??? BLE UART influence ?
    deep sleep connected 430 uA figures are fluctuating ??? BLE UART influence ? Lower than OFF
    back ON connected 570 uA same as ON connected
    ON not connected 220 uA jumping between 200 and 590 possibly advertising effects, peaks at 890 uA
    OFF not connected 39 uA But reboots with no obvious reason!!! Self ranging ampmeter not switching correctly ????????
    deep sleep not connected 37 uA But reboots with no obvious reason!!! Self ranging ampmeter not switching correctly ????????
    back ON not connected ? uA Never clear display

    Interestingly, reconnecting the ble uart (web ide) OR booting from an usb power bank, does stop all reboots and gives back the same behaviour and figures... So it really seems that the multi meter approach of the 32L476DISCOVERY is in default with those power variations. Unfortunately, the code of this part of the board is not open source: you can not know how measures are by the integrated coprocessor.

    1 Attachment

  • Ok, I just stuck a Pixl on Nordic's power profiler, which seems to do a pretty good job. It definitely doesn't appear to have ranging issues, and it can average power consumption over a 7 second period (although readings do vary over time by maybe 5%).

    I did NRF.setConnectionInterval(200) which forces the device into 200ms connection interval, so I can stay connected while using about the same amount of power as when advertising (maybe just a smidge more).

    • Normal power consumption: 216uA
    • lcd_standby(0) - 66uA
    • lcd_standby(1) - back to normal, 216uA
    • lcd_sleep() - 65uA
    • LCD physically unplugged - ~60uA

    So it looks to me like the deep sleep doesn't really save you much over normal sleep at all, unless I'm missing something.

    Anyway, this is really good news - looks like Pixl.setLCDPower will do a pretty good job without even having to re-send the LCD contents.

    (on an unrelated note, I added a temperature alarm to my freezer. It turns out the DS18B20 temp sensors use about 4x more power than the whole Pixl if you leave them on!)

  • Hi,
    So I did get values around 192 uA - 230 uA while beeing connected, after an NRF.setLowPowerConnection(true) command , display ON and nothing beeing advertising except the Pixl's name.
    The fluctuation is probably due to not averaging a long time enough.
    Also, I got 50 uA with ldc off with some random reboots on other tries later.
    That said it's very comparable to your figures.
    So far NRF.setConnectionInterval(200) is not recognised on v1.99...

    So the good news is that we will have a very efficient way to save power on the next release.

  • on an unrelated note, I added a temperature alarm to my freezer. It turns out the DS18B20 temp sensors use about 4x more power than the whole Pixl if you leave them on!

    I guess it is time to replace the DS18B20 temp sensor implementation with something more power modern... same happened with all the bipolar and NMOS logic and mc chips from 50 years ago, when they got replaced with CMOS with pin and - almost also - signal compatibility 20+ years ago...

    my 'real' conclusion from this - time flies... swiftly... but still needs time do so!

  • Just a note - I discovered a bug in the firmware that leaves the UART RX pin connected as an input inside the chip.

    With that fixed (in 2v02 or cutting edge builds), power consumption with Pixl.setLCDPower(0);NRF.sleep() drops to 15uA.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

What LCD is used in the Pixl.js? Datasheet? OSHW?

Posted by Avatar for user93166 @user93166