inmarket

The compile errors you are seeing are due to using chibios V2 board files in a chibios V3 compile or visa versa. Either revert to using the chibios version which match your chibios board files, mcuconf.h etc or update those files to be compatible with the latest chibios. Chibios V3 has a number of demo files to get you started although personally I would revert to chibios V2 because the V3 api is still in flux and changes in incompatible ways from time to time. Also, if you can't solve it that way you should discuss this on the chibios forum as this is definitely a chibios problem. I recently updated the ugfx support for Chibios V3 because of its changing api. Unfortunately that means we are then incompatible with older snapshots of V3.

You must still do the gfxinit () call as that initialises the code that gfxYield uses. At least you now know you have valid gfxSystemTicks and gfxMillisecondsToTicks functions.

An ecos package has not been built. It is on the todo list but is not high priority. For now ugfx is treated as an application. Tectu's answer above gives you the basics of that. Also look at the code in the boards/base/ecos... directory. If you want a cpu connected as a remote display you can use the ugfxnet display driver and the corresponding display client but replace the networking with SPI code. Alternatively you could write a new display driver based on one of the existing spi controllers and have the other device emulate that display

Simple replacement method... In your systick_Config handler function just increment a volatile uint32_t variable. gfxSystemTicks should then just return that variable. gfxsleepmilliseconds should then work.

Why not just draw the change where you detect the value has changed. Then the redraw routine only needs to handle the full redraw situation.

It's always a compromise between features, code size, code complexity, cpu cycles and ram usage. We trade one off against the other all the time with embedded programming. In this case adding containers and the ability to have overlapping windows (even if it is in limited situations) added a lot of complexity and some code size. By compromising on the "draw once" principle we saved lots of code and in particular a lot of ram (multiple clipping regions uses significant runtime ram). It may be possible to make minor changes to give a "conditional partial redraw" as you have done with minimal code. It is just going to take me time to ensure that we are not creating incorrect updating in some circumstances by adding it. I am guessing that you have a particular widget in mind and a particular reason for wanting partial redraws. Can you please fill me in a little on those reasons and the widget concerned as that may help when I look at this?

Delay () won't work as part of the implementation of gfxsleepmilliseconds () because it doesn't allow anything else to happen while sleeping. I suspect the tick timer has not been initialised correctly. As a simple test write a loop that gets the tick value and when it has increased by 1000 then it toggles the leds. Is the tick counter even updating?

We originally had similar code but took it out for a couple of reasons when we did the redraw engine redesign.. 1. There are many conditions where the wrong things end up being redrawn. Multi thread is such a pain! 2. It was just more complexity for gains in very few areas. 3. Full redraws are seldom a problem as you are just overwriting unchanged bits. There are no display artifacts other than some wasted cpu cycles and a slightly slower redraw. 4. Code savings made the effort worth while. Instead the code savings were invested in container and z-order based redraw capability. I will look at your changes in more depth in a week or so (just busy with real life currently). If I can verify they work reliably without any of the original partial update issues I will merge them with the master repository.

For simplicity ugfx widgets always redraw the entire widget. This just keeps code size and ram requirements small. Handling multiple or non window sized clipping regions is very complex. That being said, there is nothing stopping you from doing a partial draw in response to a signal or event or api call. This would just occur outside the normal redraw handling. An example is the graph window. The graph window does not use the automatic redraw at all. Instead it draws in direct response to a drawing request. Widgets must have an automatic redraw (graph is a window not a widget) but widgets can still draw outside the automatic redraw.

No. A tick is not the speed of the cpu. It is an arbitrary unit of time derived from the clock oscillator. For example many embedded operating system use a 100 hz tick. DOS use to use 18.2 ticks per second. The tick that you used for gfxgetsystemticks is the one that you initialised 1 tick = 1ms using systick_Config. Based on that your multiply factor is 1 so gfxMillisecondsToTicks (ms) will just return ms.

Yes that is correct. It is usually just a simple multiply or divide.

A simple test to verify the problem... Manually delete the .dep directory. The first make after that will succeed (subject to any other compile problems). Try compiling again and it will fail. It is the format of the paths in the dependancy files that is killing the compile.

