Joel Bodenmann
-
Posts
2,656 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
Wow, looks like you're doing really good progress. Like that the driver will be part of the official repository in no time
~ Tectu
-
Thank you very much for the update. I'm glad that you're making progress with display.
~ Tectu
-
Nice work!
Please keep us up to date. I put a link to your blog in our demos section.
~ Tectu
-
So, uGFX is up running on a Raspberry Pi with FreeRTOS operating system.
Glad to hear!
Could you please share your work with the rest of the world? This would help the project to become more popular as this is currently our biggest concern. The User Projects section of this forum is suited.
If you don't have a blog or something, I am more than happy to give you access to the new wiki so you can create a page there. I am planing to add a section in the wiki which shows many different demo projects anyway.
Let's see if we can find out what causes the problem with the startup logo and a halting FreeRTOS...
~ Tectu
-
Does your display controller provide a native orientation mode? As in: Can you tell him to flip 90°?
If not, it's just a matter of doing some calculations for the pixel positions. The following is a code snipped from the framebuffer driver:
LLDSPEC void gdisp_lld_draw_pixel(GDisplay *g) {
unsigned pos;
#if GDISP_NEED_CONTROL
switch(g->g.Orientation) {
case GDISP_ROTATE_0:
default:
pos = PIXIL_POS(g, g->p.x, g->p.y);
break;
case GDISP_ROTATE_90:
pos = PIXIL_POS(g, g->p.y, g->g.Width-g->p.x-1);
break;
case GDISP_ROTATE_180:
pos = PIXIL_POS(g, g->g.Width-g->p.x-1, g->g.Height-g->p.y-1);
break;
case GDISP_ROTATE_270:
pos = PIXIL_POS(g, g->g.Height-g->p.y-1, g->p.x);
break;
}
#else
pos = PIXIL_POS(g, g->p.x, g->p.y);
#endif
}Sometimes it's also a good idea to take a look at already existing drivers.
~ Tectu
-
The µGFX library is now documented through a wiki. Check it out!
~ Tectu
-
Sure, let us know when you need any help.
~ Tectu
-
No reason to be ashamed of yourself. We all do make mistakes
I'll be more than happy to include the driver in the official repository once I find some time.
~ Tectu
-
Hello and welcome to the community!
If it writes bytes directly through SPI, then everything is OK.Could you please point directly to the working code and the not working board file? When I understand you correctly you already have a working driver and just porting it to uGFX does not work?
~ Tectu
-
After some more days of thinking I came to the conclusion that GREGISTRY might still be better than GCONF so we don't confuse new people with the configuration of the uGFX modules themself (gfxconf.h) etc.
~ Tectu
-
Thank you very much for reporting this bug. We just fixed it.
~ Tectu
-
I am sorry for my late reply. I have been quite busy these days.
Module name
As it makes sense to keep the module name as short as possible (see the following point), I'd strongly prefer to call the module GCONF instead.
API
I totally agree with the API listed by steved. However, the API style of uGFX is as the following: (); using camelCase. Following these rules, the API has to look like the following:
bool_t gconfWrite(uint16_t tag, const void *data, uint8_t size);
uint8_t gconfRead(uint16_t tag, void *data, uint8_t size);
uint8_t gconfSize(uint16_t tag);I'm sorry but I am very pedantic when it comes to API and naming convention. I am already struggling with the older GDISP code that does not fit into the current naming style. However, this will be updated with the next major release.
Edit: I just realize that inmarket already adjusted the API naming accordingly in his second last post.
With everything else I agree. This looks like a solid base to start.
~ Tectu
-
I am AWFULLY sorry. I actually had "make sure that GDISP_RAM is correct" in the list from the other post, but for some reason I deleted the wrong line.
But I'm glad to hear that it is working now
Feel free to open a new thread for any question you might have.
~ Tectu
-
I'm sorry, I meant "Call gdispClear() after gfxInit()", not gdispInit() (there even isn't such a thing).
At the moment I cannot see any reason why your board_init() does not get called. Please step through your code and show us your trackback / calltree if necessary.
Setting the backlight there does not seem to be a very good idea to make sure that the function is being executed as the backlight settings will probably be overwritten after that call. Step through your code instead (or light up an LED if you're not able to properly debug it).
Well, when it's an ILI9320 then you should probably also know that there have already be an awful lot of problems with the ILI93xx drivers. It looks like there are MANY different revisions of that chip out there. I myself even had the problem that I received an ILI9325 and the chinese person told me it's an ILI9320 and vice-versa.
What I strongly recommend you to do is replace the initialization code inside gdisp_lld_init() and replace it with the working ones you have.
~ Tectu
-
It looks like you're using the wrong driver. The web site you linked says that the board uses an SSD1289 controller, but inside your board.mk you include the ILI9320 one. Please make sure that you include the right driver. Change the board file accordingly.
Other things I have noticed:
- Disable all the other subsystems until you have your GDISP module working
- Don't uncomment values in the gfxconf.h file when you leave it to the default value anyway (talking about GDISP_TOTAL_XXX
- Call gdispClear() after gdispInit(). I recommend to take some vibrant color for debugging (like blue or red).
~ Tectu
Edit: fixed typo gdispInit() -> gfxInit()
- Disable all the other subsystems until you have your GDISP module working
-
"evening" is starting here in about 30 minutes. Then I'll take the look as promised. Stay tuned :-P
~ Tectu
-
I'll take a look into this this evening. I'll keep you posted.
~ Tectu
-
Using the GFILE to be able to read and write these configs to any file sounds sane. However, I'd definitely keep the GFILE magic hidden behind a real uGFX configuration API. This could become part of the core system (gfx.c) in form of:
gfxConfigSave()
gfxConfigRead()
gfxConfigXxx()About the buffer size: I'd recommend to make the first few bytes the information about the size of the actual content. One could then read out these few bytes, allocate the space and continue reading. This could either be implemented in form of gfxConfigGetSize() or simply doing it manually in gfxConfigRead().
~ Tectu
-
Hello Steve
This sounds like a good idea and it's definitely suited for the future.
Both, Andrew and I, are very busy at the moment. As soon as we finished our current tasks, we'll take a look at this. I'm sure that Andrew has some more comments on his own as well :-P
~ Tectu
-
Could you please attach your project? The important files are:
- main.c (any any other related sources)
- Makefile
- gfxconf.h
- board files
One more thing to check: Can you please make sure that the backlight is on? You should try to manually enable it in your main source files first. It's very likely that your display is actually displaying it but you just can't see it as the backlight is off. Also, when the backlight is on the screen might either be white or filled with garbage. The later would indicate a successful display controller initialisation.
We're more than happy to help where we can.
~ Tectu
- main.c (any any other related sources)
-
This is strange... I took my Embest hardware and I don't experience this issue at all (the backlight is a problem indeed. That one used to work but got merged the wrong way at the end).
Could you try to find something like a version or revision number on your Embest LCD board?
~ Tectu
-
Hello himsha and welcome to the community!
I am working with SSD1963 7" 800x480 TFT. Refresh that I am able to get is ~8FPS using FSMC. How ever it is seem that maximum FPS that can be achieve is ~30 FPS. Is any here able to achieve this FPS?
We need a lot more information to help you with this one.
- uGFX version (or repository state)
- Underlying operating system used (the GOS port you use)
- The microcontroller that you are using
- The clock setup of your microcontroller
And the most important thing: Please attach your board file (gdisp_lld_board.h).
And 2nd how µGFX embedded GUI is helpful in designing TFT source code?I don't understand your question, I'm sorry. Could you try to rephrase it?
~ Tectu
- uGFX version (or repository state)
-
Hello Wolf,
Sorry for our late reply but as we mentioned in the Announcement section we were not only for a couple of days.
Do you still have the problem? I took out my STM32F407-Discovery board with the same Embest baseboard + LCD module and everything works as expected here. Could you please attach your main.c (test case) and your gfxconf.h?
~ Tectu
-
I won't be online at all until the 16th of June, 2014. All posts will be handled after that date for sure.
The second uGFX maintainer, Andrew aka inmarket, will have a look at the forum during his spare time and handle posts accordingly.
Thank you for your understanding.
~ Tectu
Using uGFX on bare metal
in Support
Posted
Could you please attach or paste the entire build log? If it's not too much trouble, please attach a .zip with your project code and especially the gfxconf.h file.
I'm not quite sure, when you say you use CooCox IDE, is that just the IDE or does it force you to use the CoOS RTOS at the same time? Does the IDE use Makefiles?
I am just curious from where the type conflicts (redefinition of the int types) come from. Are you using some other subsystem? Some STDperiph library maybe?
This is surely fixable ;-)
~ Tectu