Joel Bodenmann
-
Posts
2,620 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
There's not much sense in building such a demo for us. There are just too many factors which differ from system to system. Even if we build such a demo, there will be problems regarding toolchains. People use different compilers, different IDEs, different flash tools... As soon as we are through that, we have the problem that the panel settings differ from each display (the gdisp_lld_panel.h).
However, the STM32F407 discovery board is well supported by ChibiOS/RT and it runs out of the box. The SSD1963 driver of µGFX itself is used by many community members as well and there's even a demo board file for the STM32F407 discovery. Assuming that your toolchain is working fine and that you're able to wire it up correctly, there's really nothing that can go wrong beside the panel config file - and that's where we simply can't give any working demo at all.
If you have specific questions, please feel free to open up a new thread and ask, we will help you as best as we can.
~ Tectu
-
Sounds good to me! The video has been added to the blog.
~ Tectu
-
That's cool! May I put the video onto the blog?
Please note that you have to contribute your modifications of µGFX due section 2.1.c of the license.
~ Tectu
-
Wow, that's a great video... but is that already µGFX or something done by the distributor? :shock:
~ Tectu
-
Nice to hear that you finally got it working! Maybe you could provide a small video once you got something working? It would be nice to have a demo showing cyrillic stuff.
Why do you use STDperiph lib for the FSMC by the way? There are many example board files showing how to use FSMC within ChibiOS/RT.
May I ask how much you paid for that board? I cannot find any price information
~ Tectu
-
Nice to hear that you got it working!
Good luck with the SPI - the forum will always be there
~ Tectu
-
We need to have the schematics of your hardware in order to check your board file.
~ Tectu
-
This guide leaves some notes about getting the GDISP_RAM value set properly.
~ Tectu
-
Hello tronicgr and welcome to our forum!
I tested the SSD1289 driver myself two days ago and it still worked fine, therefore the issue must be somewhere else.
How is the display connected on your board? Is it a GPIO bit bang or does it use the FSMC interface of the F4? Can you attach the schematics of the board? I have some F4 discovery and an SSD1289 here, so I can try to hook one up to that board.
Also, what does 'black/white screen' exactly mean? Do you see anything or just a black screen and nothing at all?
And to answer your question: There are no ChibiStudio examples themself, sorry. But I am sure we can make this working without any problems
~ Tectu
-
This guide should lead you through the process without any problems. In the Integrate µGFX section, you can find a link to a working Win32 Makefile.
Basic examples can be found under /demos/modules/gdisp/. All these demos are meant to work out of the box just by copying the gfxconf.h and the main.c file from the demo directory to your working project.
~ Tectu
-
I finally got my hardware back so I could test it out. You were right, there was a bug. It's fixed.
Thank you very much for finding and reporting!
~ Tectu
-
Thank you very much for finding and reporting.
I have currently lend my SSD1289 hardware to a friend - I'll digg into this within the following week.
~ Tectu
-
That's really impressive, thanks for sharing!
I added your video to our demos section 8-) I also let the people from the ChibiOS/RT community know.
Please keep us up to date.
~ Tectu
-
My thought is that any window drawn over another could impose a clipping area that would prohibite the window on the back to draw there. After setting visibility of the foreground window to false then the window on the back could be redrawn / refreshed etc.
Note that this would require to save the actual information for the background display somewhere. The displays we are using are simple memory mapped display and we cannot afford double buffering or any other kind of "information memory". What I want to say: When you want to draw something to the part of a background window that is overlapped, then you cannot display it directly, so you have to save it to some other memory location. After the overlapping foreground window has gone, you have to read your memory to see what needs to be drawn to the newly revealed area. This would involve a huge amount of memory.
~ Tectu
-
I recommend you to take the gdisp_lld_board_template.h you can find in the driver directory and start filling out the needed routines. There's no real difference between 8- and 16-bit mode apart from how you actually talk to the display. You can take a look at the tdisp_lld_board_st_stm32f4_discovery.h which you can find in the HD44780 driver directory of the TDISP module. It shows how different bus widths can be handled.
Just as a side note: Make sure your display itself is in 8-bit mode. Many of these display modules you get from e-bay required to change a solder bridge or any other kind of jumper to select the 8-bit mode. However, some just might need a different initialization value.
~ Tectu
-
I've added a full example using cyrillic fonts to the repository. You can find it in /demos/modules/gdisp/gdisp_fonts_cyrillic. I added some more documentation about how to use the font converter etc.
~ Tectu
-
Thank you very much for your contribution. Your work seems very good so far.
I added the driver to the repository. Could you please give it a try to confirm that everything works as expected?
You may want to tell me your real name, in case of you want to see it on the contributors page.
-
Uhm, that's strange... I'll try to find some time to look into this. Can you probably clean up your code in the meantime and upload the latest version?
~ Tectu
-
Did you make sure that it's not a stack issue?
~ Tectu
-
Hey mate,
I'm sorry. There was a huge spam attack going on over night and I had to delete several accounts, most of which were inactive like yours. I observed that you where online many times but you never actually wrote something, so I thought you might have been some sort of scan bot.
Please don't take this personally. You're totally welcomed here.
~ Tectu
-
Can you please describe what exactly you did? There happened some real life stuff and I won't be able to put together a full tutorial before wednesday.
~ Tectu
-
Maybe it would be a nice idea if we'd introduce some value widget. It would be like a label widget, but you can only display digits. You give it the amount of digits before and after the decimal point and then you can simply display integer values. It can then recognize the changes very easily and just update the changed ones.
Let me know about your results.
~ Tectu
-
Redrawing any GWIN widget does indeed clear the entire widget are with the background color and redraw from ground up. The label does the same. To optimize this, you'd need to know the current content of your display memory and with most setups you don't do that (no double buffering). You'd first have to read back that pixel and then decide if it would need to be updated or not. Just redrawing every pixel is way more efficient there.
However, usually you don't redraw yourself anyway. The widget recognizes itself when its content changed. As soon as you call gwinSetText() on your label, it will update while the others stay the way they are.
~ Tectu
-
Making a widget unvisible using gwinSetVisible() will clear the entire widget area with the currently set background color. That's the reason why you get a differently colored rectangle there.
Furthermore, a widget does have a clipped area using gdispSetClip(). However, destroying a widget should reset the clipper - I'll take a look into this. To draw anything on the screen, you should just create a plain GWIN window and draw to it using all the gwinDrawXxx(GHandle, ....) API calls (Take a look at /demos/modules/gwin/basic). This will workaround your clipping problem too.
~ Tectu
How To Start
in Support
Posted
See, this is exactly the problem I mentioned
When you're using Keil as your IDE, you have to add all the used .c and .h files of µGFX to your project path. I did this once for a friend quite a while ago and it was a real pain. Sadly it's not possible to build from an external Makefile out of Keil, so you can simply forget about the Makefile (modification). I'd suggest you to use ChibiStudio. That's a ready-to-use eclipse setup coming with the compiler and flasher already built-in and setup.
~ Tectu