SSD1306 OLED on a BS2p

TimC

Hi all,
After getting the slots figured out, I was able to find enough space to implement a dual color .96" OLED display.

The problem at the moment is a way to feed numeric variables to the display, because there is no Basic Stamp formatter to use via I2C.
Easiest way I can see so far is to pluck the numeric digits one by one and convert them to numeric characters?

Slot branching is a mess to deal with. Should take a few days to clean up the code.

Regards
Tim

Tracy Allen

Hi Tim,
If you are using one of the p series Stamps, the i2cIn and i2cOut instructions in PBASIC do in fact support the entire range of formatting options, same as for serial i/o.

TimC

Tracy,
The problem is you can't send ascii characters to the display. You have to send bits that represent the characters because there is no character generator inside the display. However you gave me an idea. We don't want to add hardware to a software problem but I don't think there is any other way. I could use an eeprom or ram chip to write formatted data via I2C then read the formatted data then pass again via I2C to the display. If there is a I2C clock or temperature sensor with some RAM that would be perfect because there would be a bonus for adding one more chip.
Tim

Tracy Allen

Oh, I see. I thought maybe your oled had a driver chip that supported ascii input, like the driver chips available for many character displays. Graphics are more complicated. How about adding a Propeller chip as your interface?!!

On my Stamp data loggers i used Atmel dataFlash memory for massive logging, and that would be sufficient to hold screen Images or the character generator. Or how about one slot of Stamp memory to hold a font? The Propeller 1 font coincIdentally occupies 2k of 8 bit memory. Just copy it over to a stamp. Best on a BS2pe with 16 slots available, 8 for data only.

TimC

Tracy,
The ssd1306 I am using is just the standard I2C ones you see all over for around $5. Using a Propeller chip to drive the display has already been done so I would not be helping there. In my code every character is 4 bytes in a table so a little less than 400bytes. There is enough memory to hold multiple fonts if I wanted, even on a smaller stamp.

I'm starting to make the changes so an I2C EEPROM chip can hold an Image of the display. So far I think this will make the app easier to use because XY positioning will be easier and numeric formatting possible. Maybe polling could be used to update the display? The less clunky RUN goto jumps the better.
Tim

TimC

I got stuck trying to make the run return any easier to use with all the labels it creates, however sharing in-slot subroutines works without too much bulk:

'=================clear oled=================================
SSD_Clear:   ' in-slot subroutine entry point
isSubroutine = isSubroutine + 1
_34SSD_Clear:    ' entry point from an out of slot call
#IF DebugMode #THEN DEBUG "Start SSD Clear.",CR #ENDIF
SSD_Column=0
FOR SSD_Row=0 TO 7
    GOSUB SSD_SetXY    ' we are now able to call multiple gosubs without loosing where we are
    FOR index=0 TO 127
       I2COUT SDA,SSD_Device,[SSD_DataCommand,0]   'Send 0 to every column in every line
    NEXT 'index
NEXT 'SSD_Row
SSD_Column=0 : SSD_Row=0 : GOSUB SSD_SetXY   ' Go to home position
GOTO SlotReturn   ' decides if we return to a different slot or return from sub

I am posting the version without the additional EEPROM pass through so others can take a look.

Tim