inmarket

In the ugfx tree there is a directory for each of the two mikromedia STM32 m4 boards. In those subdirectories is an example project for Chibios V2 and chibios V3. Copy the files from that directory to your project directory and use that makefile as a starting point. There are two problems going on here... 1/ chibios board files are not provided by chibios for the mikromedia boards. We have included them as part of the ugfx directory tree. 2/ The chibios makefile does not know how to build ugfx. The ugfx makefile however knows how to build both ugfx and chibios so the ugfx makefile is the best one to use (and in our mind is much simpler for a user anyway). I hope that helps. Let us know of any more troubles you have.

You are right. Really weird. Can you please post your touch driver board file. It is likely to be something in there.

PS. The beta for ugfx studio is very close. I would think it is likely to be available in a few weeks (the primary developer of the studio is currently in uni exams)

We believe that ugfx is a good choice for what you want but then we are biased. The trick with simplicity is not to reinvent the wheel. For example, we have a number of users that want to use ugfx without an operating system. Whilst possible it is definitely more complex than using an existing real time operating system. I would strongly suggest that you start with the chibios and ugfx combination. Chibios is the hard real time operating system and ugfx is the GUI. The reasons for suggesting this combination are: 1. Both chibios and ugfx are well supported with active user groups to help with problems, 2. The chibios ugfx combination is the best supported combination of GUI and os with many boards supported out of the box for this combination, 3. Chibios is small and extremely fast. Ugfx runs as a (lower prioroty) user thread thus not affecting the real time response of your system, 4. Chibios has an excellent HAL that supports all the STM32 peripherals and supports dma operation where supported by those peripherals, 5. The ugfx makefile system knows how to build a chibios/ugfx system out of the box - no makefile nasty stuff to hack. 6. Ugfx supports a Linux or win32 emulation that should enable easy prototyping and debugging of your gui even before putting it on real hardware often with no code change (ugfx is designed to be operating system portable). Questions on the real time performance of chibios is probably better being asked in the Chibios forum. A good place to start to learn ugfx is with the demo programs. They are designed to demonstrate how to use various aspects of the system. If you are using win32 as a Dev platform read the wiki guide on your first windows compile. It will have you up and running in a few minutes with all the appropriate compilers etc for that platform. Next read the other wiki articles on the ugfx architecture. That will help when you go to port to your own hardware. I would also suggest trying the Chibi - Studio ide (part of the chibios project). Based around the popular eclipse ide it includes all the necessary bits and pieces such as compilers, configuration etc for working with your actual hardware. Whilst taking other paths such as using Kiel is definitely possible, it is just another complication to have to deal with initially. Good luck and welcome to the community.

Can you please post all your board files, your gfxconf.h file and whatever else is needed to build a basic version of your project preferably in a zip file or create a git hub or bitbucket repository. Please be patient, this is all done in our spare time and I have been very busy with work.

UGFX is typically compiled using a makefile system. Whilst this is great for most platforms, some IDE's do not allow external makefile build projects and it can be difficult to work out which source files need including and which ones should not be included. This is particularly relevant on platforms like Arduino were the compiler does not allow libraries to have include paths other than the master source directory. To help with these platforms we have added a "single file" source compilation. Simply add "src/gfx_mk.c" to your IDE project and it will automatically include all other ugfx source except for drivers and board files. Note: the master gfx.h file will still need to be on your include path. There are still some limitations with this single file compilation in that inclusion of functions from third party libraries may not at this time work correctly (FAT, PETITFS, TinyGL etc). There is also an issue with user supplied fonts (with a simple work-around). We will work to resolve these issues as we get to testing them. For those that would like to play with the single file compilation using the standard ugfx make, we have added a new make option. Set GFXSINGLEFILE=yes in your makefile and it will use the new single file compile. In our in house testing this decreases the compile time from 14 seconds to 2 seconds

A new cpu option for the STM32 M3 series cpu's has been added to the ugfx makefile system. If you have a board with one of these cpu's eg STM32F103 then your makefile should have the following line in it to get the correct cpu. OPT_CPU = stm32m3

Some specifics may help if you would like us to help dig deeper into the problem. What touch/mouse are you using? What type of board is it?

Usually that error occurs if you have defined ginput_need_mouse (except in uppercase) in your gfxconf.h file but haven't added a mouse driver to your build. That error indicates it can't find the mouse driver to compile in. Ps. The extern is needed. Without the extern it is an auto variable which makes the unresolved symbol dissappear but the program will crash as the mouse driver it is expecting is not linked in. Note: if you are using a mouse driver outside the repository (not one of our standard ones) you will need to upgrade the driver to match the new mouse calling interface.

I am also cleaning up some code inclusion issues that should make it all a lot easier. Start with the gdisp/basics demo. That was about as far as I got with my proof of concept with ugfx as an arduino library.

The gfxconf.h must be put in the library directory due to the include path arduino uses when it is compiling the library. With regard to it making one big file which "reduces optimisation", it actually increases optimisation as it increases the size of the compilation unit. Gcc link optimizer is also almost never used anyway due to bugs in the optimizer. This combining of source files is what the arduino build platform seems to do anyway for libraries - it combines all the source in the directory and then compiles it as a single unit.

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.