Joel Bodenmann

We're proud to announce that uGFX Version 2.3 was released just moments ago. Download The 2.3 release can now be downloaded as a ZIP archive form the downloads section. If you're a student or hobbyist and therefore permitted to use uGFX free of charge please consider donating to the project to help us developing this library. Donations can be submitted through the Paypal donation button on the downloads page. Changelog Let's have a look at the change log: FEATURE: Added more events to the slider widget FIX: Clean up visibility issues FIX: Correct moving of containers FIX: Fix GTIMER bug that could cause all timers to stop. FIX: Various minor driver fixes FEATURE: Add support for STM32 CCM memory with DMA in SSD1289 and SSD2119 FEATURE: New Tabset GWIN widget FEATURE: New keyboard driver interface with drivers for Win32 and X FEATURE: Support for keyboard layouts for non-english keyboards FEATURE: GDISP now supports pixmaps (in memory drawing) FEATURE: Rename files to improve experience in certain brain-dead IDE's FEATURE: Add a checkbox "Toggle Button" custom draw FEATURE: Add Tetris as an application demo FEATURE: Add HY-MiniSTM32V board support FEATURE: Add GWIN feature to flash any window/widget FIX: Lots of GDISP monochrome drivers fixed FEATURE: Added TLS8204 GDISP driver FIX: Fixes for the board files for Olimex SAM7EX256 FEATURE: Add a number of UEXT connector board files for Olimex SAM7EX256 FIX: Fix for error rounding in gdispFillConvexPoly() FEATURE: Vastly improved gwin arrow button drawing FIX: GINPUT toggle fixes FIX: GFILE_ALLOW_FLOAT compile error fixed FIX: GFILE_NEED_STDIO compile and emulation errors fixed FEATURE: Added STMPE610 driver by lliypuk FIX: Corrected self calibration code for driver STMPE811 FEATURE: Added Mikromedia Plus STM32-M4 board based on work by lliypuk & inmarket FIX: Work to improve the gdisp SSD1963 driver FEATURE: Added SSD1351 gdisp driver FEATURE: Added SSD1331 gdisp driver FEATURE: Added arduino as a GOS supported operating system FEATURE: Added additional pixel format's FIX: Color components fixed for some strange compilers FEATURE: Added GWIN virtual keyboard widget FEATURE: Added gwinListSetSelected() FEATURE: Added gwinListViewItem() FIX: GDISP driver color conversion when GDISP_PIXEL_FORMAT != GDISP_LLD_PIXEL_FORMAT Beside many fixes and general improvements some new features have been added to the library: Tabset The tabset is a new container that implements real tabs. Until now radio buttons with the custom tab rendering had to be used to create tabbed menus. This new container provides an easy to use API to dynamically create tabbed menus that can either fill just a portion or the entire area of the display. The API reference of the Tabset container can be found here: http://api.ugfx.org/master/group___tabset.html Keyboard interface A new interface has been added to the GINPUT module in order to process keyboard inputs. This new interface can be used to handle any kind of keyboard whether it be a real physical full sized QWERTY keyboard, some numpad or a virtuall on-screen keyboard. The keyboard interface API can be found here: http://api.ugfx.org/master/group___keyboard.html Keyboard Widget A keyboard widget as been added to GWIN which allows to display a virtual on-screen keyboard on a touchscreen device. The keyboard allows to dynamically change the layout during runtime. The API reference of the Keyboard widget can be found here: http://api.ugfx.org/master/group___keyboard.html Pixmaps A new feature called 'pixmap' has been added to the GDISP module. Pixmaps are framebuffers that can be created dynamically during runtime in RAM. These framebuffers allow to execute drawing / rendering operations directly in RAM and just blit the finished result to the display when finished. This can improve the performance of the system vastly as the main systems RAM is way faster to access and burst-writing a buffer to a display is faster than pixel-based access. Pixmaps can be created of any size during runtime. It's furthermore possible to blit the same pixmap to multiple different locations on the actual display. Pixmaps behave like real displays and are therefore very easy to use as any GDISP drawing/rendering function call can be called on them. The API reference for Pixmaps can be found here: http://api.ugfx.org/master/group___pixmap.html Drivers A few new display drivers have been added to the library: TLS8204, STMPE610, SSD1331, SSD1351 Arduino An Arduino port has been added to the GOS module. Therefore uGFX can now run out of the box on any Arduino system. Comments and any kind of feedback is welcomed!

The RAW32 port is is located under /src/gos/gos_raw32.*. Link for lazyness: https://bitbucket.org/Tectu/ugfx/src/88 ... ?at=master I'm sorry to disappoint you but there's currently no such widget. Implementing your own custom widgets is however feasible assuming that you know your C. There are already many examples and we're happy to help should you face any problems. ~ Tectu

Hello zaher and welcome to the community! It's no problem at all to use uGFX without the make build system. However, as every IDE is different we didn't write any useful step-by-step guide. What you basically have to do is go through the src directory file by file and add what you need as you described yourself. This article might help a bit but don't expect too much. It is furthermore possible to use uGFX without any underlying OS at all as well. We provide a port that is called RAW32. This port can be used to run uGFX on any system. All you have to do is to implement two function regarding delays. These are basically just a matter of dividing and multiplying your systick and there are some examples available so the implementation should be pretty straight forward. To directly answer your question: What you need is the GDISP module, the GOS module (the RAW32 port) and the required GDISP driver. Personally I'd like to suggest to follow this guide in order to set up a working project for your STM32F429i-Discovery. Once your project is working adding uGFX will be very easy as the required display and touch drivers are already part of the official repository. Upgrading to an underlying OS such as ChibiOS/RT afterwards will be pretty easy as well. If you have any questions please do not hesitate to ask. We like to help where we can. ~ Tectu

