SSD1306 OLED driver

SSD1306 OLED driver

[Ssagarr Patil]

Hi,

I have the SSD1306 oled device connected via spi, will the same driver work ? as the current one is based on i2c what all mods would be required to have it working with SPI ?

Thanks & Regards,
Sagar 
 		 	   		  

Re: SSD1306 OLED driver

[maxime.ripard]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

Hi,

On Fri, Nov 14, 2014 at 05:09:09PM +0530, Ssagarr Patil wrote:
> Hi,
> 
> I have the SSD1306 oled device connected via spi, will the same
> driver work ? as the current one is based on i2c what all mods would
> be required to have it working with SPI ?

It won't work out of the box, but it should be fairly easy to support.

You need to had support for SPI probing, and then provide some generic
accessors the rest of the code can use to wrap around the i2c and spi
calls.

I'm not sure regmap can be used for this, but this would be something
worth looking into to do that.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Maxime,

>
> On Fri, Nov 14, 2014 at 05:09:09PM +0530, Ssagarr Patil wrote:
>> Hi,
>>
>> I have the SSD1306 oled device connected via spi, will the same
>> driver work ? as the current one is based on i2c what all mods would
>> be required to have it working with SPI ?
>
> It won't work out of the box, but it should be fairly easy to support.
>
> You need to had support for SPI probing, and then provide some generic
> accessors the rest of the code can use to wrap around the i2c and spi
> calls.
>
> I'm not sure regmap can be used for this, but this would be something
> worth looking into to do that.
>
Thanks for the inputs :)

Does the driver work as a standard fbdev driver, is there any library on top
of it to ease the user space ?

Thanks & Regards,
--Sagar
 		 	   		  

Re: SSD1306 OLED driver

[maxime.ripard]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Tue, Nov 18, 2014 at 08:29:51PM +0530, Ssagarr Patil wrote:
> Hi Maxime,
> 
> >
> > On Fri, Nov 14, 2014 at 05:09:09PM +0530, Ssagarr Patil wrote:
> >> Hi,
> >>
> >> I have the SSD1306 oled device connected via spi, will the same
> >> driver work ? as the current one is based on i2c what all mods would
> >> be required to have it working with SPI ?
> >
> > It won't work out of the box, but it should be fairly easy to support.
> >
> > You need to had support for SPI probing, and then provide some generic
> > accessors the rest of the code can use to wrap around the i2c and spi
> > calls.
> >
> > I'm not sure regmap can be used for this, but this would be something
> > worth looking into to do that.
> >
> Thanks for the inputs :)
> 
> Does the driver work as a standard fbdev driver, is there any library on top
> of it to ease the user space ?

It exposes a monochrome fbdev, so the usual framebuffer tools and
libraries are supposed to work quite well, provided they've been
written to handle monochrome displays.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Maxime,

>
> On Fri, Nov 14, 2014 at 05:09:09PM +0530, Ssagarr Patil wrote:
>> Hi,
>>
>> I have the SSD1306 oled device connected via spi, will the same
>> driver work ? as the current one is based on i2c what all mods would
>> be required to have it working with SPI ?
>
> It won't work out of the box, but it should be fairly easy to support.
>
> You need to had support for SPI probing, and then provide some generic
> accessors the rest of the code can use to wrap around the i2c and spi
> calls.
>
I have done the spi probing stuff, now only stuck with changing this to SPI calls,

static int ssd1307fb_write_array(struct i2c_client *client,
                 struct ssd1307fb_array *array, u32 len)
{
    int ret;

    len += sizeof(struct ssd1307fb_array);

    ret = i2c_master_send(client, (u8 *)array, len);
    if (ret != len) {
        dev_err(&client->dev, "Couldn't send I2C command.\n");
        return ret;
    }

    return 0;
}

Any help on this would be appreciated!

Thanks,
Sagar
 		 	   		  

Re: SSD1306 OLED driver

[maxime.ripard]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

