Joel Bodenmann

Then change that code part to use GPIOD instead of GPIOA as described above. The code that you're showing is using GPIOA at the moment.

You don't need that. The GDISP code will clear the display after the driver has been initialized.

Good work! One thing I'm not sure about: Could you explain what the purpose of this is in the init()? #if (KS0108_NEED_READ == FALSE) uint16_t k; for (k=0; k<BUFFSZ; k++) { RAM(g)[k]=0; } #endif

They are described in the documentation: https://wiki.ugfx.io/index.php/GFILE#File_systems The RAM part in RAMFS really just means RAM. It has nothing to do whether the RAM would be internal or external. For read-only access there's ROMFS. That's widely used and very well tested. It allows you to load files from the FLASH and due to how it's implemented you don't need to spend time fiddling around with the linker script. It outputs a simple C array that gets included in your binary by simply including the C array in your source code. If you want to load something from an external memory then using FatFS will most likely be the most simple solution unless the memory is fully addressable. For FatFS we have a GFILE wrapper named FATFS that works both with a built-in version of FatFS that comes with µGFX or with your own external/existing distribution of FatFS. For everything else we offer USERFS where you can implement whatever you want. There are quite a couple of people using that interface and there are no known issues with that. If you have an existing way of reading and/or writing data to/from an external memory then you can just wrap the USERFS wrapper around that and you're ready to go. This way you can use your existing stuff and still use the high-level GFILE API and there's almost no overhead at all (everything is done with function pointers). Regarding the JPG discussion: If your users supply the JPG files then that is obviously a very valid reason not to move to anything different. In that case you have still the remaining three options: You implement the entire JPG decoder in µGFX yourself We implement the entire JPG decoder in µGFX ourselves (we can get that done within one to two weeks, depending on how fast you need it) You take your existing JPG decoder and wrap it around the µGFX image decoder interface. That interface is well documented and as there are already four decoders available you have enough reference material. If there are questions you can always ask here on the forum or get a paid support plan. In either case we're happy to help wherever we can.

Looking at the initialization code in your first code it seems like your pins are not being initialized corresponding to the list that you just posted. IOBus busD = { GPIOA, (1 << 0) | (1 << 1) | (1 << 4) | (1 << 5) | \ (1 << 7) | (1 << 8) | (1 << 9) | (1 << 10) | (1 << 11) | \ (1 << 14) | (1 << 15), 0 }; There are a whole lot of pins being configured on PORTA but you don't seem to have any pins connected to port A. It might be confusing because the struct instance is called busD instead of busA Go through all pins and make sure that the board_init() function initializes them properly.

MEMFS is fully implemented. RAMFS is just a playful thought. Nobody had ever any use for that. Why are you asking about that? JPG images are a really bad choice for small embedded systems. BMP, GIF and PNG offer way better alternatives for almost all cases (again: on those platforms). I did write a µGFX wrapper for an existing JPG decoder once (a really good one!) and the performance is horrible and unusable for any embedded system that doesn't offer vasts amounts RAM and a very fast CPU. Unless somebody is really in need for a JPG decoder we don't plan to add it in the next couple of months. We can of course do that within just a week or two as a paid feature implementation. Alternatively you can always write your own implementation or take an existing one and just wrap it inside the µGFX image decoder wrapper. Is converting the images of your existing GUI to a different format (not to say better suited in this case even) posing a problem to you? If it's due to the fact that you have lots of them: Nothing that a very simple shell script can't handle. You can use any font that you have as a *.ttf or a *.bdf format in µGFX. There's a font encoder/converter that allows converting any font to be used efficiently with the µGFX library. That converter is available both as an online and as an offline too. You can find the online version here: https://ugfx.io/font-converter I'm gonna let @cpu20 handle the IAR stuff.

As I said: If you keep having troubles just add them as drag'n'drop attachments as shown in my screenshot.

Just add as regular attachments. Works like a charm:

Can you please try adding your screenshots using drag'n'drop or uploading them as attachments and then using the "+" symbol on the image/attachment thumbnail to add them to the post? In case of you can't edit your post anymore (I think there's a 15 minutes limit or something) -> Just copy the contents, create the new post and I'll delete the previous one. Never had issues with screenshots before. Also seems like it worked out well for @cpu20 and we haven't touched the board software since his last post with the screenshots.

