inmarket

Having a clip size of zero should clip all display from happening as you suggest. Currently however setting a zero sized clip region is considered as invalid parameter values and is therefore ignored. If you believe that shouldn't be the case we will certainly listen however each drawing operation will need to be boundary tested to ensure that it doesn't cause any of the drawing operations to crash. If you are happy to test them all or even to visually verify that a zero sized clip area will be handled correctly then we will be happy to change the code to suit. Unfortunately it is the end of the financial year in our country and so I am too busy to do that testing myself currently at least for the next couple of weeks.

If you are using chibios and you are having speed issues then using spiPolledExchange may help. Note that the driver as talked about above was working, just not with the expected performance.

The polygon functions support translation and the gwin 3d widget supports full translation, rotation and scaling but other than that no. The reason is just complexity for embedded platforms. Come to think of it there might be suitable matrix operations in the GMISC module but I can't remember if they made the master repository. If they did make it they include those capabilities as either floats or fixed point math.

In ugfx there are two pixel formats involved; the system pixel format and the display pixel format. For a single display they are always the same. For multiple displays each display may have a different pixel format. The user selects (as part of their gfxconf.h file) the system format. It is normally picked to match the larger of the two device formats as translating colors is computationally expensive. Pixmaps always work using the system pixel format. 4bpp is definitely possible eg 16 color grayscale, but is not supported by the framebuffer driver. Translating to and from 4bpp to other standard formats is very computationally expensive so if you want to do that you should write a custom framebuffer that supports that format and use that format throughout to avoid color conversions.

By the way, for smallish displays (320x240) that you tend to see on embedded systems, the speed of the display itself is seldom an issue. A well written program, a well implemented board file (the software interface that describes the cpu - display electrical interface) make the biggest difference to display speed. The exception is some of the monochrome displays. These tend to be very slow

If you are wanting to display different parts of the image on different displays, this is easy to do in ugfx and you won't need to use pixmaps. The api calls for drawing an image allow you to specify which part of the image you want to show on each individual display. For speed reasons however you might consider using the image caching api or pixmaps unless your image is coming out of flash (using GFILE and ROMFS). Both caching mechanism however use a lot of ram. You will need to experiment as to which is best in your circumstance.

There is a difference between the two. From memory it is something to do with the runtime environment. A quick Google search should show you the difference. I do know however that the arm "none" compiler is the one you should be using for any embedded work.

I am hazy on the ecos details, it was a quite a while ago. The scheduler definitely needs to be started first before calling gfxinit. The details on how to do that I have forgotten. Essentially ugfx runs as a user thread once the scheduler is started as ugfx needs the multi-threading capabilities of ecos which are not available until the scheduler is started.

I didn't have that problem when I was tinkering with it but that was a while ago now. It looks like the ecos scheduler has not been initialised or something similar. Perhaps you can provide more back trace information so we can see the call hierarchy at the point of the exception.

There are a few things that might be happening here. .. 1/ The openocd file provided is designed to be used with the openocd driver for the st-link. If you are using the official st-link drivers you may need to change some lines in the file to match. 2/ openocd is a project that changes its api over time. It could be a version issue of openocd. The scripts have already been upgraded several times to take this into account. Maybe it is time to do it again. Later when I am on my computer I will look at which version we are currently using. I think this is the most likely issue. 3/ The scripts as provided are designed to be used using a combination of the script itself and parameters. The parameters tell it what to do eg whether to upload, or act as a debug target. It should be relatively obvious from the script itself but I can't remember how or if I documented how to use it.

Yes, I have run ugfx with ecos although it was a while ago. Can you please give us more detail on the error you are getting and we will help solving it.

Well done on getting it working! Yes. The default values can be set in your mouse board file or in your gfxconf.h If you look at the template board file you will probably find they are listed there already. If not look at a couple of the other mouse driver template files, you will see how it works.

Unfortunately chibios V3 is not stable. We have found lots of this sort of thing happening from time to time. Chibios V2 is much more stable although Giovanni from chibios sneaks changes to the api in from time to time that breaks things. The latest V2 version should work. I will look at updating the V3 chibios files as soon as I get a chance. Alternatively you could do that for us, we would definitely appreciate the contribution. The mikromedia STM32 m4 board with chibios V2.6.7 is what I use for a lot of my own development.

Just a additional thought... If you have one of the non m4 versions of the mikromedia boards you are still better off using our example m4 project but just change the cpu definition in the makefile. The reason is that I believe that mikromedia use largely consistant pin outs etc across their boards and just change the cpu. So you might still need to make modifications but it is a much better starting point than the STM32 100 board files.

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.