inmarket

PS. That is the primary reasons V2.3 was released. It locks off significant new development in the main line until the non threaded code is ready to become the basis for the next version (which may yet be called V3 instead of V2.4 depending on how deep the changes need to go).

It is definitely a work in progress. It does not compile yet - at this stage I am just hashing out the structural changes required and the various dependencies. On one hand we want it to support non - threaded execution but on the other multi-threading safety is still absolutely critical for many people. It is balancing those two often times conflicting requirements while allowing either or both capabilities that is tricky. I created the new branch so that I can switch between mainline development and non threaded code as need requires. Eventually the non threaded branch will become the main line but it a long way from that yet. Once I have the structural changes done and the dependencies figured out I would love some help in finishing it off and testing etc. If you want to see where it is heading do a diff against the master branch. The major changes will be in GOS and GTIMER modules although eventually just about everything will be touched with the multi-threading changes.

Other people have avoided the wierd and wonderful arduino build system and have created makefile based builds for their arduino project into which ugfx fits natively. It is possible though to use ugfx as a standard arduino library (that is how I did it for my project) however the bits of glue and documentation on it is not yet ready for the main repository. The arduino library structure is a bit strange the way it determines dependencies etc and so there was a fair amount of kludging involved. The basic process is to create a library called ugfx, then create a subdirectory within the library called ugfx that contains the real ugfx repository. Into the top level library directory create a ugfx.c and a ugfx.h and of course a config.h suitable for your project. In ugfx.c then #include all the relevant source files from the real repository subdirectory. In ugfx.h just #include the real ugfx.h from the real ugfx subdirectory. There are a few additional bits to making it work, the details of which I can't remember without firing the project up again But the above should get you most of the way there. When I get more time I will look at what is required to put the necessary bits into the master repository and write a wiki article on how to use it. Unfortunately that will not be in the next couple of weeks as I just have too much on currently.

Probably better is to use the custom draw capability of a widget. As above create your transparent background draw routine. When you initialise the label put your transparent draw routine into the customDraw member of the widget initialisation structure. That saves having to play with the vmt structure or altering any of the standard widget code.

I have ordered another display supposedly with that controller. I will let you know when I get it and how it goes.

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

The display I ordered that was supposed to be sh1106 turned out to be a ssd1306. Have you tried that driver?

Also, with the current version of ugfx the setting gdisp _ total _ controllers is no longer needed. Similarly you shouldn't need to set the pixel format - it should auto detect as there is one controller type.

Your application code looks fine. Can you please post your entire board file. I suspect the problem is in the aquirebus/releasebus and the write calls. To give you more detail... You are configuring both boards (including their chip select lines) in the init call. Once you have init the spi for cs2 it will maintain that for all writes and thus only the 2nd display gets written to. In practice the chibios experience of storing the chip select in the spi port means it is assuming a single slave device. There are two solutions, 1/ do your own chip select manipulation or 2/ re initialise the chibios spi port during each aquirebus operation.

Where you are using the same controller chip with two displays you can use the board member of the gdisplay structure to work out which chip select pin to activate. This member is for your board files private use. Your list of boards will then contain the same controller twice (or rather GDISP_TOTAL_DISPLAYS will be set to 2 if they use the same controller I think). It will then get initialised twice with a different display number each time. The init routine sets up the board member and thereafter that is used to distinguish the displays.

Announcing the new GarbageCollection module for UGFX. This module does everything an embedded program really wants to do but never could due to RAM constraints or code space. Want to have a full windowing system and multi-tasking operating system on a 1K RAM ATMega? Now you can! Just garbage collect your program with the new ugfx module. Currently there is one small bug - it tends to garbage collect your main user application. This short-coming is not high on our list of things to fix but will be addressed one day.

There are a number of places in ugfx where functions designed for Init have no Deinit. This may be due to the deinit being unnecessary (say when the init does nothing but clear the object memory), or it may be that the routine has just never been written. Even some that are written do not completely clean everything up properly. The reason for this is that these deinit routines are an after thought. In a real embedded platform they are of no use and actually take up precious code space (a real cost for no functional benefit). Tectu and I have been of differing opinions at various times about this and so any of these routines actually implemented are minimal at best. Objects (such as mutexes and semaphores) that are commonly created and destroyed have the proper routines, it is really just routines that are considered primarily "init" time that may not not have a deinit routine. In the next major version of ugfx I am looking to add a define that will control the explicit inclusion or exclusion of these routines and clean up much of this behaviour.

