inmarket

Yes. I have been playing with it over the Easter weekend. It was hard to initially get the arduino IDE up and running as the Tinyduino board file is not easily found. In the end I wrote my own (fairly simple once I knew what was going on). I have written a driver for the SSD1331 for the TinyScreen which was nearly completed testing when my TinyScreen died (the display not the cpu). Nevertheless I have put it up in the repository along with the necessary board files (in the board/addon's directory) and I think it should work as it is. It is a great controller as it supports accelerated commands including the ones necessary to support generalised scrolling. Like most small controllers it doesn't support read over SPI. I have also added arduino as a full GOS layer (even though it is really just a variant of the RAW32). This enables arduino support with no extra support routines being required. I am currently working on making ugfx as an "arduino IDE library". There are some issues with this due to differences in the directory layouts given that the arduino IDE does not support a separate include path for libraries. I have most of the issues sorted out but it is not ready for integration with the ugfx repository yet. It has also raised some interesting issues with respect to GTimer. GTimer is an essential module for most of the other modules (except GDISP). Unfortunately it uses a separate thread for implementation. Whilst this is supported by the GOS emulation layer even for arduino, the real issue is the amount of RAM that the stack for a separate thread requires - particularly one that may be drawing on a screen. 1K for a stack on a CPU that only has 2K RAM is a bit too much. I have some ideas to remove the dependence on threads for GTimer but that will take some time to implement and is a fairly major change so that will come later.

Without reading the controller data sheet in detail, I suspect the buffer swapping needs to be delayed until a vertical blanking period. There will be a pin interrupt or a register to poll which will tell you when the appropriate time has come to swap the buffers.

Yes you can do it without making major modifications to your conf file. Do as the comment suggests and put that particular symbol in your makefile. In fact using the ugfx makefile it is a one line change to use a different operating system.

Thanks. That is a great help.

By the way, none of the gdisp api will alter the clipping region (except gdispSetClip). The only place that currently uses api level clipping in the current ugfx is the gwin api which uses it is clip drawing operations on a window to the window area.

I'm not understanding why paging is needed at all. Why not just draw the lot in one pass? Adding paging of any sort is a big drain on available ram. The only reasons I can think for paging is to smooth drawing artifacts in high motion situations -like video. In those situations I am not sure paging the way we have been talking about it is the right approach. For something like video the gdisp streaming api would be much more efficient.

Yes I realised the chips and boards were different, I am just not use to the arduino way of doing things and was hoping your project with mods would form a shortcut to building a project from scratch on a platform I am unfamiliar with. Even if it isn't close enough to form a project base the sameness and differences would be useful in determining how to create a supported arduino port for ugfx. Send me whatever you think might be useful given that my two aims are 1. To get a project working on tinyscreen, and more importantly 2. Make arduino a supported platform for ugfx.

Why use the pixmap at all then? Why not just set the clip on the real display to say page 1, draw, set the clip to page 2, draw etc. There is something in this situation I am obviously missing.

Congrats. Can you post your project as I am wanting to start playing with my new arduino tinyscreen? It will make a nice sideline project over easter. Thanks.

By the way gdispSetClip can be used to clip drawing operations to any desired portion of the display. Each display maintains its own clipping region.

Pixmaps are interesting in that they have a dual personality. On one hand they look like a full display (origin =0, 0). On the other hand they look like a native format image. A native format image can be blitted to a real display at any position using gdispGBlitArea. I suspect therefore that this will do what you want. initialise it as 64x64 (1/4 the size of the real display). Draw to it as if it is a it is a 64x64 display and then blit it to each quarter of the real display as required.

You are right, there is no generic framebuffer driver for monochrome displays. They are however all very similar and it has been in the back of my mind to eventually develop one. In the mean time just take one of the existing monochrome drivers and modify it to suit.

Looking at your comments there, it looks like bits 0 and bits 4 will be the ones to change to do the orientation. Bit 0 will be clear for R0 and R180, set for R90 and R270. Bit 4 will be clear for R0 and R90, set for R180 and R270. I may have bit 4 back to front for R90 and R270.

To answer your questions... The files in the boards/addons directory are not ready to run as-is (although they should be close). They are effectively example files designed to be added to your project and modified to suit. In your case the board_ssd1351_teensy.h would be copied to the project and renamed board_ssd1351.h. The corresponding cpp file would also be copied to your project and the pin definitions modified to suit your hardware. The files in the boards/base directory however are designed to exactly match a particular supported board configuration and the appropriate board makefile can be included directly into the users project to get all supported hardware on that board without any modification. Based on the confusion you experienced I may rename the boards/addons to boards/examples or something like that (suggestions welcome). Yes, there are extra support routines required for the arduino when using OS_RAW32. I may write a full os layer later for the arduino bare metal but probably the best solution in the short term is that we add the arduino support routines into a file that gets put into the boards/addons directory so other people can also make use of it. If you wanted to swap to a parallel interface instead of a SPI interface, normally there are some jumpers on the lcd which tell it how to expect to be talked to on power up. As far as software is concerned - the only change would be to the board_ssd1351.h file (or in your case the support board_ssd1351.cpp file) to talk via a parallel interface rather than SPI. That is the whole purpose of the board file layer - to separate the electrical interface from the details of the driver code. It also allows the driver to be completely operating system and pin assignment independent. I will have to look at the SSD1351 data sheet but some interface modes on the chip may allow reading. The SSD1351 is very similar to most embedded controllers in that you cannot read back from them. The ones you can read back from are the exception rather than the rule. Certainly if GDISP_HARDWARE_STREAMREAD or GDISP_HARDWARE_READPIXEL are not set, the read routines in the board file will never be used and do not need to be defined (in fact in board_ssd1351_teensy.h you will see that they are not defined even though the template currently says they should. All of that is something however that we can clean up later when I get the datasheet (and time). Orientation, sleep modes, contrast and backlight level are all optional and are handled by the gdisp_lld_control() function (but only if GDISP_HARDWARE_CONTROL is set in gdisp_lld_config.h). Again this is something that can be done when I have the datasheet and is not generally difficult. Just look at the ILI9341 as a reasonable example. As to what the various sleep modes mean - that is entirely up to the driver writer. Most sleep modes should be fairly self-explanatory just by their name. Rotation at the driver level is GDISP_ROTATE_0, GDISP_ROTATE_90, GDISP_ROTATE_180 and GDISP_ROTATE_270 (Ithink those are the correct labels off the top of my head). ROTATE_0 is obviously the native rotation for the display, everything else is relative to that in a anti-clockwise direction. ROTATE_90 then has the "top" to the left and the "bottom" to the right etc. I will compare the code to the repository a bit later (I need to go get some food and sleep now). Thanks for all your work!

Please use the current master repository as there have been many bug fixes and changes since 2.2. This should fix your Keil compile issues as the current master is known to work with Keil.

I just got myself a tiny circuits smart watch. This is arduino based and so I will play with ugfx on that soon. Well done on getting it going. Can you please play with the driver and interface files in the repository and see if you can get them going. That way we will have official support in the repository.

By the way - nice work on getting it going!

The yellow box and the red line look right but the blue filled box doesn't. Are you using the setpixel code (your original version) or the window based driver from the repository?

It looks like your gdisp_lld_init routine is not filling in important fields in the GDriver structure. To help I have added a quick driver for the SSD1351 to the master repository mostly based on your code. I have not done any debugging on it as I do not have this hardware. I also added an example board file and matching cpp file to the boards/addons directory. You will of course need to rename board_ssd1351_teensy.h to board_ssd1351.h and include those two files into your project. You will see that I have used driver specific routine names and externally defined them in both the board h file and in the cpp file. This saves having to mix any Arduino and any ugfx header files and will therefore prevent the compile type errors you were seeing. That issue we can save for another day to solve. Please test and get back to us on any corrections needed. Hope that helps.

It is probably time I spent some time documenting the driver architecture better.

I am happier if you do it - I have so much to do already. It is however important to me to provide you with whatever support you need. I will hold off then until you have had a go at it. If you get stuck just let me know.

Yes it will deallocate the memory associated with the pixmap.

There are a few conceptual errors here (although I wouldn't have thought they would have stopped it from working). I will fix these up for you in the next few hours and add it to the master repository. The errors mainly relate to the division of code between the driver and the board file. The driver should have all the code relating to the commands that get sent to the controller. It should contain all your calls to write_cmd for example. The only thing that is supposed to be in the board file is the electrical stuff eg how to get a byte to the controller (in your case via spi and some data lines). The board h file is now quiet slim and it should contain the functions as static functions in the h file itself. The reason for this is to allow for multiple display drivers being linked into the same program. Also, your controller is not a point and block controller, it is a window controller. Defining a set pixel routine will be a very slow way of talking to the controller. The ssd1306 controller was probably a bad example start with as that is a monochrome display and as mentioned before monochrome displays have particular problems. A much better controller to start with will be the ILI9341 which is conceptually a very similar controller. I will post again when I have the code ready in the master repository.

For most controllers for embedded platforms it is the window model that the controller uses. Usually set pixel, area fill etc routines are only needed to handle unusual controller bugs and these routines are defined in addition to the normal window mode calls. It is only when you start to get to pc emulation layers and very big displays with powerful processors that you see controllers that are not window mode. You are right, the purpose of gdisp_lld_config.h is to tell gdisp what routines to expect in the driver and how to call them. The easiest way to port a new controller chip is to find an existing one that is similar and make the changes to it. Given you are implementing the ssd1351 I would suggest starting with another ssd or ili driver with a similar electrical interface. I would not suggest using c++ in the driver, not because it isn't possible as it is possible, but because it raises all the memory management issues that c++ represents in a place where that extra complexity is simply not worth the trouble. That is particularly true for such a small processor as you are using. With regard to flushing, most color controllers don't need flushing as operations are handled directly by the controller. Flushing is typically only needed where a ram buffer has to be used (like many of the monochrome controllers) because the controller does not support single pixel level operations. When flushing is required the gdisp api supports 3 models of operation... 1. A flush occurs on every high level gdisp api call 2. A flush is performed on a periodic timer, and/or 3. The use program directly controls flushing using gdispFlush. Which mode is used is controlled by the application gfxconf.h file. Reading the code for a few existing drivers will quickly fall into a pattern. In terms of not seeing reference to a particular driver in the demo's, that is correct. There is a special bit of include file magic happening that means as long as you are only using one controller there is no need to mention it by name. The driver linked at compile time is the one used. If you want to have more than one display in the same application then that magic doesn't work and you need to specify the list of drivers in your gfxconf.h. See the multiple display gdisp demo for more details. This same approach of auto detecting which driver to use provided there is only one of them for each device class is also used for mouse/touch, keyboard and will eventually be used for all device support in ugfx. This development work is relatively recent however so some device classes don't use it yet eg audio. To see the parts that make it work there are some defines at the very top of each gdisp driver specifying the driver name. Everything else is handled by the "magic" gdisp/driver.h

Most graphics libraries require a full frame to be retained in memory. This however is not a requirement for ugfx (except for some monochrome displays) and is one of the primary advantages of ugfx over other libraries. If you are using a color display ugfx knows how to do all the drawing without a framebuffer in ram so there is no need to be worrying about paging. If you are in a very tightly memory confined processor, do not use the GWIN module. Use the GDISP api directly. You should also not enable scrolling as that allocates an extra buffer to cache the scrolling operation.