Joel Bodenmann

Thank you very much for your feedback. We put everything into our ToDo list.

Hello Serge, Although the GINPUT module provides the necessary infrastructure to detect short and long clicks (GMETA_MOUSE_CLICK and GMETA_MOUSE_CTXCLICK), these information aren't being forwarded to the GWIN module. Each widget interprets the mouse actions separately as it turned out that meta information such as click and long-click have very little semantic use on the widget level. Widgets receive mouse down, mouse up and mouse move events. There's no "click type" or other meta information inside the GWIN module. There are two possible things that you can do: Manually hook up a listener to the mouse that receives and processes the click and longlick events provided by the GINPUT module. Then you'll have to map those to the button widget events. That's a very cumbersome solution and not the recommended way of doing this. Create a custom button widget that sends the click type information via the event structure. This is the recommended way of doing this. You can copy-paste the existing button widget (the files /src/gwin/gwin_button.c and /src/gwin/gwin_button.h) and start a GTIMER in the mouseDown() function of the widget and stop it in the mouseUp() function. If the timer fires within that time you know that a long-click happened, otherwise it was a short-click. You can then add that information to the event structure that is sent to the connected listeners. We strongly recommend following the proposed solution 2. It's the proper way of doing this and it fits the uGFX philosophy and won't cause any problems when updating to future versions. There's an article that talks about custom widgets, we strongly recommend giving it a read: http://wiki.ugfx.org/index.php/Creating_a_widget Please don't hesitate to ask if you have any questions. We are happy to help whereever we can.

@czhou Could you try the driver that's now part of the official uGFX repository and let us know whether everything works as expected? Thank you again for your contribution! We appreciate it a lot.

We took a look at the issue with the monospaced font. The problem is that the font that you're using is already broken. It seems like all characters use a width of 547 but the space character is only 500 wide. Therefore the font engine encoder doesn't recognize the font as a monospace font and the width calculations won't be correct. According to FontForge the font has some other issues as well. I'm sorry but there's nothing we can do if the font itself is broken.

I just checked your project configuration: The reason you don't see the startup logo is because the startup logo is drawn using a white color. Your startup color is white too so you just don't see it Note: You should take the gfxconfig.h file out of the uGFX library directory and place it in your Inc directory. It's part of YOUR project, not of the uGFX library. If you want to update to a different uGFX version in the future you just want to replace the uGFX directory. If you'd do that now, you'd loose your configuration file. I'm sorry but I don't understand your question regarding the FatFS. Can you please explain what issues you are facing? My previous post contained the information what you have to do. Yes, it's possible to dump raw pixel data anywhere on the display. You can do that by using the gdispBlitArea() function. For more advanced needs, you might want to consider the use of pixmaps. Note that the pixel buffer you pass to the gdispBlitArea() function needs to use the same pixel format as your display driver. Therefore, if your display driver is not using RGB888 you will have to convert the pixel format prior to calling gdispBlitArea().

That might be related to a rounding issue. Thank you for providing the corresponding font files - we'll have a look at it during the next week. Well, as you mentioned this topic has been discussed already multiple times. Please follow the advice/guide in the corresponding forum thread. Note that you will find other similar forum threads using the forum search. Especially note the known issue where pixmaps can't be used in single-file-compilation mode as the documentation mentions. We (inmarket) is currently working on resolving this issue. If you are not able to track down and resolve the issue with the existing information, please let us know what compilation errors you get. We can't help you if you don't provide all the available information.

