Dual SSD1306 displays

WhiteSpace

Well-known member
Using two SSD1306 OLED displays is obviously entirely gratuitous, but just in case anyone else wants to do so, here are some suggestions, which I hope will save some time. At the moment it's just a proof of concept.

24531

The first step is to be able to change the i2c address of one of the displays. I don't know if there's a software method - the only method that I'm aware of (there's quite a lot of stuff on discussion boards for [cough] other microcontrollers) is to re-position one of the resistors on the back. Not all displays have the ability - I discovered that I have some with and some without. I found a pack of 4 displays online that showed a picture of the back. You can see the spot to look for at the top left of the two displays below, helpfully labelled "iic address select". The left hand display has the resistor in its default position, soldered across the two left hand contacts. On the right hand display, I de-soldered the resistor and soldered it across the right hand contacts. I've never soldered tiny surface mount components before - it was very fiddly but I got it done after a couple of tries, without burning the display.

24532

Once that's done, connect the two displays to the Picaxe.

The displays are then addressed, corresponding to the addresses shown on the back of the displays:

Rich (BB code):
'I2C addresses
Symbol LeftDisplay = $78
Symbol RightDisplay = $7A
The same Symbols can then be used for both displays. Each display will need its own setup instructions. Then the key thing to remember is that each time you want to start a set of instructions to a different display, you need to address it:

Rich (BB code):
hi2cout [LeftDisplay], (0)
gosub ClearDisplay

hi2cout [RightDisplay], (0)
gosub ClearDisplay
Subroutines can be specific to one or other display, or common to both, so in the example above the subroutines that hold the instructions for "Hello" and "World" are specific to left and right displays, but the subroutine that converts the characters into dots on the screens are common to both.

I attach the file - I hope it's useful as a starting point.
 

Attachments

mrm

Well-known member
Very Interesting.

The picaxe with the SSD1306 displays are certainly a great combination and can be driven by even the humble 08m2 or with the 14m2. The 14m2 being the ideal chip with its 512 byte table for the character bitmaps and 2 slots which allows the oled driver to sit in slot 1 and do the displaying with slot 0 fully available for the application. The only downside is the slow update rate for the screen particularly on the 08m2 where the bitmaps are held in lookups.

Have recently ported the 14m2 driver to the 28x2 to take advantage of the improved stability of the serial connection and its faster speed to remove the screen delay, there is seemingly nowhere convenient to hold the character bitmaps (80 x 5 byte ascii characters require 400 bytes) apart from the scratch pad memory which then has less space for the serial data. Reverting to the lookup method used with the 08m2 is a possibility and at the em64 speed setting gives a barely noticeable screen update delay but seems a step backwards.

Have you developed your oled driving on the 28x2 any further and perhaps solved the character bitmap memory issue?
 

AllyCat

Senior Member
Hi,

Yes, I believe I have largely "solved" the issue of bitmap storage in the 08M2 (and perhaps X2 family) by using the method described in THIS "Finished Project" THREAD. It can store around 80 characters in each KiloByte of Program Memory, and is very fast (for a PICaxe).

