[Event/semaphore-related crash?]

This is code that has been fairly well tested but there are always opportunities for things to slip through. I will have a good look tomorrow. Thanks for bringing it to my attention.

PS. The frame window is not an implementation I am very happy with as a) it uses a lot of memory, and b) the window move logic won't work properly because it has children windows outside the client area. These things really require a rewrite of the frame window but that can come later when I have more time.

[Event handling using tags]

I will integrate this over the next few days. Thanks.

[Registry/calibration data code]

Thanks. I look forward to going through the code over the next few days and integrating it into the ugfx repository.

[chibios.c not compiled in Keil]

Another thing to test us to make sure you have "." at the beginning of your include path. The current directory should always be searched first for an include file but some compilers don't follow the rules. For those compilers "." (without the quotes) must be the first include path to operate in the c standard manner.

[Using uGFX on bare metal]

Please send me your main.c. There must also be other header files that are conflicting with the type definitions. Seeing your main.c will enable me to check the other header files.

Note with ugfx you typically don't need to include any standard header files as ugfx takes care of all that for you when you include gfx.h. You then add standard header files only for stuff the ugfx does not handle.

The error log should show which is the conflicting header file and you take the same approach that we took to resolve the stdint conflicts.

[Using uGFX on bare metal]

The problem is that the int32_t definitions in your system are conflicting with the defintions in uGFX.

There are two possible solutions to this...

1. Restore the definitions in raw32.h to what they were and remove the inclusion of in your project. uGFX should then define those types for you and there will be no conflict.

