inmarket

I also have a ssh1106 module on order. I will write a driver for it when it arrives if you can wait.

Unfortunately I am in Australia. I have done the next best thing and ordered the same module. My guess is that it will take 2 to 3 weeks to arrive though. My reasons for suspecting it is spi is a) the labelling of the pins, b) the aliexpress advert uses both i2c and spi in the description (wwhich was the same with the previous product I purchased that was spi) and c) it is not working with normal i2c protocol.

Looking at the module, it looks identical to a module I purchased. I strongly suspect that this is a SPI module rather than a i2c module. Certainly the one I have that looks identical is spi. Try it with spi first and get back to us if that doesn't work and we will look closer at the i2c side.

I'll have to look into the module and the other reference in more detail when I get some more time however I thought I would quickly reply on the other question. We don't have a software bit banging i2c implementation in the examples that I know of. We do however have a software bit banging SPI implementation. Have a look at the UEXT board files for the SAM7EX256 board. You may be able to modify that to suit your needs.

Overlapping window redrawing is something that ugfx doesn't handle because the code to do so is very complex and it requires fairly large ram tables (not good for an embedded platform). In practice this is seldom a problem due to containers and rudimentary support for Z order. Your use case however is slightly different and it is why you see the artifacts when dragging over a button. You solution is probably the best one, just to redraw the screen afterwards. With regard to parent relative coordinates, widgets always store their coordinates relative to the display. The reason for this is that it makes drawing in each widget much simpler. GwinMove, being a user api, takes coordinates relative to the parent. Your solution to correct the coordinates is the right approach however you also need to subtract the top and left border width. There are calls to get the border or at least the inner width and height of a container. Look at the code for gwinMove itself. Creating an api to get the relative position is probably a good idea. I will look at that when I get some time. Nice work.

I will look at it in the next few days. Sorry i can't get to it earlier, it's just very busy at my real work after the easter break.

You are looking in the right place. Widgets are in the place they are put. The application can move them with gwinMove but that is something not well tested as the moving of widgets seldom happens in embedded platforms (or even desktop applications except in dynamic sizing forms). It should be possible however to copy the label code into your project and modify it to get the functionality you want. You are indeed looking at the right spot in the code to be doing something like that.

Its possible. Can you please post a cut down version of your project (the minimum necessary to replicate the fault) and describe your hardware. We will try and help with debugging.

A GWIN virtual keyboard widget has been added.

We have been having some similar reports from other users. They solved their problems by changing their compiler optimisation flags from -O2 to -O0. Try this first and see if it solves your problem.

Well done with the touch driver. When you are happy with it please email the code and we will add it as an officially supported chip to the repository.

These optimiser bugs we really should find so we can rearrange the code to fix it. Any help you can provide with that would be appreciated. The last one I found was a ternary operator being used for an integer between two values test. The optimiser was completely stuffing up the range test. Unfortunately the test was in a macro in an chibios header file so outside our control. I ended up rewriting the block of code using the test to get around it.

It definitely could be an optimisation issue. We only compile with -O0 due to significant problems we have had with other optimiser settings in the past. Unfortunately the gcc optimiser is quite buggy.

Wonderful! Another compiler optimizer bug. We have seen a few of those. Mostly we fix these as we find them (by code rearrangement) however different versions of compilers, let alone different compilers can have different optimisation bugs.

A couple of thoughts here... 1. The read_xyz and the register definitions should go into the c file rather than the board file as they are not interface specific but rather controller dependant. I know MCU does that differently but in that case there is no controller. 2. I am wondering if the threading issues are something specific to the implementation of threading emulation with the particular compiler you are using. We have tested it with all the compilers we have access to but some compilers are strange. What compiler are you using?

This is obviously fairly well tested code so things I would suggest trying... 1/ if you are using a custom font, try replacing it with the ui2 font. If that doesn't crash then it is likely to be your custom font has some corruption. 2/ Increase the size of the stack. Many linker scripts provide any initial stack that is just too small.

The multi threading is jumping off the rails for some reason. To debug this take note of the cxt field generated by each call to create thread (the set jump call). When the fault happens you will then be able to work out where it was trying to get to by looking at the cxt value in the long jump call.

When the gtimer module is turned on (and it will be for any gwin stuff like the label), it obviously needs a stack. Specifying 0 for the size of the stack causes the gos layer to put in a default size stack which may not be big enough for gtimer when being used with gwin. GWIN is unfortunately a heavy user of stack. With the problems you are currently having, they could very well be stack related. Just remove the stack size define from your gfxconf.h and see if that works. Try to optimise ram usage later.

GINPUT drivers are initialised after GDISP as GDISP may be required for calibration during GINPUT initialisation. The initialisation order for modules is defined in src/gfx.c

For the get function, TRUE gets returned when there is valid reading, FALSE when there is no new reading available.

There is currently no walk-through for writing a touch panel driver. The existing drivers are really currently the best available form of documentation. The main reason this is not yet documented well is because a) this is fairly advanced coding - well beyond most users, and b) we never have enough time to do all we want and this hasn't been high enough priority yet as Tectu and I have been the ones to write all the touch drivers to date. The wiki page article is probably old. The touch infrastructure recently went through a major change to a) support gdriver as the base, b) allow for multiple touch devices c) to fix lots of problems with data consistency, averaging and common controller problems. Getting touch to work reliably is really very complex with lots of different approaches taken on the internet in various libraries that try to compensate for the issues - usually the wrong way. Our current touch system is probably the best out there currently and writing drivers is now fairly simple. To write a driver you need to fill in the GMouseVMT structure with the properties and routines for your touch device. This is a static structure usually compiled into the ROM. See the definition of GMouseVMT in src/ginput/ginput_driver_mouse.h. The comments describe the fields and their meanings fairly well. The existing drivers will give you good examples. The most basic is probably the MCU driver, and yet that is the worst case driver in terms of signal conditioning. The FT5x06 driver is a good controller based example. The STMPE811 driver is an example of a controller chip that has some problems. Once you have initially written your driver there are some programs that you should use to test your touch device properly. The demos/tools/touch_raw_readings program is used to see exactly what your touch controller is returning in various situations. This is very handy for initial debugging. After that there is the demos/tools/touch_driver_test which does full touch screen testing including calibration, sensitivity areas etc. Have fun and let us know how you go. We are keen to see support for some new controllers. We will help wherever we can. Private message me for any low level details you need help with.

Separate threads are available even for bare metal and arduino as the GOS layer provides that emulation. For these platforms the multi-threading is co-operative but it is still multi-threading. This has been implemented in the GOS layer for exactly the reason you describe, many parts of gfx currently need that functionality. This multi-threading can also be used by user applications and provides significant benefits to these normally non-multithreaded environments. If RAM is very tight there is a define that can be added to your gfxconf.h to control the size of the GTimer stack.

A new driver for the SSD1351 controller chip has been added

A new GOS layer has been written for Arduino. Based on the RAW32 GOS layer it also provides co-operative multi-tasking.

Some (strange) compilers don't perform macro expansion and arithmetic in the largest supported integer format as the C standard requires. For these compilers HTML2COLOR() does not always produce the correct colour code for a constant parameter value. This has now been corrected.