thexeno

After more investigation and asking also on more specific forums, the AVR8 (these 8bit Atmega) platforms are needing dedicated instructions for accessing data in flash, but also a dedicated address space, which is somehow coded in the pgmspace.h. So apparently I can adjust the linker for storing, but then I had to modify all the access in reading and writing, because the Atmega (8bit) are not supporting the flash visible in RAM address space. So in the end is not compatible with a 8 bit Atmega family. Now I wonder if this is a limitation of gcc or of the MCU, but I think it is the latter. If I really want to use such uGFX, I had to modify all the variable access and declaration, a thing that no one like. But please, if I am wrong tell me. Thank you.

Nice to know, that is the issue I was talking about. In the Atmega processors (I expect others too) with gcc compiler, they need the pgmspace.h functionality and declare variables as one of these two options: const type name PROGMEM or type name PROGMEM (the const is just a good habit, but is not functionally needed here to work) const __flash type name Using the static const only do not save in flash. I don't know if it is possible to tweak this on the linker. Any Atmel example and documentation use massively these two approaches. I am not sure, but I read that is the GCC way of working.

Hi, sorry for the delay. As far as I know, with certains compilers, it is sufficient declare stuff as static to store in flash. Now, of course don't doubt that what are you actually implementing is designed to be stored in flash, but what I miss is how you can make it compatible with gcc. I am saying that because I had to setup a small project with a an Atmega using a big LUT, and the only way to tell the compile to store in flash, was to use the PROGMEM directive, and reading writing with the related macros. But seems that in uGFX something different is used, which I do ignore. And seems to store in RAM just because when loading a certain font (it goes on overflow RAM by some hundreds of bytes, meaning that is not only variables used by the functionality). To be exact, without any fonts, FLASH is 9614B, RAM is 1542B. With fonts loaded, FLASH is 11208B (+1500B) and RAM is 2126(+580B), with the fixed_5x8 loaded. Do you know a way to actually have something similar to PROGMEM? Or is it already optimized at maximum? Other libraries like U8g2 seems to occupy less memory, but I never analyzed them directly to be honest, I just compiled some open projects which are using graphics and text. If this was a just a bug in the gcc compatibility of uGFX, I see in it a huge improvement, that's why I tried at least to ask. Thanks

Hi, After I've made HUGE progresses in the uGFX integration, I now step into text. And of course, with any text, I go just above 2kB of RAM. I was wondering if you have some support for the text to be handled byte by byte from the flash, natively. I thought that the static prefix would just suffice, but instead... Thanks and apologize for the many questions. Keep up!

I tried this way. Is calling the alloc only 2 times, one with size sz = 40(dec) and the second with 1024. But the display works properly with 1068 of heap available. Do you know why?

I just have a last question. The heap allocation is only for the framebuffer or also other? I was wondering if I have a way to know exactly the minimum heap size that I can safely set. This because if I corrupt the memory, not necessarily I see it as a dirt on the screen and may be latent for later bugs.

Hi, I've got it work! -> I had to manage the correctness of my I2C driver interfaced with the library (as expected). But something was still wrong, like the display bad configured and not getting useful data in the GRAM. -> So I had also to manage in the write command and write data, through appropriate change in my I2C APIs, the initial send of the command or data ID byte (0x00 or 0x40) (I initially thought that was managed in the driver). Now I get the display animation and drawings, but gets dirty with random pixels. -> Then I had to increase the heap memory, everything works fine. But now, the heap of 1024 was not enough and was messing up the memory. I made few trials, now works with 1212 bytes, maybe could be a bit less. But still, the only GFX (with 1212B of heap) now occupy 1460B of RAM. Is it normal? (Is it possible, not for practical reasons but for my own curiosity, a native support for external memory?)

But the weird thing is that this happens when no optimization is applied.

But I thought that the file which I need to modify is the gfxconf.h, I did not modify something else (attached for your information). Now, with your suggestions (everything else were already correct, in terms of inclusions), it was not updating the driver for another reason, related to the clipping. I think is related to the fact that you said it is a window region based driver, so I assume thatI need to use other APIs, but I wonder what I should use instead. Here why the graphics memory does not get updated: But then when disabling GDISP_NEED_VALIDATION the CLIP is disabled and I actually send some data. Of course it does not visualize anything yet, but this need some additional debug, which may involve my I2C library. For additional information, I also attached my main.c. But then, I realized something bad: the code sends data only if I put a basic optimization, since if it is not optimized at all, it gets stuck in this loop, because of this weird numbers (see image below), which are not happening with a basic optimization. And, with no optimization, if I tweak those number in debug to actually exit the loop, the code continues to work. See picture: Those values are never happening with Optmimize(-O1) option active, which is the minimal optimization, and therefore the code works and never get stuck. I though that may be a bug related to gcc used in Atmel Studio 7. Sorry if I may seems naive, but have you tried this driver with Atmel Studio or a gcc compiler? gfxconf.h main.c

