inmarket

It sounds like there may two possible problems with this... 1. The gfile api is not thread safe. In other words you must not allow two different threads to be calling the api at the same time. If they are calling at different times and there is no overlap then everything will work. 2. Perhaps something has ended up in thread local storage rather than global storage. This would be something strange about the operating system you are using and it's use of memory (yyou didn't specify which). Of the two, number 1 is the most likely problem. If you don't think it is that then you will need to debug to see what is going on.

Yes the stm32429-idiscovery board uses SPI during initialization of the graphics controller. It is however only used during initialisation. The trick to being able to do both comes down to the chip selects associated with the two peripherals. I am not looking at the code now but typically we use an aquire_bus() and release_bus() call in each board file to arbitrate between 2 devices on the same bus. Examine those routines in the graphics controller board file and the corresponding code in the fatfs wrapper and you should be able to get them both to work. From memory the touch initialisation occurs after the lcd initialisation.

The STM32F429i-Discovery LCD driver has been updated to fix shimmering effects with half-tone colors.

I have updated some of your changes back into the master repository. A few things to check... Can you please check that the pin set up's are correct in the ChibiOS_Board file in the master repository to allow the SD-Card to work. I have run out of time to test it myself this weekend. I have added the sdio pin check from your code into that board file. In your board file - you have the direction's swapped in the setreadmode() and setwritemode() routines. This will only be a problem if you put the display into low power mode. I have raised the refresh rate back to 73Hz. 60Hz created noticeable flicker for me when lights are on. I guess this is a frequency difference effect with the mains light (I am in Australia which has 50Hz mains). This display seems extremely slow. I can see it filling the screen eg change the color scheme in the widget demo. This is surprising given that it is a parrellel interface. Compared to the Mikromedia-STM32-M4 board (non-plus) which should be very similar and several other boards which use SPI interfaces (which should be much slower) this display is a LOT slower. I am not sure if it by nature of the display controller, an issue with the CPU running much slower than what it should, or some other problem. Can you please look at it and see what you can find. In light of the above I have removed the delay in the write-strobe in the board file. This still works and seems to help with the speed a little. It might need to be reversed if you find the problem was perhaps CPU configuration related.

These warnings have now been fixed. The FT5x06 driver and STMPE610 driver have now also been updated with the self-calibration fixes.

I have added a method to fix the touch calibration load/save initialisation order problem. Read this article: http://forum.ugfx.org/viewtopic.php?f=9&t=169&p=1284#p1284

I have added a feature which should solve this problem. You will be able to allow gfxInit() to initialise the operating system and just define a routine with your extra initialisation code that needs to happen before anything else. Read this article: viewtopic.php?f=9&t=169&p=1284#p1284 It also contains simpler load and save routines for the calibration data and fixes an allocation fault in your load routine.\ Let me know if you have any problems with the new method of fixing this problem.

