inmarket

Great to hear you got it working. Well done!

Another note: just looking at the code that looks like an interrupt handler. Try setting the interrupt stack size. Also note: 0x23000 is way too big for a stack on this hardware. Try numbers like 2k (0x0800) or 4k (0x1000).

This stuff seems to be buried in what looks like chibios code. It certainly doesn't look like uGFX code. I have a couple of suggestions for you... 1. Try to debug and find out what the last line that was executed in the uGFX code and we might be able to help you find a cause. 2. Contact the chibios forums as it definitely looks like a chibios problem.

This should be defined in your halconf.h (I think that is what the stm32 cube config file is called). Another possibility is you are using an old version of the stm32 cube files. STM change them often in incompatible ways.

The issue with the color names and various other name conflicts that occur on some platforms will be fixed in uGFX v3.0. The colors Red, Green, Blue etc will be renamed as GFXRED etc. The old color names will still be defined in v3 (for user program compatibility reasons) unless you rurn off V2.x compatibility. The reason this is being done in V3 (a new major version) is because changing these color names breaks existing user program code.

Also check your stack sizes. The default chibios stack sizes are a bit small for uGFX.

1. Make sure you are using the latest version of the F7 HAL files. STM change them often and in incompatible ways. We try and keep compatible with several versions of the HAL but it is a losing battle with the time we have available. 2. If that doesn't work look for where HAL_StatusTypeDef is defined and find out why the definition is not being included. Please let us know what you find.

Joel, it looks like this controller only supports x-axis reversal (atleast the way the control code is currently set up) and hence lines 133 to 148 is necessary. I haven't checked the datasheet to see if y axis reversal is really possible and I would want to have the hardware before trying that. Line 188 matches line 197. Whilst the or with 0 is unneeded, it will be optimised out by the compiler and properly documents the set/reset instruction for program enable and hence is worthwhile for code readability.

This has been added to the repository. Can you please check that I haven't broken it as I made some small efficiency changes on the way through.

Nice.

Check if you are overflowing one of your stacks. That is the most likely cause of this sort of problem. Another test is to run the same program using the win32 or linux emulators. If it runs fine there you know the problem is definitely not in the text edit or your program. In that case it must be memory or stack or something similar - something that is runtime environment sensitive.

There is a keyboard driver as part of the X multiple driver that should show you the simple mechanism for doing a keyboard without layout support (multiple language and scan code support). A keyboard without layout is equivalent to a "cooked" terminal under linux. If you want full layout support then look at the Win32 keyboard driver. Although the layout is only implemented for a US keyboard it does demonstrate the scancode to ascii conversion engine using a set of tables for each language layout.

There is actually an option for that in our makefile process (OPT_MAKE_LIB=yes). See tools/gmake_scripts/readme.txt for more options.

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.