inmarket

There is another thread in the forum on a very similar issue. You will find a number of things to try in that thread. In summary it is likely to be a memory, stack or touch driver problem and very unlikely to be a textedit bug. You should be abke to find it by searching the forum. Unfortunately i can't look at the video as I am currently only able to get internet on my phone (not enough data capacity). I should be able to look around the 22nd if you haven't sorted it by then.

The easiest way is to just save the x & y coordinate minimum and maximum in the driver pixel draw routine. When the flush happens you then flush based on the rectangle you saved. Some draws will not optimise based on this simple method (eg the diagonal line from corner to corner) but for most workloads it will save refresh time. Another optimization that will help with the diagonal line is to force a flush whenever the pixel to be drawn is outside a certain maximum refresh area size.

The repository has now been updated to properly support Visual Studio when compiling.

The updates are now in the repo.

The master repo has now been updated to FATFS-0.13 The GFILE FATFS demo has been added The makefile system has been upgraded to support .S files Thankyou @cpu20 for your fantastic work in getting this ready.

The GDISP_FLG_SCRSTREAM flag has nothing to do with the current bus state. This flag is used to indicate that the current controller window covers the entire display area. It is an optimization that is only possible when the controller supports a position set operation. The flag improves the efficiency of setting pixels where no vertical wrap is required. Note also that it is perfectly fine to aquire the bus multiple times (or arguably even release it multiple times). It is the first aquire and first release that are effective. For a streaming driver the cycle is start/write.../stop. For a streaming driver with pos capability it is start/(pos/write).../stop. In both cases start and stop are typically used to obtain and release the bus. When you add fillarea into the mix things become a lot more complex. The fillarea is defined as being independent of the stream cursor window. If a driver maintains both streaming and fillarea it needs to be able to perform the fillarea without affecting the stream operation if any is in progress or to atleast reset the cursor window to its original state (and by implication the bus). Looking at the SSD2119 driver, the fillarea you are talking about is only activated in the DMA enabled situation. DMA is completely incompatible with a shared bus unless custom interrupt handlers are written to release the bus at the end of the dma operation and thus aquire/release are meaningless in that scenario. If you are finding writes on an otherwise unaquired bus this is likely therefore to be a driver bug. The simple solution in the short term is to simply turn off the accelerated fillarea (or the dma acceleration) in the gdisp_lld_config.h file for the driver. Looking at the few drivers that use streaming with a fillarea acceleration, it appears that the assumption of the cursor window being retained is actually not normally happenning. I have therefore made a change to the gdisp that should fix that for those few drivers. The changes will be in the repository soon and should also help with your aquire/release ordering (although it will not fix drivers that prematurely release the bus on a dma operation).

Interesting. .s and .S are synonymous under windows because the file system is case insensitive. Whilst case can usually be controlled it is not reliable. For .c/.C files the .C files are typically renamed .cpp or .c++ (depending on the compiler/make system) for windows. I will need to investigate the equivalent for .s/.S so I can add the correct handling to compiler_gcc.mk for both windows and unix based systems. Note: as a result of the above problems the use of .C is falling out of convention and is now sometimes not supported even on linux.

Thankyou. Let us know when it is ready.

Thank you for the demo. Are you happy for us to add it to the repo? Yes we would love the upgrade to fatfs-0.13. Can you please create a repo pull request and we will merge it into the current branch (and V3)

The message about the requested speed can be ignored. It is the openocd software trying to talk to your hardware debugger and complaining about the synchronization speed. The openocd figured out the correct speed for itself (hence the message).

It could be by simply changing the allocation in pixmap. The problem is likely to be speed. External ram is still external ram running at whatever the bus interface speed is. In this case it is likely to be very slow for a framebuffer.

If your display controller supports additional on chip RAM you can use special gdispControl commands to perform operations on that RAM. None of the existing uGFX drivers currently do that due to the code overhead and the time for us to implement it although there are some commercial projects that have written custom drivers to enable such features. Note if you are trying to access that RAM in order to provide a type of tearing protection you will likely need a much more powerful processor than the teensy despite the accelerated operations provided by the controller. The reason is that despite those operations there is still quite a lot of overhead that requires cpu intervention and adding any sort of double bufferring definitely increases the amount of drawing required.

Also you need to set GFX_OS_HEAP_SIZE to something other than zero. This is the heap size when using Raw32 so it is not surprising your memory allocations using gfxAlloc are failing. Try setting it to say 10240 as a starting point (10K heap size).

You are probably misunderstanding pixmap. Pixmap provides a RAM based framebuffer of any specified size. It has no relation to your real display other than it uses the same pixel format. A pixmap then can be treated as a framebuffer, a display and optionally as an image. When treated as a display you can draw on it using any of the normal gdisp calls. When treated as a framebuffer you can use it as the source parameter for gdispGBlit (to copy any portion of it to a real display or another pixmap). When treated as an image any of the gdispImage calls can use it as the image parameter. So, 1. gdispGBlit does not require a pixmap - it only requires an array of pixels as the source. Pixmap can be used as one posdible source of those pixels. 2. Pixmaps don't care about the type of display you are using. They are RAM based. 3. If you want to get information off a display the ONLY way is to use the gdispGetPixel call. The only exception is a pixmap (which is not a real display) because pixmap has this ability to appear as a display, an array of pixels (a framebuffer) or as an image. There is no connection between the framebuffer a pixmap uses and the framebuffer of a real display controller.

The stm32f4-discovery board files in the repository works perfectly well. Why rewrite what is already working?

Don't forget to do a "make clean" and then recompile.

Part 1: workaround... After moving the container do a gwinRedraw on your lightbulb. Part 2: fix... It is difficult to tell exactly what is going on without suitable source code. Please write the smallest program you can that demonstrates this problem, attach it in a zip to this forum topic and we will try and work out what is going on. I suspect it is either related to a partial redraw optimisation or alternatively the move code (which is not well tested as it is a less commonly performed operation)

This problem is usually caused by your include path containing the src/gdisp/fonts or src/gdisp/mcufont directory. Remove those directories from your include path and the problem should dissappear. If you search the forums this topic is not uncommon. Reading those posts will give you a lot of background on why it is this way.

Yes please. That would be great.

The link above contains generalisms. The license file that comes with the font is ALWAYS what you must pay attention to. Generally font licenses are written that generating characters and chatacter strings have license restrictions but once generated and layed out you can look at the result without license restrictions. In terms of embedded use, assume you are using the ttf file itself when reading the license even though you are using a file format derived from the ttf.

Well done in tracking down a curly problem. I will look in detail on the weekend and see if there is anything that needs migration into our source repository.

The gray problem with eclipse is exactly that - a problem in eclipse (not uGFX). The function that you have displayed for switching the mirror in effect changes the initialisation sequence of the controller. We will look to make this a board level define for that driver.

The wiki should be correct I think for most touch drivers. Note this belongs in your mouse board file (not the general gfxconf.h file). In the mouse driver itself it should use that board specified macro to set the extreme calibration flag in the drivers VMT flags when it is defining the VMT structure. It is possible that the mouse driver you are using has not implented that - if so let us know and we will fix it. I would have checked for you but you didn't mention which touch driver you are using.

1, 2, 3 & 7: yes. 4. The 0 is a special flag to FreeRTOS to shut down all threads. _gosDeInit is unlikely to ever be called in an embedded environment so it can quite safely usuallyvne left as an empty function. 5. Microsecond delays are seldom provided by os's and are not used by uGFX itself however a driver might try to use it. Rounding it to milliseconds is what most gos implementations do. 6. I have no idea. Take a guess or read the doco to understand its significance in threadx. 8 & 9. Great. 10. No problem as pointers and uint32_t are (usually) the same size. The only time it might be a problem is if you are on a 64bit pointer cpu however i suspect threadx doesn't support that. Just typecast the param pointer to a uint32_t.

This has been cleaned up a bit and added to the repository.