No announcement yet.

Issues Minimizing Power Consumption

  • Filter
  • Time
  • Show
Clear All
new posts

  • Issues Minimizing Power Consumption

    My project is an automotive digital multifunction gauge/clock. It is implemented with a PIC18F4520 talking to a uOLED-128-G1h display.

    When the car's key is off, I want to minimize the power consumption, so I power down the uOLED-128-G1h with a 59h, 03h, 00h string and put the PIC to sleep.

    When I bring the PIC back to life and power up the uOLED-128-G1h, strange things start happening to the display. In all cases when it gets flakey, Opaque mode is turned off, so my text overwrites whatever is on the screen. Sometimes it draws a purple arc across most of the screen and sometimes it draws a burnt orange semicircle.

    The only way I have been able to minimize the display power consumption and get it to work properly is to do the following sequence:

    Key off
    1. Turn the display off: 59h, 01h, 00h
    2. Power down the display: 59h, 03h, 00h
    3. Put the PIC to sleep
    Key on
    4. Wake up the PIC
    5. Power up the display: 59h, 03h, 01h
    6. Reset the display via a PIC output port
    7. Wait
    8. Send autobaud character
    9. Clear the display: 45h
    10. Set opaque mode: 4Fh

    Any variation from this sequence seems to result in flaky operation upon wakeup. This implies to me that there is a sequence I should be following when I power down and power up the uOLED-128-G1h.

    I have searched for a recommended power-down/power-up process and can't find anything.

    Can you tell me the best way to power down and power up the display?

    Thanks in advance.


  • #2

    That power down looks great.

    You are leaving the Goldelox chip 'running' this way, Have you tried the 'sleep' command to put it in low power as well?

    Have you tried the 'wake on serial' option of the sleep command?

    To wake in that case it is best to send autobaud until you get an ACK as the display will probably not wake up immediately, then wait to make sure you don't get another ACK, as if you just headed off after the first ACK that second ACK could cause all sorts of issues with your program later on.

    The bit above might explain the strange issues you are seeing.

    If you are going to reset the display using the reset line, then there's no need to send any sort of 'wakeup' before you do that.


    • #3

      I had not yet put the Goldelox chip to sleep yet. I was having trouble with just powering down the display, and didn't want to complicate it further.

      I followed your advice on powering down the Goldelox chip tonight and it is working great. It is interesting though. When I used the 80h mode, the display module would not come back to life with a hardware reset. When I used the 01h mode, the display came back after its reset, no problem.

      Thanks for your help.



      • #4

        Dont you mean

        "When I used the 80h mode, the display module needs a hardware reset to come back to life."


        That is expected and I thought you had the ability to give it a hardware reset with your "PIC output port".

        I've tried it here and it certainly works for me


        • #5

          I have a 1n4148 diode connected to an output port of the PIC processor and connected to the reset pin on the uOLED-128-G1h. To reset the uOLED-128-G1h, I pull that output low for 3mS.

          The reset works great for me if I use the Sleep command with 01h mode, but not with 80h mode.

          I found that to be pretty strange. Let me try it with the debugger to see where it is getting hung up.


          • #6

            I learned that, when I issue the Sleep command with 80h mode, I get stuck waiting for an ACK. If I issue a Sleep command with 01h mode, I get the ACK so the software can move on.

            Is it possible that the module doesn't send an ACK as it shuts down?



            • #7

              The ack is always sent at the 'completion' of the command, so when you user 0x01 the ACK woul come after the serial 'wakeup'.

              For 0x80 there would be no aparent ACK


              • #8

                That is interesting, by my experience seems to imply something different it happening.

                My code issues the command to the uOLED-128-G1h, then it starts a 50mS timer and starts waiting for an ACK. If it gets an ACK before the 50mS timeout, it moves on. If it gets a NAK before the 50mS timeout, it reissues the command and does it all over again. If the 50mS timer times out, it reissues the command and does it all over again. So the code will hang in an endless loop if it does not get an ACK within 50mS of the end of any command.

                Every command sent to the uOLED-128-G1h is handled this way.

                When I tell it to sleep in 01h mode, I must be getting an ACK prior to the actual sleep mode because the PIC is executing the code that checks for the key coming back on. It would not get to that point in the code if it didn't.

                Your description explains why my code hangs when I issue a Sleep command in 80h mode, but I can't figure out why my code works in 01h mode...

                Since I do a hardware reset to wake it back up, I guess I should use the 80h mode Sleep command and not wait for an ACK in that case only.




                • #9

                  I don't think there is any way you can get an ACK in 01h mode.

                  Maybe your controller is sending somthing that's waking up the display almost the instant it goes to sleep?

                  Maybe the ACK is for a previous command that somehow hasn't already been read?


                  • #10

                    I just ran it with the debugger again. My software will keep repeating a command until it receives an ACK. With the 05Ah command with an 01h mode byte, it definitely gets an ACK and moves on to put the PIC to sleep.

                    With the 05Ah command with an 80h mode byte, it definitely gets stuck in a loop trying to get an ACK, and it definitely does not get to the point in the code where the PIC is put to sleep.

                    I'm just reporting what I am seeing...


                    • #11

                      Dunno what to say.

                      Using FAT Controller I do not see a response.

                      I can also see from the code that nothing is sent until after the display wakes from sleep.


                      • #12

                        Must be my code then. I'll keep digging...