inmarket

The master has now been updated. Set the define GDISP_NO_DMA_FROM_STACK to TRUE in your board file to tell it to use main memory instead of stack space for the define. By the way, why are you using main ram for a framebuffer? Ugfx should work without a framebuffer for the SSD2119 controller.

Yes interesting problem. Removing the local variable means that the translation from user pixel format to driver pixel format doesn't occur. This ok if the pixel formats are the same (your case) but is not ok generally. There is however a simple solution - make c a static variable. This can also be conditioned on the use of dma, and optionally a define indicating the use of ccr memory. I will make the change to the master to reflect this (and in other drivers the can use dma too)

These have been updated to the latest master. Can you please test the latest master.

Yes you are 100% correct. Board files are always meant to be tweaked for the specific hardware and cable lengths etc to displays are often a critical factor. In terms of initial settings, what tends to happen is that we (or someone else from the user base) gets a board file working on their hardware. That is then posted as the "reference" board file and it is only when someone else complains about it not working that it may be re - examined. The main reason we don't perform a testing of conservative settings etc is just time. With ugfx there is just so much to do and Tectu and myself fit this around our normal work lives. In many cases we don't own the hardware as the driver/board files have been donated by a user (although I like to do a quality pass over the code before it makes the master repository). It is for this reason that we so highly value your contribution in fine tuning these parameters to work on a much wider range of hardware. Without efforts such as yours ugfx would not be usable by a wide enough base of users. Thank - you. Your changes should make the master repository in the next few hours.

Thanks. I will integrate these changes asap.

Thanks for your work on this. Can you please post your updated board files and we will integrate the changes into the master repository? Also the mouse testing, was that done against the current master. We have completely rewritten the mouse sub system since your previous post in June. The new system is much more tolerant of bad data and transitions. The work you have done with frequency of the busses is fantastic and will be very helpful in getting great results. Thank you for your hard work.

Thank you. We will correct that asap.

Thankyou. We will fix it immediately.

There are a few reasons that the font files are currently in c files rather than h files... Historically it has just always been done this way The font generator generates a c file and to alter this would require changing old and fragile code (I am not sure we can even still compile the mcufont font generator utility) None of these are really good reasons, it however just takes time to change these things and the effort involved has been very low priority considering the other work that we want to get done. Note: this is not the only place in uGFX that c files get included into other sources rather than being compiled directly. Other places this happens include where we are incorporating third party code into uGFX such as FATFS. Doing it this way allows us to leave the original code unchanged and "patch" necessary changes into it using macro definitions from the file including the source. Unfortunately, other than directly modifying the third party code (which may create license issues) this is the only way this can be done. Although using the IDE to directly "build" the project is possible - it is not our supported configuration. Our supported configuration is using a "custom makefile" project. This avoids all of these sorts of dramas. Source files can then be included into the IDE without them affecting the build process. As proof of this, more than 30% of my development of the uGFX library itself is done using Em:Blocks (the other 70% is using the Eclipse IDE or the command line). The original source of this thread related to an IDE that supposedly could not do custom makefile builds. That particular situation is still being investigated.

It is not a bug so much as a difference in how the display is spoken to via a 16 bit interface versus a 8 bit interface. The code you have changed is correct for a 16 bit hardware interface but will break an 8 bit bus interface. The code has previously only been used on such chips with an 8 bit processor interface. This driver is currently used successfully as-is on such boards as the Mikromedia STM32m4 board (which use an 8 bit cpu interface for the display). Note that changing the bus interface width may also require changing some of the initialisation code to ensure the controller expects 16 bit wide data. I will re-examine the code for the driver. It should be possible to define a MACRO that specifies 8 or 16 bit bus width and to alter the code correspondingly. Can you please post your board file and your (modified) driver file and I will build an integrated solution for the master repository so we don't break boards that are using it with an 8 bit bus.

One more thing to try if you must use the chibios supplied makefile... try changing the direction of the slashes in your absolute path to forward slashes.

I suspect you are running into a problem with make under windows. Depending on the version of make you are using it struggles to handle Dos style paths like c:\... The way around this is to try using one of our example makefiles rather than a chibios based makefile. These makefiles can be found in /boards/base/xxx/example. We have spent considerable effort trying to get the makefiles working properly under win32. The chibios supplied makefiles don't work properly under win32 using absolute paths. Please also read our wiki article on your first project in win32. One other bit... Make sure you are using the latest master as we found bugs in our makefiles as late as last week to do with absolute paths under win32

It looks like your GFXLIB define in your makefile (describing the location of the ugfx directory) is not correct. I suspect that is why you get the permission denied errors - it just cannot find that directory Similarly the "no rule to make" seems to indicate the same thing. Hope this helps. Andrew.

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!