inmarket

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.

To implement your read routine in the board file, copy the chibios example but replace the chibios call with the equivalent function from your spi library. It should be almost a one for one api call replacement. The spiexchange chibios call just writes some bytes on the spi port and then reads some bytes - in this case it writes one byte and then reads 2 bytes. You won't need to worry about the details of how to extract the reading from those values returned by the read call - the driver handles all that, and lots of signal conditioning for you. If you are interested in the details have a look at the driver source code and then also the ginput mouse layer which handles all the heavy lifting associated with processing mouse coordinates.

To be able to help you more we will need a lot more detail. What board are you using, what lcd module, what resolution, how is it connected to your board, what is the sequence of events that happen to the lcd when you turn the device on, what demo are you running, what operating system, what debugging have you tried, do you have a scope so you can check the pins are toggling correctly, is the controller a real SSD1289 or could it be an imitation chip? These sorts of information are essential for us to help you debug. With more information we will do what we can to help.

Thanks

Can you please post the project file as I would like to add it or a variant to the repository. It would be good to have a KEIL example in there.

I know of no reason this should be so. Can you please attach a zipfile with a very simple demo showing the problem and we will look to see what is going on. A font size of 5 seems very small anyway as the standard fonts are typically around 11 pixels high.

I have uploaded more updates on the master repository that should fix these. Let me know if there are still any problems.

I will update the master with the changes to the setjmp. Thanks for that. With the int8_t, all that block should not be defined if stdint.h has been included as all those definitions should come from that file. I suspect that all the other defines are matching and so they don't give a warning whereas Keil has some funny ideas about char signed-ness (or not). A better solution is to check the top of stdint.h from Keil and change the block to be: #if !defined(_STDINT_H) && !defined( the appropriate symbol that kiel uses at the top of stdint.h ) typedef char int8_t; typedef unsigned char uint8_t; typedef short int16_t; typedef unsigned short uint16_t; typedef int int32_t; typedef unsigned int uint32_t; #endif Can you please get back to me on the correct symbol for that. Thanks.

Reply posted to that thread. Thanks for helping ivan47

I have pushed a small change to the master repository that will hopefully fix the issue with the Kiel compiler for you. Can you please try it and let me know if it works and if not then what changes are needed to make it work.

_setjmp is a compiler defined routine (although occasionally it is found in the c library). Specifically check the compiler options and if that doesn't help try including the standard c library. Also, _setjmp is generally the compiler specific version whereas setjmp (without the underscore) is the c library version which internally calls _setjmp. With the Kiel compiler however it may not define the underscore version. In that case change gos_raw32.c so that it uses the correct version for the Kiel compiler. If that happens please let us know so we can patch the master repository.

I you want to use ugfx without a rtos, have a look at the raw32 gos layer. It allows you to implement ugfx with no operating system. If you search the forum you will find code snippets etc from other users who have used this.

It is almost certainly due to the overheads in the chibios spi driver. I suspect that chibios is suspending the thread while waiting for the spi to send rather than polling the registers to see when it is done. Resuming a suspended thread is a very expensive proposition hence the big delays between bytes of data. An even better method than polling for the transaction to complete would be to poll just before starting the next transaction for completion of the previous transaction. Unfortunately we are talking the specifics of how chibios implements it's drivers here, not something we easily control. The only solutions are... 1. Use a bit banging method of implementing spi, or 2. Write cpu specific direct hardware register calls, or 3. Rewrite the chibios spi driver. Method 1 was used in the SAM7EX256 uext drivers. Method 2 was used in the SAM7EX256 lcd driver Method 3 is probably impossible due to deficiencies in the way chibios drivers work. Unfortunately the SAM7EX256 board uses a different cpu so method 2 is not directly transferable from that code. The bit banging code however should work on any cpu. It has been on the agenda for a while for ugfx to write a HAL module which would overcome many of these problems. That is a very big job however so for now we have to rely on the base operating systems hardware drivers.

gwinDestroy on a container will destroy all gwin objects in it. It will not however close any gfiles' or gdispImage objects associated with buttons etc just as it does not automatically open them. The reason for this is that the same gfile for an image can be used for multiple buttons. It would not be good if a destroyed button was to close the image gfile as then all the other still existing buttons using the image would fail. So, images associated with gwin objects must be manually opened and also manually closed.

I strongly suspect the difference is the way spi is implemented. I would suggest that mbed is using bit banging versus chibios using the real spi hardware. Bit banging is usually faster but more cpu intensive. An implementation of bit banging spi can be found under the SAMEX256 board for some of the uext peripherals (initially implemented that way due to buggy spi drivers for that cpu in chibios). Other factors... Make sure your board file routines are marked as "inline". This way with the right optimization settings your compiler will remove any function call overhead. Set the DNC pin in your board_init and also at the end of the write_index call. Setting DNC can then be removed from write_data as it will already be set.