Joel Bodenmann

Interesting. That's a change that @inmarket committed. I'm not sure what the story on that is. However, due to how the clipping works that definitely shouldn't lead to the problem that you're experiencing. Especially as that code appears to be working everywhere else. I'll dive into that and report back. Stay tuned.

You should really stop doing modifications in the library itself all the time unless you know what you're doing. This way it will be very difficult to provide support in the future as you'll have a completely different set of code than everybody else. If you have questions or doubt I'd recommend you to ask first. Otherwise it's simply not worth for us spending our spare time finding out why you're having issues when we have to start with "please give us a complete list of changes that you made". To clarify: I'm not saying that the µGFX library is perfect. It's far away from that and there are many known issues and most likely a lot more unknown ones. It just becomes impossible for us to provide support for a version that has tons of changes - some of which are wrong and some of which have huge impacts, even if they appear small. In general we try as hard as possible to provide a library where no source code modifications are needed outside the per-project files such as the configuration files and board files. Unfortunately, there are some exceptions to this like the display initialization sequences but that's something that will be resolved by the next version of the library. But just changing internal code, especially if we tell you how to do it the correct way, is definitely the wrong approach that can and will lead to problems in the future. If you do have questions please just ask - we're always happy to help wherever we can. If we explained something and you feel like it's insufficient information - just tell us that you need a bit more explanation and we're happy to dive into every detail as needed

gdispDrawString() draws a string with the given color without clearing the background. Basically every non-character pixel stays untouched. gdispFillString() on the other hand first fills the bounding rectangle of the string with the given background color and then draws the string on top of that with the given foreground color. The API documentation of those GDISP functions can be found here: http://api.ugfx.io/group___g_d_i_s_p.html

That has nothing to do with rotation. That's because the manufacturer of the display module has different options/choices how to connect the display panel to the display controller. Higher developed GDISP drivers such as the SSD1963 have a configuration flag that allows inverting the long the X and Y axis if required. It appears that the author of the ST7565 driver didn't implement that. If you want to handle this properly then that's the way to go. Quickly looking through the driver I see that things like the display inversion (positive / negative display mode) are hardcoded. These things should be passed through the GDISP control interface. The SSD1306 driver shows how to do that.

Line 84 of the gdisp_lld_ST7565.c file.

Check whether the allocation of the framebuffer in the driver initialization succeeds.

Great! Good luck! Don't hesitate to ask if you have any further questions.

Regarding 6: That flag controls the priority inheritance behavior of the mutex. The problem you have with mutex on operating systems with thread priorities is that when a lower priority thread has a mutex and a higher priority thread is waiting on that mutex the higher priority thread can't do anything for an awful lot of time because the lower priority thread is blocking the mutex. Because the lower priority thread gets less CPU time it also requires more time to do the job and release the mutex. This results in the fact that a lower priority thread can block a higher priority thread which is a huge problem. That problem is called priority inheritance. To prevent that problem most operating systems provide a mutex that has priority inheritance support. What that does is temporarily increasing the lower priority thread's priority to the same priority level as the level of the higher priority thread that is waiting on the mutex. This way the lower priority thread gets more CPU and is thus able to release the mutex a lot earlier and no longer blocks the higher priority thread that long. It's really a basic operating system problem and a basic feature: https://en.wikipedia.org/wiki/Priority_inversion In your case I'd simply use TX_INHERIT to enable the feature.

Revert your project back to the state where everything was compiling without any modules enabled (just GOS which is always enabled) and then follow the guide on Keil µVision that has been linked previously that explains step-by-step how to use the single-file-inclusion mechanism. It explains and shows how to add a driver: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM#Adding_Drivers The process is exactly the same on Eclipse. The single file inclusion mechanism is universal. Our community member and IDE expert @cpu20 is currently in the process of writing an official & very detailed guide on how to add the µGFX library to an existing eclipse project. I'm sure he could help you out here already if you have problems doing just what the guide linked above explains and demonstrates. In general: Just don't add any files you're not explicitly being told to add.

@doc_rob Could you please grab the latest master branch of the repository and check whether everything is working out-of-the-box?

Glad to hear that you managed to make some progress. Huge Thank-You! towards @cpu20 for providing the IAR configuration screenshots.

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?