In some cases it is necessary to perform various initialisation tasks after the operating system is initialised but before certain other modules are initialised. An example of this might be when you are using GFILE to load calibration data while GINPUT is initialising the touch. That is, It may be necessary to start the block device (eg chibios's sdcInit()) after the operating system initialisation but before GFILE loads. Previously the solution was to define GFX_NO_OS_INIT, initialise the operating system yourself, initialise the block device and then call gfxInit(). This was obviously a complicated solution to an initialisation order problem. We have now defined a macro GFX_OS_EXTRA_INIT_FUNCTION which you can put into your gfxconf.h file which contains the name of a function that is called immediately after gfxInit() initialises the operating system. As an example... In your gfxconf.h: #define GFX_OS_EXTRA_INIT_FUNCTION ExtraOSInit #define GINPUT_TOUCH_USER_CALIBRATION_LOAD TRUE #define GINPUT_TOUCH_USER_CALIBRATION_SAVE TRUE In your main.c: #include void ExtraOSInit() { // Initialise my SD-Card device which is used by GFILE. sdInit(&sdcard_params); } bool_t SaveMouseCalibration(unsigned instance, const void *data, size_t sz) { (void)instance; GFILE* f; if(!(f = gfileOpen("calib.gfx", "w"))) return FALSE; if(gfileWrite(f, data, sz) != sz) { gfileClose(f); return FALSE; } gfileClose(f); return TRUE; } bool_t LoadMouseCalibration(unsigned instance, void *data, size_t sz) { (void)instance; GFILE* f; if(!(f = gfileOpen("calib.gfx", "r"))) return FALSE; if(gfileRead(f, data, sz) != sz) { gfileClose(f); return FALSE; } gfileClose(f); return TRUE; } void main(void) { // Initialise uGFX gfxInit(); // Everything is ready to go and mouse calibration data would have been loaded if it exists. .... } You can also define GFX_OS_EXTRA_DEINIT_FUNCTION which has a similar effect during de-initialisation.

The GFILE module was not being initialised properly in gfxInit(). In reality this was only an issue if using the NATIVE gfile file system and then using the stdin and stdout equivalent handles. It is now fixed.

GWIN Containers with image backgrounds had the cx and cy parameters interposed. This affected Containers, Frames and Tabset's. This has now been fixed. Thanks to steved.

I will do some testing today and get back to you. Hmm, it's a nasty initialisation order issue of some kind.

That warning can be ignored. I will fix the warning today but it is nothing to worry about and should not affect the operation of the code.

No reason that I know of. There is simply nothing that we should be able to do to cause that given we avoid any interrupt level code in uGFX. The only thing I can think of that might be application related is that maybe one of your stacks are too small in the linker script you are using (either your main stack or your interrupt stack). Another possibility is that you are calling the FAT operations in multiple threads and they are overlapping. The FAT library code definitely does not support multiple threads making simultaneous requests and I don't think we have added any threading protection in GFILE either unlike GDISP which is fully protected from re-entrancy (if you specify GDISP_NEED_MULTITHREAD) and GWIN (by default).

Now fixed.

I can see the problem. I will fix it today. like you said, I missed a break. Sorry.

A compiler warning with GWIN Tabsets is now fixed.

The Mikromedia-Plus-STM32-M4 board has been added thanks to work by lliypuk. Development on this board is not complete and there are likely to be frequent updates over the next few weeks. Currently the board should support display, touch and audio (although audio has not been tested).

Changes to the SSD1963 driver have been made to hopefully make it more compatible with new boards. Those with existing hardware using this driver should test it with the new version and report any problems.

The STMPE610 touch driver has been added thanks to work by lliypuk.

The STMPE811 driver has had its self-calibration capability updated to work correctly on orientations other than GDISP_ROTATE_0

I finally got an opportunity to try the Mikromedia-Plus-STM32-M4 code. I have added the code now to the master repository (with changes). I have some interesting results: The display code that you had wouldn't work for me. There was simply no display at all. Reverting to the standard SSD1963 code worked for me and I had none of the flicker issues that you had. It was rock-solid. I have tried to integrate your code as much as possible whilst still maintaining a working driver. You will see I have defined SSD1963_INIT_METHOD_2. If set in the board file it will use your code (with some mods). Without it, it uses mostly the old code. I have not tried other orientations, changing the backlight level or contrast although I fixed a couple of obvious problems. I will write a test utility specifically for this so that all the drivers can have these functions more easily checked. The touch driver is not working correctly in self-calibration mode. I will need to do more work with this. I have not tried the ugfx audio on this board yet. I have not tried any other hardware (non-ugfx related eg Ethernet, sdcard) yet. My board is labelled V1.02 (just below the SD-Card and above the 2.4G transceiver. Can you please try the latest repository code and let me know how you go. I am particularly interested in any changes you have subsequently made to your source, any changes to the ChibiOS files and how the display driver works for you. Please also let me know what hardware revision your board is. Thank-you for your great help.

When GFILE_NEED_STDIO was set to TRUE there were a couple of sources of compile errors. A/ There were definition conflicts within the stdio emulation routines themselves. B/ A number of GOS emulation layers (eg Win32, X) and supporting drivers require access to the native platform stdio.h file. When GFILE_NEED_STDIO was defined this lead to definition conflicts for these platforms. Both these issues are now resolved.

Setting GFILE_ALLOW_FLOAT to TRUE would generate a compile error. This is now fixed.

Both these compile bugs should now be fixed.

Thanks for finding the bug. Code gets changed and we don't always get to test every code option. I will fix it in the master repository in the morning (too late for me now). Using sprintg is probably the best way to get a float value into a label. Given that you have found this problem it looks like you were heading that direction anyway.