inmarket

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.

If you are directly drawing using GDISP calls, or manipulating GWIN flags directly, or having to understand the drawing lock then you are definitely approaching the problem incorrectly.

The implicit conversion warning is just that, a warning. It is perfectly valid C and perscribed behaviour for the C language. That the compiler is warning is being overly cautious and should be ignored. The reality is that the code is perfectly fine and is 100% valid C. The gtimer.c warning is a situation of dammed if you do and dammed if you don't. As gtimer is run as a thread process most operating systems require a return value for the function. So even though the code is unreachable most compilers will complain if you don't have a suitable return statement. On the other hand most compilers don't bother to complain about unreachable code in that situation unless the warning levels are set too high. So, in either case you will get a warning message from the compiler. You are just less likely to get a warning the way we have coded it. Without checking the code I suspect the gwin.c situation is the same. In summary, the code is fine. If the warnings bother you then turn down the warning level on the compiler.

Or the mcufontencoder command line utility in the tools directory of the repository.

Double buffering is complex and how to do it is invariably application specific. In your case I would do what you are doing now - just drawing traces to alternative buffers. Don't try copying from one buffer to the other, you would have lost all the benefits of using 2 pages. Instead draw each frame from scratch or just wipe the old traces (by block fill or redrawing the trace). Yes buttons will be a problem but if your swap speed is fast enough it may not be noticeable. Another hint that may help is to use the 2nd ltdc layer to display the outer area with the buttons and then double page the centre background with the traces. Note this will however increase ram bandwidth requirements. This is probably the approach I would use provided the bandwidth numbers match. Another hint is to use a lower colour depth. Using RGB565 will halve the bandwidth compared to RGB888. The ltdc driver already support both - just change the gdidp_lld_config.h for the ltdc controller.

Try using uGFXStudio. It will help you design the screens and will help generate initial code or you. Note uGFXStudio is still a Beta product so it does have some bugs that may require you to adjust the code afterwards.

As the code you are referring to is not part of the uGFX library but is from a 3rd party library with no connection to uGFX, we unfortunately cannot help with that. Please contact the people suggested above who might be able to help.

Dma2d is not significantly faster than using the CPU with a well written block routine. It's advantage is that it releases the CPU to prepare for the next operation thus reducing latency between operations. In your case, with a 800x480 display on a f4 you are approaching the limits of the sdram bandwidth and therefore the number of pixels you need to write is definitely a consideration that will affect performance. Writing over a trace will definitely be much faster than block filling and will provide a better visual appearance. If you really want to do the block write there is a method that will be much better than using a pixmap but will require a custom extension to the ltdc driver. The method is to use the ltdc's ability to change the base sdram address. Using this you could create 2 display pages and swap between the pages, drawing on one while displaying the other. You still need 2 framebuffers of ram but it doesn't require the bandwidth sucking framebuffer copy that using pixmap requires. Ram bandwidth will still be a limiting factor but just not as limiting as with your current strategy. With ram bandwidth make sure that you are not using the display sdram chips for any other purpose even if there is spare ram available as the extra CPU access to the ram will contend with display refresh and drawing bandwidth. I hope that helps in finding a solution that will work for your situation.

There are much easier and faster ways to draw the traces. Have a look at the oscilloscope demo in the repository. It demonstrates doing an oscilloscope using a really slow processor and even demonstrates a mechanism to do software triggering. From memory there are two versions, one in the Gaudio demos and one in the gadc demos.

You will need to contact that library writer or an Arduino forum on support for that. Unfortunately we can only provide support for uGFX.

Make sure you are using the very latest repository version. The error messages clearly show you are using an earlier version (eg bool_t is a type that is no longer used in gfx function definitions)

Some more changes moving toward V3. CHANGE: Added type gDelay to replace V2.x delaytime_t and values gDelayNone/gDelayForever to replace TIME_IMMEDIATE/TIME_INFINITE CHANGE: Added type gTicks to replace V2.x systemticks_t CHANGE: Added type gThread to replace V2.x gfxThreadHandle CHANGE: Added type gThreadreturn to replace V2.x threadreturn_t CHANGE: Added type gThreadpriority to replace V2.x threadpriority_t and values gThreadpriorityLow/Normal/High to replace LOW_/NORMAL_/HIGH_PRIORITY CHANGE: Added type gPoint to replace V2.x point and point_t CHANGE: Added type gCoord to replace V2.x coord_t CHANGE: Added type gPixel to replace V2.x pixel_t CHANGE: Added type gColor to replace V2.x color_t CHANGE: Added type gColorformat to replace V2.x colorformat CHANGE: Added type gFont to replace V2.x font_t CHANGE: Added type gPowermode to replace V2.x powermode_t, and values gPowerXXX replace powerXXX CHANGE: Added type gJustify to replace V2.x justify_t, and values gJustifyXXX replace justifyXXX CHANGE: Added type gFontmetric to replace V2.x fontmetric_t, and values gFontXXX replace fontXXX CHANGE: Added type gOrientation to replace V2.x orientation_t, and values gOrientationX replace GDISP_ROTATE_X CHANGE: Added macros JUSTIFYMASK_HORIZONTAL, JUSTIFYMASK_VERTICAL to replace macros JUSTIFYMASK_LEFTRIGHT, JUSTIFYMASK_TOPBOTTOM As always the old types are still defined and compatible because GFX_COMPAT_V2 is set to GFXON by default.

That has been added to the repository. Thanks