Joel Bodenmann

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

Could you please attach or paste the entire build log? If it's not too much trouble, please attach a .zip with your project code and especially the gfxconf.h file. I'm not quite sure, when you say you use CooCox IDE, is that just the IDE or does it force you to use the CoOS RTOS at the same time? Does the IDE use Makefiles? I am just curious from where the type conflicts (redefinition of the int types) come from. Are you using some other subsystem? Some STDperiph library maybe? This is surely fixable ;-) ~ Tectu

Wow, looks like you're doing really good progress. Like that the driver will be part of the official repository in no time ~ Tectu

Thank you very much for the update. I'm glad that you're making progress with display. ~ Tectu

Nice work! Please keep us up to date. I put a link to your blog in our demos section. ~ Tectu

Glad to hear! Could you please share your work with the rest of the world? This would help the project to become more popular as this is currently our biggest concern. The User Projects section of this forum is suited. If you don't have a blog or something, I am more than happy to give you access to the new wiki so you can create a page there. I am planing to add a section in the wiki which shows many different demo projects anyway. Let's see if we can find out what causes the problem with the startup logo and a halting FreeRTOS... ~ Tectu

Does your display controller provide a native orientation mode? As in: Can you tell him to flip 90°? If not, it's just a matter of doing some calculations for the pixel positions. The following is a code snipped from the framebuffer driver: LLDSPEC void gdisp_lld_draw_pixel(GDisplay *g) { unsigned pos; #if GDISP_NEED_CONTROL switch(g->g.Orientation) { case GDISP_ROTATE_0: default: pos = PIXIL_POS(g, g->p.x, g->p.y); break; case GDISP_ROTATE_90: pos = PIXIL_POS(g, g->p.y, g->g.Width-g->p.x-1); break; case GDISP_ROTATE_180: pos = PIXIL_POS(g, g->g.Width-g->p.x-1, g->g.Height-g->p.y-1); break; case GDISP_ROTATE_270: pos = PIXIL_POS(g, g->g.Height-g->p.y-1, g->p.x); break; } #else pos = PIXIL_POS(g, g->p.x, g->p.y); #endif } Sometimes it's also a good idea to take a look at already existing drivers. ~ Tectu

Sure, let us know when you need any help. ~ Tectu

No reason to be ashamed of yourself. We all do make mistakes I'll be more than happy to include the driver in the official repository once I find some time. ~ Tectu

Hello and welcome to the community! Could you please point directly to the working code and the not working board file? When I understand you correctly you already have a working driver and just porting it to uGFX does not work? ~ Tectu

After some more days of thinking I came to the conclusion that GREGISTRY might still be better than GCONF so we don't confuse new people with the configuration of the uGFX modules themself (gfxconf.h) etc. ~ Tectu

Thank you very much for reporting this bug. We just fixed it. ~ Tectu

I am sorry for my late reply. I have been quite busy these days. Module name As it makes sense to keep the module name as short as possible (see the following point), I'd strongly prefer to call the module GCONF instead. API I totally agree with the API listed by steved. However, the API style of uGFX is as the following: (); using camelCase. Following these rules, the API has to look like the following: bool_t gconfWrite(uint16_t tag, const void *data, uint8_t size); uint8_t gconfRead(uint16_t tag, void *data, uint8_t size); uint8_t gconfSize(uint16_t tag); I'm sorry but I am very pedantic when it comes to API and naming convention. I am already struggling with the older GDISP code that does not fit into the current naming style. However, this will be updated with the next major release. Edit: I just realize that inmarket already adjusted the API naming accordingly in his second last post. With everything else I agree. This looks like a solid base to start. ~ Tectu

I am AWFULLY sorry. I actually had "make sure that GDISP_RAM is correct" in the list from the other post, but for some reason I deleted the wrong line. But I'm glad to hear that it is working now Feel free to open a new thread for any question you might have. ~ Tectu