2. Include within the raw32.h file (somewhere around line 27 would make sense (just after the #if GFX_USE_OS_RAW32). Then comment out the definitions for int8_t through to uint32_t (lines 45 - 50) in raw32.h

Option 1 is the better solution.

If you post a copy of your stdint.h (each compiler uses slightly different definitions) I will try to add protection around the definitions to solve the problem in future where someone includes both files.

[Raspberry PI + FreeRTOS + µGFX]

Porting should be very easy.

Use the frame buffer driver. You only have to supply the board file. That file contains two functions. The first just needs to initialize the hardware and set the frame buffer pointer and size into a structure. The second function is optional and only needs code if the frame buffer needs a sync call.

There is a template in the frame buffer driver directory that you can copy and rename.

Any help you need just ask.

[Calibration Data load/save interface]

GREGISTRY it is then.

Saving the error silently in a variable for debugger or logging use later sound acceptable to me in order to simplify the api.

Ordering from the top for system ones sounds fine. Or just use 0x7FFF for top user. The top bit then indicates a system or user tag.

I think you are right - 256 makes a good maximum data size so unit 16 it is.

I think that that is probably a good enough first api design. Have fun implementing it. I am looking forward to seeing it.

Just for your info - we have just completed work on fat file system support for GFILE. It is currently in a branch and should be merged with the master sometime tonight after final testing. The block interface is currently only written for Chibios but it would be simple to add replacement routines for other os.

[Calibration Data load/save interface]

THis is turning into a module in its own right. Excellent!

What do you think of GREGISTRY or GCONFIG as the module name? I will use the GREGISTRY terminology below just for simplicity in the discussion.

As GFILE is light (it is not a full file-system just a shim layer) it makes sense to have GFILE able to access the raw devices as just a block of raw data/memory/device and then use GFILE to implement GREGISTRY. It gives a lot of flexibility to the implementation.

A uint16 tag identifier sounds great. I would suggest tags > GREGISTRY_MAX_USER_TAG be reserved for ugfx. That way the user can number their own blocks starting from 0 (nicer for the application).

Using a null pointer on the read call to get the size certainly works. More complicated from an API perspective but it seems to be the way most os's do that sort of thing. It is less obvious though.

I personally have a pet hate for "errno" style of error reporting (where the error is saved in a global variable). It is not thread-safe and it is non-obvious.

I personally also am not keen on passing by ref to get what is effectively a return value. I realise that conflicts with the above statement but that is just my particular design style. Of the two I am more opposed to the "errno" system.

I am wondering however for an embedded registry if it really matters why the read or write failed. It is good enough to know that it did and that you didn't get the setting you wanted. Debugging the system will have long ago told you of any systemic problem. For an embedded system fall-back in this type of situation really doesn't need to know why it failed, simply that it did. Using this embedded system simplification we can then can simplify the API...

So (as a suggestion):

bool_t gregistryWrite(uint16_t tag, const void *data, uint8_t size);
uint8_t gregistryRead(uint16_t tag, void *data, uint8_t size);
uint8_t gregistrySize(uint16_t tag);

Note that use of uint8_t. I am thinking that registry data should always be small. Is 255 bytes a reasonable limit or should this be a uint16_t with a GREGSITRY_MAX_DATA_SIZE #define?

What do you think?

[Calibration Data load/save interface]

One more comment. Specifically about the read call:

It is important to be able to determine the size of the buffer needed for the call. Their perhaps needs to be a call to return the size of the buffer needed for the read. As the write could save different sizes even for the one device type, the size of the data block written needs to be saved with the data itself.

The read call should probably therefore fail if the data block passed in is not large enough. It may be worthwhile for the read to return the size of the data actually returned with 0 indicating a failure.

[Calibration Data load/save interface]

This is something I have been thinking about for a while now. I have been thinking that there is potentially another layer of abstraction that can be applied here. That is as a general settings register much like the windows registry but without all the complications.

This background thinking was part of the recent addition of the gfile module. The register could be implemented as a file or pseudo file on any storage system that can be hooked into gfile.

Storage in raw flash blocks, in a ROM file, in a file on a FAT file system would all be possible.

The delay in making this happen is always time. Gfile is not complete enough yet and more api needs to be designed and tested.

We are currently working on adding FAT file system support to gfile. So perhaps we are getting close.

A contribution in the area of a general settings register appropriate for an embedded platform would be highly appreciated.

[V21 Embest STM32F4-Discovery-BB mouse/button]

I have not specifically had much to do with that particular touch device however we used to have similar problems with the MCU touch driver. The reason ended up being due to spurious readings occurring across the touch event as the touch is being depressed or released. The workaround was to lower the polling rate (less chance of getting the reading during the indeterminate period). The fix was to not accept a reading until you had two readings in the same depression state.

I suspect that something similar is going on with your controller. I will look in the next few days.

At least it is operating acceptably for you currently.

Thanks also for the hint with the back light.

[ILI9325C over SPI]

Nice work.

Looking at the repository we now seem to have 3 drivers that handle the ILI93xx range...

• The repository ILI9320 driver (which also seems to handle 9325's)
  
• The repository ILI9325 driver (based on chinese code?)
  
• Your driver.

As I do not have one of these particular displays, could you please have a look at the 3 drivers and see if it is possible to easily integrate them into a single driver or at least tell me which is the best so that I can remove the duplicates from the repository.

Also, what board was your board file for? I will then add it to the appropriate directory in the repository.

Many thanks for your contribution.

[2.2" TFT LCD 320x240 (ILI9341 SPI)]

Thank-you for your contribution. I have added it into the repository under the boards/addons/gdisp directory.

[2.2" TFT LCD 320x240 (ILI9341 SPI)]

Good and bad accessing the SPI registers directly.

On one hand it is operating system independent (a good thing for uGFX), but on the other hand that then makes it CPU specific.

So pluses and minuses.

[Changing screen orientation makes letter unreadable]

This has now been updated in the source repository.

Thanks for finding this bug.

[cannot define font to include]

The problem is in the example gfxconf.example.h

In your gfxconf.h replace the lower-case "x" in the font name with an upper-case "X" and it should all work.

I have updated the source repository to fix this.

[Hardfault in mouse.c]

This is now fixed in the master source repository.

Thanks for bringing it to our attention.

[Hardfault in mouse.c]

Thanks for finding it!

I will adjust the code to fix this problem. I am a little swamped with my day job so it may be a little while but it will eventually be in there.

[Difficulty with Sharp LCD]

It looks like the bit order is reversed relative to the display. In other words:

• Bit 0 is where Bit 7 should be
  
• Bit 1 is where Bit 6 should be
  
• etc

Hope that helps.

[Hardfault in mouse.c]

Interesting problem as the two methods should be completely equivalent.

FYI - I am currently using the same compiler with no troubles but with a different processor.

To give you some background...

• There are a number of other places in the code where structure copy is used (although not all that commonly)
  
• We generally try to avoid using memcpy() to avoid dependence on system header files and system libraries (which are not always 100% compatible)

Some things to look at:

• Stack - perhaps the stack is being overrun?
  
• Does changing the compiler optimiser flags change the code generated (ie could this be an optimiser problem)?
  
• Exactly what hard-fault is being generated as that might indicate what is going on?
  
• Perhaps it is the compiler flags for code generation are not quite right for your processor?
  
• If it is using an implicit system library call to do the structure copy, perhaps the system library has been compiled incorrectly for your processor.
  
• Is it a bus alignment issue - ie the memory returned by the load function is non-bus aligned and the structure copy is assuming bus aligned data.

If you can please investigate these things that would be appreciated as I would prefer to avoid the use of memcpy unless necessary. This problem may also affect other area's of the code if it is a systemic problem that we need to handle.

Thanks for bringing this to our attention.

[[TODO] GWIN Console scroll strange behavior]

I have an idea on what might be going on.

Can you please define GDISP_NEED_CLIP as FALSE in your gfxconf.h file and see if the symptoms continue.

I suspect it is a multi-threading issue with the way that gwin uses the clipping calls.

If the symptoms dissappear i know what needs to be done to fix it properly.

[Rounded box drawing issues]

Thanks, that test was perfect.

The problem has been fixed in the current master repository.

[Rounded box drawing issues]

The old arc routines were significantly broken and have definitely been updated for the new code.

Arc's on the old system were VERY problematic and almost never got it right. Filled arc's previously did not even fill the arc area properly leaving a moire type pattern of gaps.

It is however quite probable that there are some boundary cases which my testing didn't include. Can you please upload me a short demo program that demonstrates the problem. Replace any variable numbers with absolutes (for example replace things like gfxGetWidth()/2 with an actual number) as the problem could be location and size specific.

I will get right on to fixing the problem for you.

[How To Start]

The reason that the readme just says to include the one file but the example file includes two different files is because the Mikromedia board is not a board that is supported by default in ChibiOS. The additional line in the example Makefile was to add the support for that board to ChibiOS (which is really quite independent of uGFX).

The additional line is included in the example Makefile so that the makefile is complete and compilable with potentially no other change than to change the location of where uGFX and ChibiOS has been stored relative to your project directory.

Similiarly the ChibiOS_board directory is purely to add the files to ChibiOS to support that board.