inmarket

We are unsure of how to handle an IDE that won't allow such basic operations as to exclude files from a project tree or do a makefile build. We have not come across that sort of behaviour before on the many IDE's we have used. We will test mbed.org and get back to you

I would suspect the error is in the original font. A font with every character the same width is not the same as a monospace font because of kerning. If there is no kerning information in the original font then the two are equivalent. That your font changed its display based on kerning information implies the original font had kerning information in it which a true monospace font should not have had. Well done on finding the problem.

Whilst we are not the developers of MCU font, we should still be able to help you. The function you mention is the correct one. What you are missing is that it also adds an inter - character gap which is font dependant. It could be that it is just an extra single gap but more likely your drawing routine is not taking into account the gap between characters thus leading to incorrect rendering and an error that appears to be string length dependent. When implementing the gfxGetStringWidth() function for ugfx and the matching drawing implementation, the code needed to take account of this. The ugfx function should return the correct result. In general you should use the ugfx functions rather than the base mcufont functions where ever possible if you are using ugfx. If not you will need to contact the author directly.

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.

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.

Well done!

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.