inmarket

As we said, we are at the point where we need code to help you further.

Looking at that doc reference it looks like the armcc compiler cannot do the required functionality using the inline assembler. In particular it allows no reference to the real registers, access to sp & lr are prohibited and storing of register values on the stack is also prohibited (which actually makes it pretty useless). There is an alternative called "embedded assembly" which does not have those restrictions. Unfortunately in my brief scan i couldn't see how to use it. I will leave it to you to investigate further.

Since the last article we have made changes to the c library handling so it may (or may not) now work with the Keil c library routines. There has been no progress on rewritting the asm calls to be Keil compatible as there are other working solutions (eg switch to gcc) and we are short on man power. Hopefully sometime soon this will become important enough for someone so that they volunteer the time to update the asm code for Keil.

With embedded development, other than real time issues which are not relevant for a gui, there is really one overriding design criterea... keep things small. The most critical resource on most embedded boards is (in order) RAM, followed by ROM, followed by cpu speed. As RAM is the most critical of these we spend a lot of time optimising RAM (which includes stack usage). We will often sacrifice code size (ROM) or rendering speed in order to save a few bytes if RAM. The next most critical resource is ROM. In any gui there is a temptation to add lots of features. Those features take code space and therefore reduce the available ROM and therefore reduce the applications maximum complexity. So, features are added only if essential to the operation of the control. For example, ugfx does not handle overlapping windows well except in a strict parent/child relationship. This is to save RAM and to save significant code space. This is worthwhile as overlapping windows has little benefit in a largely static application. It is not a user desktop situation where the dynamic creation and moving of windows is critical. One major tool we have in keeping code size down is ugfx's use of conditional compilation to only turn on needed features. The last major consideration is cpu speed. While embedded cpus are getting faster and faster the more efficiently you can code something the higher the apparent speed and the lower the power consumption. For ugfx, while we often develop on high powered desktops or high speed embedded devices, in the real world manufacturing cost, power consumption and other factors mean that the end device is often very low powered. As the ugfx library is built to support all these configurations these factors are critical in ensuring that ugfx does not outgrow the very environment it was designed for. A prime example of that is Linux itself. It started out as being able to run on machines with as little as 1M ram. These days it would struggle to run in less than 256M. Ugfx currently runs on 8 bit micro's (although slowly), in as little as 1k RAM (although with very limited functionality) and with as little as 2k ROM (again with limited functionality). In reality a decent minimum size for ugfx is a 16bit micro, 4k RAM and 10k ROM.

If you are getting error 22 the most likely causes are: 1. Your kernel does not have a framebuffer driver installed. You may be able to recompile the kernel to include it or you may be able to load it dynamically. 2. Your kernel framebuffer does not support the video mode you are trying to set. One of the easiest ways to test this is to add the flags to the linux kernel bootloader to start the kernel in graphics rather than text mode. Whatever video mode that ends up using set your ugfx parameters to match as the linux graphics boot internally uses the framebuffer driver.

What platform are you running. If you are say running raw32 it is using a cooperative multitasker. This means that once the flush starts no other thread will run until the flush completes. Also, all drawing operations are mutex protected. As the gwinSetText issues a redraw then depending on your redraw strategy (controlled by gfxconf macros) the actaul redraw of the control and any subsequent flush may occur synchronously. Look carefully at the gwin redraw settings. The defaults are usually the best. Finally, depending on your operating system, thread priorities might not be implemented at all at the operating system level. Basically we need a lot more information and an example program (as small as possible) that demonstrates the issue to help you debug further.

Yes. The linux framebuffer is designed for situations where ugfx is the only application writing to the display (no X or other gui). It is ideal for embedded application situations where linux is the operating system but you want absolutely minimal disk footprint and minimal opportunity for the user to "get around" your provided gui. Eg Ctrl Shift Backspace will kill X and drop to a text command shell on most linux boxes with X.

Rather than using your own low priority thread to flush the display have you tried using the ugfx flushing mechanism? Of particular interest to you may be the GTIMER based flushing mechanism. Unfortunately it is not possible for us to debug what sounds like a mutex contention without actually having your display driver code (including the low priority flushing thread code). I would suggest to try using the ugfx flushing mechanism first. If you can't use that then provide us with the driver and thread code and we will see what we can do to help.

St link is supported well with openocd. You will in fact find an openocd.ini in each board directory in the repository for the boards i commonly use. I use openocd under eclipse for just about all my dev work. It works well with the stm32f7 boards (although you need an up to date version of openocd for the f7 support).

Not currently. GFILE is currently just a translation layer to the underlying file system. Some of those file systems have no concept of a volume (in fact FATFS, PETITFS and NATIVE are the only ones that do). I presume here you are talking about a FATFS volume? If so the proper approach currently is to use the FATFS call directly to determine that.