There's no other dependencies for the startup logo. The logo is very crude as it's drawn with nothing but rectangles to ensure that it doesn't take up any code space and that it works on any platforms. If the GDISP module is enabled, the startup logo will show when GDISP_NEED_STARTUP_LOGO is set to TRUE. The µGFX-Studio is currently in beta and that for good reason: As you mentioned it's far from complete. Right now the µGFX-Studio is useful as a layouting and prototyping tool to get started quickly. Both the download page AND the "New Project Wizard" inform you that the µGFX-Studio is far from complete and not meant to be used in a productive environment. We are working on the µGFX-Studio but right now it has lower priority than the µGFX library itself. We are happy to hear your feedback, bug reports and feature suggestions in the corresponding µGFX-Studio forum thread: https://community.ugfx.org/topic/371-release-beta-v014/ After all the more user feedback we get the more we'll put time into it. What problems are you facing? You need to give a lot more information than just "I am having a problem" or "It doesn't work" in order for us being able to help you. As mentioned in the previous post you might want to start off using the built-in FatFS module to ensure that everything is working. Then, if you want to replace it with a different version, just replace the FatFS directory under /3rdparty. Depending on the changes to that version you will have to slightly modify/update the FatFS wrapper which you can find in /src/gfile/gfile_fats_wrapper.[ch].

The proper way of doing something like this is having to separate labels: One for the text and one for the numeric value. This helps with a. If you want to further decrease flickering (and improve the overall FPS performance) you might want to consider using pixmaps: http://wiki.ugfx.org/index.php/Pixmap The way you solve b. might be a bit over complicated for no reason: Simply use a mono-spaced font. You can apply a font to just one individual widgets. Therefore, you can have a monospaced font that you just apply to the labels that contain numeric values and you can use a different font for all the other widgets. You apply a font by using gwinSetFont(). Note that having one label per digit is a very bad idea in terms of flexibility and especially memory and CPU requirements. Regarding c.: I'm not sure what you mean. The label widget comes with three built-in rendering routines: Align right, align center and align left: https://bitbucket.org/Tectu/ugfx/src/25802124fb64a949971a89dd2ef34b749d949494/src/gwin/gwin_label.h?at=master&fileviewer=file-view-default#gwin_label.h-112 Please do not hesitate to ask if you have any further questions or if we need to clarify something.

Ah okay, sorry for not providing a helpful answer then. Glad to hear that you got it working, though!

I'm not exactly understanding your question / your concern. You are not supposed to mess with ginputCalibrateMous() or anything else yourself. Implement the board file and that's it. The struct you have in your board file allows you to configure many things like the calibration tolerances and so on. Don't modify anything else. If you are just using a regular setup with just one touchscreen there's also no need to ever manually use any of the GINPUT API. The ginputCalibrateMouse() function is called automatically for you unless you have disabled it. It's also possible to load calibration data that has been obtained by a previous calibration process. If the loading of calibration data succeeded, the calibration screen won't be shown on startup. You can find all the information needed here: http://wiki.ugfx.org/index.php/Touchscreen_Calibration

Are you able to drawing anything else on your display? If the startup logo doesn't show up when GDISP_NEED_STARTUP_LOGO is set to TRUE this most likely indicates that the display isn't working at all. This can either be a physical issue (eg. wiring) or an error in your board file. The µGFX library includes its own copy of the FatFS library for compatibility reasons and for ease of update. If you don't want to replace the actual FatFS directory in the /3rdparty directory of the µGFX library (which we don't recommend) we'd suggest you use the one provided by µGFX. You can access the built-in FatFS library from outside the µGFX library without any problems. Note that we strongly recommend to ALWAYS use the high-level API provided by the GFILE module. This keeps your application portable, allows you to use multiple file systems at once and brings a few other advantages.

Glad to hear that you got it working! Regarding the startup logo: You can find the corresponding setting in the configuration file documentation. It's explained here: http://wiki.ugfx.org/index.php/Configuration Look out for GDISP_NEED_STARTUP_LOGO