Ok, here what is happening. In this function: static GFXINLINE void drawpixel(GDisplay *g) { // Best is hardware accelerated pixel draw #if GDISP_HARDWARE_DRAWPIXEL #if GDISP_HARDWARE_DRAWPIXEL == HARDWARE_AUTODETECT if (gvmt(g)->pixel) #endif { gdisp_lld_draw_pixel(g); return; } #endif // Next best is cursor based streaming [...] } the gdisp_lld_draw_pixel(g) should be the one defined in file gdisp_lld_SSD1306.c because of the vmt if I had understood well. But the gvmt(g) -> pixel is always false, in other words, the only call should be the one shown in the snippet but it gets skipped, and since all the other calls that came later are skipped from the configuration, the drawpixel just returns by doing nothing. How can I check the correct initialization of g? In gfxconf.h I had #define GDISP_DRIVER_LIST GDISPVMT_SSD1306 and in gdisp_lld_SSD1306.c I had #define GDISP_DRIVER_VMT GDISPVMT_SSD1306

I know, but I set GDISP_NEED_AUTOFLUSH to true. As you said, if both are set to false, it does not work, but I've got them to true. If I have time later I will try to debug again, but the flag in my code seems to be 0. Could be a problem with the defines? The conf file is correctly taken from the compiler, because if I set the GDISP to false, is not initializing the GDISP. Later I will try again to follow the assignments of this flag in the gdisp_lld_SSD1306, so that I can bring you something more precise.

Hi, I've managed to integrate the uGFX with my libraries and get it almost working with the SSD1306 display. Now, I read that I don't need anymore to manually flush the modifications in the controller, by enabling the autoflush (which is by default when including the SSD1306 driver). Now, the display is configured (well, I receive the aknowledge in the I2C bus transactions during the initialization). But I have the problem that is never sending the display data even calling the gdispFlush(). Basically, this // Don't flush if we don't need it. if (!(g->flags & GDISP_FLG_NEEDFLUSH)) return; is always true. Could be that there is something mismatching in the defines? Because GDISP_FLG_NEEDFLUSH is defined as #define GDISP_FLG_NEEDFLUSH (GDISP_FLG_DRIVER<<0) and is not well clear enough where is set the g->flags. Seems always to be Zero, since looking in the ugfx/src folder never gets a different value. What am I missing?

It worked, thanks. But, I had to copy the gfx_mk.c to the root of the project, and remove from the linker scope of course without eliminating the original file in the original position (in Atmel Studio by just dragging to the main.c) Otherwise it wasn't able to locate the gfx_mk.c and therefore knowing which .c file to link, because Atmel Studio was not able to locate the function of the gfxInit, but only the prorotype, which was able to find because in the main.c I put the gfx.h, as it should be.

Ok, I tried and I have understood better the philosophy too. But, there is something wrong. I try to achieve the same folder structure as in the example (which btw I had completely overlooked), and I get errors, but meaningful at least: With the following structure: In my explorer, I have this hierarchy: And the inclusion is: What makes me suspicious is that the library should have a default mode, even if in the gfxconf.h I have nothing uncommented, but still arise the error directive. Any other configuration and combination of includes, lead to the compiler to not find the includes or mismatching the folder hierarchy (so that the headers they need an additional "./" to work, and is wrong, since I must not edit the sources). Any clue?

Hi, I am trying to use the uGFX library in AS7, with the GDISP module for a OLED display, the SSD1306, but I am struggling in the right importing procedure. I have the goal to setup just something which build, it does not matter if the HAL and various modules are not setup properly. I tried to follow the procedure without the makefile, since I would need to modify the Windows environment and I would like not to do this on every machine in which I could work on this project. So I tried the inclusion file approach. I've imported the gfx folder in the root of my project, and added all of its content. Then, in the compiler directories, I have added: C:\Users\[...]\Atmel\ugfx_disp\ugfx_disp\ugfx\src C:\Users\[...]\Atmel\ugfx_disp\ugfx_disp\ugfx\ while in the gdisp.h, for the inclusion of the right lld config, I modified the include in: #include "../ugfx/drivers/gdisp/SSD1306/gdisp_lld_config.h" and of course I have activated the various modules, in my case just the RAW_OS32 and the GDISP and the heap size. But still, I get a lot un undefined stuff which is for sure related to something very naive, but which still keep me blocked. The errors are all related to app1.c or app2.c which are not existing. I am not a deep pro of Atmel Studio, but I have used it a lot for C and C++ stuff, and converting from one to another. But I am not sure what is going on now. I also not completed the lld files, but what I see is not related to this. But anything incomplete shall not give an error, if I have understood how is written the code. I can attach the project file, which I think is better that posting some code lines here and there. Of course, the Atmel project file is related to my own PC path, so I will include only the sources with their hierarchical structure. Thanks to anyone. project_root.zip