inmarket
-
Posts
1,296 -
Joined
-
Last visited
-
Days Won
4
Content Type
Forums
Store
Downloads
Blogs
Posts posted by inmarket
-
-
The STM32F429i-Discovery is now in the current master repo along with an example makefile for chibios.
The gdisp display is now working. I haven't yet written the board file for touch support. That however should be very easy as I believe it uses one of our supported controllers for touch. When I next get some time I will get that working too.
-
To explain a little...
Chibios and other embedded operating systems don't provide lcd drivers or code to draw using those drivers.
ugfx provides those drivers and the drawing code. To make that work there are two levels of interfacing... One between ugfx and the operating system. This is provided by the GOS layer in ugfx. It enables ugfx to use freertos or chibios or even win32 for operating system services.
The other interface layer is between the ugfx driver and the physical hardware. This is required because the same graphics controller chip could be connected to two different boards in different ways. The board file provides this interface. That is why the board file from the Mikromedia board does not work with the 429 discovery. They are physically connected very differently.
For the 429 discovery it gets worse. Although it has a ILI9341 controller chip it is driven in a very strange way on the 429 discovery board. It appears to only be used for initialising the display with the cpu ltdc controller then taking over based on a frame buffer in sdram. The sdram is external to the cpu so it also requires special initialisation.
what this all means is that the normal ugfx ILI9341 driver cannot drive this board and neither can the ugfx frame buffer driver. What is needed is a custom driver that is a hybrid between the two with some special ltdc controller, dma and sdram code thrown in as well.
I am currently in the process of writing this special driver and if everything goes well I should have an example project in the ugfx repository that will work with chibios sometime in the next week.
The examples you have seen to date with the 429 discovery board are all based around freertos and use the STM32 firmware library to do all the heavy lifting of initialising the lcd. This firmware library is particularly "heavy" so the new driver I am currently writing will work without using it.
Please be patient, I am nearly there.
-
I Have just recently received a 429 discovery myself.
It is sitting in my "to do very soon" box.
The one missing part is a display driver for the 429.
Hopefully I will get to it this week.
I also primarily use chibios and so that will be the platform I build it for.
-
Exclude the font source files from your build list. They are automatically being included in other ugfx source files.
The error is occurring because the font source file is effectively being compiled twice.
-
Another quick thought...
uGFX assumes that the .bss segment has been cleared to zero as per the C standard. The .bss segment stores variables that have not been explicitly initialised in your code at compile time. This task is usually performed by the C runtime before reaching your main function.
It is however possible that because you have no C runtime library that your cpu startup code is not clearing the .bss segment. That will cause all sorts of strange issues.
This is one of those embedded development traps.
-
I suspect one of three things...
1. It is requiring LCD_Init() to be called twice.
2. There is a timing issue and calling it later saves the day, or
3. There is some difference in the IO state between the two locations.
I would try putting a delay before and after LCD_Init() in the board file, checking the LCD_Init() is actually being called, putting a double call to LCD_Init() in the board file (possibly with a decent delay between them).
Another thing to try is to ensure the uGFX startup logo is turned on and see if that displays or you at least get the delay associated with its display (a few seconds I think).
Hope that helps.
-
-
Thank you for showing this. What a fantastic project!
-
The compile errors you are seeing are due to using chibios V2 board files in a chibios V3 compile or visa versa. Either revert to using the chibios version which match your chibios board files, mcuconf.h etc or update those files to be compatible with the latest chibios.
Chibios V3 has a number of demo files to get you started although personally I would revert to chibios V2 because the V3 api is still in flux and changes in incompatible ways from time to time.
Also, if you can't solve it that way you should discuss this on the chibios forum as this is definitely a chibios problem.
I recently updated the ugfx support for Chibios V3 because of its changing api. Unfortunately that means we are then incompatible with older snapshots of V3.
-
You must still do the gfxinit () call as that initialises the code that gfxYield uses.
At least you now know you have valid gfxSystemTicks and gfxMillisecondsToTicks functions.
-
-
An ecos package has not been built. It is on the todo list but is not high priority.
For now ugfx is treated as an application.
Tectu's answer above gives you the basics of that. Also look at the code in the boards/base/ecos... directory.
If you want a cpu connected as a remote display you can use the ugfxnet display driver and the corresponding display client but replace the networking with SPI code.
Alternatively you could write a new display driver based on one of the existing spi controllers and have the other device emulate that display
-
Simple replacement method...
In your systick_Config handler function just increment a volatile uint32_t variable.
gfxSystemTicks should then just return that variable.
gfxsleepmilliseconds should then work.
-
Why not just draw the change where you detect the value has changed. Then the redraw routine only needs to handle the full redraw situation.
-
It's always a compromise between features, code size, code complexity, cpu cycles and ram usage. We trade one off against the other all the time with embedded programming.
In this case adding containers and the ability to have overlapping windows (even if it is in limited situations) added a lot of complexity and some code size. By compromising on the "draw once" principle we saved lots of code and in particular a lot of ram (multiple clipping regions uses significant runtime ram).
It may be possible to make minor changes to give a "conditional partial redraw" as you have done with minimal code. It is just going to take me time to ensure that we are not creating incorrect updating in some circumstances by adding it.
I am guessing that you have a particular widget in mind and a particular reason for wanting partial redraws. Can you please fill me in a little on those reasons and the widget concerned as that may help when I look at this?
-
Delay () won't work as part of the implementation of gfxsleepmilliseconds () because it doesn't allow anything else to happen while sleeping.
I suspect the tick timer has not been initialised correctly.
As a simple test write a loop that gets the tick value and when it has increased by 1000 then it toggles the leds.
Is the tick counter even updating?
-
We originally had similar code but took it out for a couple of reasons when we did the redraw engine redesign..
1. There are many conditions where the wrong things end up being redrawn. Multi thread is such a pain!
2. It was just more complexity for gains in very few areas.
3. Full redraws are seldom a problem as you are just overwriting unchanged bits. There are no display artifacts other than some wasted cpu cycles and a slightly slower redraw.
4. Code savings made the effort worth while. Instead the code savings were invested in container and z-order based redraw capability.
I will look at your changes in more depth in a week or so (just busy with real life currently). If I can verify they work reliably without any of the original partial update issues I will merge them with the master repository.
-
For simplicity ugfx widgets always redraw the entire widget. This just keeps code size and ram requirements small. Handling multiple or non window sized clipping regions is very complex.
That being said, there is nothing stopping you from doing a partial draw in response to a signal or event or api call. This would just occur outside the normal redraw handling. An example is the graph window. The graph window does not use the automatic redraw at all. Instead it draws in direct response to a drawing request.
Widgets must have an automatic redraw (graph is a window not a widget) but widgets can still draw outside the automatic redraw.
-
No. A tick is not the speed of the cpu. It is an arbitrary unit of time derived from the clock oscillator.
For example many embedded operating system use a 100 hz tick. DOS use to use 18.2 ticks per second.
The tick that you used for gfxgetsystemticks is the one that you initialised 1 tick = 1ms using systick_Config. Based on that your multiply factor is 1 so gfxMillisecondsToTicks (ms) will just return ms.
-
Yes that is correct. It is usually just a simple multiply or divide.
-
A simple test to verify the problem...
Manually delete the .dep directory. The first make after that will succeed (subject to any other compile problems). Try compiling again and it will fail. It is the format of the paths in the dependancy files that is killing the compile.
-
By the way - proof that it is using the cygwin tools comes from looking at the fork problem line. Notice that sh comes from /usr/bin/sh. This path shows that it is cygwin based as the mingw version would show a Dos style path.
The fork problem is likely caused by having mismatching versions of the cygwin.dll file. Perhaps there is an instalation of cygwin on your system where the version conflicts with the version included with chibistudio. This is why I suggested to upgrade your cygwin instalation on your machine. If that doesn't fix it go looking for errant cygwin dll's on your path.
-
This is definitely the cygwin make issue. The chibios chibistudio uses the cygwin make to execute it's makefiles and so is subject to these problems. It is exactly this scenario where I came across this problem -chibios being my primary platform at the time.
Because it is environment based I got no answers from the chibios forums etc. I eventually found the problem. I switched to using the mingw make which has less problems than the cygwin make.
When I was doing the make system rebuild for ugfx I added the fixes into our scripts for these problems. As chibios has never acknowledged the problem it continues to be a problem with the chibios make scripts on the Win32 platform - but only in certain circumstances eg using absolute paths containing a drive letter. It is the colon in the path that causes cygwin make to die when handling dependancy file inclusion.
-
These are problems I have experienced.
This is a problem when compiling in Win32 using the cygwin make program. If you are using UNIX you can ignore the discussion below and your problem must lie elsewhere.
Cygwin make gets confused with DOS style paths and drive letters and it seems to affect it worst when including dependencies.
Firstly update your cygwin installation to the latest version. I expect that will get rid of the "sync_with_child" issues but not the dependency issue.
If you update to our latest master in the git repository and use one of our example makefiles (eg. boards/base/Win32/example/makefile) we have put special code in to handle these cygwin nasties. If you are cross compiling for another platform (eg ARM) just use another example makefile in the board area as your base makefile. All our example makefiles now contain the fixes that allow them to compile properly on Win32.
The makefiles provided as part of the ChibiOS project do not have those fixes and often have issues when compiling on Win32.
Whilst the GNU make is very powerful (which is why we use it) it has a number of very bad limitations (on all platforms - Windows and Unix). The cygwin version has even more limitations. We have put a number of fixes into our makefiles to overcome many of these limitations. The current rules when using our makefiles are:
- With our makefiles you can handle absolute paths (eg c:\mydir) or relative pathnames (eg ..\mydir) using dos or unix directory separaters (eg "\" or "/").
- You CANNOT currently use drive relative pathnames (eg e:mydir).
- I think we can handle directories that have spaces in them provided that the makefiles do not reference any part of the directory that contains the space eg. If the project directory is "c:\my dir with spaces\project1" you can use paths such as "../otherdir" in the makefile but not anything that contains a space. (I have not fully tested this). It is generally better to not use directories with spaces in them at all with GNU make.
- Filenames cannot contain spaces at all.
On our Wiki we have a very nice article on getting your first compile to work on Win32. Follow those instructions first and see how you go.
- With our makefiles you can handle absolute paths (eg c:\mydir) or relative pathnames (eg ..\mydir) using dos or unix directory separaters (eg "\" or "/").
STM32F429I-discovery working example?
in Support
Posted
I have now added touch support for the STM32F429i-Discovery.
You will need to use the newmouse branch of the repository rather than the master branch in order to get this code.
The newmouse branch will soon become the master branch (we just need to finish porting some old board files) so there was little point adding touch for this board using the current master.
The full widgets demo should now run.