I've reached another milestone in the development of my sleep mask: the OLED module works.
This section of the project was relatively straightforward: basically nothing more complicated than establishing a serial connection to the device and starting it up appropriately.
The Hardware
This is identical to my original design, which was, in turn, copied from the module datasheet. This is the same hardware as is sold by Adafruit Industries; I acquired mine from another source, without the breadboard-friendly PCB attached. It has an on-board capacitor charge pump to provide the high-voltage (~7.5V) necessary to drive the OLED pixels. The serial interface is identical to the Serial Peripheral Interface (SPI) with a Command/Data select line and a Reset line in addition to the usual Chip Select line.
The Software
The stripped-down testing firmware I used is posted here. It's not much to look at; it just starts up the SPI on-chip peripheral and sends the necessary command bytes (while manipulating the control lines appropriately) to start up and activate the display module. It then starts sending out data bytes to change what is shown on the display. The commands sent are outlined in the module controller's data sheet (the Solomon Systech SSD1306).
The controller continuously updates the pixels in the display by reading from an internal display memory. When data is written to the device, it is used to update the contents of this display memory.
The folks at Adafruit have also implemented some software to drive this display module. My software is largely the same, with one noticeable difference. The controller contains twice as much display memory as needed for the module (to make it capable of driving larger displays); when writing to this memory over the serial link, the memory is all written over in turn before restarting at the beginning. The Adafruit software just writes zeros onto that second half of the driver memory; however, there is a command which allows you to set the limits of the memory to be written. By setting this command to only write over the usable half of the memory, my software doesn't need to write the entire memory every time, only the half that is actually visible. In this way, I don't need to devote as much of my computational resources to updating the display.
The Goods
The test hardware setup is shown below. As usual, I used my oh-so-refined soldering and fabrication skills to gain access to the tiny pads on the end of the display's ribbon connector. The connections are relatively simple; a few decoupling caps between power pins to ground, some pass-throughs for the serial link, and the two capacitors for the charge pump.
To prove that I actually got this to work, here is a short video of the device (and ATXMEGA controller) as power is applied; first the display is told to turn all the pixels on, then it displays from the display memory (which is, initially, full of noise; this is in contrast with the data sheet, which states that the RAM should be blanked after a reset cycle). Then, the controller starts sending alternating frames of display data.
The firmware source containing the specification of the alphabet/symbols is here.
This section of the project was relatively straightforward: basically nothing more complicated than establishing a serial connection to the device and starting it up appropriately.
The Hardware
This is identical to my original design, which was, in turn, copied from the module datasheet. This is the same hardware as is sold by Adafruit Industries; I acquired mine from another source, without the breadboard-friendly PCB attached. It has an on-board capacitor charge pump to provide the high-voltage (~7.5V) necessary to drive the OLED pixels. The serial interface is identical to the Serial Peripheral Interface (SPI) with a Command/Data select line and a Reset line in addition to the usual Chip Select line.
The Software
The stripped-down testing firmware I used is posted here. It's not much to look at; it just starts up the SPI on-chip peripheral and sends the necessary command bytes (while manipulating the control lines appropriately) to start up and activate the display module. It then starts sending out data bytes to change what is shown on the display. The commands sent are outlined in the module controller's data sheet (the Solomon Systech SSD1306).
The controller continuously updates the pixels in the display by reading from an internal display memory. When data is written to the device, it is used to update the contents of this display memory.
The folks at Adafruit have also implemented some software to drive this display module. My software is largely the same, with one noticeable difference. The controller contains twice as much display memory as needed for the module (to make it capable of driving larger displays); when writing to this memory over the serial link, the memory is all written over in turn before restarting at the beginning. The Adafruit software just writes zeros onto that second half of the driver memory; however, there is a command which allows you to set the limits of the memory to be written. By setting this command to only write over the usable half of the memory, my software doesn't need to write the entire memory every time, only the half that is actually visible. In this way, I don't need to devote as much of my computational resources to updating the display.
The Goods
The test hardware setup is shown below. As usual, I used my oh-so-refined soldering and fabrication skills to gain access to the tiny pads on the end of the display's ribbon connector. The connections are relatively simple; a few decoupling caps between power pins to ground, some pass-throughs for the serial link, and the two capacitors for the charge pump.
To prove that I actually got this to work, here is a short video of the device (and ATXMEGA controller) as power is applied; first the display is told to turn all the pixels on, then it displays from the display memory (which is, initially, full of noise; this is in contrast with the data sheet, which states that the RAM should be blanked after a reset cycle). Then, the controller starts sending alternating frames of display data.
The firmware source containing the specification of the alphabet/symbols is here.
This comment has been removed by a blog administrator.
ReplyDelete