Joel Bodenmann

Probably we could just typedef the widget tag type so it is a signed value and we can use -1 for an invalid widget (so the user can check for < 0) and use the positive values including zero as the real tag values? Otherwise I'll just note that down in the documentation very very carefully. ~ Tectu

I took a look and I see one potential problem: The gwinGetTag() routine returns the tag of the widget or 0 if it is not a widget. However, it is completely valid to set the tag of a widget to 0. I think that this behavior should be changed. ~ Tectu

We appreciate feedback like this as we see where we have to improve our documentation. The file board_ssd1289.h is a board file. You have to write the board file yourself as this depends on your wiring (how the display is connected to your microcontroller). You can find a template at /drivers/gdisp/SSD1289/board_ssd1289_template.h. Simply copy the file to your project directory, name it board_ssd1289.h and fill in the routines. In order to see if everything compiles fine, I strongly recommend to just compile the template without filling in anything yet until it compiles. ~ Tectu

It is not possible for us to check and fix your include path. However, you need more than just the path to the uGFX top level directory. You take a look at each modules Makefile (sys_make.mk) and the toplevel Makefile (gfx.mk) to see what needs to be included. Note that you also need to manually add all the related source files manually to your IDEs file tree. That's the pain (and price) you have to pay for using an IDE :-P Also make sure that the relative path that you showed in the image posted above is correct. The undefined reference error that you are getting is because the gfx.h file is not being included properly in your inclusion path. ~ Tectu

I'm not sure if I understand you correctly here. Do you want to get the actual size of the "client window area" that is now left? In that case, the thing you want is already there: gwinGetInnerWidth() and gwinGetInnerHeight() which are available for containers (like the frame widget). Or am I completely misunderstanding you here and you want to specify the width and height of the client window and extend the borders and stuff from the parent widget to the outside in order not to decrease the width and height of the client window area? ~ Tectu

There is definitely a problem as I can confirm it myself now. We will look into this as fast as possible. In the meantime you can probably try to add a custom calibration load function (using ginputSetMouseCalibrationRoutines()) and returning an empty struct. "Empty struct" means that the parameters are set in a way that they don't change anything. Probably "neutral calibration data" would be the more appropriate term. The neutral struct looks like this: ax = 1; bx = 0; cx = 0; ay = 0; by = 1; cy = 0; The struct itself is defined in mouse.c: typedef struct Calibration_t { float ax; float bx; float cx; float ay; float by; float cy; } Calibration; ~ Tectu

When you are getting an undefined reference to the gfxInit() call, then you either don't have the gfx.h header file properly included (by using #include "gfx.h"[/] at the appropriate place) or you have an issue in your inclusion path (Check your Makefile). ~ Tectu

You're very welcome. Please let us know about the result. ~ Tectu

I think that this seems to be a ChibiOS/RT + Keil problem where I cannot help. Please ask in the ChibiOS/RT community forum. I'll be more than happy to help once you hit other uGFX problems. ~ Tectu

You are clearly having some inclusion problem. Can you please make sure that all the ChibiOS/RT relevant files are there? I'd recommend you to compile and run the test suite from ChibiOS/RT to ensure that everything runs smoothly. If you're using the project templates for Keil that come with some ChibiOS/RT versions, please make sure that they are still fully supported and work with your Keil version. I remember that Giovanni once mentioned that he's going to discontinue the IAR and Keil examples. ~ Tectu