Its "problem" is that the character bitmaps cannot be "processed" by the PICaxe Program itself, i.e. for "Reversed" or Double-Height/Width, etc., because the data bytes are not directly "accessible" to the Program. One solution is to use another external I2C chip (a few "spare" bytes of Register/RAM is all that's needed) but particularly for the 08M2 I've been considering adding an I2C serial EEPROM such as the 24LC16 (which has a similar cost to the differential between an 08M2 and 14M2). Only the pins along one side of the DIP8 package need to be accessed, so the package could be mounted "vertically" like a SIL package, fitting immediately beside the 08M2 and taking little extra board space. Then there is ample space for multiple fonts and variations such as Double-Height, etc..

Also, reading the pixel bytes via the I2C bus is the fastest way that the PICaxes can access multiple data bytes: The speed of reading byte lists within the PICaxe is quite problematic and very often it is NOT intuitive. For example READ w1, WORD w2 or READ w1, b4, b5 or POKE w1, $12, $34 , etc. take more program space and are MUCH slower than you might expect. The LOOKUP instruction itself is not too slow, but it is by the time it's been enclosed in a Loop which has to be executed at least 5 times for a single character. :(

I've recently been planning to "revisit" my thread above, perhaps moving (just) the Numbers and a few related characters into the EPROM area (i.e. as data bytes), so that they can be processed to Double / Quadruple-Height, Double-Width / Character-Rounded (interpolated), or reversed, etc.. Also, to find the fastest way to recover the bytes from Table Memory in the other M2 chips, and to execute a Double-Height algorithm, which seems the most useful format for those particular displays.

Cheers, Alan.
 

mrm

Well-known member
Thank you for this very informative response.
Hi2cout seems very quick even on the 08m2 so that a graphic bitmap covering the full screen area and hardcoded across 5 hi2cout statements appears instantaneously whereas even two rows of characters are visibly written. It does not really matter for a display that shows a short data display which is incrementally updated at intervals greater than one second but it is quite distracting and the effect is probably more noticeable in peripheral vision so the screen catches the eye rather than waiting to be looked at.

So this solution is well worth trying and it is probably fairly quick and easy to adapt the 80 existing table statements to hi2cout's.

Having compared the 28x2 chip with the 08m2 or 14m2, the 28x2 hi2cout seems much quicker even for the same clock speed so the update flicker disappears but the 28x2 is quite a bulky animal with most of the pins going unused.

Another matter mentioned in your post for the hi2cout method of character display is an application utilising a rtc clock.
Does some precanned code exist somewhere in the forum for rtc clock setting?
It is easily done using a loop that cycles through all the fields and uses one or two buttons or just one button and different clicks to control the flow but there may be a more space efficient solution out there already. Also the picaxe inbuilt button function handles repeating clicks but does not play well with code to detect short, long or double clicks if only one button is used.
 

AllyCat

Senior Member
Hi,

I can't comment on the relative speed of X2 chips versus M2's because I've never measured any X2 chips, and perhaps they have a faster architecture for some commands (e.g. by using interrupts). But I must warn against making "assumptions" about which commands might be "expected" to be faster with any PICaxe. I've actually measured many typical commands and structures, but often an "indication" can be obtained from the number of bytes created by the Compiler (i.e. by performing a Syntax Check), because every byte introduces a significant Interpreter delay. For example READTABLE w1, b4, b5 (or WORD w2) compiles to more bytes than READTABLE w1, b4 : INC w1 : READTABLE w1, b5 and executes more slowly ! The reason is because only a few of the "list" type of instructions are executed "automatically" within the interpreter, whilst others are "Macros" created (sometimes non-optimally) by the Program Editor / Compiler (and can be up to ten times slower).

Yes, there are several examples of RTC code in the CODE SNIPPETS section of the forum, for example by "marks". The Dallas DS1307 has an advantage of containing some spare NV RAM but it's been superceded by the vastly superior DS3231 (that does NOT contain any spare RAM) which is available in "breakout" modules of tiny dimensions (e.g. "DS3231 for Pi"), or with an additional serial EEPROM. I also used the Microchip MCP7940 which does include some internal RAM, but seemed to have a few "gotchas" in it's setup, and I don't think I've posted any code for it.

Cheers, Alan.
 
  • Like
Reactions: mrm

mrm

Well-known member
Thanks for all this additional info.

I am still processing and testing your character drawing example. In fact font doubling is not really required so the initial idea is to replace the existing lookup or table based font bitmaps and select case loop for mapping ascii characters to bitmap locations with the on goto structure and hi2cout statements directly to the oled display and see if there is improvement.

In previous work I had avoided keeping fonts in external eeprom thinking that a read from eeprom and then a write to the oled would slow things up.

I will then visit the RTC code. I am using an RV-1805 RTC which also has some NVRAM for storage. My own code seems to work well enough but seems to take up too much memory space and there are fiddly bits of code to handle time and date rollovers when setting the time/date where there are probably better solutions. The project is currently at 3020 bytes and intended as a watchdog over another system so the real work of watchdogging still needs to be fitted in to the remaining space. If the rtc setting routines cannot be compacted then they could be run in another slot.

You obviously have deep experience of picaxe systems but on the few occasions I have used them for real world work they seem to be very reliable which is unexpected for something using interpreted basic code. The annoyingly slow oled display with a piggybacked 14m2 has been running quite happily for over a year embedded in an 230V AC junction box and provided the oled is reinitialised periodically to remove screen artefacts from electrical noise the picaxe driven system has proved far more stable than the pumping system it is monitoring. Outdoors a 08M2 has been faithfully monitoring water levels for over a year on an AA sized 3V lithium battery that has only needed recharging once.
 

WhiteSpace

Well-known member
Have you developed your oled driving on the 28x2 any further and perhaps solved the character bitmap memory issue?
@mrm no, I haven't done much more with this particular project - 2 OLEDs from a single Picaxe - although I have been working on a couple more projects using a single OLED. They include one using an OLED to display a temperature: https://picaxeforum.co.uk/threads/ds18b20-displaying-on-128-x-32-ssd1306-oled-with-08m2.32048/ This is a very simple project using an 08M2, where the double height digits, degree symbol, decimal point and "C" are stored as individual subroutines, and another using a 28x2 to display scan data, displaying x,y coordinates transmitted from another Picaxe as individual pixels on the OLED. There's a video here: https://picaxeforum.co.uk/threads/scanning-tof10120-with-output-to-oled.32283/ At the moment it's also displaying dummy motor data (current and voltage) and I'm in the process of writing the code to send the actual motor data from a remote vehicle. That uses a combination of subroutines to write the x,y position and scratchpad to store the characters for the motor data. The 28x2 generally drives the screen very quickly, particularly when set to em64. On the scan project, it currently refreshes every 3 or 4 seconds or so, but that is determined by the scan speed on the vehicle, not by the OLED or receiving Picaxe speeds, I think. I haven't tried anything other than scratchpad for holding the characters on the 28x2.
 

mrm

Well-known member
@mrm no, I haven't done much more with this particular project - 2 OLEDs from a single Picaxe - although I have been working on a couple more projects using a single OLED. They include one using an OLED to display a temperature: https://picaxeforum.co.uk/threads/ds18b20-displaying-on-128-x-32-ssd1306-oled-with-08m2.32048/ This is a very simple project using an 08M2, where the double height digits, degree symbol, decimal point and "C" are stored as individual subroutines, and another using a 28x2 to display scan data, displaying x,y coordinates transmitted from another Picaxe as individual pixels on the OLED. There's a video here: https://picaxeforum.co.uk/threads/scanning-tof10120-with-output-to-oled.32283/ At the moment it's also displaying dummy motor data (current and voltage) and I'm in the process of writing the code to send the actual motor data from a remote vehicle. That uses a combination of subroutines to write the x,y position and scratchpad to store the characters for the motor data. The 28x2 generally drives the screen very quickly, particularly when set to em64. On the scan project, it currently refreshes every 3 or 4 seconds or so, but that is determined by the scan speed on the vehicle, not by the OLED or receiving Picaxe speeds, I think. I haven't tried anything other than scratchpad for holding the characters on the 28x2.
Ok thenks for the response and also the links to related projects which look interesting.
 
Top