inmarket
-
Posts
1,311 -
Joined
-
Last visited
-
Days Won
4
Content Type
Forums
Store
Downloads
Blogs
Posts posted by inmarket
-
-
The fact that draw routines are being called but nothing is displaying, especially the crosses, indicates that perhaps only certain drawing operations are working.
Please start with some of the gdisp module demos just to make sure all drawing operations including text are working properly.
If they are working properly my guess is that sometimes the bus is not being released thus stopping the drawing from continuing.
-
I will check the repository code later today.
-
It appears that you have not implemented your board_ST7735.h properly as that is where those routines are defined.
-
Check the font is successfully opened.
-
I suspect that something else is going on as the driver structure is allocated and initialised to zeros before gdisp_lld_init is called.
On the other hand the private area PRIV() is allocated and initialised by the driver in gdisp_lld_init.
-
It sounds like your path is not set correctly. "mkdir" is built into the windows command shell (cmd.exe) and is an external utility for cygwin bash. The fact that it is missing means something is wrong with your path.
-
There is now a new wiki article introducing the changes for V3.0
https://wiki.ugfx.io/index.php/Changes_from_V2.x_to_V3.0
This wiki article will expand with more detail as we get closer to the V3.0 release.
-
Can you please give us the exact version of the Keil compiler, and whether you are using it in ARMCC compile mode (the default) or GCC compiler mode.
What would also help is if you add
#define GFX_SHOW_COMPILER TRUEto your gfxconf.h
It will display a warning about what it auto-detected the compiler as. This will help us track down what is causing the incompatibility.
-
I just checked the repository and it was a problem there too. I have now fixed it in the repository.
-
You also don't need to add GDISP_DRIVER_LIST to your gfxconf.h as the ST7789V driver is the only driver in the system
-
The STM32LTDC based board files have been updated in the repository.
-
Don't forget the main thread stack size (which is normally part of your board linker script or part of your operating system initialisation).
-
Make sure you are using the latest repository version as this bug may be fixed.
If not, just add the g parameter to that call and where it is used.
I will check the repository later and if it is wrong there I will fix it.
-
My guess is that the include path does not contain the driver directory (the directory containing the gdisp_lld_ST7789V.c file).
Check that first. Don't forget to do a rebuild all afterwards if it wasn't there. If that is fine, the next step would be to debug into the gfxInit call to get some idea on why you are not getting to the gdisp_lld_init call.
-
Yes it does. If you look at the existing gdisp drivers you will see that they make a bus_aquire call and a bus_release call which are normally implemented in the board file. These calls are there so that they can be used to get exclusive access to the bus. Where the bus is not being shared with another device these calls can be simply ignored.
So from the gdisp side that is what you need to use.
From the touch side there is typically only the one call made. This call must also obtain exclusive access to the bus. If the bus is busy (due to a gdisp call) then gfxYield() can be called in a loop until the bus becomes available.
Well done on getting what you have working!
-
This sounds like you are over-running your stack and therefore modifying unrelated data structures. Please check your stack sizes carefully.
-
Yep. That works too. Well done.
-
There is another simpler way...
Listen for the toggle event in your main event loop and when you get it manually change tabs.
-
Correct. The board file is not portable. The driver is portable but not the board file.
The board file is supposed to be specific to your particular board so it is not surprising that a board file from a different processor won't compiler. The board file is what you should be customising to get the toggle driver working for your board.
Off the top of my head I can't remember if tabsets support toggles. Have a look at the source code and see if the toggle entries are set to anything in the vmt structure initialisation. If it is not supported yet they values will be zero.
-
The SAM7 toggle driver actually uses ChibiOS gpio calls. This should be completely portable to the stmf4 using chibiOS except that the corresponding board file will need to change the pin descriptions.
Usually a hang straight after calibration is an indication that threading is not working. Please make sure the demo runs fine with ginput_need_toggle turned off first.
-
Not easily. Double buffering is never easy.
-
No need to write something new. In your main loop before calling geventWait you can obtain the mouse source and attach it to the listener. That way you will get a copy of all mouse events and you can find when it is pressed over the graph. As an example look at code in the touch test tool (under the tools directory).
-
We will add that line to the current repository. Thanks for finding it.
Note this is a board level change not a driver change and there is a good chance the same or similar bug exists in other board files that use the same driver. I will check and fix as necessary.
Adding a define to use or not use external sdram is not necessary as a board either does or does not use external ram. It is the board file that encapsulates that. If you change the physical board to remove the external sdram then the board file needs to change too. As the stm32fxxc-discovery boards tend however to be used as examples I will add documentation to the board files to indicate what must be done for that type of physical change.
Thanks for your good work on this.
-
There are 2 problems...
1. Your include path is not correct. That is causing the messages about the missing .h files. I suspect the board directory is not on your include path as that is where I would expect those files to be found.
2. That board file is a chibios specific one. The SPID5 is a symbol defined by chibios. You will need to update the code to use the cubemx equivalent.
I thought someone had already done an example for the 429 discovery board for RAW32. Check the downloads area.
Redrawing transparent label with background image
in Support
Posted
Option 1 from Joel's list above is the most obvious and most portable solution.