Joel Bodenmann
-
Posts
2,620 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
I can't spot anything that would be deemed "obviously wrong" in your configuration file.
I'm mainly confused by this:
On 18/04/2022 at 16:57, AnSc said:I get warnings about "GOS_NEED_X_THREADS" is not defined and "GOS_NEED_X_HEAP" is not defined.
This should only be the case if you use the raw32 port (GFX_USE_OS_RAW32). This doesn't appear to be the case based on your config file.
Is there any chance that you're overriding some config options directly from your build system?
Did you try to do a proper clean build? Because even if you'd set GFX_USE_OS_RAW32 elsewhere the compilation should fail due to the GFX_USE_OS_xxx being mutually exclusive.Can you please do a proper clean build and share your entire build output log?
Alternatively, is this an open-source project with a public repo that we can access?There's not much that can be wrong here. Both STM32 and ChibiOS are first-class citizens in the world of µGFX.
-
On 18/04/2022 at 16:57, AnSc said:
I did clone the main repository and stumbled again over the missing driver.mk file.
We'll add the missing driver.mk file in the next couple of days.
On 18/04/2022 at 16:57, AnSc said:which led to a successful build without the problem with a "wrong" ChibiOS version.
Awesome!
On 18/04/2022 at 16:57, AnSc said:I get warnings about "GOS_NEED_X_THREADS" is not defined and "GOS_NEED_X_HEAP" is not defined.
I also get many warnings about "GFX_MEM_LT64K" is not defined.
Can you please share your gfxconf.h? Just attach the bare file to your next post.
When using ChibiOS, those should not be needed. I do assume that you set GFX_USE_OS_CHIBIOS to GFXON?On 18/04/2022 at 16:57, AnSc said:I would feel more comfortable if there was some documentation on the individual options so I knew how to rate these warnings.
You can find some of them documented here: https://wiki.ugfx.io/index.php/Configuration
And for the rest there is the API documentation: https://api.ugfx.io
If there's anything missing in terms of documentation will will rectify that ASAP.On 18/04/2022 at 16:57, AnSc said:The first two read to me as if they do not apply since I'm using ChibiOS.
Exactly, so something seems wrong. The ChibiOS port is used heavily by DIYs and commercial customers. While that doesn't mean that there isn't any bug I do think that in this case it's more likely to be a configuration issue. Please share your config file(s) as mentioned above.
When changing options (eg. in the gfxconf.h) don't forget to do a proper clean build.On 18/04/2022 at 16:57, AnSc said:Have I a problem with my understanding and calculations or does the OS or uGFX make some error here?
When you're using the ChibiOS port, µGFX doesn't do anything memory related. All memory management related functions are mapped to the underlying ChibiOS system.
-
On 19/04/2022 at 04:17, mohsenMaz said:
You know it would be great if you as the developers design Ugfx so that it would be INDEPENDENT of Ugfx built-in drivers.....
That is actually the case! All drivers are separate components. You can use them, or you can not use them.
On 19/04/2022 at 04:17, mohsenMaz said:Like LVGL for example......you just need to define DrawPixel(x,y,color); and that's it......
You can do that with µGFX too.
You can make a simple wrapper driver which uses the Point and Block interface. Then you only need to implement this function:
gdisp_lld_draw_pixel(GDisplay *g);
Where g is a pointer to the GDisplay structure which will hold x, y and color information.
Let us know if you have any questions. We'll gladly help wherever we can
-
Just get back to this whenever it fits you. We'll be right here 😉
-
Hello & Welcome to the µGFX community!
17 hours ago, AnSc said:I'm using the current version of Chibios (21.11)
Honestly didn't yet get time to test with ChibiOS 21 but ChibiOS 20 support was added a few months ago. You might want to consider using the master branch of the official µGFX repository: https://git.ugfx.io/ugfx/ugfx
17 hours ago, AnSc said:ugfx/drivers/gdisp/SSD1322/driver.mk: No such file or directory
That appears to be a "bug". That driver is indeed missing the driver.mk file.
I can´t test this right now but the driver.mk file should be as simple as:
GFXINC += $(GFXLIB)/drivers/gdisp/SSD1322 GFXSRC += $(GFXLIB)/drivers/gdisp/SSD1322/gdisp_lld_SSD1322.c
Would be awesome if you could let us now if that worked out so we can patch the driver (adding the missing file).
17 hours ago, AnSc said:and some additional warnings:
That's actually mishandling of the C standard by the compiler you're using (I assume it's GCC). This was something that has been going on for years. You can find some discussions of that online (and also on this forum). We eventually caved in. This was also patches in the master branch of the official µGFX git repo.
16 hours ago, AnSc said:at this point it stops:
uGFX init gdisp_lld_SSD1322.c
[code] *ram &= ~xybits(x, y, LLDCOLOR_MASK()); [/code]
Debugger says:[code] ram gU8 * 0x20005027 <error: Cannot access memory at address 0x20005027> [/code]
First of all: Can you please provide more information regarding your setup (exact STM32 MCU that you're using, which compiler etc)? Please also share (as attachments) your gfxconf.h and your board_SSD1322.h.
The SSD1322 driver uses the framebuffer model. As such, it needs to allocate a buffer large enough to serve as a framebuffer. This happens at line 69 of the driver. gfxAlloc() is used to allocate memory. The first thing you should check is whether the framebuffer allocation was successful. The driver would fail to initialize if the underlying system couldn't provide the memory needed but we have to start somewhere plus you'll need to know the framebuffer address for the next step below.
The fact that your debugger cannot access memory at that location as well as your "crash" happening when accessing that framebuffer memory might indicate that it is located in an inaccessible memory section/area. To further dive into this, we really need to know the exact type of STM32 MCU you're using.
The datasheet/reference-manual contains the memory map which tells you in which memory section your framebuffer got allocated. These days, microcontrollers got rather complex. They contain a lot of different memory sections with different accountabilities, policies and so on. It's not unlikely that your framebuffer got allocated in a memory section that cannot be accessed the required way.
We can continue looking into this after you provided more detailed information.
-
Hey,
I was just about to respond to your posts from yesterday - they seem to be deleted now. Also your initial post appears to be edited.
Did you managed to get it working? -
Hello & Welcome to the µGFX community!
It's difficult to get any information from just a picture of a display module. In general, any display can be interfaced with µGFX due to the flexible interface design.
ILI9341 based displays are certainly very common and used by plenty of individuals and commercial customers.Could you please provide more detailed information such as:
- The physical interface used (i.e. parallel 4-bit, parallel 8-bit, parallel 16-bit, RGB, SPI, I2C, ...)
- The GDISP board file(s) you're using
- Your gfxconf.h
- Datasheet of the display module itself (or link to where you purchased it from)
- Details on how you hooked up that display module to your host controller
In general, if only colors are incorrect you're almost there. This indicates that the system is overall working.
Common sources of problems regarding colors:- Incorrectly configured color format
- Incorrect color handling in GDISP board file (if any)
- Incorrect display controller initialization
- Incorrect wiring if using a parallel interface
The last point is unfortunately very common with ILIxxxx display controllers. What we observed over the years is that often you get a different chip than advertised, differences in silicon revisions, knock-offs and so on. Often you'll be supplied with a display controller initialization sequence from your dispaly module vendor. This sequence can sometimes look different than the sequence of the official ILI9341 driver found in gdisp_lld_init() here: https://git.ugfx.io/uGFX/ugfx/src/branch/master/drivers/gdisp/ILI9341/gdisp_lld_ILI9341.c
17 hours ago, mohsenMaz said:(the ugfx logo at the startup displays correctly with blue and black background) .
The logo should actually be white on back
-
Hi!
The µGFX GDISP module provides different kinds of driver interfaces. These are listed explained here: https://wiki.ugfx.io/index.php/Display_Driver_Model
The framebuffer model is only one of them. If your display controller doesn't provide direct access to the framebuffer it's usually not the right model to use.
Please don't hesitate to ask if you have any questions! -
Also: Hello & Welcome to the µGFX community
-
Hey!
Yeah that is indeed one possibility. However, right now we're more tending towards creating a dedicated port for the ESP32 FreeRTOS version. The reason is maintenance. When someone (in this case Espressif) is willing to modify something like FreeRTOS it's not unlikely that other changes can follow in the future. Furthermore, it's not unlikely that we want to update the µGFX FreeRTOS port to support newer FreeRTOS version in the future while the ESP32 modified version might not have been updated by Espressif.
Having a dedicated port just makes this a lot easier to maintain.In case you want to help on that effort: inside the /src/gos folder the existing FreeRTOS port can be copied, renamed to freertos_esp32.[ch] and modified for this version. There are a few more bits & pieces that need to be modified (eg. new configuration macro to use this GOS port, adding it to the GOS port list and so on).
-
Thank you for all the information you provided.
We're still discussing this internally. Personally, I have no idea why anybody would do this but I guess it is what it is.
We'll most likely not have a choice other than providing a dedicated GOS port (µGFX operating system abstraction) for this modified version of FreeRTOS... -
Thank you for sharing - we will review this in the next couple of days.
Just to be sure here: Those modifications, are they to support a newer version of FreeRTOS or is the FreeRTOS used on the ESP32 modified by Espressif themselves? If so, I'd wonder why.
-
Ideally you'd provide us with a patch file (eg. by running git diff). This way we can look at the changes you propose and review them.
If for whatever reason that is not an option you can also send us the modified files and we will generate the patch file ourselves. -
Very nice! Keep it up!
-
Hello & welcome to the µGFX community!
It's always nice to see when people write drivers & board files for new hardware/kits. Nice!
If you're willing to share your efforts (drivers, board files, ...) we'd gladly review those and potentially add them to the library so new users can get started with µGFX on this platform very easily thanks to you! -
Yes, it's located under /tools/mcufontencoder/src
-
On 23/12/2021 at 14:10, lijian100 said:
After GIPIO switch, if(event) did not work. if(GPIO_GetBit(GPIOM, PIN18)) Work properly，
Have a look at some of the application demos. You'd want to do something like this instead:
switch(event->type) { case GEVENT_TOGGLE: // Here you know it's a toggle event // You can cast the event to GEventToggle* and retrieve information which toggle triggered the event and the true/false state break; }
On 23/12/2021 at 14:10, lijian100 said:Sorry for the above text translator's help to me, hope the description is clear,
No worries! We try our best to work together - Language has never been a problem 😉
-
Hello and welcome to the µGFX community!
On 16/02/2022 at 12:08, Vadim1980 said:So, I try to use gwinDestroy(ghContainer) and seems to me it works! In this function deletes all child items, that belong to this container.
That is indeed the correct/expected behavior
On 16/02/2022 at 12:08, Vadim1980 said:But font settings losts too, so I make definition before the every container creation!
Depending on your application design, you can just keep the font open and re-use it later. So during initialization, open your font and keep it open. You can create and destroy any number of widgets & containers you want without having to close the font if you plan to re-use it later.
On 16/02/2022 at 12:08, Vadim1980 said:Solved!
Glad to hear that - sorry for the late response. Please don't hesitate to ask if you have any other questions!
-
Hey!
Unfortunately, I have no real understanding of the cyrillic glyphs. While this might sound silly to you: Could you tell us what appears "wrong" in the picture that you showed?
In general the font converter utility can convert any TTF or BDF font. If your source font is fine, it should work.
When working with small font sizes, make sure that the source font gets converted to a size where the smallest 1-pixel resolution is actually working. What I mean to say: Can you try to re-convert your font but this time with a larger font size and see whether that yields better results? The idea is to check whether the tools work properly. -
UC8175 datasheet seems to be publicly available from the good-display.com website.
I'll attach the actual PDF to this post for preservation: UC8175-1.pdf
-
I think that's a typo in the readme that you're mentioning.
Unfortunately, I am unable to share the datasheets of the UltraChip controllers I have as they were acquired under NDA
While I don't know for sure, experience would certainly say that you can use the one driver as a starting point for the other driver you're intending to make.As usual: Don't hesitate to ask if you have any questions. We're happy to help wherever we can.
-
Hello & Welcome to the µGFX community!
Those ILIxxxx chips are known to have "problems" with different default configurations and incorrect reset values across different versions and revisions. This is especially bad with clones.
Given that everything else is working this might be as simple as flipping the scan direction bit(s) in the display controller's control register. Check the SS bit in the Display Function Control Register (0xb6). That controls one of the scan directions. There is another such register value to control the other scan direction somewhere. These two values allow you to "flip" the display.Please don't hesitate to ask if you have any further questions - we're happy to help wherever we can!
-
The function in question is named
snprintg(): https://git.ugfx.io/uGFX/ugfx/src/branch/master/src/gfile/gfile.h#L378 -
@lijian100 Welcome to the µGFX community!
We need more information in order to help you out. Please open a new topic and describe the problem you're facing with the necessary code snippets.
ugfx/drivers/gdisp/SSD1322/driver.mk missing
in Support
Posted
Regarding the warnings of GOS_NEED_X_THREADS and GOS_NEED_X_HEAP: It would seem like we're missing the default definitions of those. But I need to look into this more properly. I'm a bit thrown off by the fact that we haven't encountered this issue before and we're working on STM32 + ChibiOS projects every day.
For now, you can simply define them to GFXOFF in your gfxconf.h to be safe.
Are you able to debug your system properly now?