[SSD1306 driver]

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.

[SSD1306 driver]

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.

[SSD1306 driver]

The master branch is at a point where we have locked it off and stopped making any changes. We are about a week away from merging the GDISPStreaming branch into the master and releasing it as v2.0. The code in the GDISPStreaming branch is ready to go now - Tectu is just busy this week and he needs a bit of time to write release documents and update the website to match.

If you have any updates and changes relative to the GDISPStreaming branch I will be happy to incorporate them.

I am guessing from your previous post that there are a few changes to be made relative to the spi board file in the GDISPStreaming branch. Can you please post the updated SPI board file and I will integrate it immediately.

Note the location for the example board files has now changed. They are now stored in the boards/addons/gdisp directory if they are not specific to a particular base board.

Thanks for your work. It is very much appreciated.

[SSD1306 driver]

The issue with the command byte has now been fixed.

Have a look at the updated code as I found a way of doing it without copying the data onto the stack.

The overhead is one byte of RAM per page line (8 bytes total).

Can you also please test again.

[SSD1306 driver]

Thanks for the testing.

I thought that might be the case with the board file.

Does that also apply to the spi interface?

I will see if I find another way of including the extra byte as it seems a shame to allocate a whole new buffer and copy the line particularly as stack seems to be a critical resource for most processors. I should have the fix up later today.

The GDISP_NEED_SCROLL turns on the gdispVerticalScroll() function - in other words the GDISP API for scrolling. GDISP_HARDWARE_SCROLL says that the controller supports hardware accelerated scrolling. Note with the new code that GDISP_NEED_SCROLL now works even if there is no hardware support for scrolling provided the low level driver provides a read pixel routine (and yours does).

With the new code, provided there is a read pixel routine (which there is for your driver) you don't need to specifically implement a scrolling routine any more as the high level code will do it for you.