Yes, i believe that someone has used a pic32 chip and had it working. I dont know what changes were made if any. UGFX is designed to be cross compiling compatible with many cpus and many different compilers. We have even had someone who has had uGFX running on an 8 bit micro. Searching the forums may help you find related content.

Good idea.

Yes that approach should work. The vmt flag is really designed for touch devices that are more than likely going to be used with finger. We should probably add a gfxconf setting for defaulting to finger for every other situation.

UGfx relies on two threads, the main thread for the users application and a gtimer thread. The user may of course add extra threads for their application. Ginput code usually ends up running on the gtimer thread as part of a gtimer event. All gtimer events effectively run synchronously on the one thread. Doing things this way keeps stack use as small as possible. Mutexes are needed to protect objects and api calls where... 1/ uGFX might call gfxYield or one of the gfxSleep calls; or 2/ where the underlying thread implementation is preemptive. The raw32 thread implementation for example is non-preemptive and so this clause 2 doesn't apply. Note that generally mutexes are cheap. They tend to have very little overhead unless the mutex is already taken (likely to be an uncommon occurance). The unfortunate side is that they can take up space in structures (increasing the structure size and therefore ram requirements) and they introduce code complexity. Still if you are runnung in a multithreaded environment then they are required.

Note the pixel format specified for uGFX must exactly match the pixel format for the framebuffer in the Linux machine. The pixel format in uGFX is setup at compile time not runtime so it cannot handle when the Linux framebuffer is not in the format it expects. The problem you are describing on your target sounds very much like a pixel format mismatch problem.

uGFX Studio itself uses c++ with widgets however that is closed source. It does however demonstrate that it is possible.

Have a look at the oscilloscope demo under demos/audio. It creates a simple custom widget from outside the normal ugfx gwin directory. That will hopefully give you some hints. It is virtually impossible for us to be able to diagnose any further without access to your project and source files. All we can do is provide some hints on where to look.

The other way is to use byte escape sequences that match the utf8 version of the unicode character. As for the undefined symbol when compiling c99 - that is a question to ask in linux forums as it is a linux defined symbol. I am surprised that changing the language standard would cause t h e symbol to be undefined in the standard linux headers.

Those references that are undefined are routines you need to create to save and reload your touchscreen calibration data. Saving calibration data obviously requires some form of persistant storage. As ugfx knows nothing about any persistant storage on your board you need to provide the routines to do that. As you are using chibios, the main stack size is defined in one of the chibios config files in your project. I can't remember which file or what the setting is called (I think it might also change between chibios versions). You will need around 2K ram on your main stack for any reasonable sized ugfx application.

Can you please start by compiling and testing the demos/modules/gdisp/basics demo as this tests basic drawing. If that works you know the problem is likely to be in your application code. If it doesn't work the problem is likely to be related to your hardware and the display driver. If that is the problem, driver issues can happen for a number of reasons. 1/ Sometimes chips are not what they say they are. 2/ Sometimes different revisions of chips will behave differently 3/ Sometimes the panel itself can mandate changes to the initialisation sequence. 4/ Sometimes problems occur due to problems in the board file (which interfaces the driver to the phyical bus used) Before getting too far with any new hardware it is important to do the basic tests to make sure the hardware and drivers are working as expected.

It is quite possible that gwin_class.h is not c++ compatible as it is an internal ugfx implementation header file. If so, it wouldn't be hard to make it c++ compatible. You just need to add the appropriate extern "C" block around the api functions.

Just as a follow up to the link optimising problem, here is the ld bug report and resolution... https://sourceware.org/bugzilla/show_bug.cgi?id=18199 It affects some versions of ld (in particular the version that cygwin is currently using).

The other way of getting around that linking error is to rename main() to WinMain(). It is your compiler runtime startup that is incorrect (ie the wrong compiler binary for this job). It is looking to create a pure win32 application rather than a console application but the above may enable you to work around it. It is not a question of the version number of the compiler but rather its builtin runtime support. By the way, this topic really doesn't belong under "Development and Feedback", it should really have been under the support topic. Now it is here though we will just resolve the problem here.

There is not enough information in your post above for us to make any sort of determination as to what is wrong. Ugfx is c++ compatible. That is, the public api header files can be included in c++ source files and the ugfx api can be used from c++. The ugfx source itself (the .c files) still need to be compiled using a c compiler. Make automatically uses the correct compiler for source code based on the file extension.

You need to add the flags to the compiler that tell it it is a console application. I think it is something like "--console" but i cant remember the specifics. The difference between the -pc compiler and the -w compiler is exactly this. The -pc compiler assumes a console application, the -w compiler assumes a windows application. Unfortunately cygwin has recently stopped supplying the console based compiler.