Yes. The linked forum post lists the available options: Use a library that provides working setjmp() and longjmp() implementations Get the provider of your library to fix their broken implementations (experience tells that they won't care much) Implement your own setjmp() and longjmp() functions Implement your own context switching assembly code in the existing GOS threading Use an RTOS Sorry, there's not much else we can do here. We try our best to be as flexible as possible but if the 3rd party underlying system is broken it's difficult to make something functional out of it. For instant success you definitely might want to consider using an RTOS. Personally I may recommend ChibiOS/RT and FreeRTOS.

Well either the registers are incompatible - in which case you might be able to simply copy and modify the existing code for the Cortex-M0 - or the assembly syntax used isn't compatible with the compiler that you are using which is a huge pain in the ass.

Yep, sadly as the linked forum posts mentions it's a very common problem that functions like setjmp() and longjmp() aren't working correctly in embedded libraries. It seems like they are simply not tested at all. This even happens with libraries from large companies like Keil (which is ARM itself). We have implemented a scheduler ourselves for all the Cortex-M series including the Cortex-M0. I'm not sure about the Cortex-M0+ but I think that the Cortex-M0 scheduler should work on it just fine. You can enable it by setting GFX_CPU to GFX_CPU_CORTEX_M0 in your configuration file.

It seems like you are missing the configuration for the GOS module in your configuration file: http://wiki.ugfx.org/index.php/Configuration#GOS In your case you want to have at least this minimal configuration: #define GFX_USE_OS_FREERTOS TRUE #define GFX_COMPILER GFX_COMPILER_KEIL #define GFX_CPU ...

Sure, let us know how the test went. We're looking forward to resolving your issue

The GINPUT module will automatically enable the GTIMER module as it's a dependency. Check your compiler output log. You should get a corresponding #warning that tells you that this happened unless you set GFX_DISPLAY_RULE_WARNINGS to FALSE (which isn't a documented feature).

We checked your µGFX-Studio files and everything looks good there. I assume that you are able to see all widgets in the preview that you can generate by clicking the green arrow in the toolbar - is that correct? Sadly we're not able to compile and test your project as we lack the required tools and hardware. We took a look at the project and we couldn't spot anything that's obviously wrong. Can you please check the values of the GHandles that are returned by all the gwinXxxCreate() functions in the guiCreate() function? If some of them are NULL this might indicate a lack of memory which would explain why you only see some of the widgets. You can find more information regarding the memory management on bare metal systems here: http://wiki.ugfx.org/index.php/BareMetal#Built-in_memory_manager If that doesn't help I'd recommend you to start off a clean project that doesn't do anything but flashing an LED and then add the µGFX GUI. It seems like your project still contains unrelated code for manually handling the touchscreen and so on. A couple of general remarks: Take the gfxconf.h file out of the µGFX directory and place it in your project directory. It's part of the project, not part of the µGFX library. This way you can easily upgrade to newer versions of the µGFX library in the future by simply replacing the µGFX directory. You can make your GUI look better by using WidgetStyles, custom rendering routines or by writing custom widgets. If you are using an explicitly supported platform, enable it in the configuration file: http://wiki.ugfx.org/index.php/GOS#CPU If you are using an explicitly supported compiler, enable it in the configuration file: http://wiki.ugfx.org/index.php/GOS#Compiler I'm sorry that we can't give you a guide to success. We have never encountered this problem before. Please don't hesitate to ask if you have any other questions. We are happy to help wherever we can.

Can you tell us what you're not understanding? We are happy to help wherever we can but we need to know what the problem is. You can find many examples of configuration files in the /demos directory of the µGFX library and the download section on this website: https://community.ugfx.org/files/ This article shows all possible configuration options and links you to the corresponding parts of the documentation that explain them: http://wiki.ugfx.org/index.php/Configuration Note that the display driver that you want to use (eg. SSD1289 in your case) is not part of the configuration file. You add it by simply linking against it. In case of you're using the Makefile build systems you can simply include the drivers makefile: include $(GFXLIB)/drivers/gdisp/SSD1289/driver.mk Besides the part for the GOS module the configuration file doesn't contain any platform specific configuration. That's why you can use a tool like the µGFX-Studio to automatically generate the configuration file for you.

Glad to hear that! Thanks for your positive feedback! If you're interested you can post your project in the "User Projects" section in the forum - or, if you'd like - we can give you a separate blog: https://community.ugfx.org/blogs/ In any case we'd appreciate any kind of pictures - especially if you allow us to use them in the demos section of the homepage.

