The keyword for this post is power management. Dealing with power management is complex work in hardware or software design. The algorithm of this Vanagon multi-function display has now becomes quite complex. There is a round robin multitasking in which the tasks has their independent cadence and conditional logic. Additionally there is timer interrupt driven polling of the joystick. Now I am adding power management features to manage the ability of soft-on and soft-off based upon the Vanagon's ignition, as well as the ability to use the data logger function independent of the Vanagon's ignition key position. I started to add the power management function when the flash memory is already at 95% capacity. The RAM is already at 70% capacity. Cutting it tight is an understatement.
I have been designing on the fly with this multi-function display project for the Westfalia Vanagon
camper. I have been learning about the programming language, the more in depth use of the architecture of this Atmel AtMega328 uC, and all these electronic modules while designing the hardware and software on the fly. One aspect of the design that I haven't given much thought is how would the multi-function display system power down and power up as would the normal vehicle instrument responding to the ignition key lock positions. There would not be a physical on/off power switch. Instead the instrument would be switched on whenever the ignition of the Vanagon is on, like the instrument cluster.
However, because of the data logging function, I want to be able to use the data logger independent of the ignition. For instance, if a data logging session is already in progress, it would not be interrupted when the ignition is switch off. With the ignition switched off, and no data logging is in progress, the system would enter sleep state with the display switched off. In this state, a user can wake it up by pressing the joystick once. Any functions of the data logger can be used without the need to switch on the ignition. The tasks supported includes:
- Remove the SD card to download files into a notebook computer.
- Insert a SD card.
- Start a data logging session.
- Stop a data logging session.
- Upload new code into the multi-function display (the entire system) to change data logging sensors.
- Put the system back into sleep state.
Using one or more of the uC's sleep mode is the answer. The Vanagon's ignition signal (+12V present when the key is at the ignition or starting positions) would be used by the uC as one of the signal to enter or exit sleep mode. When the ignition is off, and data logging is not in progress, the system would go into low power state and the display is "switched" off. However, it can be waken up by pressing the joystick button for data logging functions even if the ignition is off. That is my current idea of the implementation. There would be no need to turn on the ignition to manage the data logging functions - such as stopping a logging session and removing the SD card, and even invoking the OLED display. It would certainly be a challenge as I only have about 2k byte of flash memory left to carry this out.
I added a decimal place for the temperature display
soft-off is a bit like playing possum; not dead, but just pretend to, albeit in a low power state
With the addition of the ignition soft off of the display, and the ability to use the data logger both with ignition and without ignition the code increased the complexity and with it require more memory.. Many flags are added so the left hand would know what the right hand doing. For example when the ignition is switched off which wold put the display into a soft off (playing dead possum), I want to maintain the ability to switch on the display to begin or terminate data logging. Right now I am running dangerously close to exceeding the 32k flash for the code storage. I have to make some hard choices to reduce the complexity and hence the code size.
It is good that I have not begin to transfer all the loose bits on the solderless prototype board onto the data logger shield's breadboard area. I realize I need more passive discretes, a handful of schottkey diodes, and a Schemitt trigger inverter. The data logger feature is what make this project complex in both hardware and software, especially trying to pull this off on a Atmel AtMega328 based Arduino Uno. At this point, I have gotten the code to do what I envisioned, including the ability to use the data logger at will when the ignition is switched off. I also able to put it into sleep if done with the data logger. There are still some bugs, and I have not tested all the boundary cases. The best part is I have not broken the memory limits - though dangerously close:
Sketch uses 30,926 bytes (95%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,495 bytes (72%) of dynamic memory, leaving 553 bytes for local variables. Maximum is 2,048 bytes.
A few words about the implication of the program storage space (flash memory) and the dynamic memory. As long as the program does not exceed the 32k bytes flash memory limit I am golden. However with the Global variables consumption of the dynamic memory it is not that straightforward. As shown here of the 553 bytes left for local variables, what is not mentioned is the stack. It does not take a few nested function and interrupt calls to crash the stack.
Tonight I made significant progress in sorting out the two pin state change interrupts. One thing that had plagued me was the mistriggering of the data logger session as the same joystick press serves both to wake the system from sleep, as well as to initiate a new logging session. There is also switch bounce to contend with, which if not properly manage, can cause a large number of nested function calls and cause stack overflow. At the mean time I have to be very careful in adding more lines of code. Here are some current consumption figures at different operation mode:
during normal condition functioning as a multi-function display the current consumption is about 45mA
with the ignition switched off the system enters sleep the current consumption is about 23mA (a few mA are due to the LED and the USB interface chip on the Uno)
when function as a multi-function display and with the data logging in session the current consumption is about 73mA peak - only when writing to the micro SD card
In my implementation the system appears to be powered off when the Vanagon ignition is switched off. The current consumption is about 23mA. Most of this current is due to the overhead of the Uno being a development board. The USB interface contributes to some of this current. I do not want to have a physical power switch partly due to the data logging function.
here I set it up to log the temperature of the DC refrigerator just as a software test
No comments:
Post a Comment