On Mon, Jan 05, 2015 at 04:33:22PM +0530, Ssagarr Patil wrote:
> Hi Maxime,
> 
> >
> > On Fri, Nov 14, 2014 at 05:09:09PM +0530, Ssagarr Patil wrote:
> >> Hi,
> >>
> >> I have the SSD1306 oled device connected via spi, will the same
> >> driver work ? as the current one is based on i2c what all mods would
> >> be required to have it working with SPI ?
> >
> > It won't work out of the box, but it should be fairly easy to support.
> >
> > You need to had support for SPI probing, and then provide some generic
> > accessors the rest of the code can use to wrap around the i2c and spi
> > calls.
> >
> I have done the spi probing stuff, now only stuck with changing this to SPI calls,
> 
> static int ssd1307fb_write_array(struct i2c_client *client,
>                  struct ssd1307fb_array *array, u32 len)
> {
>     int ret;
> 
>     len += sizeof(struct ssd1307fb_array);
> 
>     ret = i2c_master_send(client, (u8 *)array, len);
>     if (ret != len) {
>         dev_err(&client->dev, "Couldn't send I2C command.\n");
>         return ret;
>     }
> 
>     return 0;
> }
> 
> Any help on this would be appreciated!

I'm not sure what help you are expecting.

This is a simple function that takes an array and sends it over I2C.

It's probably even easier with SPI. Have you considered reading
include/spi/spi.h?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Maxime,

>>>
>>> You need to had support for SPI probing, and then provide some generic
>>> accessors the rest of the code can use to wrap around the i2c and spi
>>> calls.
>>>
>> I have done the spi probing stuff, now only stuck with changing this to SPI calls,
>>
>> static int ssd1307fb_write_array(struct i2c_client *client,
>>                  struct ssd1307fb_array *array, u32 len)
>> {
>>     int ret;
>>
>>     len += sizeof(struct ssd1307fb_array);
>>
>>     ret = i2c_master_send(client, (u8 *)array, len);
>>     if (ret != len) {
>>         dev_err(&client->dev, "Couldn't send I2C command.\n");
>>         return ret;
>>     }
>>
>>     return 0;
>> }
>>
>> Any help on this would be appreciated!
>
> I'm not sure what help you are expecting.
>
> This is a simple function that takes an array and sends it over I2C.
>
> It's probably even easier with SPI. Have you considered reading
> include/spi/spi.h?
>
Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?

Thanks & Regards,
--Sagar
 		 	   		  

Re: SSD1306 OLED driver

[maxime.ripard]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

On Tue, Jan 06, 2015 at 06:30:01PM +0530, Ssagarr Patil wrote:
> > It's probably even easier with SPI. Have you considered reading
> > include/spi/spi.h?
> >
> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?

You can't use it like that. It's a standard framebuffer, that is
represented as an array of pixels, so you need to use a font rendering
software if you want to output some text.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Maxim,

>>>
>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
>
> You can't use it like that. It's a standard framebuffer, that is
> represented as an array of pixels, so you need to use a font rendering
> software if you want to output some text.
>
can fbtest (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/) be used to to draw something ?

Thanks And Regards,
Sagar
 		 	   		  

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Maxime,

>>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
>>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
>>
>> You can't use it like that. It's a standard framebuffer, that is
>> represented as an array of pixels, so you need to use a font rendering
>> software if you want to output some text.
>>
> can fbtest (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/) be used to to draw something ?
>
how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.

Thanks And Regards,
Sagar

 		 	   		  

Re: SSD1306 OLED driver

[maxime.ripard]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Fri, Jan 09, 2015 at 03:45:01PM +0530, Ssagarr Patil wrote:
> 
> Hi Maxime,
> 
> >>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
> >>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
> >>
> >> You can't use it like that. It's a standard framebuffer, that is
> >> represented as an array of pixels, so you need to use a font rendering
> >> software if you want to output some text.
> >>
> > can fbtest
> > (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
> > be used to to draw something ?
> >
> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.

Last time I tried, fbtest didn't support monochrome display.

And you'll find anything you need in the documentation.
https://www.kernel.org/doc/Documentation/fb/framebuffer.txt

> 
> Thanks And Regards,
> Sagar
> 
>  		 	   		  

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Maxime,

Thanks for your response!

> On Fri, Jan 09, 2015 at 03:45:01PM +0530, Ssagarr Patil wrote:
>>
>> Hi Maxime,
>>
>>>>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
>>>>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
>>>>
>>>> You can't use it like that. It's a standard framebuffer, that is
>>>> represented as an array of pixels, so you need to use a font rendering
>>>> software if you want to output some text.
>>>>
>>> can fbtest
>>> (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
>>> be used to to draw something ?
>>>
>> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
>
> Last time I tried, fbtest didn't support monochrome display.
>
> And you'll find anything you need in the documentation.
> https://www.kernel.org/doc/Documentation/fb/framebuffer.txt
>
In my case I see that init is done but I dont see any pixels on the screen at all.
I am now concerned if the driver was tested in first place ?

Thanks And Regards,
Sagar

 		 	   		  

Re: SSD1306 OLED driver

[Geert Uytterhoeven]

Hi Maxime,

On Fri, Jan 9, 2015 at 12:03 PM, maxime.ripard@free-electrons.com
<maxime.ripard@free-electrons.com> wrote:
>> > can fbtest
>> > (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
>> > be used to to draw something ?
>> >
>> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
>
> Last time I tried, fbtest didn't support monochrome display.

Really?

On ARAnyM:

atari:~# fbset -i

mode "640x480-60"
    # D: 25.176 MHz, H: 31.470 kHz, V: 59.943 Hz
    geometry 640 480 640 972 1
    timings 39720 42 18 31 11 100 3
    rgba 1/0,1/0,1/0,0/0
endmode

Frame buffer device information:
    Name        : Atari Builtin
    Address     : 0x67a000
    Size        : 311296
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 32
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 80
    Accelerator : Atari Blitter
atari:~# ./m68k-linux-gnu-fbtest
Using drawops planar (monochrome and (interleaved) bitplanes)
Available visuals:
  Monochrome
  Grayscale 2
  Pseudocolor 2
Using visops pseudocolor
Running all tests
test001: PASSED
test002: PASSED
test004: PASSED
test005: PASSED
test006: PASSED
test009: PASSED
test011: PASSED
Benchmarking... 10x10 squares: 17.25 Mpixels/s
Benchmarking... 20x20 squares: 40.96 Mpixels/s
Benchmarking... 50x50 squares: 102.41 Mpixels/s
Benchmarking... 100x100 squares: 195.06 Mpixels/s
Benchmarking... 200x200 squares: 348.61 Mpixels/s
Benchmarking... 500x500 squares: 742.07 Mpixels/s
test012: PASSED
Benchmarking... triangles of max size 10: 139444.38 triangles/s
Benchmarking... triangles of max size 20: 107443.29 triangles/s
Benchmarking... triangles of max size 50: 71237.96 triangles/s
Benchmarking... triangles of max size 100: 40962.10 triangles/s
Benchmarking... triangles of max size 200: 23407.09 triangles/s
Benchmarking... triangles of max size 500: 9102.64 triangles/s
test013: PASSED
atari:~#

And the result did look good ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: SSD1306 OLED driver

[maxime.ripard]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

On Fri, Jan 09, 2015 at 02:58:16PM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Fri, Jan 9, 2015 at 12:03 PM, maxime.ripard@free-electrons.com
> <maxime.ripard@free-electrons.com> wrote:
> >> > can fbtest
> >> > (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
> >> > be used to to draw something ?
> >> >
> >> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
> >
> > Last time I tried, fbtest didn't support monochrome display.
> 
> Really?
> 
> On ARAnyM:
> 
> atari:~# fbset -i
> 
> mode "640x480-60"
>     # D: 25.176 MHz, H: 31.470 kHz, V: 59.943 Hz
>     geometry 640 480 640 972 1
>     timings 39720 42 18 31 11 100 3
>     rgba 1/0,1/0,1/0,0/0
> endmode
> 
> Frame buffer device information:
>     Name        : Atari Builtin
>     Address     : 0x67a000
>     Size        : 311296
>     Type        : PACKED PIXELS
>     Visual      : PSEUDOCOLOR
>     XPanStep    : 32
>     YPanStep    : 1
>     YWrapStep   : 0
>     LineLength  : 80
>     Accelerator : Atari Blitter
> atari:~# ./m68k-linux-gnu-fbtest
> Using drawops planar (monochrome and (interleaved) bitplanes)
> Available visuals:
>   Monochrome
>   Grayscale 2
>   Pseudocolor 2
> Using visops pseudocolor
> Running all tests
> test001: PASSED
> test002: PASSED
> test004: PASSED
> test005: PASSED
> test006: PASSED
> test009: PASSED
> test011: PASSED
> Benchmarking... 10x10 squares: 17.25 Mpixels/s
> Benchmarking... 20x20 squares: 40.96 Mpixels/s
> Benchmarking... 50x50 squares: 102.41 Mpixels/s
> Benchmarking... 100x100 squares: 195.06 Mpixels/s
> Benchmarking... 200x200 squares: 348.61 Mpixels/s
> Benchmarking... 500x500 squares: 742.07 Mpixels/s
> test012: PASSED
> Benchmarking... triangles of max size 10: 139444.38 triangles/s
> Benchmarking... triangles of max size 20: 107443.29 triangles/s
> Benchmarking... triangles of max size 50: 71237.96 triangles/s
> Benchmarking... triangles of max size 100: 40962.10 triangles/s
> Benchmarking... triangles of max size 200: 23407.09 triangles/s
> Benchmarking... triangles of max size 500: 9102.64 triangles/s
> test013: PASSED
> atari:~#
> 
> And the result did look good ;-)

Ah, good to know :)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: SSD1306 OLED driver

[maxime.ripard]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

On Fri, Jan 09, 2015 at 06:13:43PM +0530, Ssagarr Patil wrote:
> Hi Maxime,
> 
> Thanks for your response!
> 
> > On Fri, Jan 09, 2015 at 03:45:01PM +0530, Ssagarr Patil wrote:
> >>
> >> Hi Maxime,
> >>
> >>>>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
> >>>>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
> >>>>
> >>>> You can't use it like that. It's a standard framebuffer, that is
> >>>> represented as an array of pixels, so you need to use a font rendering
> >>>> software if you want to output some text.
> >>>>
> >>> can fbtest
> >>> (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
> >>> be used to to draw something ?
> >>>
> >> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
> >
> > Last time I tried, fbtest didn't support monochrome display.
> >
> > And you'll find anything you need in the documentation.
> > https://www.kernel.org/doc/Documentation/fb/framebuffer.txt
> >
>
> In my case I see that init is done but I dont see any pixels on the
> screen at all.
>
> I am now concerned if the driver was tested in first place ?

No. I just submitted some good looking code that never ever got
tested.

More seriously, There's a few thing that comes to my mind:
  - Your controller doesn't behave the same way than the ones already
    supported.
  - You haven't posted your changes yet, so maybe you're not doing the
    transfers right
  - Your SPI controller is doing something weird

What happens if you plug a logical analyzer on the bus?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: SSD1306 OLED driver

[Noralf Tronnes]

Den 09.01.2015 23:31, skrev maxime.ripard@free-electrons.com:
> On Fri, Jan 09, 2015 at 06:13:43PM +0530, Ssagarr Patil wrote:
>> Hi Maxime,
>>
>> Thanks for your response!
>>
>>> On Fri, Jan 09, 2015 at 03:45:01PM +0530, Ssagarr Patil wrote:
>>>> Hi Maxime,
>>>>
>>>>>>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
>>>>>>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
>>>>>> You can't use it like that. It's a standard framebuffer, that is
>>>>>> represented as an array of pixels, so you need to use a font rendering
>>>>>> software if you want to output some text.
>>>>>>
>>>>> can fbtest
>>>>> (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
>>>>> be used to to draw something ?
>>>>>
>>>> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
>>> Last time I tried, fbtest didn't support monochrome display.
>>>
>>> And you'll find anything you need in the documentation.
>>> https://www.kernel.org/doc/Documentation/fb/framebuffer.txt
>>>
>> In my case I see that init is done but I dont see any pixels on the
>> screen at all.
>>
>> I am now concerned if the driver was tested in first place ?
> No. I just submitted some good looking code that never ever got
> tested.
>
> More seriously, There's a few thing that comes to my mind:
>    - Your controller doesn't behave the same way than the ones already
>      supported.
>    - You haven't posted your changes yet, so maybe you're not doing the
>      transfers right
>    - Your SPI controller is doing something weird
>
> What happens if you plug a logical analyzer on the bus?
>
> Maxime
>
Hi,

The major difference between the SSD1306 SPI and I2C interfaces, is that 
SPI uses a D/C pin to signal whether it's data or command coming in.
Looking at ssd1307fb, this Data/Command info is embedded as the first 
byte in the i2c package/message.
Without looking up the datasheet, I would guess that this is the only 
difference, the way the D/C bit is handled.
The rest of the package payload should be the same.
So:
dc=0, spi write command
dc=1, spi write data (optional)


Apart from that, I have SSD1306 SPI support in a project of mine:

This is the part writing the framebuffer: 
https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
This writes commands (for many controllers): 
https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
This is the SPI specific part: 
https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
Project wiki: https://github.com/notro/fbtft/wiki

The code isn't particularly pretty, it was my first venture into the kernel.
It has recently been submitted for the staging tree: 
https://github.com/notro/fbtft/issues/161#issuecomment-68431405

I'm currently rewriting the project armed with better knowledge of the 
kernel and the various LCD controllers.
I haven't done the SSD1306 controller yet, but the principle is almost 
the same for all these MIPI DBI like controllers.
The major difference is that it's monochrome and has a different 
register map.
In my rewrite I have made an abstraction for the LCD register: 
https://github.com/notro/fbdbi/blob/master/core/lcdreg.h#L46
SPI part matching several controller variations: 
https://github.com/notro/fbdbi/blob/master/core/lcdreg-spi.c

In case you wonder: In my code I set the the window where the update is 
to take place every time, whereas ssd1307fb does this only once in init.
I do this because controllers supporting higher resolutions can be sped 
up using partial updates (set_addr_win).


Regards,
Noralf Trønnes

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Noralf,

>>>
>>> I am now concerned if the driver was tested in first place ?
>> No. I just submitted some good looking code that never ever got
>> tested.
>>
>> More seriously, There's a few thing that comes to my mind:
>> - Your controller doesn't behave the same way than the ones already
>> supported.
>> - You haven't posted your changes yet, so maybe you're not doing the
>> transfers right
>> - Your SPI controller is doing something weird
>>
>> What happens if you plug a logical analyzer on the bus?
>>
>> Maxime
>>
> Hi,
> 
> The major difference between the SSD1306 SPI and I2C interfaces, is that 
> SPI uses a D/C pin to signal whether it's data or command coming in.
> Looking at ssd1307fb, this Data/Command info is embedded as the first 
> byte in the i2c package/message.
> Without looking up the datasheet, I would guess that this is the only 
> difference, the way the D/C bit is handled.
> The rest of the package payload should be the same.
> So:
> dc=0, spi write command
> dc=1, spi write data (optional)
> 
I was working on ssd1306 itself.

> 
> Apart from that, I have SSD1306 SPI support in a project of mine:
> 
> This is the part writing the framebuffer: 
> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
> This writes commands (for many controllers): 
> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
> This is the SPI specific part: 
> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
> Project wiki: https://github.com/notro/fbtft/wiki
> 
Thanks for the pointers that was really helpful.

just a quick help the dc pin should be a gpio and be set as output pin
to control D/C ?
in my case for ssd1306 needs to be added as slave device in
board file since I dont have DT.

> The code isn't particularly pretty, it was my first venture into the kernel.
> It has recently been submitted for the staging tree: 
> https://github.com/notro/fbtft/issues/161#issuecomment-68431405
> 

hope it gets accepted soon.

Thanks,
--Sagar
 		 	   		  

Re: SSD1306 OLED driver

[Noralf Tronnes]

Den 10.01.2015 13:34, skrev Ssagarr Patil:
> Hi Noralf,
>
>>>> I am now concerned if the driver was tested in first place ?
>>> No. I just submitted some good looking code that never ever got
>>> tested.
>>>
>>> More seriously, There's a few thing that comes to my mind:
>>> - Your controller doesn't behave the same way than the ones already
>>> supported.
>>> - You haven't posted your changes yet, so maybe you're not doing the
>>> transfers right
>>> - Your SPI controller is doing something weird
>>>
>>> What happens if you plug a logical analyzer on the bus?
>>>
>>> Maxime
>>>
>> Hi,
>>
>> The major difference between the SSD1306 SPI and I2C interfaces, is that
>> SPI uses a D/C pin to signal whether it's data or command coming in.
>> Looking at ssd1307fb, this Data/Command info is embedded as the first
>> byte in the i2c package/message.
>> Without looking up the datasheet, I would guess that this is the only
>> difference, the way the D/C bit is handled.
>> The rest of the package payload should be the same.
>> So:
>> dc=0, spi write command
>> dc=1, spi write data (optional)
>>   
> I was working on ssd1306 itself.
>
>> Apart from that, I have SSD1306 SPI support in a project of mine:
>>
>> This is the part writing the framebuffer:
>> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
>> This writes commands (for many controllers):
>> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
>> This is the SPI specific part:
>> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
>> Project wiki: https://github.com/notro/fbtft/wiki
>>   
> Thanks for the pointers that was really helpful.
>
> just a quick help the dc pin should be a gpio and be set as output pin
> to control D/C ?
Correct.

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Noralf,

> Date: Sat, 10 Jan 2015 14:50:09 +0100
> From: notro@tronnes.org
> To: hugarsagar@outlook.com
> CC: linux-fbdev@vger.kernel.org
> Subject: Re: SSD1306 OLED driver
>
> Den 10.01.2015 13:34, skrev Ssagarr Patil:
>> Hi Noralf,
>>
>>>>> I am now concerned if the driver was tested in first place ?
>>>> No. I just submitted some good looking code that never ever got
>>>> tested.
>>>>
>>>> More seriously, There's a few thing that comes to my mind:
>>>> - Your controller doesn't behave the same way than the ones already
>>>> supported.
>>>> - You haven't posted your changes yet, so maybe you're not doing the
>>>> transfers right
>>>> - Your SPI controller is doing something weird
>>>>
>>>> What happens if you plug a logical analyzer on the bus?
>>>>
>>>> Maxime
>>>>
>>> Hi,
>>>
>>> The major difference between the SSD1306 SPI and I2C interfaces, is that
>>> SPI uses a D/C pin to signal whether it's data or command coming in.
>>> Looking at ssd1307fb, this Data/Command info is embedded as the first
>>> byte in the i2c package/message.
>>> Without looking up the datasheet, I would guess that this is the only
>>> difference, the way the D/C bit is handled.
>>> The rest of the package payload should be the same.
>>> So:
>>> dc=0, spi write command
>>> dc=1, spi write data (optional)
>>>
>> I was working on ssd1306 itself.
>>
>>> Apart from that, I have SSD1306 SPI support in a project of mine:
>>>
>>> This is the part writing the framebuffer:
>>> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
>>> This writes commands (for many controllers):
>>> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
>>> This is the SPI specific part:
>>> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
>>> Project wiki: https://github.com/notro/fbtft/wiki
>>>
>> Thanks for the pointers that was really helpful.
>>
>> just a quick help the dc pin should be a gpio and be set as output pin
>> to control D/C ?
> Correct.
>
Thanks!

Is there any sample app/library to draw/test  this driver?

Thanks,
--Sagar 		 	   		  

Re: SSD1306 OLED driver

[Noralf Tronnes]

Den 10.01.2015 22:07, skrev Ssagarr Patil:
> Hi Noralf,
>
>> Date: Sat, 10 Jan 2015 14:50:09 +0100
>> From: notro@tronnes.org
>> To: hugarsagar@outlook.com
>> CC: linux-fbdev@vger.kernel.org
>> Subject: Re: SSD1306 OLED driver
>>
>> Den 10.01.2015 13:34, skrev Ssagarr Patil:
>>> Hi Noralf,
>>>
>>>>>> I am now concerned if the driver was tested in first place ?
>>>>> No. I just submitted some good looking code that never ever got
>>>>> tested.
>>>>>
>>>>> More seriously, There's a few thing that comes to my mind:
>>>>> - Your controller doesn't behave the same way than the ones already
>>>>> supported.
>>>>> - You haven't posted your changes yet, so maybe you're not doing the
>>>>> transfers right
>>>>> - Your SPI controller is doing something weird
>>>>>
>>>>> What happens if you plug a logical analyzer on the bus?
>>>>>
>>>>> Maxime
>>>>>
>>>> Hi,
>>>>
>>>> The major difference between the SSD1306 SPI and I2C interfaces, is that
>>>> SPI uses a D/C pin to signal whether it's data or command coming in.
>>>> Looking at ssd1307fb, this Data/Command info is embedded as the first
>>>> byte in the i2c package/message.
>>>> Without looking up the datasheet, I would guess that this is the only
>>>> difference, the way the D/C bit is handled.
>>>> The rest of the package payload should be the same.
>>>> So:
>>>> dc=0, spi write command
>>>> dc=1, spi write data (optional)
>>>>
>>> I was working on ssd1306 itself.
>>>
>>>> Apart from that, I have SSD1306 SPI support in a project of mine:
>>>>
>>>> This is the part writing the framebuffer:
>>>> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
>>>> This writes commands (for many controllers):
>>>> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
>>>> This is the SPI specific part:
>>>> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
>>>> Project wiki: https://github.com/notro/fbtft/wiki
>>>>
>>> Thanks for the pointers that was really helpful.
>>>
>>> just a quick help the dc pin should be a gpio and be set as output pin
>>> to control D/C ?
>> Correct.
>>
> Thanks!
>
> Is there any sample app/library to draw/test  this driver?
I find it easy to just use the framebuffer console for simple testing: 
con2fbmap (or X windows)
I have also used Geert's fbtest.


Noralf.

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Noralf,


>>>> just a quick help the dc pin should be a gpio and be set as output pin
>>>> to control D/C ?
>>> Correct.
>>>
>> Thanks!
>>
>> Is there any sample app/library to draw/test this driver?
> I find it easy to just use the framebuffer console for simple testing:
> con2fbmap (or X windows)
> I have also used Geert's fbtest.
>
Thanks.

I got it compiled against my kernel, but not sure how to add it in my board file (My platform
has no DT support). Should it be registered as spi slave device , I tried adding the following,

    {
        .modalias    = "fb_ssd1306",
        .irq        = -1,
        .max_speed_hz    = 16000000,
        .bus_num    = 2,
        .chip_select    = 0,
        .mode        = SPI_MODE_0,
    },

But nothing came up how do I register ? any quick pointer would be helpful.

Thanks And Regards,
Sagar
 		 	   		  

Re: SSD1306 OLED driver

[Noralf Tronnes]

Den 12.01.2015 10:44, skrev Ssagarr Patil:
> I got it compiled against my kernel, but not sure how to add it in my board file (My platform
> has no DT support). Should it be registered as spi slave device , I tried adding the following,
>
>      {
>          .modalias    = "fb_ssd1306",
>          .irq        = -1,
>          .max_speed_hz    = 16000000,
>          .bus_num    = 2,
>          .chip_select    = 0,
>          .mode        = SPI_MODE_0,
>      },
>
> But nothing came up how do I register ? any quick pointer would be helpful.

Copy/symlink fbtft.h to include/fbtft.h and do it like this: 
https://github.com/notro/fbtft/wiki/Build-kernel-and-fbtft-drivers#configure-devices

Or use the fbtft_device module:
https://github.com/notro/fbtft/wiki/fbtft_device
ssd1306 entry: 
https://github.com/notro/fbtft/blob/master/fbtft_device.c#L272
The values can be set/changed using module arguments.

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Noralf,

>> },
>>
>> But nothing came up how do I register ? any quick pointer would be helpful.
>
> Copy/symlink fbtft.h to include/fbtft.h and do it like this:
> https://github.com/notro/fbtft/wiki/Build-kernel-and-fbtft-drivers#configure-devices
>
> Or use the fbtft_device module:
> https://github.com/notro/fbtft/wiki/fbtft_device
> ssd1306 entry:
> https://github.com/notro/fbtft/blob/master/fbtft_device.c#L272
> The values can be set/changed using module arguments.
>

Thanks for the pointers that helped!

will the regwidth and buswidth be populated ?
I am not sure what these two should be set to.

Thanks And Regards,
--Sagar
 		 	   		  

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Noralf/Geert,

>>>> But nothing came up how do I register ? any quick pointer would be helpful.
>>> Copy/symlink fbtft.h to include/fbtft.h and do it like this:
>>> https://github.com/notro/fbtft/wiki/Build-kernel-and-fbtft-drivers#configure-devices
>>>
>>> Or use the fbtft_device module:
>>> https://github.com/notro/fbtft/wiki/fbtft_device
>>> ssd1306 entry:
>>> https://github.com/notro/fbtft/blob/master/fbtft_device.c#L272
>>> The values can be set/changed using module arguments.
>>>
>> Thanks for the pointers that helped!
>>
>> will the regwidth and buswidth be populated ?
>> I am not sure what these two should be set to.
> I'm skipping CC'ing the mailinglist as this still is an out-of-tree driver.
>
I have got the driver working!

I am also able to run the fbtest application, but with test10 I do not see 'hello world'
pattern. Am I missing something.

Thanks & Regards,
Sagar
 		 	   		  

Re: SSD1306 OLED driver

[Geert Uytterhoeven]

Hi Sagar,

On Wed, Jan 14, 2015 at 2:51 PM, Ssagarr Patil <hugarsagar@outlook.com> wrote:
> I am also able to run the fbtest application, but with test10 I do not see 'hello world'

Good!

> pattern. Am I missing something.

That's because that test requires 16 colors, although these aren't used.

If you change ".numcolors \x16" to ".numcolors = 2" in tests/test010.c,
it should at least draw some text, but the colors may be of as it
failed to install
the 16-color console pallette.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Greet,

>
> On Wed, Jan 14, 2015 at 2:51 PM, Ssagarr Patil <hugarsagar@outlook.com> wrote:
>> I am also able to run the fbtest application, but with test10 I do not see 'hello world'
>
> Good!
>
>> pattern. Am I missing something.
>
> That's because that test requires 16 colors, although these aren't used.
>
> If you change ".numcolors \x16" to ".numcolors = 2" in tests/test010.c,
> it should at least draw some text, but the colors may be of as it
> failed to install
> the 16-color console pallette.
>
Thanks for your response, I did try with setting .numcolors = 2 but it doesnt help
neither I still don’t see 'Hello World' on the oled.

Thanks & Regards,
Sagar
 		 	   		  

RE: SSD1306 OLED driver

[Ssagarr Patil]

Hi Greet,

>>
>>> pattern. Am I missing something.
>>
>> That's because that test requires 16 colors, although these aren't used.
>>
>> If you change ".numcolors \x16" to ".numcolors = 2" in tests/test010.c,
>> it should at least draw some text, but the colors may be of as it
>> failed to install
>> the 16-color console pallette.
>>
> Thanks for your response, I did try with setting .numcolors = 2 but it doesnt help
> neither I still don’t see 'Hello World' on the oled.
>
Sorry for back to back mails.

Is there any graphics library to draw text ? can directfb be used ?

Here is the verbose output of fbtest:
# ./fbtest -f /dev/fb0 -v -d
fb_init()
fb_open()
fb_get_var()
fb_get_fix()
fb_map()
fb_start = 0, fb_offset = 0, fb_len = 4000
fb_save()
fb_clear()
Using drawops cfb16 (16 bpp packed pixels)
clut_create_rgbcube(): RGB 8x8x8
Available visuals:
  Monochrome
  Grayscale 32
  Truecolor 5:6:5:0
Using visops truecolor
Running all tests
Running test test001
test001: PASSED
Running test test002
test002: PASSED
Running test test003
test003: PASSED
Running test test004
test004: PASSED
Running test test005
clut_create_rgbcube(): RGB 8x8x8
test005: PASSED
Running test test006
test006: PASSED
Running test test007
Visual 6 not supported
Running test test008
test008: PASSED
Running test test009
Screen size too small for this test
Not applicable
Running test test010
test010: PASSED
Running test test011
No support for virtual screen and panning
Running test test012
Benchmarking... 10x10 squares: 70.19 Mpixels/s
Benchmarking... 20x20 squares: 163.23 Mpixels/s
Benchmarking... 50x50 squares: 451.62 Mpixels/s
test012: PASSED
fb_cleanup()
fb_restore()
fb_unmap()
fb_set_var()
fb_get_var()
fb_get_fix()
fb_close()

Thanks & Regards,
Sagar