inmarket

Have a look at the gkeyboard drivers. They support having multiple character sets mapped to the same key depending on their mode. Take a normal pc keyboard, it produces scan codes (equivalent to your 4x4 keyboard producing codes 0 to 16) which get translated to ascii characters which depend on the language, the mapping mode eg numlock/capslock, and multi-key combinations like shift. So your 4x4 keyboard is a large simplification on a keyboard such as a pc keyboard for which you already have the driver in the ugfx repository for you to use as example code.

No. gdispFillString always fills the background area first. This may change sometime after V3 is released but for now that is the way it works. A simple way to reduce the drawing is to not redraw the constant part of the string. For example "Temperature: " could be displayed once only and only the temperature itself be updated in your loop.

In your board_SSD1331.cpp at the top of the file above all other #include's try adding... #include "gfx.h" This compile error has likely been introduced in V2.9 because we have changed lots of type names and unfortunately we don't get to test every platform before release. Let us know if this works.

I can't remember off the top of my head if the ST7567 controller is already supported however there are plenty of similar STxxxx monochrome drivers that could be easily modified if necessary.

There are a couple of example keyboard drivers you can copy and modify. Just copy an existing driver, modify it and link link it into your project instead on one of the standard drivers. While this is a bit laborious in V2.x it will be much easier in V3.

The "blinking" you are seeing is because your display communication is slow (SPI) and you are constantly updating the display.

Editing chibios.c/h is the way to go. We have already added support in our uGFX v3 code but that is significantly different to the current V2 code base. Due to the significant changes for v3, V2 is currently in lock-down (emergency bug fixes only). V3 is not yet available for the public as changes are still in progress.

There appear to be 2 things it is complaining about... 1. It is missing the math library. Add -lm to the link line. 2. It appears you have turned on mouse support but have not included a mouse driver. The raspberry pi uses the standard Linux event device if running in framebuffer mode, or the X input driver if running in X mode.

GwinPrintg uses the internal printg framework which requires gfile. GwinPrintg effectively creates a pseudo file based on each window. This in practice is a very efficient use of code reuse. For now enable GFILE and the "string" sub-system as that enables sprintf equivalent functionality and the string sub-system is tiny. I will look at how easy it is to change the code so it can either be used without GFILE or at least without any sub-module file-systems turned on.

And the development boards for these chips are generally cheap eg a STM32F4-Discovery board which includes the LCD is somewhere around US$25 from memory.

The problem is that you are assuming that the source and destination bitmaps have the same line width or that you are even drawing the full width of the source bitmap. Note CX != X2. Similarly you are not using the starting position x1,y1 for the source bitmap. Passing the extra info to your draw routine you should be able to recode the X,y loop to fix the problem.

Note you can also use the command line binaries for windows or Linux that are found in the repository under the tools directory. The binaries have none of the restrictions of the web version.

The trouble here is that you get any two devices from different sources and they will possibly have different alignments between the touch screen and the display screen. To make things worse very few devices are well aligned physically. Also the resolution of the display seldom matches the resolution of the touch panel. What this means is that floating (or fixed) point multiplication is needed in 99% of cases whether or not that is via fixed calibration settings. Despit this we have implemented fixed alignment code as an option for some drivers but that doesn't work for all devices (as you have already discovered) due to the reasons above. In V3 we are looking at providing better fixed alignment code that caters for more orientations but for now the correct solution is either a custom driver hack or, preferably, the fixed calibration matrix.

Have a look in the example makefiles. It should be obvious.

This has now been updated into the repository. Thanks for finding it.

Use our file instead of the firmware file in your build. STM keep changing their firmware in incompatible ways which is why we include a particular version in our repository. @cpu20 is the expert in getting ide's to include the correct files. He has published a number of guides that may help. The other way is to not rely on the ide's build generator and to instead create a true makefile project in eclipse. It is by far the easiest way to build uGFX and it is where we as developers started. If you are nterested in this have a look at some of the prepared makefiles in the various board example directories.

Thanks. I will look closely at that asap and update the repository accordingly.

If the line specified is right at the top of the function my guess is that it will work. If it is not at the top then you are running into a common C, C++ language misconception. C does not allow variable definitions except at the top of a block. Once a non-variable definition statement has occurred variable definitions are not allowed in the block. Whilst the C language does not allow this, C++ does. As many C compilers have associated C++ compilers many C compilers relax the rules and allow such definitions eg gcc. My guess is that the IAR C compiler follows the language standard and doesn't allow this. In general in C it is a good idea to seperate variable definitions from code to set the variables.

It is possible to use RTL languages with ugfx but it's a little more work for the programmer. 1. Use right justification instead of left justification for all your text boxes. 2. Reverse the characters in any string you want to print so they appear in the correct order when displayed. This can either be done programmatically (something like the gtrans module) or simply writing any fixed string with the characters reversed when programming. Eg. "abc def" would be written as "fed cba" and then right justified.

Yes

I presume you are using an M3 with the internal ltdc video controller. If that is not the case the below discussion may help even if it not directly applicable to your circumstances. The problem is likely to be related to your external sdram and it's bandwidth. The proof of this is the slow performance (noticeable redraw speed) of the gdispClear loop.The image drawing tests are therefore meaningless until that problem is solved. The first thing to try is putting the framebuffer into internal ram as a test. If that operates quickly the problem is your bus interface to the external sdram. Note that if your framebuffer is in external ram do not put any other objects, heaps, stacks, code or anything else in that external sdram. Framebuffers are extremely bandwidth intensive just with video refreshing. Other things to check are your CPU clock is running at full speed, wait states and speed and width of the sdram bus and also look for any other high speed requirement that may affect available bandwidth or speed.

Have a look at the CMD_SET_REMAP. The value 0x14 may not match your display.

It looks like the column order on your display might be a bit different to the standard arrangement. Check the initialisation sequence particularly around the column order settings. The other place to look is around the spi data format eg if you are outputting 9 bit spi bit the controller expects 8 bit spi (or visa versa) you will get similar symptoms.

What type of physical interface do you have to your display? Eg i2c, spirit, 8 bit parallel.

More information... Aquire_bus and release_bus give you an opportunity to use a shared bus. Post_init is called once the controller has been initialised. Many controllers need to be initialised at a slower bus speed. Post_unit gives you the opportunity to increase the bus speed after the controller is initialised.