Update 2015-09-10: I also added a timer 2 based version of the driver which does not need any manual refresh.
I created a fast and compact driver for the Sharp memory display LS013B4DN04. The driver is text based and uses 8×8 pixel characters on the screen. The screen can display 12×12 characters using this size of characters.
This demo is an example of the Arduino library.
Uses only 174 bytes of dynamic memory.
Refreshes only changed rows on the screen.
This speeds up the refresh process and makes the refresh method suitable to call it from an interrupt.
Each character on the screen can be displayed normal or inverted. Ideal to mark a row in a menu.
Fonts can provide up to 128 characters. The font can be changed at any time.
Minimal but complete API with direct character access, cursor based write methods and scrolling of the display in four directions.
Update 2015-09-05: Added a example font and Adobe Photoshop template.
Currently I am working on the deluxe version of the data logger. This version has a LCD screen and capacitive buttons to control the software. The Adafruit library for the display is quite large and almost uses the whole RAM, because it is a pixel oriented library. My own implementation is a text only library using 8×8 pixel characters. This simplify everything and reduces the RAM costs.
To convert the bitmap font into bytes, I wrote a small application for OS X (minimum version 10.10). It accepts a PNG image with the characters in it and converts it into bytes with the correct bits set.
First you select the mode on the left side of the application window. In this example the mode is set to “8×8 Fixed Top-Down”. Select the output format in the bottom left corner of the window.
Now drag your font file onto the area on the right side. If the dragged file is accepted, the window turns blue.
After fixing the timing problem with the sensor library, I started the data logger and recorded data in 10 seconds intervals until the memory was full. This time the AM2302 (DHT22) sensor was read every time, no cached values were used.
It created a really interesting data set you can see in the diagram below (click on the diagram to see all details):
The actual measured data values are the small dots in the background, and the lines are polynomial interpolated over these values.
For the temperature (blue) you can see the sensor precision limit of 0.1 and an interesting jitter when the value makes the transition from one value to another. In contrast, the humidity values (orange) do not have the same jitter like the temperature values, but you can see something strange at the crossing point of the two series.
I created a new diagram where you can see this point in detail:
The jitter of the humidity values is minimal, but suddenly there are huge jumps of the values. Compare the jumps with the corresponding temperature values. Because the humidity value depends on the temperature, the jitter from the temperature causes the humidity values to jump.
The test was successful: There is now real sensor data for each measurement.
If this sensor is used for a real time display of humidity and temperature values, there has to be some integrated interpolation to flatten the jitter of the read values. This is no big deal for the data logger, because you can easily do all the corrections and interpolations afterwards.
You can download the CSV file with the measurements and the Excel sheet I used with the links below: