inmarket

There are 2 operations that the most critical for acceleration; a rectangular fill and a display memory copy. The display memory copy is really only useful for window scrolling but makes a huge difference in performance for that operation. The rectangular fill is of much more general use. Note that when talking about acceleration some controllers will provide "accelerated" operations that can be slower than the cpu doing the unaccelerated operation. Sometimes they will be faster for slow busses such as spi because of the reduction in bus transfers but slower than the cpu using parallel transfers. Also some controller accelerated operations (such as arbitrary line draws) are simply of no advantage because uGFX can't use them. What the conclusion of the above means is that a controller providing an accelerated operation does not always mean it makes sense for it to be used in a uGFX driver.

The answer is that uGFX works really well with a wide range of hardware. There may be many factors that will govern the right controller for your circumstances. I will list some of those factors below... 1. Cost. Quantity production runs can mean a few cents saved per board add up to big numbers. For one-off projects there are still cost constraints but they are typically less of an issue. 2. Size (or rather display resolution). A higher resolution display requires a faster bus interface to get the same apparent performance and will typically cost more than a small display. 3. Whether integrated touch is required. 4. Availability. You can only use what you can get. Note for production runs this can get very complex, lead times for supply might be important, and life of supply might be important. 5. Required performance. Doing video will require a much faster controller and bus technology than simple 2d windows. 6. Available pin count. There is no point going for a display with a 16 bit parallel interface if your cpu only has 5 spare pins. 7. Available RAM. Some controllers require the user provide a framebuffer. Some controllers have a built-in framebuffer. If the user has to provide a framebuffer that RAM is then not available for application use. There may also be bandwidth considerations for the cpu in managing that framebuffer. 8. Required capabilities. Some controllers with embedded framebuffers do not allow you to read back information from the framebuffer. uGFX still works well in those circumstances however certain features are not available eg anti-aliased fonts on a non-filled background, scrolling etc There are lots of other factors too. From your discussion above, a couple of pointers may help... 1. A SPI interface is much slower than a 8 or 16 bit parallel interface. The required pin count is however much less. This is particularly important for larger displays for the reasons stated above. 2. Unless you want to add external RAM to your project for a framebuffer you should almost certainly be looking for a controller chip with its own embedded framebuffer. 3. Some controller chips can operate in more than one mode eg spi/8bit/16bit or external/internal framebuffer. The lcd module you buy will usually be hardwired to operate in a particular mode with no ability to change it. Make sure you get not only the controller you want but also that controller configured in the way you want to use it. Often the choice of the lcd module is what drives all the other decisions. The above discussion is of course very generic. Knowing more about what you are trying to achieve and what your budget is, or a list of lcd modules you are thinking of, could help us give more specific advice.

The issue here is that the word wrapping algorithm in the font engine is broken (or rather just not intelligent enough). It assumes the word break character takes space thus leading to the double line break when the line break is followed by an explicit line break. In reality it may or may not and in different circumstances the rules are different. Eg a '\n' doesn't take up space (ever) A space or tab takes up space if the line break is not taken but doesn't take space if the break is taken, A '-' always takes up space regardless of whether the break is taken or not. A '-' must also fit on the preceeding line if the word break is taken. The rules above can change if the word break character is a printing character. Eg some fonts the space displays as a period in the middle of the line spacing. For those fonts the space is more like a '-' except that it may be placed on either the preceeding line or on the wrapped line. uGFX also makes no attempt to handle any other non-printing characters which should probably almost certainly be treated as a word break. Also, should symbols be treated as word break characters? ... and these are just the rules for english! Other languages may have extra or different word break characters with different placement rules. In summary, the word wrapping algorithm that uGFX uses is extremely simple and is probably appropriate for uGFX's "small" nature. It's better that the programmer takes more care with their string literals than try to add the full complexity to the algorithm.

I have run some tests myself and have been unable to replicate the symptoms. Some things for you to try: Run the demos/modules/gwin/textedit_virtual_keyboard demo. Let us know if that works. Set your heap size to something like 4096 for this demo. Check that you are running the latest master version from the repository. There are some raw32 allocator improvements since the last stable release. It may be that you have made your heap too big and it is overwriting your primary thread stack. Try reducing your heap size at least for testing this problem - it can always be increased later when everything is working. It is possible something else is overwriting the textedit control memory. Strip back other code until the problem goes away. Let me know how you go.

If it is a memory allocation fault then yes it can cause the symptoms you see. Please provide the smallest demo possible that demonstrates the problem and attach the main.c and gfxconf.h here and we will try to find the issue for you.

You will need to create a GFILE wrapper for the ti file api calls. This is very easy using the GFILE_NEED_USERFS configuration option and then defining the wrapper code as part of your project. The api documentation on the uGFX website contains all the detail and the standard GFILE code provides plenty of examples.

Yes. You will need to create a custom draw that internally uses the new vertical justification options. Note the different options can be just added or or'd together eg justifyLeft + justifyTop

Jumbled text may be expected but characters not being drawn correctly is definitely not. Characters are drawn by the gdisp layer either one by one or as a string. If GDISP_NEED_MULTITHREAD is TRUE is should be impossible to get character corruption. Please check carefully exactly what is happenning.

