inmarket

My test didn't have the problem so that is why i asked for your test program (including gfxconf.h file).

Can you please put together the shortest possible test application and add it as a zip to this thread so we can test. Thanks.

What you have done is correct. The problem with the emWin approach is that not all hardware can generate a millisecond counter. Eg Old x86 hardware uses a 18.2ms hardware tick. Using the emWin strategy prevents easy use on that type of hardware. UGFX however overcomes that by not assuming that a tick is 1ms. It doesn't even need a regular hardware tick interrupt thereby enabling use on tickless hardware and operating systems eg Chibios in tickless mode. All it requires is the ability to measure time in some arbitrary manner through the use of a function call, and a way to translate between that arbitrary time measure and milliseconds.

Thank you we will look at the code. Many of the drivers are contributed and you are right, many are poorly documented. That in many cases reflects the source material. Many controllers do not have published manuals. Some manuals are confidential. Some init sequences have been replicated from known working code from other sources. Some have been reverse engineered. Some manuals are just wrong or the chips have undocumented bugs. As for the ILI9325 this is known working code eg The Mikromedia STM32 mini board. Note the ILI9325 are known for knock-off and near compatible chips. Some are marked ILI9325 but are not truly compatible particularly from Chinese sources. That is why there are a number of variant drivers for the ILI series. So, we will test your init sequence and test it against a number of boards that we have. As a result of that we may replace the existing code or we may split it to create yet another ILI series driver. What was the board you used so that we can add it to our database?

Make sure your source control fetcher is fetching mcufont.exe and the dlls in binary (not in ascii mode unlike the source code). The mcufont.exe definitely works. I run it on Win10 64bit and the original exe was compiled on win7 64bit. If you have no success in getting a valid executable then the source code can be directly compiled using the supplied windows makefile and either a cygwin compiler or a mingw32 compiler. I haven't tried vcc (the microsoft compiler). If you compile under windows go directly to the mcufont encoder directory and compile from there rather than from the mcufont root as the mcufont test harness doesn't compile under windows.

Yes - A virtual mouse. There is an idea, perhaps we could write a mouse driver that uses the arrow keys or gpio toggles to implement the mouse. That however would also require a screen mouse pointer - something we don't currently support. In reality it shouldn't be too hard to add the arrow key support to the window manager. We currently support using the tab key to move between controls so it is just a matter of adding a new switch element and some routines to find controls based on their position. Another idea would be to leave left and right arrow keys for use by controls eg inc/dec a slider position and use up and down as equivalents to tab and reverse direction tab. That would probably be easier as their is no need to find controls based on their screen position.

I suspect that @madhu is wanting to use the arrow keys for navigation between controls. It is true that the keyboard will generate arrow key events however the window manager doesn't currently recognise those keys to change the window that has the focus. It needs to be put on the todo list. It will always be a config option as arrow keys are also useful for things like sliders.

Try your same program under win32 or linux. If it works there it indicates that the threading or memory allocation has a problem on your platform. The most obvious of those is memory allocation. Debug to check that the gfxAlloc calls are not failing. If they fail then strange things might happen

Sounds like a raspberry pi might be a good choice as it will support framebuffer, standard hdmi displays of any size and standard serial or usb touch panels. It also has plenty of io.

As an additional aside, if your controller is capable of returning pressure values, using that for z and ignoring the valid flag will often give much better results. The reason for this is that our software detection of an up event is much more reliable than the simple (or non-existent) algorithms built into the controller firmware. When we rewrote the mouse driver we fixed those issues specifically because of controller bugs. Most controllers which have a "valid" flag actually are using that to indicate touch up not that the controller cant determine what is currently happenning . Of course coordinates will be invalid during a touch up but the touch up itself is still valid and important.

Actually it is a bit trickier than that as the system needs to recieve a touch up event. A better way is to always return TRUE but set the z value based on your valid flag. When not valid you don't have to read the x & y values (although you can). The button values you shouldn't touch. You can then set the vmt flags to indicate the behaviour just described. Many of the touch drivers work as just described. Look for one that returns 1 or 0 for the z value. By the way, returning FALSE basically means that no valid reading is available (including the up/down touch state). In your case the "valid" flag is more likely to indicate a touch up condition and therefore the need to return TRUE.