ChibiOS actually supports that. There should be a setting in chconf.h when I remember correctly. CH_DBG_ENABLE_STACK_CHECK and CH_DBG_FILL_THREADS are useful. Check out this and this.

Hi, First of all, thank you for sharing your driver with us and the rest of the community. I gave it a very quick look and these are the things that popped to my mind: You're using osalThreadSleepXXX() instead of gfxSleepXxx() at some locations (eg. the initialization code) Your framebuffer (lcdbuf) is a global variable. This won't work if you want to use multiple displays. You must not create any global variables at all. Instead, the GDisplay* struct has a void* pointer named priv that you can use to store custom information. If you need more information than what a simple void* can hold create a structure and let the priv pointer point to that. Have a look at other existing drivers to see how it's done. Take the SSD1306 and the UC8173 drivers as an example. There's code (that has been commented out) to clear the display. That is not necessary as the higher level GDISP stuff will take care of that and it will use the area filling if that is available so that code is really not required unless the KS0108 controller has a real "clear" hardware function. Some general serious clean-up is required. The function and variable naming appears to be inconsistent and the indentation is just all over the place. Don't hesitate to ask if you have any questions. We're happy to help wherever we can

Hello @umitgun and welcome to the µGFX community! Could you do me a favor and simply creating a new topic that contains all the information about what exactly you're working with (exact display controller/driver type, what microcontroller, what underlying system (eg. baremetal or which RTOS), your driver and everything else that would help us resolving your problem. Don't forget a detailed description of what the problem actually is Looking forward helping you resolving your problem.

In the end this really is just about what @inmarket said: We don't have enough information to help you. It's difficult for us to help with little to no information at all. If you prefer support via phone that is possible as mentioned previously, however there it would be the same: We need more information. There are numerous customers that are using the µGFX library with the IAR IDE. There are also a couple of community members. One that I remember particularly is @king2. Maybe he could help you resolving your integration issues and eventually writing a proper official guide. I'll bump him on Skype. Personally I feel like that is not the case. You're experiencing issues with the integration of a library in your existing project. That doesn't mean that the two systems are too different. From the high-level point of view they will most likely be very similar - especially when it's just about drawing shapes and images.

I'm very happy to hear that you managed to get everything working! A huge Thank-You! to @cpu20. Great work! Would you consider writing an official guide that we would put into the wiki?

Hello Joe, Thank you for your feedback, we appreciate it. I fully agree that being a developer of the library will definitely lead to a lot of bypassing when it comes to writing, reading and interpreting the documentation. I've updated my schedule to spent some time next week to improve the documentation. Setting up a µGFX project is definitely by far the hardest part of working with µGFX, mainly due to the fact that it has been designed to work with any system and any IDE. We do offer both e-mail and phone support as part of a paid support plan. That's something that is simply unfesiable to do for free. We would have to hire 10 people and the phones would still be ringing non-stop. Keep in mind that with this sort of stuff the person providing the support actually needs deep knowledge of the system itself, so we can't just get a couple of undergraduate students to do that for us during their semester breaks The last paragraph of your post mentions issues with the configuration file. Those are pretty simple to solve as they are simple that: Issues with the configuration. I'd recommend you to have a look at the various demos that you can find in the /demos directory. A good way to start is by running /demos/modules/gdisp/basics. Each demo comes with the appropriate configuration file. Additionally, there's the documentation for each option in the configuration file in this wiki article: https://wiki.ugfx.io/index.php/Configuration. The #errors that you're getting are actually good as they explain well (in our opinion, again: Probably room for improvement) what the problem with the mismatching configurations is. The upcoming µGFX-Studio should help a lot here as it generates the matching configuration file automatically. If you still have any questions, don't hesitate to ask. If you're interested in a paid support plan, please drop us an e-mail. So far we have definitely never encountered a case where the µGFX library couldn't be used in an existing project, no matter what system, platform, IDE or system in general. After all, that is the overall goal of the µGFX library.

Sorry to hear that the example is somewhat useless then. I guess I didn't understand you properly. I thought that you need something just for the specific case of having images. I haven't looked at your modifications yet as I'm somewhat super-busy these couple of days. I'm gonna let @inmarket have a look at that. In general you won't only have a clipping issue but also the problem that the default window manager doesn't handle overlapping windows. It's only supported for the special case of containers. As I haven't looked at your modifications I can't say whether you'll be okay in this case or not, @inmarket will definitely have a lot more input on this. For the case where you have to write your own window manager: That is possible and actually foreseen by the GWIN module. So far all the custom window managers I came across were all for commercial customers that didn't want to make their code become publicly available so there's nothing I can share with you right now. however, I have a friend (who is also on this forum) that once wrote one. I'm not sure to what extend he completed it but it was definitely able to handle overlapping windows. I'll ask him about that. Here's a demo:

That would be the best case scenario, yes. If you can manage to do that, then you won't have any other problems. Once you have that setup you can simply add the µGFX makefile as per the documentation. Here's a very good example for that: https://wiki.ugfx.io/index.php/Using_ChibiOS/RT

Hello @Mad River, Thank you for your feedback - I put it on our ToDo list to improve the integration documentation. I'll work on that the next week. First we have to clarify whether you're really having a project that uses an external Makefile. The keyword here is external. Some Eclipse environments are setup to generate a makefile for you, but in that case you want to use the single-file-inclusion instead of using the makefiles of uGFX. You still can use our makefiles with the generated Eclipse Makefile but I'd really not recommend you doing that unless you are very experienced with that and you know exactly what you're doing - it can and it will be very daunting. So, first thing: Could you please tell us whether you're using an existing, external makefile? If not, please use the single-file-inclusion and let us know if you have any problems. As always, we'll try our best to help you as quickly as possible Edit: Just saw your second post. You're definitely using the automatically generated makefiles. Unless you find a proper 3rd party guide on how to add path variables to those I'd recommend you using the single file inclusion. Maybe @inmarket could help though. Looking through your Makefile I see that it includes the sub-makefiles of the µGFX library but unfortunately it includes also all driver makefiles, that is wrong. And it appears to be misisng the path variables. To be honest I'm also not too experienced with the recent version of Eclipse. Please try the single-file-inclusion mechanism. It will be a lot easier. Follow the Keil µVision guide linked in a previous post.

I think you forgot to add the ChibiOS board files to your compilation tree and include path. Check out the \boards\base\Embest-STM32-DMSTF4BB\example_chibios_2.x directory inside the µGFX library. You'll find the ChibiOS board files that we used back then in there. pal_default_config and boardInit() are defined in there.

Unfortunately, we don't have a dedicated guide for that IDE yet. If you'd like to write one once you're done, we'd highly appreciate that If you're using the single file inclusion mechanism then the workflow with the Eclipse based IDE will be exactly the same as the one with the Keil µVision one, so you can have a look at this guide: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM It's just different dialogs to add the files and paths, but what you have to do is exactly the same. If in doubt, don't hesitate to ask. We're happy to help wherever we can.

I'd strongly recommend you to try everything without DMA first. Once you have that working, you can start dicking around with that. It has been a long time since I last looked at the SSD1289 driver (in fact, that is the driver that made me start writing µGFX back in the day) but I am pretty sure that the driver works well. It is definitely taken care of by the driver that there are no double writes or anything like that.

Hello @Mad River and welcome to the µGFX community! As mentioned in the documentation, there are two proper ways of adding the µGFX library to an existing library: Using the makefiles or using the single-file-inclusion mechanism. If the IDE for choice already supports Makefiles and if your project is already makefile based then that is the easiest solution. Otherwise, please use the single-file-inclusion mechanism. Both are explained in the documentation and for both there are step-by-step examples for specific IDEs (take the Keil µVision one as a guide for the single-file-inclusion and the ChibiStudio one for the Makefile). There are plenty of demos available in the /demos directory where you can grab both the application code and the corresponding configuration file from.

Before we keep writing huge texts that are largely unnecessary and probably partially ignored: Could you please clearly state how you added the µGFX library to your existing project? As mentioned there are different ways to do that. The recommended one is to use the single file inclusion mechanism. The documentation to that has already been linked above. Are you using that?

Please delete that organization on github immediately. It is very misleading and careless of you to create an organization on github with the name of a company you're not involved in. This can lead to serious problems for all parties (you, us and users & customers that might get wrong code & information from there).

Hello @Sinalco94 and welcome to the µGFX community! Could you please attach a plain text file containing the entire compiler & linker output of a clean build (make clean!) so we can have a look at that? A couple of things come to mind in form of wild guesses: Are you sure that you're using ChibiOS 2.6? Did you enable the corresponding components (eg. PAL) in the halconfig.h of ChibiOS?