You will see that the sleep function internally calls gfxYield so modifying gfxYield to call the esp code to prevent the watchdog triggering might be possible. Better perhaps would be to init ugfx and then create a thread to run your ugfx application. The main thread would then return and loop to keep the wifi code happy. Note that because the raw32 scheduler is non-preemptive you will still need to ensure that you get to gfxSleepMillseconds or gfxYield periodically in your ugfx application as that will give the main thread a chance to operate thereby satisfying the wifi requirements.

Every controller is different. What is unusual about the pictures which lead me to think it might be a bus problem is: 1. The failure is position dependant (half the ugfx logo is ok, the other half corrupted). This tells us that we know how to talk to the controller. 2. Clearing the screen and doing the box drawing doesn't show the same left right problem. This tells us it is not explicitly to do with position on the screen. 3. Rotating by 180 degrees changes the symptoms. This tells us it is not shape dependant. The more i look at it the more it looks like a short on the bus between some of the pins, or an open circuit line, or something swapped. It definitely looks like a bus problem of some sort. Are you running the display in 8 bit or 16 bit mode?

Just another thought... Looking at the yellow rectangle there is vertical overshoot. This potentially indicates a problem with D0. Check that you have the pins wired correctly. Swapping D0 and D1 (for example) might lead to strange effects like these. It would also explain why rotating 180 degrees changes the symptoms.

This looks like some commands are being written to the controller correctly but some are not. Try halving the speed of everything on the fmsc bus. If this works you can sowly increase the speed again to get the fastest possible speed. Remember it may not be the speed itself but rather the bus setup and hold times.

Sorry, the images didn't seem to make it into the post properly. Can you please repost the images.

I have had a close look at the video. Sorry it took so long - the large video created issues for me. This looks like a memory allocation or a memory overwrite issue. What platform (operating system) are you running and if you are using raw32 or something similar how much heap have you allocated and how close to that limit might you be? Can you please also do up a small test program (the smaller the better) and a set of keystrokes that will lead to the problem. This way we can attempt to debug what is going on.

1. Speed: Yes displays using a SPI interface are not the fastest. If you are talking about image drawing from an sd-card, sd-cards are really slow so your problem could be that rather than the display. Possible solutions might include moving the images to flash (using ROMFS) or caching. Both are compromises in terms of flexibility and/or resource usage. 2. GFILE : Using an additional fatfs library would be a complete waste of ram and flash storage. Implementing a fgets using gfileRead would be trivial in comparison. Also, you might want to look at the stdio emulation option. It might already provide a fgets replacement (I can't remember for sure) but if not fgets is still trivial to implement. Using another file library for image handling is not straight forward. GFILE was originally implemented specifically for image handling. Replacing GFILE for images would not be easy or necessary. GFILE is designed to easily shim other file systems to provide a level of abstraction to file handling.

It looks like the column scan order is incorrect. Yes the picture is definitely strange. The entire uGFX logo is built using rectangle area fills so it appears some are working but others are not. Still, there is no point chasing that yet as it could very well be related to the column scan order too.

Check that the reset pin is set in the correct direction. Also check the bus to see if the lcd bus is actually getting written to.

Yes, that is correct. Well done on getting it working.

Embedded programming is not the same as normal application programming. There are a lot more things to consider and therefore the programming itself is more complex. While uGFX simplifies talking to various types of lcd and provides a suite of tools to help embedded programmers in a portable manner, it is still programming for an embedded platform. We therefore expect that people using uGFX have at least a basic understanding of c programming. Our aim is not to train people who do not understand c programming concepts (although we are supportive of their efforts) but to provide an unrivaled set of tools for embedded hardware and to support people in their use of that toolset. The problems you have had above are nothing to do with embedded programming or uGFX. They clearly show your lack of understanding of simple c programming concepts. Even so, we have been generous in our repeated attempts to help you. To claim that uGFX is not compatible with uVision is false. The problem is that you are not understanding the error messages from your compiler even though they relate to normal c programming issues. To then blame uGFX for missing your university deadline is silly. The issue is not uGFX but your programming skills. As we have mentioned to you and warned you about before, we will not accept disparaging remarks on this forum. As this is the 2nd time we will now be banning you from posting on the forum. Don't try to get around it by signing up under a different name (as you did before), we will not allow this behaviour.

It uses a single rectangular clipping region. It does not use complex regions due to the (unbounded) memory requirements to support such functionality. What this means for redrawing is that in limited circumstances window redrawing is clipped. Outside those circumstances a bottom up redraw strategy is required. An example of when clipping optimization can be used is when a window is made invisible all underlying windows need to be redrawn bottom up but the redraws will be clipped to the area covered by window just made invisible.

Assert is part of the c library.

As an arm processor it is likely to be similar to one of the cortex m chips in terms of instruction set. The arm chips are generally instruction set consistent between similar levels and are often backwards compatible between levels. That is why arm publish an eabi specification. For example the m0 code can be used on a m7 chip provided your application doesn't use floating point - it just won't be quite as efficient doing the context switch. For your lx chip try a simple project with no floating point using the m0 code and work from there.

No. The ellipse is currently xy axis only for code size and complexity reasons. You could estimate it with line segments and then use the matrix 2d rotation api and then gsispDrawPoly but that is just an elipse approximation.

In gdisp_lld_write_color() try reversing the two lines that write data. I suspect you are writing them in the wrong order.

You might be interested once uGFX v3 is released as that should fix the problem with pixmaps and single file make.