inmarket

This has now been fixed in the repository. Thanks for finding it!

Unfortunately there are only two mechanisms, off-screen drawing (pixmaps) and double buffering. Double buffering is a big nasty topic in its own right - search the forum for some of the discussions on that subject. It is probably also not viable for you given your controller and bus interface. As far as pixmaps are concerned v3.0 will fix the incompatibility with single file make. The filled string drawing algorithm will be updated at some time in the future too but that is not a simple task as their are lots of complexities with fonts.

I have seen the post and have left it open to sort out when I get time but haven't had that time yet due to various project deadlines. Thank you for finding it and I will report back when I have had time to properly investigate and correct the master sources.

Have a look at the dial devices. A rotary encoder fits fairly nicely with the dial device.

You need to create a gadc driver for OSX or a dummy driver that will work cross-platform. As an example look at the existing gadc driver in the drivers directory.

Note that reparenting a widget is a real hack and is officially not supported by uGFX. The reason is that there are dependencies that may stop things working eg... 1. A child object must always be completely enclosed within its parent container 2. A child object must always have a higher z order than its parent container. 3. There are visibility dependencies. I am sure there are others too but those three alone are enough to make this a complex operation requiring deep understanding of the internal workings of uGFX to get right. That complexity is why it is not a standard part of the uGFX API. It is much better that you arrange your containers and widgets as non-overlapping, or duplicate such controls across the pages. As an example see the console object on the widgets demo.

Unlikely the compile will affect anything. Try just outputting directly a string with Unicode characters in it without using snprintf. If that doesn't work there can only be one of a few problems... 1. Utf8 support is not turned on 2. Your editor is not putting the Utf8 characters into the string correctly 3. Your compiler is stripping them out of the string or not encoding them correctly. 4. The font you are using doesn't map the particular characters used. In your case I think 1 or 2 would be the problem as you are seeing 'extra' characters.

It may be asking the obvious but have you got unicode support turned on in your gfxconf.h?

Great to hear you got it working.

This may indicate a unicode bug in snprintf. I will look later. It could also indicate that your editor is not in utf8 character format. Perhaps it is using extended ASCII or one of the other unicode formats eg utf16le

You are mixing up compiling and linking. uGFX must be compiled with gcc as it is written in C. It will quite happily link with C++ and the header file ugfx.h is fully C++ compatible. If you are using make this is really simple... .c files get compiled with gcc .c++ files get compiled with g++ Link with g++ While C and C++ are similar languages they are not totally the same.

Your memory allocation scheme sounds appropriate to me too. Good thinking.

Ahh. GDISP_NEED_STREAMING is completely different to GDISP_HARDWARE_STREAM_WRITE. The first is whether the streaming API is enabled in GDISP, the second tells GDISP whether a specific display hardware requires a streamed write methodology. The two are completely different things and are completely independent of each other. My guess is that you have been playing with the GDISP_HARDWARE_xxx definitions. Please restore these to the defaults and then try a make clean before compiling again.

With pixmap you don't need to include it in your driver list (or even add the driver list config) as pixmap is handled differently to all other drivers. You should also not include the following in your gfxconf.h: The GDISP_SCREEN_xxx or GDISP_INITIAL_xxx variables. These should be in your RA8875 board file as they are display specific. The GDISP_HARDWARE_xxx variables as they are already appropriately defined in the respective display config file and are modified and played with by the multi-display handling code.

Thanks for the positive feedback. It is appreciated. Softfp - software floating point Hard - hardware floating point No - floating point turned off There is one other setting (whose mnemonic I can't remember and is only on some CPU's and libraries) that uses hardware if available and software emulation if not.

With the pure ChibiOS (no uGFX) and USE_FP=hard it traps when you call powf (). This indicates you have a problem with either your compiler, the compiler options, or your C runtime library. You need to solve this first and this problem is independent of uGFX. Only once that is working is it worth adding uGFX into the mix.

1. Widget drawing requires a gtimer event to fire. As RAW32 is non-preemptive it requires a gfxYield() to trigger that context switch. When you comment out geventWait, unless you put a gfxYield or gfxSleepMilliseconds call in you will not get drawing. Any geventWait should be sufficient even with only a 1ms delay (even a TIME_IMMEDIATE I think). 2. Users are commonly interrupt driven and therefore Async so there should be no need for a non-blocking geventWait. The strategy is to create a gtimer task to read the uart buffer data. You can add a gtimerJabI call in your interrupt handler when your uart buffer has enough data which will then wake up the gtimer task. If you really want to make geventWait return immediately use TIME_IMMEDIATE or 1 (1ms) as the parameter. 3. Without a look at all the code it is impossible for us to say.

Great that you got it working

I can't answer the SDL questions but I have answers for the other aspects. 1. You can use the Linux event driver to get mouse/touch input when using framebuffer. Similarly I believe there is also a Linux tty keyboard driver. 2. You can use the X driver to provide display, mouse & keyboard. Although it is slower than framebuffer or SDL, for something being used for prototyping before moving to real hardware, it is ideal and much easier to get working than SDL.

Many years ago we had a stored write command style interface. We dropped it very quickly however for two reasons; 1. Noone was using it, and 2. It consumed lots of RAM and could quickly become unbounded in resource use and the complexity of controlling that got onorous.

Try swapping it around then. Use the internal RAM for the framebuffer and put the program and other stuff into the external RAM.

This is a very complex question and given that we can't see what you are talking about it is very hard for us to provide an answer. The only hint I can give you is to say that if you are using GWIN to render buttons etc there are gfxconf configuration macros that can affect GWIN's synchronisation methodology. Have a look at the GWIN redraw settings.

Yep

Don't forget to also do a make clean once you have your configuration correct (gfxconf.h) For Linux based boards there are 3 alternatives: 1. SDL 2. X 3. Linux kernel framebuffer and the Linux kernel event system. Options 1 & 2 are best for desktop, 3 is definitely best for embedded situations because of its low footprint and good performance. I have always personaly disliked SDL due to its linking nastyness, even though it is faster than the X driver. Still the framebuffer driver is the best solution for a real Linux based embedded device. As an input driver I believe the uGFX Linux event driver works on the beagle bone black so as long as your capacitive touch screen sends events to the standard Linux event driver everything should just work. I did some testing when the first beagle bone black board was released. At the time the framebuffer driver in the Linux kernel didn't work at all (kernel/hardware problem) so I ended up using the X uGFX driver for my testing. I am glad to see the Linux kernel framebuffer driver now works (even though at reduced bit depth) on the more modern hardware versions.