inmarket

No. GFILE's nativefs just passes the file name directly to your operating system's file open call. It is the base operating system that finds the file. Nativefs is really just a thunk layer to the standard operating system calls. As GFILE tries each file system in turn, for a development environment you can turn on nativefs and have the file located in the current directory when you run the development uGFX executable, and then when everything works as you expect, you can move those files into the ROMFS without changing any other application code. There is a gfxconf.h macro you can specify which turns on code that enables you to specify a filesystem specific file using a "X|" type syntax but generally that is turned off and thus GFILE searches each file-system until it finds a match.

Something is pulling in those routines from the C runtime library. Find the code that is referencing those routines and fix the problem. It could also be the startup code for your C runtime library itself that is including those routines. In that case you need to use a different C runtime library or set the flags to your compiler to run off the standard C startup routines. Often setting your compiler to produce a map file will help as that will tell you which c source files are calling those routines.

What format is your display in? If your display is in RGB888 then you should use RGB888 if you want the gdispImage calls to be able to recognise the image you have created. If your display is in RGB565 then you should use RGB565 if you want the gdispImage calls to be able to recognise the image you have created. If you are not interested in the gdisp image calls recognising the image then you can use whatever format you want. If the format is the same as your display you can use the below code to get the pixel components (obviously before you do any other translation on it)... r = RED_OF(_acgraphH[4+i+(j*width)]) etc. The reason this works is because if your pixel format matches the display and so the RED_OF() understand the pixel format.

True color does not mean 24 bit. That is a misrepresentation that comes from the X documentation that is applied only in terms of how X uses that term. True color in this sense means that the color is represented directly as r,g,b bits per pixel rather than via a palette lookup or a chroma scale.

The extra 0x20 indicates it is RGB format. 0x30 would mean it is BGR, 0x40 would mean it is greyscale. See gdisp_colors.h

Yes. As your _acgraphH array is 2 bytes each item you will need to add an offset of 4 (4 * 2 bytes = 8 byte header)

Actually just checked. Byte 6 (the 2nd last) must be 0x25 not 0x05. See the pixel color definitions in src/gdisp/gdisp_colors.h

That looks roughly right (without getting out a calculator to check the numbers). The pixel data must immediately follow the header.

The header... Byte 0: The letter 'N' (0x4E) Byte 1: The letter 'I' (0x49) Byte 2 and 3: The image width in MSB first order Byte 4 and 5: The image height in MSB first order Byte 6 and 7: The pixel format expressed in the same way that the macro GDISP_PIXEL_FORMAT is expressed. Note that this must match the pixel format of the current display for the NATIVE image handler to process it. Again it must be in MSB byte order.

If you are not planning on changing the text on a label at runtime you can also write your own custom redraw routine for the label in order to get transparency. It would be a simplified version of the standard default draw routine. The issues with a transparent label primarily relate to redraw issues if the text changes or the label is moved. If in your application the text doesn't change and the label doesn't move relative to its container then a transparent label makes some sense.

Don't forget to set your PATH variable so that the new compiler is included before the one that comes with cygwin.

With regard to GDISP_HARDWARE_BITFILLS etc, they are complicated macros. For single display support they are set using the drivers gdisp_lld_config.h file and included into the general list of defined symbols via gfx.h. For multiple display support it is a lot more complex. The macro is first used to build a VMT (virtual method table) in the driver itself which describes the various available drawing routines. The gdisp_lld_config.h file is therefore now included by the driver itself rather than by gdisp.c and is not part of the general list of symbols included from gfx.h. For the general list of symbols those macros are set as a special value which indicates to the GDISP code it should use the VMT table instead of the direct routine. This is further complicated by allowing a user to set these macros in the gfxconf.h file (but only for multiple display support). If set in the gfxconf.h file these represent overrides that tell gdisp.c that ALL multiple display drivers either do (TRUE) or don't (FALSE) support that routine and thus it doesn't need to test further for support or not. I hope that helps/

It is not clear from your description what you are actually trying to do. When you say you want a "framebuffer to work" do you mean a device that uses a memory framebuffer such as the STM32 LTDC or the Linux kernel driver, Or are you referring to an off-screen framebuffer. If you are talking about hardware that display from a memory framebuffer then you need to use the framebuffer driver and just change the init routine in your board file as appropriate. There are plenty of examples in the boards directory. If you are talking about an off-screen framebuffer then pixmaps are the way to go. Pixmaps create a "virtual display" that you can draw into. The pixmap can then also be used as a NATIVE format image to copy parts of that virtual display onto the real physical display. As there is now more than one display (one physical, one or more virtual) it requires multiple display support in the code which is the part that does not work well with the single file make. If you are wanting to create a "difference" display where you write to a framebuffer and then use some algorithm to flush those changes to a real non-framebuffer display - don't do this. The reason is that uGFX is highly optimised in its drawing routines and understands the underlying hardware design of most embedded displays. uGFX is going to make a much better job of it than any difference engine you create. The only exception to this is for displays where it is not possible to just update a single pixel such as monochrome displays where the minimum update unit is 8 pixels (one byte). For these an internal framebuffer is maintained - see one of the monochrome driver code as an example. Fortunately these display tend to be small and there only require small framebuffers.