I hope this will not end in a GarbageCollector extension for uGFX :lol: :twisted: ~Tectu

Thank you for bringing this to our attention. We will have a look at this ASAP. ~ Tectu

Wow, nice job! Keep up the good work! ~ Tectu

A bug regarding the minimize, maximize and close buttons of the frame widget has been fixed. Related Forum post: viewtopic.php?f=9&t=209 Commit: https://bitbucket.org/Tectu/ugfx/commit ... c697d4304e ~ Tectu

Hello TriZet and welcome to the community! Thank you for reporting this bug. We will take a look at it as soon as possible and let you know when it's fixed in the repository. ~ Tectu

Very nice! Keep up the good work! ~ Tectu

Did you ever try to / succeed in getting some I2C / SPI output on your microcontroller without uGFX running on it? Maybe you just forgot to enable the peripherals clock or setting the pin mode correctly. ~ Tectu

What hardware platform are you targeting? This might definitely look and feel a lot less smooth on a small microcontroller ~ Tectu

If you don't want to do it manually then the best option is to use an existing library. I don't know specific embedded solutions for this but I guess any C INI file parser that you will find using google will work. If you don't have the required resources then the best option is always to create your own set of configuration and settings structs and save them in binary to a file. You can then simply read back the raw data and cast it into the same struct again. You'll find a lot of examples on how to save and restore structs to binary files in C using google. ~ Tectu

Same here, sorry. I won't have any time until Tuesday evening next week. ~ Tectu

Looks like the actual link is missing. ~ Tectu

With the RA8875 it is a bit border line... I think we should indeed provide split drivers (GDISP only and GINPUT only) that work independent from each other as with every other touchscreen module. However, we can still provide an easier-to-use driver that is part of the /drivers/multiple directory. This way a user using the RA8875 can simply include one driver and everything else will work out of the box. It would basically be the same as for the Windows and Linux drivers. ~ Tectu

Hello kalevik and welcome to the uGFX community! All the GWIN API is thread safe. Most libraries have really big problems when it comes to multi-thread drawing. However, uGFX is one of the few that has no issues at all with that. You can draw from as many threads as you want. The only thing where uGFX is not multi-thread safe is the GFILE module. ~ Tectu

Well inmarket pretty much mentioned every point. Just one more thing: Yes the wiki page is currently out of date on the GINPUT board file and I will put this on my higher priority list. However, please note that the wiki is just giving you information on how to implementing a board file and not the actual driver. The driver is part of the uGFX library and as inmarket already said it needs some advanced coding skills and hence we have not put up documentation on that yet. The board file on the other hand just describes how the interface between your microcontroller and the touch controller works. To use an existing driver you just have to implement the board file. The uGFX driver will use the functions in the board file to communicate with the touch controller chip. ~ Tectu

If the GTIMER module is not enabled then the module does not require any stack. The amount of stack required depends from application to application. We put the default to 2k because this way it works with every even so complex application that we tested so far. However, it is possible to work with 1k or even less but that needs rigorous testing to be sure that it works reliably. But that's something that you have to do. As a general rule: All the module specific settings in your configuration file do not have any affect as long as the corresponding module is disabled. ~ Tectu

Can you please give us some information about your hardware setup, the toolchain that you are using and most importantly: Please include the full (stack) back trace from your debugger when hitting the hardfault. ~ Tectu

Can you please give a detailed description of what is not working? We need all the information that we can have in order to help you. What do you see on your screen? Is the backlight on? Did you see the startup logo? Are you using a dev-board or is it breadboard with long wires? etc... If you see artifacts or garbage on the screen a photo is always helpful as well. ~ Tectu

With these kinds of things the supplier usually gives you some arduino library to download. It often helps to take a look at the initialization code there. ~ Tectu

To answer your other question: The reason why you have to tell uGFX which OS you are using is so that you can easily use the same application with different underlying systems without any modifications. And as you see this is exactly what you want and one of the main advantages of using uGFX: It is totally portable. ~ Tectu

It looks like you're not including the c standard libraries hence you are missing NULL. About M_PI: This is sadly not properly defined in the C standard and every compiler / library does it differently. These days you usually just have to #include (which is already done for you) and tell the linker to use the math library (you need to pass the -lm flag to the linker). I don't know how you would do this in Keil, sorry. I'm sure Google will help. If you want to bypass the problem for now just make sure that GDISP_NEED_ARC is disabled in your configuration file. getpin_pressed() is a function that the GINPUT driver polls to see whether the touchscreen is pressed or not. This function need to return TRUE when the touchscreen is pressed and FALSE otherwise. Note that in case of the ADS7843 controller this is actually a dedicated pin (PENIRQ when I remember correctly). You can simply hook it up to a GPIO and return it's state. These two functions are called by the GINPUT driver at the beginning and at the end of a communication with the touch controller. These functions are very helpful when you happen to have more than one device talking on that bus etc. In your case, you can simply pull the CS line low in aquire_bus() and high in release_bus(). I hope that helps. ~ Tectu

I like where this is going. It would be neat if we could provide official Teensy (3.1) support at the end of this ~ Tectu

A wild guess: Make sure that you disable all the filling, hardware clear and streaming features in the drivers config file. When you try to draw something the GDISP module will actually try to optimize it as far as possible using hardware fills etc. If you have these functions linked but empty nothing will happen. If that is not the problem can you please elaborate how you "manually draw pixels"? Sorry for not answering your linked question yet. Inmarket and I are currently both very busy. We'll get back to you ASAP! ~ Tectu