If you want to define a hardware accelerated version you need to specify GDISP_HARDWARE_SCROLL in the gdisp_lld_config.h file for the driver. Note that most controllers only support full screen width scrolling which is not sufficient to support the GDISP vertical scroll method. I think I glanced at the datasheet for your controller and that was the case for the SSD1306 as well (although don't quote me on that - you know the controller much better than I) and if so then the only possible implementation is via the high level code using the read pixel routine.

This was actually why I added the vertical scroll handling to the higher level code - it is a common operation but few controllers seem to support a variable width vertical scroll natively.

[SSD1306 driver]

I have integrated the changes into the GDISPStreaming branch of development (which will soon become version 2.0 of uGFX).

There has been significant changes to the GDISP low level driver interface to enable some major new features such as support for multiple displays, a formal gdispFlush() call and even automatic flushing.

Can you please test the GDISPStreaming branch for your controller as I don't have equivalent hardware myself.

One change you will need to be aware of is that the gdisp_lld_board.h in your project directory should now be called board_SSD1306.h. The interface has also changed so start from one of the template ones provided.

Thanks for your contribution. It is appreciated.

I also notice that you have started adding a GTimer to your code (although it does nothing yet). I presume this is so you could do flushing using the timer. I really like the idea and now that flushing is officially supported by the new GDISP framework, I think I will add that concept to the framework itself so it can be used by any driver that needs flushing.

[GDISP low level restructure]

There is currently work being done on restructuring the internals of the GDISP module. The API will stay compatible with existing code. Included in this work are some nice new features...

• GDISP streaming. This could, for example, enable video playing in a window while still allowing normal GDISP calls to be used around the edges to draw controls etc. This is also very useful for games and other programs that need to access an area of the screen in a super-fast sequential manner.
  
• GDISP low level driver restructure. This is to simplify the writing of most drivers. Complexity to do with optimization, clipping etc have been moved to higher level code, significantly reducing the amount of code for most low level drivers. Drivers for devices that support window streaming type operations are now extremely easy to write with full optimization applied by the higher level layers.
  
• Multiple displays. Currently GDISP supports only a single display. The new code will allow multiple displays to be simultaneously used on the same board even if they use different controllers.
  
• Support for memory mapped displays. Every memory mapped display currently requires its own driver. With the new low level drivers a generic "memory map" driver allows for connection to any memory mapped display (eg a Linux framebuffer) simply by changing the interface board file.
  
• Support for virtual RAM based surfaces. This enables a bitmap display to be created in RAM, of any size (subject to available RAM). It can be drawn on using the standard GDISP calls. It can then be used to fast bitblit to a real display, or can be saved in a file.

A video demo showing the new streaming features and drawing optimization can be seen here http://youtu.be/GMfb97wbwq4

This is definitely a work in progress and not all the features listed above are available yet. In fact currently only the Win32 and the Nokia6610 drivers have been ported. If you feel like having a play or porting your current driver, the code is in the GDISPStreaming branch of the source repository.

[Items list on top of other graph objects]

Currently the GDISP clipping area is an inclusive clipping box i.e. the area INSIDE the box gets drawn, anything outside does not.

I can see that for menu's and other "pop-up" or on top items an exclusive clipping area would be useful (only things OUTSIDE the box get drawn). If I get time I might add support for an exclusion area to the new GDISP code I am currently working on. This would certainly be useful for single window overlaps like menu's. It would have to be called manually when displaying your pop-up until GWIN supports maintaining an expose list.

[Items list on top of other graph objects]

GWIN comes with a VERY basic window manager. Whilst it handles visibility etc, it currently does not support overlapping windows. Drawing is only clipped to the window boundary not to the windows expose area. If fact, with the current window manager, an expose area for each window is not even kept. This restriction is fine for most small embedded systems as it is simple and requires minimal RAM and speed overheads to manage.

This principal of keeping things tiny and simple even extends to some of the window types. Whilst all widgets can redraw themselves if requested (eg if they are revealed by the removal of another window), other window types like graph and console cannot. To enable them to do so would require that they "save state" in RAM and this would make them very expensive for small CPU's (and possibly impossible due to insufficient RAM).

As the window manager is now a "plug-in" interface it should be possible to write your own more complex window manager and use it by calling gwinSetWindowManager(). See src/gwin/gwm.c for the implementation of the current basic window manager.

I suspect that extra support will be required in the basic GWIN code to help support this, simply because GDISP currently only supports simple box type clipping area's. This is not insurmountable however if you implement a box region cache within the window manager. When the first window manager gets written that supports overlapping windows we can adjust what is necessary in the basic GWIN code.

This is not simple stuff to get right and so for now it has been on the back-burner as we implement higher priority items.

We would love it if someone (perhaps you) took on the challenge of writing a window manager capable of handling overlapping windows and then contributed it back to the project.

[problem regarding display orientation]

Your original font problem likely stems from a bug in the GDISP driver for the EMBEST board with bitmap displaying.

When in 90 degree mode it is likely that the bitmap routines are not rotating bitmap displays correctly.

The new font code does not use bitmap routines and so the problem has "appeared" to go away with the new font code. It will still exhibit however if you try to display any bitmaps.

Tectu, can you please test bitmaps on the EMBEST in the rotated configuration as I don't have this type of hardware?

[problem regarding display orientation]

This smells of being a stack issue. Try increasing the size of your runtime stack.

Looking at the code fragment below however, it looks like you are rotating to 90, performing some operations and then rotating back to 0.

If so, this may have all sorts of strange effects as the window has been created in one orientation but is being operated in a different orientation. This is definitely an untested (and probably unsupported). In general, gwin windows should be operated in the same orientation that they are created.

[Efficiency of redrawing fonts on labels]

Sorry for the late reply to this thread.

This area of uGFX is fast evolving and there are a number of competing requirements.

On one hand uGFX gets run on some CPU's with very little RAM - so generally buffering display area's is a big no-no.

On the other hand - we used to have progressive, non-frame effect text fills with the old fonts code. Whilst it didn't optimize out overdrawing of pixels (which is not possible without buffering or display read-back), it did update in a smooth manner - filling as it was drawing each changed character. For unchanged portions of the text there was no visible display change.

This capability was dropped when converting to the mcufont library simply because of the complexity of the code required due to mcufont supporting kerning.

I am currently doing major work in the basic GDISP library and drivers which will include significantly reduced stack usage, significant performance optimisations, support for multiple displays, support for area streaming (as might be used by video). I will look at re-implementing the progressive text filling as I go as it definitely a nice feature.

[Display Scrolling all the time]

There is still a bug here in the driver scrolling routine.

GDISP_CONSOLE_USE_CLEAR_LINES just clears to the end of the line. Whilst turning this off has made the problem "seem" to disappear it is actually still there. The issue will continue to appear any time you try to fill an area using gdispFillArea().

What is happening is that because your driver has not defined a "fillarea" routine (or it is not turned on in your driver config file) the emulation layer looks for an alternative mechanism to quickly fill the area. In this case it has determined that you have a vertical scroll routine so it is using that to fill the area.

If you look at the documention for gdisp_lld_vertical_scroll() you will see that it is supposed to clear the new area revealed by the scroll operation. In this case the entire area is being scrolled out which should result in the entire area being "revealed" and therefore cleared. Have a look at your code in the gdisp_lld_vertical_scroll() routine specificly for this boundary case.

It is probably a good idea for performance reasons to also create and turn on a fill area routine.

[Problem SSD1963 and STM32F4 Discovery]

Perhaps Tectu or Mobyfab would like to put together a readme on common problems someone might see with this (or similar) drivers and the steps that can be looked at to address the problems.

TechNet supplied images as part of his discussion which made it obvious to the experts mobyfab and Tectu what might be happening. Similar images in a readme would help other users to self-diagnose their new panel.

[V1.8 compilation problems]

I have just updated the button code to fix the compile error there. It was being caused by extra custom button drawing routines that are not always compiled in.

With regard to "gfxQueueASyncInit" - it is defined in include/gqueue/gqueue.h

It is turned on by having

			#define GFX_USE_GQUEUE		TRUE
			#define GQUEUE_NEED_ASYNC	TRUE

in your gfxconf.h

This should have automatically been set anyway when the GWIN Window Manager is compiled (include/gfx_rules.h). If that is not working for you just add the above lines to your gfxconf.h and it should make sure that that function is defined.