Joel Bodenmann

I can only confirm that there are huge quality differences in the TFT modules available. However, at the end you get what you pay for It is also correct that µGFX does currently not support any image or shape rotation. However, this should indeed be added at some point in the nearer future. Feel free to share your implementation with us and the community in case of you're going to implement it yourself. ~ Tectu

Hello juppeck I agree with your statement that a homogene IDE such as Keil is a lot easier for beginners. I don't use Eclipse myself and I never understood why especially all the beginner tutorials seem to use it as it is rather difficult to set up. However, Keil and other proprietary IDEs are not popular with beginners and DIY people as they have either a built-in size limit or are expensive (usually both). And when working with a graphics library such as µGFX, 32kB binary size really is not much. Note that µGFX itself has no such thing as 'prefered Compiler' or 'prefered IDE'. We spend a lot of time and effort into keeping uGFX free from any IDE or compiler bindings. In fact, that seems to be one of the reasons why µGFX is so popular with commercial and DIY users. It is true that most of our DIY users are using GCC but this is simply due to the fact that it is free to use without any restrictions. Some of those users are either using the Makefile based system, Eclipse or CoIDE, now Em::Blocks seems to become popular as well. Commercial users on the other hand seem to usually use either Keil or IAR, both of which work just fine with uGFX as well. Same as above: uGFX is held generic. It is not bounded to any underlying library. Therefore you can use whatever you like. It is true that most of the example board files are ChibiOS/RT specific. The FSMC line that you posted comes from a ChibiOS/RT usage examples from quite a long time ago. Replacing it with your suggestion (which is indeed more readable) would force the user to include the Std-Library in the ChibiOS/RT settings which adds a huge overhead. As a summary: You can use whatever you want and we don't expect you to face any issue. If you are having difficulties using a specific IDE or compiler, please let us know as we are interested in removing these kinds of boundaries ~ Tectu

Usually there is nothing to do but optimizing the FSMC timings in the board file to archive a reasonable performance. This is pretty much the same with uGFX. Benchmarks show that around 32 FPS are doable with this setup. ~ Tectu

Sorry for the late reply. I hit the post "Submit" button whilst being in the train it seems like I lost the signal there... Apologies. I confirm that there is a problem with the defines (the warnings that you see). I will try to fix this tonight. However, you are still able to create a successful build. Does it work for you? If not, can you describe the symptoms? (eg. does mounting work and just read() or open() fails etc). ~ Tectu

I can't see anything attached. Please use a pasting service or use the code tags of the forum. ~ Tectu

These are warnings, not errors. Please paste the complete compiler output somewhere and link it so we can take a look. ~ Tectu

You don't use the ChibiOS FS, you use the FatFS. So please disable GFILE_NEED_CHIBIOSFS again and enable GFILE_NEED_FATFS. From then on you are forced to use the FatFS that comes with our repository. However, everything worked out of the box for many people so far. ~ Tectu

However, this is only true for the SDC interface. Fhe user hast to submit his own diskio implementation when using the MMC mode (connected over SPI). ~ Tectu

If you're using ChibiOS/RT everything should be working out of the box. Otherwise you have to implement the diskio interface as described in the FatFS documentation. ~ Tectu

We are very curious, could you please tell us more about your display, it's purpose and probably show us a picture? We've never heard of such a display before. ~ Tectu

There is no such tool yet. You have to write all the code yourself. However, we are working on it. ~ Tectu

Glad to hear that everything is working for your now. ~ Tectu

The online converter should be working again. Can you please confirm this? I am currently on the road and I cannot try to compile it myself right now. I will try it as soon as I am at home. ~ Tectu

First of all we can be sure that this is no wiring issue as the display actually displays what it is supposed to (µGFX logo). How long are your wires? Everything longer than 20cm will cause problems with the default board file. As you said yourself you have to lower the FSMC speed. Look at the reference manual to learn about the different settngs. There are timings for address setup, data and burst operations. The timings are set in the init_board() routine of your board file (line 89 in your case). ~ Tectu

Thanks for testing. I updated the repository. ~ Tectu

Thank you for reporting this warning. It has nothing to do with the ChibiStudio example. When I remember correctly the ChibiOS/RT PWM HAL was updated quite a while ago and the PWMConfig struct gained an additional member. Can you please try to replace it with the config below and let us know if the warning vanished? We will update the repository code in that case. static const PWMConfig pwmcfg = { 100000, /* 100 kHz PWM clock frequency. */ 100, /* PWM period is 100 cycles. */ 0, { {PWM_OUTPUT_DISABLED, 0}, {PWM_OUTPUT_DISABLED, 0}, {PWM_OUTPUT_ACTIVE_HIGH, 0}, {PWM_OUTPUT_DISABLED, 0} }, 0, 0 }; ~ Tectu

This is a 3rd party demo. This means that we (the µGFX developer) did not provide the demo/example project and therefore we don't know it. In order for us to help you efficiently please open a new thread and provide us with all the information we need (Your hardware setup, your wiring, your board file and so on). I'm sorry for this inconvenience but otherwise we'd have to digg through all the example projects that are out there and this costs us a lot of time. I hope that you understand. ~ Tectu

I never had any problems with using USB and µGFX at the same time. Please open a new thread that addresses your problem (good thread name and all the information we need to help you). ~ Tectu

So your display is finally running? ~ Tectu

The errors you are getting is because your board file ueses the PWM peripheral of your microcontroller but you didn't enable it in your ChibiOS/RT configuration. You have to enable the PWM peripheral in your halconf.h and you then have to enable the corresponding PWM driver in your mcuconf.h. Which readme told you to copy the board_SSD1289.h & gdisp_lld_SSD1289.c sources? That is completely wrong. The only thing that you copy into your project directory is the board_SSD1289.h. ~ Tectu

We have added the driver to the repository: https://bitbucket.org/Tectu/ugfx/commit ... eb6b2dfb90 Can you please check if everything works for you? ~ Tectu

We also renamed the FreeRTOS files to avoid file name conflicts on case insensitive systems: https://bitbucket.org/Tectu/ugfx/commit ... e619ac333f ~ Tectu

We have added the missing type definitions for the FreeRTOS 7.x versions: https://bitbucket.org/Tectu/ugfx/commit ... cabe37a83a Can you please make sure that everything compiles fine? ~ Tectu

No reason to be sorry Did it work? ~ Tectu

You cannot simply return that string. You have to copy that string into a buffer and return the pointer to that buffer. Trunet showed how it's done in his code: strcpy(buf, "\x75\xD4\x84\xBD\x94\xE3\x72\xBA\x73\x76\x7E\x43\x2D\x67\x28\xBA\x17\x3A\xBB\x3D\x41\x05\xFA\xC1"); return buf; P.S. Can you please stop quoting the previous post all the time? Quotes are used to answer specific text parts, not the whole post. It's getting very messy otherwise ;-) ~ Tectu