inmarket

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.

Yes. I have been playing with it over the Easter weekend. It was hard to initially get the arduino IDE up and running as the Tinyduino board file is not easily found. In the end I wrote my own (fairly simple once I knew what was going on). I have written a driver for the SSD1331 for the TinyScreen which was nearly completed testing when my TinyScreen died (the display not the cpu). Nevertheless I have put it up in the repository along with the necessary board files (in the board/addon's directory) and I think it should work as it is. It is a great controller as it supports accelerated commands including the ones necessary to support generalised scrolling. Like most small controllers it doesn't support read over SPI. I have also added arduino as a full GOS layer (even though it is really just a variant of the RAW32). This enables arduino support with no extra support routines being required. I am currently working on making ugfx as an "arduino IDE library". There are some issues with this due to differences in the directory layouts given that the arduino IDE does not support a separate include path for libraries. I have most of the issues sorted out but it is not ready for integration with the ugfx repository yet. It has also raised some interesting issues with respect to GTimer. GTimer is an essential module for most of the other modules (except GDISP). Unfortunately it uses a separate thread for implementation. Whilst this is supported by the GOS emulation layer even for arduino, the real issue is the amount of RAM that the stack for a separate thread requires - particularly one that may be drawing on a screen. 1K for a stack on a CPU that only has 2K RAM is a bit too much. I have some ideas to remove the dependence on threads for GTimer but that will take some time to implement and is a fairly major change so that will come later.

Without reading the controller data sheet in detail, I suspect the buffer swapping needs to be delayed until a vertical blanking period. There will be a pin interrupt or a register to poll which will tell you when the appropriate time has come to swap the buffers.

Yes you can do it without making major modifications to your conf file. Do as the comment suggests and put that particular symbol in your makefile. In fact using the ugfx makefile it is a one line change to use a different operating system.

Thanks. That is a great help.

By the way, none of the gdisp api will alter the clipping region (except gdispSetClip). The only place that currently uses api level clipping in the current ugfx is the gwin api which uses it is clip drawing operations on a window to the window area.

I'm not understanding why paging is needed at all. Why not just draw the lot in one pass? Adding paging of any sort is a big drain on available ram. The only reasons I can think for paging is to smooth drawing artifacts in high motion situations -like video. In those situations I am not sure paging the way we have been talking about it is the right approach. For something like video the gdisp streaming api would be much more efficient.

Yes I realised the chips and boards were different, I am just not use to the arduino way of doing things and was hoping your project with mods would form a shortcut to building a project from scratch on a platform I am unfamiliar with. Even if it isn't close enough to form a project base the sameness and differences would be useful in determining how to create a supported arduino port for ugfx. Send me whatever you think might be useful given that my two aims are 1. To get a project working on tinyscreen, and more importantly 2. Make arduino a supported platform for ugfx.

Why use the pixmap at all then? Why not just set the clip on the real display to say page 1, draw, set the clip to page 2, draw etc. There is something in this situation I am obviously missing.

Congrats. Can you post your project as I am wanting to start playing with my new arduino tinyscreen? It will make a nice sideline project over easter. Thanks.

By the way gdispSetClip can be used to clip drawing operations to any desired portion of the display. Each display maintains its own clipping region.

Pixmaps are interesting in that they have a dual personality. On one hand they look like a full display (origin =0, 0). On the other hand they look like a native format image. A native format image can be blitted to a real display at any position using gdispGBlitArea. I suspect therefore that this will do what you want. initialise it as 64x64 (1/4 the size of the real display). Draw to it as if it is a it is a 64x64 display and then blit it to each quarter of the real display as required.

You are right, there is no generic framebuffer driver for monochrome displays. They are however all very similar and it has been in the back of my mind to eventually develop one. In the mean time just take one of the existing monochrome drivers and modify it to suit.

Looking at your comments there, it looks like bits 0 and bits 4 will be the ones to change to do the orientation. Bit 0 will be clear for R0 and R180, set for R90 and R270. Bit 4 will be clear for R0 and R90, set for R180 and R270. I may have bit 4 back to front for R90 and R270.

To answer your questions... The files in the boards/addons directory are not ready to run as-is (although they should be close). They are effectively example files designed to be added to your project and modified to suit. In your case the board_ssd1351_teensy.h would be copied to the project and renamed board_ssd1351.h. The corresponding cpp file would also be copied to your project and the pin definitions modified to suit your hardware. The files in the boards/base directory however are designed to exactly match a particular supported board configuration and the appropriate board makefile can be included directly into the users project to get all supported hardware on that board without any modification. Based on the confusion you experienced I may rename the boards/addons to boards/examples or something like that (suggestions welcome). Yes, there are extra support routines required for the arduino when using OS_RAW32. I may write a full os layer later for the arduino bare metal but probably the best solution in the short term is that we add the arduino support routines into a file that gets put into the boards/addons directory so other people can also make use of it. If you wanted to swap to a parallel interface instead of a SPI interface, normally there are some jumpers on the lcd which tell it how to expect to be talked to on power up. As far as software is concerned - the only change would be to the board_ssd1351.h file (or in your case the support board_ssd1351.cpp file) to talk via a parallel interface rather than SPI. That is the whole purpose of the board file layer - to separate the electrical interface from the details of the driver code. It also allows the driver to be completely operating system and pin assignment independent. I will have to look at the SSD1351 data sheet but some interface modes on the chip may allow reading. The SSD1351 is very similar to most embedded controllers in that you cannot read back from them. The ones you can read back from are the exception rather than the rule. Certainly if GDISP_HARDWARE_STREAMREAD or GDISP_HARDWARE_READPIXEL are not set, the read routines in the board file will never be used and do not need to be defined (in fact in board_ssd1351_teensy.h you will see that they are not defined even though the template currently says they should. All of that is something however that we can clean up later when I get the datasheet (and time). Orientation, sleep modes, contrast and backlight level are all optional and are handled by the gdisp_lld_control() function (but only if GDISP_HARDWARE_CONTROL is set in gdisp_lld_config.h). Again this is something that can be done when I have the datasheet and is not generally difficult. Just look at the ILI9341 as a reasonable example. As to what the various sleep modes mean - that is entirely up to the driver writer. Most sleep modes should be fairly self-explanatory just by their name. Rotation at the driver level is GDISP_ROTATE_0, GDISP_ROTATE_90, GDISP_ROTATE_180 and GDISP_ROTATE_270 (Ithink those are the correct labels off the top of my head). ROTATE_0 is obviously the native rotation for the display, everything else is relative to that in a anti-clockwise direction. ROTATE_90 then has the "top" to the left and the "bottom" to the right etc. I will compare the code to the repository a bit later (I need to go get some food and sleep now). Thanks for all your work!