The problem here is with permanency. When you draw a line in a window it will stay there until the window is redrawn. Widgets are specialised windows that have automatic redraw functions that will redraw the window whenever the widget state is changed (a container is a widget) and that is why you are losing your line. The solution is to create your own custom draw function for the container using the wi.customDraw parameter of the initialisation structure. You will then be able to put anything you want in the background of the container.

This sounds like a video mode setting problem. 1. Make sure you are running the latest repo as there were recently updates for the linux framebuffer board file. 2. Have a look in the linux framebuffer board file as there are some optional settings that control the initialization sequence as different linux kernels exhibit slightly different behaviour.

It would be possible to write a keyboard driver for /dev/tty and it should be a simple driver. We have not had a need yet to do so and so it has not been written yet. If that would solve your problem and you are happy to write it we would love to add it to the repository.

Arc filling is exceptionally complex. If you have a look at the code you will see it is by far the largest drawing function in gdisp. While there are some closed source implementations, uGFX is the only implementation that I know of where the source code is published (I know as I wrote the arc fill routine). To add a concentric circle arc routine as in your image multiplies the number of possible segment cases by about four times and that is without taking into account corner cases. So to answer your question, there are no plans to add such a routine. It is just too hard when the same thing can be achieved (although slower) with two seperate simpler arc draws. The only way we would consider adding such a routine would be if a commercial customer was prepared to pay to have it added.

Yes and yes.

The schematics and board layouts for the board are available on the st (www.st.com) website. That should enable you to find the pinout for the display.

Yes containers are what you want to use. Setting the visibility of a container controls the visibility of every child control on that container (and with optimised redrawing). Destroying a container will automatically destroy all the children controls on that container.

It looks like these are being exposed as a keyboard rather than as true gpio pins. In that case you want a keyboard driver rather than a toggle driver. A toggle driver is used when the switches affect sigular gpio pins. A keyboard driver is used when the switches are mapped to key or event codes.

The pixel format must exactly match what your hardware expects. So if your display 320x240 at 24bits then you will need to use something like GDISP_PIXELFORMAT_RGB888.

With pixmaps there is a known incompatibility with the single file make method. To use pixmaps you need to be using the full makefile.

With regard to image display speed there can be several factors at play... 1. uGFX does not decode the image to memory normally. That means that each time you display the image it re-reads it from the source storage and redecodes the image. The solution is to use the gdidpImageCache() function if you have sufficient ram. 2. Where you store the image is important for the speed of the read/decode. For example, reading from a sdcard is going to be much slower than reading from ROMFS. 3. Pushing pixels to the display can be a slow process on some hardware. For example an i2c based controller is going to be much slower than a framebuffer controller in shared ram. Even then things like the ram bus bandwidth can be a factor eg a 800x600 display being refreshed at video rates will use a significant portion of a normal ram available bandwidth. If you are looking at fast refreshing of a portion of the display also have a look at the gdisp streaming calls. They provide the lowest latency method of sending data to the display in viseo style applications. See the gdisp/streaming demo.

It would be useful for you to create a small project (as small as possible) that demonstrates the problem. The issue here is obviously some sort of threading interaction so the important parts are how you are creating your threads and how you are then using them to call your flushing mecanism and the gwinSetText. We don't need all the rest of your code, just a minimal framework to show the problem.

No changes are necessary. The arduino port was actually initially developed using an 8 bit avr chip. Look carefully at the arduino board examples and the wiki and forum for more arduino info. Start by only turning on the gdisp module. Don't get too ambitious too early. Once you have that working then turn on additional stuff. A good place to start is with the demos/modules/gdisp/basics demo. The 8 bit avr's have limited ram and rom so keep an eye on the resource usage.

We want to avoid direct asm files. The embedded assembler can do the job just not the inline assembler. The difference is that the embedded assembler seems to work at a function level rather than the statement level.