I removed those "ToDo" marks from that page to prevent further confusion. They were meant in the documentation context: The documentation of the existing feature is on the ToDo list It's correct that most often you use the toggle interface for the rotary encoders 'push' action and the dial interface for well... the rotary action.

The GINPUT already has working and usable interfaces for physical buttons, switches, potentiometers, rotary encoders and so on. These interfaces are called "Toggle" and "Dial". We understand that those names are not the best and might even be misleading but it's the best we could come up with at the time. After all this stuff was written even before the name "µGFX" existed. There's a lot of stuff we'd like to rename but that's something we can't do before the 3.0 release as backwards compatibility would be broken. The toggle interface allows to interface physical input sources that provide digital values/states such as push-buttons and switches. The dial interface allows to interface physical input sources that provide numeric values such as potentiometers and rotary-encoders. The toggle and the dial interface of the GINPUT module are integrated into the GWIN module just like the mouse and the keyboard module: When you add a rotary encoder and you register it properly through the highlevel API, certain widgets will automatically use these input sources when appropriate. For example, the list widget will automatically scroll through the list if you attached a dial to it. A button widget will automatically be pressed if you attached a toggle to it and so on. You can find the corresponding actions in the widgets VMT: http://wiki.ugfx.org/index.php/Creating_a_widget#VMT Of course you can also manually interface these input sources via the high-level API. The advantage of this is that thes einput sources are integrated into the GEVENT system and that you can write platform independent - and therefore portable - code. Now, to be honest at this moment there's only the API documentation (and the source code) available as a documentation source. The wiki doesn't contain any documentation about those yet. However, you should be able to get it working anyway as the interfaces are pretty straight forward to use. Both toggle and dial inputs are interfaced through board files just as with the displays and the touchscreens. I'd recommend you browsing through the corresponding files that you can find in the /src/ginput/ directory. If you have any questions please do not hesitate to ask. We are happy to help wherever we can.

Hello and welcome to the community! Thank you very much for sharing your driver. We will take a look at it and add it to the repository. It would be great if you could post more pictures of your project once your display stuff is done. We'd really need more pictures for our demos section on the website.

All you have to do to use the MCU driver is to copy the board file /drivers/ginput/touch/MCU/gmouse_lld_MCU_board_template.h to your project and rename it to gmouse_lld_board.h. The rest is supposed to work out of the box. It's correct that the GINPUT module will periodically call read_xyz(). This is done through a GTIMER. If it's not working then most likely the GTIMER thread crashed. This can have a couple of different reasons. The most popular ones are that the stack size of the GTIMER thread is too small or that the scheduler isn't working properly. In either case the proper way to debug this is to verify that the GTIMER module is working correctly. Increasing the stack size of the GTIMER thread is fairly easy and can be done in the configuration file as explained in the corresponding documentation. However, the default value is already very big and shouldn't cause any problems UNLESS you are running other GTIMER jobs too. As the documentation explains all GTIMER jobs share the same stack size. If one of them needs more than what the GTIMER module provides it will crash. The more likely case is that the very minimalistic scheduler that's implemented in the RAW32 bare metal port is not working correctly on your platform. The way to check this is to create two threads using the GOS threading API. It's enough to simply toggle an LED in each thread - or, if your display is already working - to increment a counter. But in that case make sure that you enable multi-threading support in the GDISP module by setting GDISP_NEED_MULTITHREAD to TRUE in your configuration file. Please report back your testing results and let us know which architecture/platform you are working on. In case of it's not a specifically supported one note that there's a known problem that causes the scheduler not-to-work: Bugs in the setjmp() and longjmp() function in the clib of embedded toolchains seems to be a very common thing: https://community.ugfx.org/topic/380-f429discoveryraw32-hardfault-after-mouse-calibration/#comment-2828 In case of you are using a platform that is specifically supported by uGFX make sure that you enable the corresponding GFX_CPU_xxx support in the configuration file. Note: Just in case of you're interested, you can find an explanation on why µGFX doesn't provide an interrupt based interface for reading the touchpanel here: https://community.ugfx.org/topic/327-touch-driver-in-semi-polling-mode