By the way - proof that it is using the cygwin tools comes from looking at the fork problem line. Notice that sh comes from /usr/bin/sh. This path shows that it is cygwin based as the mingw version would show a Dos style path. The fork problem is likely caused by having mismatching versions of the cygwin.dll file. Perhaps there is an instalation of cygwin on your system where the version conflicts with the version included with chibistudio. This is why I suggested to upgrade your cygwin instalation on your machine. If that doesn't fix it go looking for errant cygwin dll's on your path.

This is definitely the cygwin make issue. The chibios chibistudio uses the cygwin make to execute it's makefiles and so is subject to these problems. It is exactly this scenario where I came across this problem -chibios being my primary platform at the time. Because it is environment based I got no answers from the chibios forums etc. I eventually found the problem. I switched to using the mingw make which has less problems than the cygwin make. When I was doing the make system rebuild for ugfx I added the fixes into our scripts for these problems. As chibios has never acknowledged the problem it continues to be a problem with the chibios make scripts on the Win32 platform - but only in certain circumstances eg using absolute paths containing a drive letter. It is the colon in the path that causes cygwin make to die when handling dependancy file inclusion.

These are problems I have experienced. This is a problem when compiling in Win32 using the cygwin make program. If you are using UNIX you can ignore the discussion below and your problem must lie elsewhere. Cygwin make gets confused with DOS style paths and drive letters and it seems to affect it worst when including dependencies. Firstly update your cygwin installation to the latest version. I expect that will get rid of the "sync_with_child" issues but not the dependency issue. If you update to our latest master in the git repository and use one of our example makefiles (eg. boards/base/Win32/example/makefile) we have put special code in to handle these cygwin nasties. If you are cross compiling for another platform (eg ARM) just use another example makefile in the board area as your base makefile. All our example makefiles now contain the fixes that allow them to compile properly on Win32. The makefiles provided as part of the ChibiOS project do not have those fixes and often have issues when compiling on Win32. Whilst the GNU make is very powerful (which is why we use it) it has a number of very bad limitations (on all platforms - Windows and Unix). The cygwin version has even more limitations. We have put a number of fixes into our makefiles to overcome many of these limitations. The current rules when using our makefiles are: With our makefiles you can handle absolute paths (eg c:\mydir) or relative pathnames (eg ..\mydir) using dos or unix directory separaters (eg "\" or "/"). You CANNOT currently use drive relative pathnames (eg e:mydir). I think we can handle directories that have spaces in them provided that the makefiles do not reference any part of the directory that contains the space eg. If the project directory is "c:\my dir with spaces\project1" you can use paths such as "../otherdir" in the makefile but not anything that contains a space. (I have not fully tested this). It is generally better to not use directories with spaces in them at all with GNU make. Filenames cannot contain spaces at all. On our Wiki we have a very nice article on getting your first compile to work on Win32. Follow those instructions first and see how you go.

Just as a little tidy up aside, gfx.h does not need to be copied to a local project directory. It is never changed by a ugfx program and can be found from the include path "../ugfx_lib". Similiarly, as the gdisp driver files are not altered you could just add them to the compile from where they normally sit in the master ugfx source. The board_ILI9325.h file would then be placed in the same directory as your gfxconf.h file. Well done on the work you are doing here. Documenting as you go is a great idea. Thank-you.

The inclusion of the path when including the gdisp_lld_config.h has historically been required. This is due to multiple display support. I have been slowly changing things to a directory relative path where possible in the latest code. The full path should have worked for you anyway as you included "../ugfx_lib" in your include path and that path is relative to that directory. The board file that you are using has been written assuming the ChibiOS operating system. It is ChibiOS that has provided the rccEnableAHB() function and the FMSC_Bank1 global variable. Board files are the interface between the driver and the real hardware. They don't need to know about how to drive the controller but they do need to know how to talk to the hardware. As this often involves SPI or some other function that is wrapped by the operating system, these board files tend to be hardware and operating system specific. As you are using RAW32 the board file will need to be updated using whatever mechanism you have available to you to talk to the hardware eg some combination of the STM32 library and direct bit banging. FMSC_Bank1 refers to the STM32 FMSC registers, FSMC_BCR1_MBK is a STM32 bit within that register set and rccEnableAHB() is a function provided by ChibiOS to enable FMSC operation on a STM32 cpu. Similiarly palClearPad() and palSetPad() are functions for GPIO pin manipulation provided by ChibiOS. I hope that helps.

You might find it easier to move forward the ugfx integration. Reasons this may help... 1. ugfx supports bare bones implementation using the raw32 pseudo operating system. You only need to provide a tick counter. This also supports (cooperative) multitasking. 2. Ugfx already has implementations of printf etc. 3. Many of the drivers you mention are already provided by ugfx. You only have to write the driver to real hardware interface layer. This layer is written in the ugfx "board" files. In short it could save you a lot of work.

The 3d extensions for ugfx using the tinygl library can certainly do what you are asking. Unfortunately it is ram heavy as it requires a depth buffer. The rotation could otherwise be implemented using fixed point matrix operations. Scaling could be implemented in the same step. Floating point operations should be avoided as most small micros don't have floating point units so the operations are emulated (very slow). If you would like to assist in such an implementation we would love your contribution. Other than that this sort of functionality will probably only be implemented when our development queue shortens a bit unless the demand for these operations is high.

This is now fixed in the repository. Sorry for the delay.

I may be stating the obvious but you will need to turn on the FATFS support (GFILE_NEED_FATFS). That is what provides the ability to read the FAT file system on the SD-Card. The connection between FATFS and the SD-Card itself is currently done using the FATFS method - see the FATFS documention about their diskio interface. We have already implemented that interface for ChibiOS and we intend to simplify this for other operating systems soon by creating a block device driver abstraction. For the moment for anything other than ChibiOS you need to do what Tectu said - implement the FATFS diskio. If it helps, the ChibiOS version is found in src/gfile/gfile_fatfs_diskio_chibios.c Also of interest might be the PETITFS option (GFILE_NEED_PETITFS). It also provides a FAT file system interface but with much less code. That also means it has restrictions that FATFS doesn't; mainly it is read-only and only one file open at a time. It's diskio interface is similar but slightly different to that of FATFS.

We are currently making some changes to the API that may affect some user programs. Some have occurred already whilst some are still in the pipe-line. Note these will only affect programs using the current master in the repository. It will not affect "releases" such as the V2.1 release. The changes that have already occurred are: GEvent's that are sent by GWIN components have had the field containing the GWIN handle renamed to 'gwin'. Eg For GButtonEvent, pe->button has become pe->gwin. All GWIN events now have commonly named (and positioned) members wherever possible. All driver makefiles have been renamed "driver.mk". Although this was the name used by some drivers previously, it is now used for all driver makefiles. You may need to alter the includes for drivers in your project makefile. The changes that will be happening within the next month (depending on how quickly we get it done) are: The driver infrastructure will be changing to support multiple drivers of any type. Previously multiple displays were the only multiple driver situation allowed. Unfortunately this will change the driver API for most drivers. Any drivers in the repository will be updated but any custom drivers in a users project will require modification when this is released. If you have a driver you would like us to upgrade for you as part of this transition then please send us it now to add to the repository. Note: custom board files will not need to be modified - only custom driver code. As part of the driver structure transition, the current configuration settings for multiple displays will change. If you use multiple displays, you will need to change your gfxconf.h once this change is released. A number of old deprecated API functions that still compile will be removed. In most cases these functions currently produce a compiler warning so you should be aware already if your code currently uses these functions. An example is the old functions for loading images from various sources. These were replaced with functions that use GFILE to load the image some time ago. For most users these changes should result in little or no changes to their project code. If you have any difficulties with the changes please let us know in the appropriate section of the forum and we will help you where we can.

It is also possible that your fonts are not valid ttf fonts (atleast as far as the freetruetype library is concerned). Try converting a known working font such the UI font found in the repository. That will tell you whether it is the font converter or your fonts that are the problem.

The framebuffer driver is not the best one to model it from. Monochrome drivers don't fit into the framebuffer model because there is more than one pixel packed into a byte. To add that capability to the framebuffer would needlessly complicate the code. Instead try using the PCD8544 driver as a base. It also is a monochrome driver running over SPI.