In this case the differences in the init sequence and the differences in the routine alone were sufficient to make it worthwhile to have to separate routines. They may look similar but there are differences. Another cost for making them a common routine is the extra parameter. This extra parameter has effectively traded off RAM usage for code size. As you know RAM usage is far more important on embedded processors. Also, once you get beyond about 4 parameters on ARM platforms the cost of the parameters increases as they cause register definitions to be pushed onto the stack. This affects optimisation all the way done the function stack (which in this case is quite deep). There is also an extra conditional branch. While these are small overheads, they still make it combined routine slower and more expensive than the separate routines. On top of that - the ugfx style is to have two different routines for Draw versus Fill. That therefore completed the argument. There is very little value in combining them into one routine as the amount of common code saved is not high enough to warrant the other costs.

This has now been fixed in the repository. The problem was that the window manager was delaying the initial clear (from when the graph widget was set visible) and when this clear happened it was overwriting the axis.

Thanks. This is now in the repository. I have also put the same changes into the slider widget.

It is because of the problems with stlinkdbg that we generally use openocd to debug. You will find the appropriate openocd.ini files in the various board project sample directories. You pathing problems may also be caused by using cygwin programs. Cygwin is a great unix compatibility layer but it does some strange things to paths in order to make it as unix like as possible. Often the equivalent MINGW programs are better in a windows environment because they don't try quite so hard to be unix compatible but instead concentrate on functionality. Our makefiles have a fair amount of code buried in them to handle cygwin strangeness.

There are no current plans to add guesture support. The good thing however is that it is relatively simple to add your own. In your main event loop the listener is capable of listening to general mouse events. Use geventAttachSource (i think that is the name) to attach the mouse to your listener before your event loop. Your listener will then get mouse events that you can process to see guestures. The current remote display code uses tcp/ip. Any hardware that supports tcp/ip connections and is supported by your embedded tcp stack will work. Note also that the remote display and its coresponding client are both written using ugfx so it would be very simple to modify them to use whatever protocol or hardware you want including such things as a simple serial connection.

You would still update the number, name or whatever else you are using to describe the style in the change event. You would just delay the style change till the dial finished moving.

Try using a gtimer toutine to fo the restyling. Set the timer as you move the wheel. When the movement stops the timer goes off and the display styling is changed. It might give a better user experience

There is currently no vertical tabset widget. There are however a couple of other possible solutions... 1. Write a vertical tabset widget using the normal tabset as an example code base. 2. Look at the code in the widgets demo. It has two methods of performing the tabset operation and a #define controls which is used. The first method is obviously using the tabset widget. The second method is to use a group of radio buttons to control the visibility of a set of containers. A custom draw routine for the radio buttons can make them look like the vertical tabs you want and unlike tabset buttons they can be positioned anywhere. There is already a horizontal tab custom draw routine for the radio buttons that you can copy paste and modify.

Pixmaps can be used for that. Note that they take up a lot of ram and they will, in your case, need to be internal ram as the performance issue for you is the external sram bandwidth. Putting the pixmap in external sram with the video buffer will make your problem worse as you are halving your available cpu bandwidth. In reality it would even be more than a halving performance penalty because you will lose cpu caching due to the ram lines being more than the cpu cache apart in size.

The redrawing strategy for ugfx is much simpler than a normal desktop operating system. Because it doesn't support clipping shapes (due to the code and RAM requirements to implement such a feature), when it wants to redraw a container it needs to first redraw the container and then redraw each of it's children. Each of the children then appear to flash as the container is drawn on top of them before the child gets redrawn itself. Unfortunately nothing can be done about this without implementing clipping shapes which we will not be doing anytime soon for the reasons above. Now that you have changed your redraw strategy, compare setting the page to invisible or not first. It may or may not improve the drawing behaviour you see depending on how many redundant redraws the new strategy has been able to save. GWIN_REDRAW_IMMEDIATE is a very good flag to have turned off. When this flag is on all redrawing must be done on the current thread at the time the causal event is triggered. As this is normally buried deep in an input driver GWIN_REDRAW_IMMEDIATE causes this all to occur on the now very deep stack thus causing very high stack usage. By turning this off you have sped up your redraw and also significantly reduced your stack usage. In general, unless there is a specific need to play with the GWIN redraw flags they should be left as the default values ie unspecified (all FALSE).

The frame widget now has a new flag GWIN_FRAME_KEEPONCLOSE to be used when creating the frame window which will prevent destruction of the frame when the close button is pressed. Note that with this flag specified, the close button does not hide the frame - the user application will still need to trap the CLOSE event and manually set the frame to invisible. The flag just prevents the frame window from being automatically destroyed when the close button is pressed.

The new flag GWIN_FRAME_KEEPONCLOSE will now prevent destruction of the frame when the close button is pressed. Note that this flag does not hide the frame - the user application will need to trap the CLOSE event and manually set the frame to invisible. The flag just prevents the frame window from being destroyed. This is now in the repository.