inmarket

I will look at the offset table problem as soon as possible.

Currently any string handling in ugfx is based on 8 bit characters (ascii, utf8 etc). Changing to 16 bit characters would require appropriate source code modifications. If you would like to attempt this we would love the contribution. I would suggest a new type called "gfxchar" whose definition is based on a gfxconf.h macro eg GFX_NEED_CHAR16.

After Tectu has said all that (to which I agree), the MCU ADC touch driver does work really well as we have put a lot of effort in making that happen. Some dedicated touch controllers have internal bugs that mean they are not as reliable as they should be. Again we have had to spend a lot of time making sure these issues are worked around. For example, I think all the touch drivers currently poll the controller as the hardware interrupt pins are exceptionally unreliable leading to missed touch events and even the touch controller appearing to turn off. Check the code for each touch driver if you are interested in the detail. In conclusion, our preference is for a dedicated controller chip as it can be more cpu efficient however both solutions work well, dedicated controllers no longer have such a clear advantage, lazy touch work arounds are now seldom needed, and cost is allowed to be a factor in the hardware you use.

Thanks Tectu.

Yes and we will tidy that up shortly. It is low on the priority list though because the other code works and the compiler optimiser will likely sort it out anyway.

It is interesting that you got warnings for this as it is part of the C preprocessor standard. A preprocessor variable not defined is treated as having a value of 0 (or false if tested as a boolean). Whilst we have added the define as we like to be complete with our definitions, you might want to tone down the compiler warning settings a little.

Send your code to enter and leave deep sleep and we will have a look as soon as we get a free moment.

The stm32f4-discovery is a bastard display. It uses the stm32 ltdc to run the display but uses a ili9341 controller to initialise it. The interraction between the two, that is a very good question and very badly documented. I suspect that after deep sleep everything is corrupt with the display, both the init provided by the ili9341 and the ltdc stm32 registers. It could even be that the external sdram is now corrupt and needs to be reinitialised or the fmsc registere that allow talking to the sdram. I would suggest starting by looking at the sdram when you come back from deep sleep. If you can read and write from the sdrsm yhen the problem is with the ili9341 or the ltdc. If you cant read/write the external sdram then look at the fmsc registers first and then at the sdram itself. I hope that will lead you to which part is not being restored properly after cpu deep sleep so that you can reinitialise.

Hmmm. Interesting. This is not somethung we have tried but i have a few suggestions that may help... 1. You can try using the gdisp api display power down before going into deep sleep and the the gdisp api power up after returning from deep sleep. This would be the proper way of doing it but i am not sure if those are implemented in the stm32f4-discovery driver. Perhaps you would like to implement them for us? 2. In the absense of driver support, the another way would be to deinit and then reinit gfx itself. This may not be very successful as the deinit code is by no means complete and the gfxInit was never designed to be called more than once. 3. Alternatively manually call the driver init call again when returning from sleep. Normally this is a static routine. You will need to write a wrapper call in the driver file so that you can access it externally and call it from your code. If you would like to attach your code for entering and leaving deep sleep, we will look at the problem when we get some time.

Thank you for the update

Can I please ask when the conversation has completed if you could please post a summary in English of the important points in the conversation so that other people can gain benefit from the outcome as well. Thanks.

Thank you Andrey_13 for helping llya in his native language.

There is now a new gwin textedit widget. It works with both real keyboards and the virtual gwin keyboard. A new demo in demos/modules/gwin/textedit has been written to demonstrate this. All other gwin widgets now have the capability to accept keyboard input although the textedit widget is the only widget that currently implements this. As a result of the new capabilities a new style color element has been added for the focus rectangle. If you statically initialize your style color set you will need to add the new element.

1. Which operating system are you using? Most operating systems define the thread return type as an int so gtimer is correct for them. Check the definition of that type in the gos source file for your operating system. If necessary for the moment either change the type definition or remove the return statement. Let us know and we will fix the issue for your operating system. 2. This form of const definition is an old style definition that means the pointer and the object it is referring to both need to be placed in code space. Unfortunately many modern compilers complain about it (although they still compile it correctly). Semantically however modern compilers are ambiguous. It is a nuionce that has been lost as cpu platforms have grown larger and this sort of functionality has become less important. In practice the code is technically correct and the (incorrect) compiler warning can be ignored. 3. I presume you are talking about a template board file that has been copied but not filled in with real code. In this case the warnings are appropriate as the template files are supposed to be copied into your project, renamed and filled in first. I suspect you have added the template file to your ide build list. If so just remove the template board files from your build list. 4. Can you please provide source file lines for the double definition as this seems strange and is something we will fix. It is unusual in that that is not a problem normally seen. Perhaps there is something wrong in your include lists? 5. This is a harmless warning and comes from the font code being derived from a third party (donated) library. The warning can be safely ignored. 6. I will check this one out. The gdisp driver inclusion order is very vomplex and changes depending on if you are using multiple display controller drivers. I will look and see if things are correct with respect to gdisp_rules.h. Is it causing you any particular problems?

