SSD1306 driver

[inmarket]

There are a couple of problems with the scrolling routine as implemented and why I took out the original implementation. I also have a suggestion for a better way to implement it...

• The scroll routine as implemented assumes that you are always scrolling the full width of the display and exactly one page line in the upward direction. This does not match the GDISP API which allows arbitrary scrolling window sizes and either direction
  
• It is no longer needed in the new driver to get scrolling as the higher level layer supports scrolling provided a readpixel is defined (which it is for your driver)
  
• The new requirements for gdisp_lld_scroll() no longer requires anything to be cleared as the high level layer does that separately. Instead the gdisp_lld_scroll() routine only needs to move the bits around that are being scrolled

The biggest problem of the above is that the new routine doesn't match the API specification. I can see however that a special hardware assisted scroll may be useful in the limited situations your scroll supports and it would be faster on slow cpu's.

I will look at adding code to the high level to support a special hardware accelerated but limited situation scroll if the parameters to gdispVerticalScroll() match what is supported in hardware. It will use software emulation if the parameters don't match. This however is a bit of work so it won't happen right now. Quite a large number of displays support full width only scrolling in hardware so this may be a useful addition particularly for small displays where a full width scroll is more likely.

I am reluctant to include that scroll routine in its current form as it doesn't match the API specification. I would suggest then that your special situation scroll be implemented as a driver specific gdisp_lld_control() code (much like the flush was in the v1.9 driver) for the moment. If you can make that change I will then include it in the new driver for the SSD1306.

Although Version 2 has not been released yet, I will happily include any updates to GDISPStreaming branch either before the merge or after it becomes v2.0.

As for the source control - we use to use GitHub but migrated to bitbucket because of various problems we had. Setting up a bitbucket account is free.

If you are running Windows they also have a very nice piece of free software called sourcetree.

[inmarket]

Just a little explanation of the new driver/board directory structure...

• Drivers are in the "drivers" subdirectory. They will include a board_XXXXX_template.h file which is obviously an empty template for the board_XXXXX.h file used in the real project. The template file can be copied into your project directory and compiled without changing (except for the rename). It will obviously do nothing as there is no real code but it enables all the drivers to atleast be compiled on any platform.
  
• The "boards/base" directory contains all the necessary files for a predefined "base" board. For example, if you have a Mikromedia-STM32-M4 you can include the board.mk file in that directory into your makefile and it will add in all the drivers (and the necessary board files) for the hardware on that board. You only need to add any extra custom hardware drivers. In each board directory there is also a example project that you can just copy and have a working demo for your hardware.
  
• The "boards/addins" directory contains example board files for any other hardware. They illustrate various ways of interfacing to the drivers. Typically a suitable one would be copied into your project directory and then modified to suit your hardware.

This scheme enables us to support standard boards whilst still allowing you to add the extra bits into your project for any non-standard hardware bits you have. Even the predefined boards are optional - they just make getting started on those boards a lot quicker.

Edited November 8, 2013 by Guest

[joherold]

Hello everyone,

I have been trying to understand how the driver works, but I have come across one issue, I couldn't understand.

For the SPI version, the board files uses funcions like "spiStart", etc. Where are these functions coming from / where are they defined? Do i need to use an extra library for SPI communication add it to my project?

Thanks for your help!

[steved]

For the SPI version, the board files uses funcions like "spiStart", etc. Where are these functions coming from / where are they defined? Do i need to use an extra library for SPI communication add it to my project?

They are hardware drivers for the SPI - if you use chibiOS they are already implemented as part of the operating system. There are no doubt similar routines in other embedded RTOS.

[Joel Bodenmann]

There are no doubt similar routines in other embedded RTOS.

Only if your RTOS comes with it's own HAL. Otherwise you have to manually implement these functions.

~ Tectu

[joherold]

Awesome, thank you guys!

Didn't know Chibios implements those SPI functions

[aimatt]

I bought one of these: http://www.aliexpress.com/item/Free-shi ... 91904.html and I can't get it to work on STM32L discovery I2C1 (LCD removed). The address as the jumper shows is 0x78 and there are only 4 lines. No reset pin. I can run an I2C scanner and pick up other devices (BMP180 and MS5611), but nothing else. I've tried with and without 4.7k and 2.2k pullups.

After reading the comments I saw "works OK, used U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_DEV_0|U8G_I2C_OPT_NO_ACK|U8G_I2C_OPT_FAST) lib". I googled a bit and saw that this module may not be able to pull the line to set the acknowledge bit. Is there any way to shoe-horn this existing driver to work with it while allowing the slave to not sends ACKs, or do I have to implement bit-banging?

Speaking of bit-banging-- is there a canonical implementation of software I2C for STM32 in the case that I do have to use it?

Thanks a bunch!

[inmarket]

I'll have to look into the module and the other reference in more detail when I get some more time however I thought I would quickly reply on the other question.

We don't have a software bit banging i2c implementation in the examples that I know of. We do however have a software bit banging SPI implementation. Have a look at the UEXT board files for the SAM7EX256 board. You may be able to modify that to suit your needs.

[inmarket]

Looking at the module, it looks identical to a module I purchased. I strongly suspect that this is a SPI module rather than a i2c module. Certainly the one I have that looks identical is spi.

Try it with spi first and get back to us if that doesn't work and we will look closer at the i2c side.

[aimatt]

I have the SPI equivalent as well, it does look identical, but that has 6 pins instead of 4. I did get that one working successfully with some modifications to the SSD1306 code in the UGFX repo.

Also, one of the buyers of this particular module did say they got it working with U8G_I2C_OPT_NO_ACK using U8Glib.

Are you in the US? I can mail you one of mine if it comes down to that.

[inmarket]

Unfortunately I am in Australia.

I have done the next best thing and ordered the same module. My guess is that it will take 2 to 3 weeks to arrive though.

My reasons for suspecting it is spi is a) the labelling of the pins, b) the aliexpress advert uses both i2c and spi in the description (wwhich was the same with the previous product I purchased that was spi) and c) it is not working with normal i2c protocol.

[aimatt]

I just tried plugging SCK (PB13) into SCL and MOSI (PB15) to SDA, but no luck so far.

[aimatt]

Yeah, no good. I'm giving up for now. O-Scope didn't really show anything on the SDA line, but then again, I'm not good with it. If you get some luck, let me know. I'm going to try to get U8glib working on it.

[Joel Bodenmann]

Did you ever try to / succeed in getting some I2C / SPI output on your microcontroller without uGFX running on it? Maybe you just forgot to enable the peripherals clock or setting the pin mode correctly.

~ Tectu

[aimatt]

Yes. The SPI output works for a different LCD (with uGFX) and the I2C is working with a barometer.

[aimatt]

I figured it out. It needed 400kHz and address 0x3C.

static const I2CConfig i2cconfig = {
    OPMODE_I2C,
    400000,
    FAST_DUTY_CYCLE_2,
};

[inmarket]

Fantastic. When my display arrives I will know what to do.

[inmarket]

Got mine working. It is now a UEXT based board file for the Olimex SAM7EX256 board In the repository.