inmarket

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.

Those changes have been put back into the repository. I also removes the Portrait and Landscape orientation cases as they are handled automaticly by the higher level code. I have also added your board file to the boards/addons/gdisp directory. Thank-you.

Good catch. It is now fixed in the repository. There are two cases for the close - one with GWIN_BUTTON_LAZY_RELEASE and one without. In one case it was using the wrong destroy routine which would have caused the lockup, in the other it wasn't sending the close event. The close event MUST be sent before the destroy because the send code accesses the structure to get the tag to put into the event. You are right, line 312 was a typo and has also been fixed. Thanks.

This has now been fixed and a GEVENT_GWIN_CLOSE event is now sent. Because I have changed the structure slightly for GWIN events you may have some small changes to make in your code. Basically pe->button, pe->slider, pe->frame, pe->list etc have all been renamed to pe->gwin (being the handle of the window creating the event). All GWIN event structures now have the same "type", "gwin" and "tag" elements.

Thank you for this great work. We will add it to the master repository.

I will re-add this event for you asap. I am thinking of adding events for all gwin significant opens such open, close, resize. Now might be the time to do it.

This bug has been found and now fixed.

The c standard says that undefined macro variables if used in an expression will evaluate as 0. Not all compilers always follow the rules though. Try... #if defined (var) && var == 8

Write the save routine to output the data to a debug console in binary hex. You will then be able to read the results and potentially hard code them into your load routine. Note the data is binary not text and may contain as ascii null characters.

General anti-aliasing is a hard thing. With some displays it is actually impossible. Anti-aliasing requires knowing the surrounding pixel values. If a display has no read back capability this obviously cannot happen. With text anti-aliasing on these types of displays we can still anti-alia but only if we are also filing the background. So, any general anti-aliasing support will only ever be possible on certain types of display. This is the primary reason it had been low priority for us. There is just so much else to do.

Send us your board file and/or the link to your repository and I will add it ti the official ugfx repository as either a full board definition or in the boards/addons directory. It is a pleasure to help where we can. Well done on getting it going.

It is pretty hard to tell from the video however it appears it might be a problem with the back-light or with the display not being driven. Close visual inspection might help you determine which is happening. For a back-light issue: At reset it appears the backlight turns full on and then partially fades out leaving horizontal bars. Check the black-light is set to 100% and this is done as a solid logic level drive rather than a PWM signal. A PWM signal to the back-light at too high a frequency might cause this behaviour. If it is definitely the backlight but not a PWM issue then there is a hardware fault with the LCD panel. If it is not the back-light: It appears as if the display might not being driven at all. That explains the "fade" affect as the capacitance on the display charges or discharges. Perhaps the display is still in the "OFF" state or the address you are using to talk to the display is incorrect. Check the board file for the display matches your physical display connection. Double check that the display controller is what you think it is and that it matches the driver you are using. There are many E-Bay purchased displays that are mis-labeled with regard to their controller chip. Also, because physical line length to the display significantly affects timing, use the shortest possible connections between the display and your board. In your board file also choose the most conservative timings possible at least until you have the display operational. Hope that helps.

The rawrtos code has been added to the repository. There were a couple of minor changes made to the code for compatibility with other platforms so can you please test it to make sure I haven't broken anything? For the helper2416 board, in your code parts of the mouse and video drivers have been located in routines outside the uGFX framework. Whilst this is fine for the video driver as it is localised to the hardware specific board file, I will have to think about how to integrate the mouse driver so that uGFX driver can be stand-alone but still allow you to share part of the driver code with systems outside of uGFX. I should get this done over the next week or so. Many thanks for your great work.

If using consecutive tag values starting from 1, 0 as the do nothing case works well as the compiler should generate a switch jump table where 0 is the first element of that table thus leading to the most efficient code (no table offsets to add by the compiler).