inmarket
-
Posts
1,296 -
Joined
-
Last visited
-
Days Won
4
Content Type
Forums
Store
Downloads
Blogs
Posts posted by inmarket
-
-
Use radio widgets with the button draw routine.
-
The init is called seperately for each display. There is a integer field in the GDisplay structure that reports the display number on the controller and another field that reports the display number in the whole system. See some of the example template board files for various controllers, you will see a switch statement in the init function that demonstrates how 2 displays on the one controller type can be used.
-
1. Yes. Most micros don't have enough RAM for a framebuffer so uGFX (unlike most graphics libraries) doesn't require one. Three are a couple of exceptions - when the display controller requires one, and where the controller is not pixel addressable (eg sub 8 bits per pixel).
2. V3 is a work in progress that is taking much longer than originally intended due to there being more work involved than we expected and we have had fewer resources to devote to it than we expected. We were hoping it would have been out by now but it isn't, and so I am now reluctant to put time frames on it. Hopefully soon (read that as months not weeks).
-
Try setting the option to TRUE (or GFXON if using the latest repository version).
-
Not presently. Anti-aliasing requires being able to read back from the display surface and adds significant complexity to the algorithms particularly if you want to do it using integer mathematics.
Many display controllers simply don't provide read back access to the display surface. We fudge it for fonts by assuming a constant background colour or, if we can't do that, we simply ignore anti-aliasing on the anti-aliasing font. This strategy is unlikely to be useful for basic shapes as the whole point of anti-aliasing is to mix the edges of the shape with the background.
Similarly the additional complexity (read that as code size, stack space requirements, and speed) is not worth it for most embedded platforms. In uGFX we have very well optimised image handling and with the right image this can replace most needs for anti-aliasing shapes.
Having said all that, we are adding the technology basis in V3 to allow these operations in future if the programmer and hardware designer are prepared to meet the requirements and are prepared to accept the speed and code overheads of these routines.
-
I see what you are talking about. I will check the code later today.
-
The strategy you are suggesting will not work and is unnecessary.
The ms parameter is in milliseconds. The whole number of seconds will always be ms/1000. Adding anything else to it will cause it to be too much. Similarly the nsecs field gets the fraction of the second and is expressed in nano-seconds. Ms%1000 gives you that component. It just needs to be multiplied by 1000000 to convert from milliseconds to nanoseconds.
If you are getting overflow it is because your compiler is not extending the arithmetic on the left hand side of the expression to 64bit as it is supposed to as the tv_nsecs field is 64bit. The way around this is to add constant expanders to the constant in the left hand side ie change 1000000 to 1000000ULL. Unfortunately this is compiler dependant and not all compilers support that syntax but it is a work-around for the compiler not following the C standards properly.
-
You are misunderstanding. The way the raw32 scheduling works is by playing with the stack. This is incompatible with Keil compiler stack checking by very definition.
If you are however using a RTOS as you explained in your later posts you should not be using raw32 at all. Instead you should be porting gos for your RTOS. Freertos, cmsisv2 and rawrtos are examples of that.
-
Don't forget to check the size of the main thread. This is normally done using a linker script or for Keil it is somewhere in the project properties. 2K should be more than enough for most situations.
You may also need to turn off stack checking as uGFX provides non-preemptive threading by manipulating the stack.
However, now that you mention you are using a RTOS, using the bare-metal port is probably not the best approach. Bare metal (raw32) is designed for when there is no RTOS. Your best solution is to provide a gos port for your RTOS eg see rawrtos or freertos or cmsisv2 for examples. Again please contribute your result.
-
Try either the m7 or m7_fp (fp stands for hardware floating point) first but also make sure you are also compiling as if it was a m7 processor.
The other arm versions can also be tried - the difference between them corresponds to differences in the instruction set of the variants of arm cpu. The corresponding code used is found in the src/gos/gos_x_threads.c etc.
It is likely one of the existing arm CPU specific code options will work for you. If not you may need to add one for the arm9. If an existing one works for you please let us know which one and similarly if you add you own for the arm9 don't forget to contribute the code so other users can benefit too.
We would attempt to add it ourselves but unfortunately we don't have a board with that chip on it for testing.
-
Also check the threads demo works.
The Keil compiler is supplied with a buggy C runtime library so make sure you have specified the CPU to uGFX so that it can use the CPU specific threading rather than the C library based one. This C library bug will result in symptoms just as you are describing.
-
This is an issue of sibling window drawing. uGFX's window manager does not currently support overlapping windows except for a container/child relationship. This is due to lacking complex clipping region support (due to memory and complexity overheads).
What this means is that whenever you touch something it gets fully redrawn regardless of any overlapping sibling windows.
Someone has written a replacement window manager that supports this but they didn't contribute that back to the community. This doesn't solve your immediate problem but it does demonstrate it is possible.
-
This is either an issue with your CPU, the definition of which CPU you are using, your startup code or an io configuration issue.
1. Check that the CPU you are using supports both DMA2D and ltdc.
2. Make sure you are correctly telling the stm32 Hal layer which CPU variant you have.
3. Check the board level startup code and make sure you are configuring the clocks and io as per the examples provided.
-
Please carefully read the guide suggested above. It will explain a lot.
The first error is caused by adding the GDISP_TOTAL_DISPLAYS and the GDISP_DRIVER_LIST settings in your gfxconf.h. These lines are for multiple display support and are not needed for a single display. Instead the correct driver is managed using the compiler include path and the link script as per the above guide.
The second error is caused by not including a mouse/touch driver. Either include a driver or remove the GINPUT_NEED_MOUSE setting and optionally the GFX_USE_GINPUT setting from your gfxconf.h file.
-
Try using a online font converter to convert from otf to ttf. Google will help you find one.
The uGFX font converter may or may not work with otf files - I either case it is not on the official support list.
-
Not yet unfortunately. The reason is that we have just been so busy and we are very resource constrained. We have two VERY large projects that are currently consuming us. We had actually hoped to have it out by now.
What is coming very soon is a V2.9 which contains some of the type changes that were part of V3. We are taking this step for two reasons; one to keep uGFX moving forward, and secondly to reduce the workload with keeping V2 alive while V3 is being developed (the internal source changes are quite significant).
With regard to your planned driver, if you develop it for V2 and contribute it to the repository we will port it to V3 as part of the V3 effort. We may need your help testing it but we will cover the porting work.
-
Only being able to insert into a list widget at the end is not uncommon eg Win32.
The correct method is to clear the list and re-add the items as per Joel's post above.
-
It is a very good idea when working with a new display to try the various gdisp demos first. These can help hilight problems related to gamma, different drawing mechanisms, rotation etc.
Start with the gdisp basics demo and then try the text demo. They will help you find where any problems might be.
-
When you commented out the fillarea calls you forgot to also comment out the if statement just before it. The if statement still being there is causing the following if statement to also be conditioned.
Comment out the if statement just before the commented out fillarea statements and I suspect it will work.
-
The issue here is not so much about Studio, uGFX itself doesn't support .ico files. Once support has been added to uGFX the Studio developers will quickly add support into Studio.
As Joel mentioned, if you want to take on adding .ico support to uGFX then the Studio developers will add support into Studio shortly thereafter. This shouldn't be too hard as I believe it is similar to BMP which is already supported.
-
This has been updated in the repository. Thanks for bringing it to our notice.
-
I am sorry we only support English on this forum. This is both for our ease (although we also understand some other languages) but also so that others can also make use of any information or answers to your post. Google translate normally does a good enough job of converting to English.
-
This is definitely more advanced uGFX functionality and uGFXStudio knows nothing of users so you would need to implement this yourself.
Let me suggest again that the best approach for screendumps for manuals etc is to run your uGFX program on the Win32 emulator and then use the windows screen capture tools. I'm sure the same could be done using the Linux and X combination if that is your preferred development platform.
-
From an application that is currently not possible. Remember that uGFX is designed for small embedded processors that often cannot read their own framebuffer.
If you want to draw onto a "virtual" display and then save that into a BMP file that is possible. Look at pixmaps. You will still need to do the BMP encoding yourself but you can use GFILE to save it to an SDCard.
If you are just after screenshots for a demo of your product (or something similar), the easiest way is to compile and run your uGFX program on the win32 platform. You can then use the windows snipping tool to take screenshots of what is happening.
gdisp_lld_ILI9341.c: Hardware reset not working properly in gdisp_lld_init
in Development and Feedback
Posted
First note that the sense of the parameter between uGFX and the adafruit code is reversed.
Second, the startup reset delays for a controller chip are normally documented in the controller data sheet is. It is a controller specific property once the power supply is stable (which it definitely should be by this code stage).
So, in this case there are three possible problems...
1. Whoever wrote the board file didn't notice the parameter is logical level not pin level and was therefore holding the controller in the reset state, or
2. The driver writer did not include delays as per the dataset, or
3. The controller is a cheap Chinese equivalent with significantly different speed properties.
Nevertheless, your idea of making it a single board level routine has some merit. I will look at how it can be used in V3 which uses a gBus module for all io of this type.