Did the 'implicit declaration' warnings go away when you added the path? (Make sure that you don't manually include ch.h on top of the chibios.c file anymore). I took a look at the link you posted and I don't see much similarity. He is definitely assigning a different datatype, but our pointer is of the type void*. You can try to force a cast to see what happens: np = (void*)gfxAlloc((size_t)newsz); However, I am pretty sure that you're still having problems including the chibios.h properly. I don't know Keil, but is there any mechanism to give a list of all files that are included and compiled (-> files that are handled by the compiler & linker). Also, is there something like a pedantic mode for the Keil compiler that is set on by default? If so, can you please try to disable that mode and lower the over-all warning level? We know that this is no permanent solution, just to see where the problem lies. ~ Tectu

You are missing the path to .\ext\ugfx\src\gos. Make sure that you add .\ext\ugfx\src\gos\chibios.c to your sources as well. ~ Tectu

Thanks, it's merged. ~ Tectu

About the first error: This seems to be some file inclusion error. You are either not including all necessary files or you are having a different file named chibios.h somewhere. For some reason, chibios.h does not get included properly. Hence the implicit declaration warnings. Please check your include path carefully and compare it to the ones from our Makefiles. If you don't find the source of the problem, please post your include path here. Also, which version of ChibiOS/RT are you using? ~ Tectu

But which touch driver are you using? I don't see which driver from /drivers/ginput/touch you're using. Try the trick with the 9999 instance first. I'm currently not at home either so I cannot investigate. ~ Tectu

Thank you very much for reporting this issue. GCC does not even throw a warning about these... The second one can be fixed easily: return chThdCreateStatic(stackarea, stacksz, prio, fn, param); becomes return (gfxThreadHandle)chThdCreateStatic(stackarea, stacksz, prio, fn, param); However, I am not sure about the first error yet. I don't see a problem there. Can you please show me the type definition for your size_t type? The implicit declaration warnings can be temporarily vanished by include ch.h on top of the file. As soon as everything works for you, I'll push the fixes to the main repository. ~ Tectu

I'll have a look at this tonight. Can you please leave some more information about your hardware setup, which driver you are using and why you want to skip the calibration? There's a small hack: You can use 9999 as the instance parameter that you pass to gwinAttachMouse() to skip the calibration for now. However, this is not the desired way as it is a workaround. ~ Tectu

Can you please show us your code (both the part in the driver and the board file) and tell us what problem you're experiencing? ~ Tectu

I'm not entirely sure what this means. No reason to be sorry at all :-) ~ Tectu

There's one thing that inmarket and I recognized: You are limiting the performance through the board file extremely. You're calling write_data(g, RAM(g), 1); in a for-loop but the function is actually meant to take the size of bytes so everything can be done in one call. The reason why this does/did not work for you is because in your board file you're using spiStartSend. However, that call is asynchronous so you have to wait for the completion of the transmission! You can use spiSend() instead as this is operation is synchronous. Could you please try it this way so we can modify the driver to improve the performance? ~ Tectu

Thank you very much for sharing your work. I'm sure people will appreciate this. If you pull request to our repository, we could easily merge the drivers into the main ugfx repository. ~ Tectu

I took a look at the header that you're using and there is no definition for the size_t data type. Therefore there shouldn't be any reason for you to remove that from raw32.h. Can you please post the exact error message? ~ Tectu

Looks good to me! Good work! Pull-request whenever you feel for it ~ Tectu

That does not seem to make sense to me. The first build log just tells you that stuff like uint32_t is redifined. When you comment those out in the )/src/gos/raw32.h file, then the second build log should not tell you that it is missing that definition now. Try to include the file that does define the types (inttypes.h?) in /src/gos/raw32.h and see how that goes. ~ Tectu

I did just give it a quick watch. Why are you including stdint.h in your main? Do you really need that? I though the CMSIS provides the necessary types. Can you try to remove the type definitions in ugfx/src/gos/raw.h which are giving a conflict? Note 1: I'd strongly recommend you to use the uGFX master state of the repository and not the 2.1 release. Note 2: The guide for using the bare metal port is not finished yet in the wiki. However, the documentation of the RAW32 port states the following: /** * The raw32 GOS implementation supports any 32 bit processor with or without an * underlying operating system. It uses cooperative multi-tasking. Be careful * when writing device drivers not to disturb the assumptions this creates by performing * call-backs to uGFX code unless you define the INTERRUPTS_OFF() and INTERRUPTS_ON() macros. * It still requires some C runtime library support... * enough startup to initialise the stack, interrupts, static data etc and call main(). * setjmp() and longjmp() - for threading * memcpy() - for heap and threading * malloc(), realloc and free() - if GOS_RAW_HEAP_SIZE == 0 * * You must also define the following routines in your own code so that timing functions will work... * systemticks_t gfxSystemTicks(void); * systemticks_t gfxMillisecondsToTicks(delaytime_t ms); */ But that is not related to your current issue with the types. Just that you know for when you have this type issue fixed ;-) ~ Tectu