Joel Bodenmann

I'd like to point out that the proper way of doing this is to implement your own custom widget. You can use the existing graph window as part of the widget or implement everything from scratch. In either way, your custom widget will contain a list of the points that need to be redrawn. Under certain conditions this can be optimized as @inmarket mentioned. You can find a guide that explains how to implement custom widgets here: http://wiki.ugfx.org/index.php/Creating_a_widget If you have any questions, please don't hesitate to ask. We are happy to help wherever we can and we'll improve the documentation where needed to clear things up. The only reason why you can use pixmaps is when you are using the single-file build mechanism. If you're using the makefile build system (or manually compiling each file) you should be able to use the pixmaps without any issues. There's no action required to use the pixmaps when you're using the makefile.

Glad to hear that you got it working! Thank you for letting us know!

That's the right decision Let us know if you have any questions.

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.