inmarket

I don't know of any particular keyboard maker. For commercial product these are usually custom designed as part of the case design. Membrane switches are common so perhaps look for a membrane manufacturer. Perhaps a better possibility for a one off project is to look on aliexpress or on ebay. I am sure you will find something suitable for your project there.

The GFILE module supports creating a GFILE based on a ChibiOS BaseFileStream however in ChibiOS V3 the API for accessing file streams has changed. GFILE has now been updated to use the correct API for both ChibiOS V2 and V3. As part of this gfileOpenBaseFileStream() has been renamed as gfileOpenChibiOSFileStream() to improve clarity. For compatibility a #define has been added so that existing code using gfileOpenBaseFileStream() will work unchanged.

The hardware keyboard stuff is working nicely even handling complex operations like scan code conversion. For most hardware keyboards a driver would need to be written as the only keyboard drivers currently in the repository are the Win32 and x drivers. A virtual gwin based keyboard is underway but has been on the back burner due to other demands. I will bring that forward again but no promises on when it will be ready as I am very busy currently with other work. As Tectu mentioned, hand writing recognition is well beyond most embedded platforms.

Also, just looking at your gfxconf.h file, whilst you have enabled bmp images you have not enabled the particular sub-format of your image eg GDISP_NEED_IMAGE_BMP_8. As a first test set all the sub - image formats to TRUE in your gfxconf.h. You can always turn the extra ones off later to reduce code size.

Start with the image demo and get that working first. Once that is working replace the image with your image. If it doesn't display then you have either not enabled the right decoder for your image or there is something funny about the image. I hope that helps you find the problem.

If you need two ranges from the font file there are a few ways of doing this... 1. Find an original font that only has those ranges in it and then don't filter when converting, or 2. Convert the font twice with different ranges and then treat them as separate fonts in ugfx (see the above post). 3. Alter the mcufont library to allow the font converter to accept multiple ranges. If you go to the trouble to do this we would love a copy of the modified conversion utility.

A few things to check... 1. Does the demo work without the image? The reason to ask this is that setting orientation except at the beginning of a program is officially a no-no. This demo has been limited to give that the best chance of working by restricting all drawing to the smallest dimension box. Even so, it may not work on all hardware as it requires both the touch and display driver to support orientation properly. If the button demo works correctly with the button at its new location then move to step 2. 2. Try your demo without the gwinImageCache call. Caching an image takes a huge amount of memory. It may be slow without it but check correct operation first. If it works without this call it means that caching the image has run you out of memory. 3. Try running your program on one of the emulator platforms. If it runs there but not on your hardware I would suspect that something is crashing on your hardware effectively freezing the program. In this case you will need to get your hardware debugger working and see what is causing the exception. Another way of testing for this would be to also create a gtimer that flashes a led on your board say once a second. If that stops then it has crashed.

In your userfonts.h file #include each of the font files generated by the font converter. Eg in userfonts.h #include "font1.h" #include "font2.h"

One more thing, it is probably a good idea to leave changes to the driver as a very last resort. This driver is well tested and has not been known to need changes to get it to work.

A few things... 1. The spiSelect and spiUnselect can go in the aquire and release bus too. This reduces significant overhead especially when transferring data. 2. There is something wrong with the way you are talking to the controller in that you are sending that 0x73 before each transfer. That looks like i2c addressing. If your controller is setup to use i2c then you should be using the chibios i2c api not the spi api. If your controller talks via spi then it almost certainly will not want that preamble. Have a look at some of the other boards that use the spi interface to talk to their controller. 3. There seems to be a problem with the width of the data being sent for an write_index. Although the parameter type implies a 16 bit transfer, in reality I believe it is actually a byte operation (something to cleanup some day in the board file template). Have a look at the display board file for the stm32429-idiscovery board. Although it uses a different driver and has lots of other complications at the driver level, the controller is actually an ILI9341 that is addressed using spi so it's board file should be close to what you need.

To clarify, GDISP_NEED_MULTITHREAD makes gdisp thread safe. GWIN is thread safe because it has been written as thread safe code and talks to thread safe gdisp. GTIMER is thread safe, GQUEUE is thread safe (eexcept for the "I" versions of the functions which designed to only be called at interrupt time. GMISC is thread safe as it has been written as thread safe code, GINPUT is not thread safe but doesn't need to be as event sending is thread safe and that is how you communicate at run time with input devices. GEVENT is thread safe. GDRIVER is not but is typically only called at init time and very seldom by application code. GAUDIO and GADC are thread safe but not multi-stream. GFILE is not thread safe and neither are many of the underlying file system interfaces eg FATFS. We should probably document this somewhere! Making GFILE optionally thread safe is probably a good idea although locking granularity versus complexity will be an interesting design decision. If you are finding that gfileopenfilelist fails if you don't make a open call first, this is likely a problem in the fatfs code itself (third party llibrary). I will investigate and see what I can find.

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.