stm32plus 2.1.0

The latest release is now 3.0.0. Be sure to check out the announcement here.

Due to the use of c++0x features the minimum compiler requirement is now version 4.7.0 of gcc

stm32plus version 2.1.0 has now been released and is available from my downloads page. This article will present a brief overview of the following new features.

  • LGDP453x TFT driver
  • SSD1289 TFT driver
  • SSD1963 TFT driver
  • ST7783 TFT driver
  • AT24C32/64 serial EEPROM support

As mentioned in the banner at the top of this page you will need to ensure that you are using at least version 4.7.0 of gcc. I’m currently working on a driver for one of the big on-chip peripherals and it just couldn’t be done cleanly without real variadic templates so I took the opportunity to migrate all the template ‘feature’ mix-in classes to variadics. I also replaced lots of subclass types that were there as a workaround for the lack of template typedefs with much cleaner template aliases.

I use the free ‘arm-2012.09’ arm-none-eabi gcc release supplied by CodeSourcery (aka. Mentor Graphics) on Windows 7 x64 and Ubuntu Linux and I recommend that you do too. Other gcc toolchains may also work but are not tested. non-gcc compilers will certainly not work.

The installation and usage instructions have not changed since version 2.0.0. Documentation can be found in this previous article.

LGDP453x TFT driver

The LGDP4531/2 is a 320×240 (QVGA) TFT panel from LG. The stm32plus driver for this panel was contributed by Andy Franz and gratefully accepted by myself into this release.

64K and 262K colour modes are supported in landscape and portrait orientations. A full list of driver declarations are:

LGDP453x_Portrait_64K
LGDP453x_Landscape_64K
LGDP453x_Portrait_262K
LGDP453x_Landscape_262K

Andy created a corresponding example demo that you can find in the ‘examples/lgdp453x’ directory.

SSD1289 TFT driver

Experimental support is now provided for the Solomon Systech 1289 QVGA TFT driver with 64K and 262K colours and in landscape and portrait mode. The driver names are:

SSD1289_Portrait_64K
SSD1289_Landscape_64K
SSD1289_Portrait_262K
SSD1289_Landscape_262K

An example demo program is supplied in the ‘examples/ssd1289’ directory.

I have labelled this driver as experimental because I have not been able to verify that it works with the cheap ebay SSD1289 panel that I have because my cheap panel appears to be hardwired into an interlaced mode.

That is, if you set a display window to cover the whole screen and then fill it with pixels then the pixels will fill the rows in this order: 1,0,3,2,5,4… This makes it impossible to support with my graphics driver.

The offending driver input line is ‘GD’ and of course it’s the only one you can’t set in software using the ‘driver output control (r01h)’ register. Hopefully one of you will have a panel with ‘GD’ set to the non-interlaced mode!

SSD1963 TFT driver

The SSD1963 is another one from Solomon Systech. It’s slightly unusual in that it’s not hard-wired to any particular resolution. Instead it allows you to program it to support any resolution up to 800×480 as long as you know the timings for the panel that you’re going to use.

The stm32plus driver for the SSD1963 calls upon small ‘traits’ classes to supply the timing and size information for the panel being controlled. My test panel is a 4.3″ 480×272 device obtained on ebay and I have supplied traits classes for it. The driver names are:

SSD1963_480x272_Portrait_262K
SSD1963_480x272_Landscape_262K
SSD1963_480x272_Portrait_16M
SSD1963_480x272_Landscape_16M

I’ve put together a short video of this panel in action connected to the STM32F103.

ST7783 TFT driver

I’ve got a cool new docking expansion board for my STM32F4DISCOVERY that adds some common peripherals to the system including an ethernet PHY, an RS232 socket, an SD cage and of course a QVGA LCD with a touch panel.

The driver IC for this panel is the ST7783 and I am pleased to announce support for it with 64K and 262K colours in portrait and landscape modes. The driver names are:

ST7783_Portrait_64K
ST7783_Landscape_64K
ST7783_Portrait_262K
ST7783_Landscape_262K

I also put together a short video that shows it in action. The F4 drives this panel very quickly indeed.

AT24C32/64 serial EEPROM support

Unlike some other devices such as the 8-bit AVRs the STM32 doesn’t have any EEPROM memory included on-chip although it is possible to emulate it to some extent by reading and writing the internal flash memory at runtime.

If you need real EEPROM support then you have to purchase and wire up an external IC.

The Atmel AT24C32 and AT24C64 are 32/64Kbit serial EEPROM devices that are controllable via an I2C bus. The STM32 I2C on-chip peripheral is ideally suited to communicating with these memories.

stm32plus provides two drivers named ‘AT24C32’ and ‘AT24C64’ to manage communication with these devices. Both drivers inherit from InputStream and OutputStream so you can use all the methods that the stream interfaces provide.

The driver class is templated with the I2C interface that you are going to use to communicate with it. An example declaration might be:

#include "config/stm32plus.h"
#include "config/i2c.h"
#include "config/eeprom.h"

typedef AT24C32<
  I2C2_Default<I2CTwoByteMasterPollingFeature>
> MyEeprom;

I2C::Parameters params;
MyEeprom eeprom(params);

A full example is included in the ‘examples/i2c_at24c32’ directory.

Changelog

Here’s the changelog for version 2.1.0 in full.

Added “TypeB” Nokia N95 8Gb driver (LDS285 controller). stm32plus now supports both types of this cellphone display that I’ve found so far.

Accepted LGDP453x TFT driver and demo contributed by Andy Franz. Thanks Andy!

Added drivers for SSD1289, SSD1963 and ST7783 LCD interfaces. Demos are included.

Change compile flags to C++0x with GNU extensions. This will facilitate a migration to variadic templates for the feature classes. The motivation for the migration is cleaner and smaller code generation.

Ported all peripheral classes that allowed template features to variadic templates.

Ported all LCD interface declarations from subclasses to template typedef aliases. Removed the colour depth suffix from graphic terminal class names, i.e. remove _64K, _262K suffixes. This is because there’s no difference between the colour depths making the suffix irrelevant.

Replaced SmartArray.h with scoped_array.h and scoped_ptr.h lifted from the open source Chromium project with appropriate credits.

Added reset() method to MillisecondTimer to bring the clock back down to zero.

Fixed STL slist for modern, stricter compilers.

Increased reliability of ADS7843 touch screen by preventing the pen interrupt from occurring while sampling is taking place.

Replaced the 3 GraphicTerminal* classes with a single GraphicTerminal template. The terminal declarations for each LCD interface have been updated accordingly. Graphics terminal declarations have now lost the colour depth suffix. So for example:

ILI9325_Terminal_Portrait_262K<LcdAccess> 

would now be:

  
ILI9325_Terminal_Portrait<LcdAccess>

Also, the terminal class constructor is now a reference and not a pointer.

Implemented AT24C32/64 serial EEPROM classes with I2C interface. An example program is provided. Include “config/eeprom.h” to get access to the class.

Created StreamBase base class for InputStream and OutputStream and lifted up the error codes into the base as well as the common close() interface method.

Update: bug notification

A bug has come to light that affects optimised builds. It’s too small for me to do a full release so I’ll explain here what you need to do to fix it.

The problem is that the counter used by the MillisecondTimer class should be declared volatile. You can fix it like this:

In stm32plus/include/timing/MillisecondTimer.h change the counter declaration to include ‘volatile’:

public:
  volatile static uint32_t _counter;

Also change it in the source file: stm32plus/src/timing/MillisecondTimer.cpp:

volatile uint32_t MillisecondTimer::_counter;
  • Peter

    Hi Andy.

    That was quick after the message the oher day.
    The SSD1289 example works fine, the only comment I have is the colours could do to be a bit brighter or is it the backlight that is to dark as some of the tests are difficult to see especially the image tests.
    Do you have any suggestions.

    Regards Peter

    • Thanks for the reply and confirmation Peter. It could be a weak backlight, or maybe the panel gamma settings.If you comment out the following line from the demo:

      _gl->applyGamma(gamma);

      does it make a difference?

      I would also be interested if you have a link to where you bought your panel. I need to get one to replace mine that I know hasn't been configured badly by the maker.

      • Peter

        Hi Andy.

        Thank you for the reply.
        I commented out the line you suggested and that made a big difference.
        Regarding the backlight initialy it was wired directly to VDD and it was a lot brighter, now I have it wired to the backlight control pin PD13 so will have to do some tests and get the scope out to see what is going on.

        Below is the link to the display I am using. http://tinyurl.com/am2x5wk

        When I build the Library the SConstruct file directs the library to be placed in INSTALLDIR="/usr/lib/stm32plus/"+VERSION
        but it buts it in /lib/stm32plus/"+VERSION.
        So maybe I am doing something wrong when I set up the build environment in cygwin.

        Regards Peter

  • Ben

    Andy,

    Not sure if it's deliberate or not, but in the SConstruct file, the version is still listed as 2.0.0.

    cheers,

    Ben.

    • It's an oversight. Thanks for the heads-up. It's now corrected.

  • I've taken the liberty of cloning Andy's empty GitHub repository for stm32plus, and republishing his version 2.1.0 code there. Hopwfully Andy will pull this back to his github repository, but for now, you can find it at https://github.com/cjheath/stm32plus

  • Guyom

    Hi Andy,

    First of all, thank you for this library !!!!!

    I'm encountering an issue with the Pframe example..
    When I try to setup the example for the ST7783, the terminal class fail with the following error message :

    error: 'class stm32plus::display::GraphicsLibrary<stm32plus::display::ST7783<(stm32plus::display::Orientation)1u, (stm32plus::display::ColourDepth)1u, stm32plus::display::Fsmc16BitAccessMode<stm32plus::FsmcPeripheral<0ul> > >, stm32plus::display::Fsmc16BitAccessMode<stm32plus::FsmcPeripheral<0ul> > >' has no member named 'setScrollPosition'

    is there something missing ?…

    Thank you
    Guyom

    • Hi Guyom, thank you for your comment. The photoframe example relies on hardware support for vertical scrolling as you can see in the videos. The ST7783 does not provide hardware scrolling so the pframe example will not work with it.

      • Guyom

        Thanlk you Andy

        I'm now able to compile my project ( just a skeleton of your photoframe example)

        I have got a strange behaviour when trying to use the ST7783 in 262K with my own lzg picture in 262K or with some pictures form the ST7783 example (It's seems that the screen print the picture but not aligned).

        With my own 64k picture and the ST7783 in 64K, I'have got the expected picture printed on screen

        Is there something needed to use the St7783 in 262K (regarding the example ST7783) ?

        • Hi Guyom, did you remember to convert your graphics for the 262K colour depth using bm2rgbi? Something like this:

          bm2rgbi input.png output.lzg st7783 262 -c

          • Guyom

            Yes Andy,

            I've already converted my input file in 262K
            but I've got also this issue with the picture you gave in the Zip file

          • I just tried it on my board and 262K worked for me. Starting with the example code, here's what I did:

            1. Change the driver name:

            // typedef ST7783_Portrait_64K<LcdAccessMode> LcdPanel;
            typedef ST7783_Portrait_262K<LcdAccessMode> LcdPanel;

            2. Go to CompressedPixels.s and change all .64.lzg filename extensions to .262.lzg

            Recompile and reflash.

            After doing the above steps it worked without any issues on the panel that came with my dev board.

  • aldrin thattil

    Am a new bee in electronics which board shall I chose for a good beginning ?

    • Hi Aldrin, any of the ST Discovery boards offer a cheap and easy way into the STM32. The F4 Discovery board is particularly well thought of and contains a powerful STM32F407 168MHz MCU.