Looking at your code more closely... Move the geventListenerInit and the gwinAttachSource to where you do your gfxInit. The geventDetachSource call is then entirely unnecessary along with the added gfxSemDestroy. The listener will then stay ready for when you next instantiate your frame window.

The usage case here seems a little strange. Generally geventListenerInit is called as part of the initialisation of a program. It therefore never needs to be called again. The 88 bytes then becomes a one time overhead. Actually, the gfxSem is part of the listener structure itself so the 88 bytes must be dynamic allocation by the operating system. In most embedded operating systems the semaphore is by structure definition rather than by handle so typically in a embedded system there is no allocation occurring at all. Also geventDetachSource is not the opposite pair to geventListenerInit. It is the opposite pair to the geventAttachSource routine. As such it should not (and must not) destroy the mutexes at that point. In a similar way to the use of geventListenerInit, in a real embedded device the program will never end and thus any deinit routines are just a waste of code space for objects that will survive the entire length of operation of the program (like a listener). The issue therefore with memory allocation you are seeing is unlikely to ever exist in an embedded environment both due to the operating system api specifics and due to an embedded program never ending. The issue appears to be only an artifact of the desktop emulation environment. After said all the above, I will look at the code with the objective of cleaning up any asymmetry in the init/deinit process. It is certainly a long time since I have looked in detail at this code.

Two new functions have been added to the GWIN List. The first function gwinListSetSelected() enables an item in the list to be selected or de-selected via the API. The second function gwinListViewItem() scrolls the list to ensure that a particular item is currently visible in the list

Now added to the repository (but altered slightly)

That will make a very worthwhile addition to the list. I will integrate it into the master.

A superfluous forward definition for struct GContainerObject has been removed. Whilst this should be ignored by compilers as the forward struct definition and a subsequent typedef are equivalent objects, some versions of GCC incorrectly flag a compile error (but seemingly only with some combinations of compiler flags). The superfluous definition has been removed to prevent this incorrect compile error.

Dynamic sized labels may crash if the text in the label is changed at run-time. It doesn't always happen as it requires a particular set of timing and positioning circumstances for it to occur. A work-around has been added to prevent the crash. The work-around prevents a dynamic sized label becoming smaller in order to avoid the circumstances leading to the crash. The dynamic sizing will still allow the label to grow larger. A complete fix will be attempted at some time in the future.

I have found a reasonably simple workaround for the problem so dynamic sizing should work again with the latest master repository. The caveat is that a dynamically sized label will only increase in size, never decrease at least until I can spend the time to fix it properly.

By the way - nice demo.

I have found the problem... I used the dial demo you attached to debug however I am sure that the problem is likely to be the same in the button demo. First the workaround... wi.g.width = 40; // Used to be wi.g.width = 0; wi.g.height = 20; // Used to be wi.g.height = 0; ghLabel = gwinLabelCreate(0, &wi); The widget has this nice little feature whereby it can auto-size based on the text that is in the widget. It is the only widget that supports this functionality and was at the time just an after-thought. This functionality is perfect for a static label but when the text changes at run-time it tries to resize the widget during the label's redraw function. Unfortunately due to changes in the redraw handler since this widget was originally written, this causes the widget to recursively redraw in certain conditions thus causing the hang leading to stack depletion some time later with its associated kernel inspired crash. This is likely to be tricky to fix so the work-around currently is to use a fixed size label as seen above. I will look at this in much more detail when I get some more time. Unfortunately you can tell by my slowness in getting to this that real work has been keeping me very busy. For now it will be considered a known bug.

This is now fixed in the master repository

I have had my first look at it. Please change your OPT_CPU to x32 rather than x64. x64 has not been tested for reliability and really is not needed for an embedded system emulator. There is a very good chance there are some 64 bit problems in the library. Both x32 and x64 should run on a 64 bit Linux machine. If your compiler complains about compiling x32 on your 64 bit machine it might be because you have not installed the 32 bit libraries for your C compiler. Each Linux distribution has a different process for doing this, some include the libraries out of the box. If you have trouble with this let us know what distribution you are running and we will see if we can google the proper install command line. I have not tried a compile yet - that is just what struck me when I looked at it first.

I should be able to look at this now within about 24 hours. I will report back as soon as I have any results for you.