There is currently no example for that ide. The raw32 port is found in src/gos/gos_raw32.c Typically you dont need direct access to any particular file like that as you just set the appropriate option in your gfxconf.h file and then hit the build. The gfxconf.h file controls all the bits of source need to be compiled and which can be turned off to save code size. The is no current table view widget largely because table views are code complex, are low on the priority list and don't generally work well on small screens. If you would like to implement one we however would love to include it in the main repository .

Oops. I got the typedef around the wrong way. Glad to hear you got it working. Nice work! I look forward to seeing what you have done.

I think i under stand the question. You are not sure what to do when the c++ mutex type needs to be used in the gos_xyz.h file. The solution is: gfx_xyz.h typedef gfxMutex void; #define Mutex gfxMutex The gfx mutex function definitions In your c++ file: #include "gfx.h" #undef Mutex #include extern "C" gfxInit (gfxMutex *p) { p = new Mutex; }

You need to compile the ugfx source code with gcc not g++. Your own files however can be compiled with either g++ or gcc as you see appropriate. The ugfx header files are designed to be used by either compiler whereas the ugfx source MUST be compiled with gcc as it is C source NOT C++ source. Whilst C++ is mostly a superset of C and some C programs can be compiled using the C++ compiler, there are also many language incompatibilities. Normally a C++ compiler will detect the language based on the file extension. GNU however takes a different approach - it supplies two different compilers (gcc and g++). You must use the correct one in each case. Make will normally take care of those issues for you based on the file extension. If you are trying to port your C++ operating system into the ugfx GOS layer then there are one of two approaches you need to take... Using the C binding API for your operating system in the GOS layer - most operating systems will provide one Create stub routines in gos_your_os.h for each GOS routine needed. Create a gos_your_os.cpp file that implements each of those routines as extern "C" functions. That source file can include your operating system c++ header files and will be compiled by the g++ compiler without affecting the compilation of any other part of ugfx. As an example: gos_xyz.h extern "C" { void *gfxAlloc(uint32_t sz); void gfxFree(void *ptr); ... } gos_xyz.cpp #include #include "ugfx.h" // Optional - but does pull in ugfx typedefs and function prototypes extern "C" void *gfxAlloc(uint32_t sz) { // Not real code - but using c++ only symantics as an example return new byte[sz]; } extern "C" void gfxFree(void *ptr) { // Not real code - but using c++ only symantics as an example delete ptr; } ...

The uGFX build script support for ChibiOS V3 has been updated to reflect recent changes in the ChibiOS V3 project.

Support for the SH1106 controller has been added to the SSD1306 driver. To use a SH1106 controller include the SSD1306 driver in your makefile and then add the define #define SSD1306_SH1106 TRUE to your gfxconf.h file.

This has been added to the master repository. Thanks!

When you say "8 bits per pixel" I assume you mean 8 pixels per byte. As a monochrome display you will need a framebuffer and flushing will need to be turned on in your config file. GDISP_NEED_AUTOFLUSH is the correct setting to set to TRUE in your driver config file. With that setting turned on the GDISP system makes sure that your driver flush function gets called automatically as needed. Your flush function then needs to transfer the contents of the framebuffer to the controller.

Replacing code in gdisp.c is a big no no. That code is complicated and interrelated. It is driven by the defines in config file in your driver. As I have not looked at your driver controller data sheet, can you tell me about it. Is it monochrome or color, the number of bits per pixel supported, is it a window stream or pixel controller (as per the wiki), does the controller use a dual port ram framebuffer or is the display framebuffer accessible via controller commands? Generally only monochrome controllers and dual port framebuffer should be implemented using a driver using a framebuffer. Monochrome displays require flushing (in the driver config file) but dual port framebuffer typically don't. Look particularly closely at drivers for controllers that are similar in nature to yours.

It is saying you don't have a chconf.h file in your project directory. This is a required ChibiOS file. ChibiOS will also require a halconf.h and mcuconf.h file in your project directory.

I am not sure why your code size has suddenly grown so much but here are a few things to check... 1. The options in your gfxconf file make a HUGE difference to the end code size. Turn off options you don't need. 2. Storing images using GFILE ROMFS will take up a lot of flash. 3. The compiler optimiser can make a big difference but the gcc optimiser is particularly buggy and stops things from working so increase your optimisation one level at a time until it doesn't work. 4. Make sure the link optimiser is turned on in your makefile. It also can make a big difference. With regard to type redefinition, we are playing a losing battle. The commit that you mention was an attempt to do the standard definitions in a more portable way using one of the c standards specified header files. It should have reduced problems for you. Unfortunately the world is not that simple and compilers are seldom really compliant with the standards. It is one of those sorts of problems you have struck. GIven this I have been tempted to go through and create our own type names for these however that is a ton of work and introduces compatibility problems for existing users. I am therefore open to any way you can think to make it more compatible. In the mean time try with those lines reverted to the old method to ensure that that change was the cause of the problem. By the way, you might want to try the alternative schedular branch. It contains updates for the threading support for raw32 and arduino and should prevent hard faults that use to occur. Changes: GOS_RAW_HEAP_SIZE is now called GFX_OS_HEAP_SIZE. Try also defining GFX_CPU = GFX_CPU_CORTEX_M0. Hopefully that last define will use a cpu specific schedular which is much smaller and faster than the generic one. Let me know how it goes for you if you have time to play with it as I am hoping to roll it into the master branch in a couple of weeks.