inmarket

To implement your read routine in the board file, copy the chibios example but replace the chibios call with the equivalent function from your spi library. It should be almost a one for one api call replacement. The spiexchange chibios call just writes some bytes on the spi port and then reads some bytes - in this case it writes one byte and then reads 2 bytes. You won't need to worry about the details of how to extract the reading from those values returned by the read call - the driver handles all that, and lots of signal conditioning for you. If you are interested in the details have a look at the driver source code and then also the ginput mouse layer which handles all the heavy lifting associated with processing mouse coordinates.

To be able to help you more we will need a lot more detail. What board are you using, what lcd module, what resolution, how is it connected to your board, what is the sequence of events that happen to the lcd when you turn the device on, what demo are you running, what operating system, what debugging have you tried, do you have a scope so you can check the pins are toggling correctly, is the controller a real SSD1289 or could it be an imitation chip? These sorts of information are essential for us to help you debug. With more information we will do what we can to help.

Thanks

Can you please post the project file as I would like to add it or a variant to the repository. It would be good to have a KEIL example in there.

I know of no reason this should be so. Can you please attach a zipfile with a very simple demo showing the problem and we will look to see what is going on. A font size of 5 seems very small anyway as the standard fonts are typically around 11 pixels high.

I have uploaded more updates on the master repository that should fix these. Let me know if there are still any problems.

I will update the master with the changes to the setjmp. Thanks for that. With the int8_t, all that block should not be defined if stdint.h has been included as all those definitions should come from that file. I suspect that all the other defines are matching and so they don't give a warning whereas Keil has some funny ideas about char signed-ness (or not). A better solution is to check the top of stdint.h from Keil and change the block to be: #if !defined(_STDINT_H) && !defined( the appropriate symbol that kiel uses at the top of stdint.h ) typedef char int8_t; typedef unsigned char uint8_t; typedef short int16_t; typedef unsigned short uint16_t; typedef int int32_t; typedef unsigned int uint32_t; #endif Can you please get back to me on the correct symbol for that. Thanks.

Reply posted to that thread. Thanks for helping ivan47

I have pushed a small change to the master repository that will hopefully fix the issue with the Kiel compiler for you. Can you please try it and let me know if it works and if not then what changes are needed to make it work.

_setjmp is a compiler defined routine (although occasionally it is found in the c library). Specifically check the compiler options and if that doesn't help try including the standard c library. Also, _setjmp is generally the compiler specific version whereas setjmp (without the underscore) is the c library version which internally calls _setjmp. With the Kiel compiler however it may not define the underscore version. In that case change gos_raw32.c so that it uses the correct version for the Kiel compiler. If that happens please let us know so we can patch the master repository.

I you want to use ugfx without a rtos, have a look at the raw32 gos layer. It allows you to implement ugfx with no operating system. If you search the forum you will find code snippets etc from other users who have used this.

It is almost certainly due to the overheads in the chibios spi driver. I suspect that chibios is suspending the thread while waiting for the spi to send rather than polling the registers to see when it is done. Resuming a suspended thread is a very expensive proposition hence the big delays between bytes of data. An even better method than polling for the transaction to complete would be to poll just before starting the next transaction for completion of the previous transaction. Unfortunately we are talking the specifics of how chibios implements it's drivers here, not something we easily control. The only solutions are... 1. Use a bit banging method of implementing spi, or 2. Write cpu specific direct hardware register calls, or 3. Rewrite the chibios spi driver. Method 1 was used in the SAM7EX256 uext drivers. Method 2 was used in the SAM7EX256 lcd driver Method 3 is probably impossible due to deficiencies in the way chibios drivers work. Unfortunately the SAM7EX256 board uses a different cpu so method 2 is not directly transferable from that code. The bit banging code however should work on any cpu. It has been on the agenda for a while for ugfx to write a HAL module which would overcome many of these problems. That is a very big job however so for now we have to rely on the base operating systems hardware drivers.

gwinDestroy on a container will destroy all gwin objects in it. It will not however close any gfiles' or gdispImage objects associated with buttons etc just as it does not automatically open them. The reason for this is that the same gfile for an image can be used for multiple buttons. It would not be good if a destroyed button was to close the image gfile as then all the other still existing buttons using the image would fail. So, images associated with gwin objects must be manually opened and also manually closed.

I strongly suspect the difference is the way spi is implemented. I would suggest that mbed is using bit banging versus chibios using the real spi hardware. Bit banging is usually faster but more cpu intensive. An implementation of bit banging spi can be found under the SAMEX256 board for some of the uext peripherals (initially implemented that way due to buggy spi drivers for that cpu in chibios). Other factors... Make sure your board file routines are marked as "inline". This way with the right optimization settings your compiler will remove any function call overhead. Set the DNC pin in your board_init and also at the end of the write_index call. Setting DNC can then be removed from write_data as it will already be set.

I don't know of any particular keyboard maker. For commercial product these are usually custom designed as part of the case design. Membrane switches are common so perhaps look for a membrane manufacturer. Perhaps a better possibility for a one off project is to look on aliexpress or on ebay. I am sure you will find something suitable for your project there.

The GFILE module supports creating a GFILE based on a ChibiOS BaseFileStream however in ChibiOS V3 the API for accessing file streams has changed. GFILE has now been updated to use the correct API for both ChibiOS V2 and V3. As part of this gfileOpenBaseFileStream() has been renamed as gfileOpenChibiOSFileStream() to improve clarity. For compatibility a #define has been added so that existing code using gfileOpenBaseFileStream() will work unchanged.

The hardware keyboard stuff is working nicely even handling complex operations like scan code conversion. For most hardware keyboards a driver would need to be written as the only keyboard drivers currently in the repository are the Win32 and x drivers. A virtual gwin based keyboard is underway but has been on the back burner due to other demands. I will bring that forward again but no promises on when it will be ready as I am very busy currently with other work. As Tectu mentioned, hand writing recognition is well beyond most embedded platforms.

Also, just looking at your gfxconf.h file, whilst you have enabled bmp images you have not enabled the particular sub-format of your image eg GDISP_NEED_IMAGE_BMP_8. As a first test set all the sub - image formats to TRUE in your gfxconf.h. You can always turn the extra ones off later to reduce code size.

Start with the image demo and get that working first. Once that is working replace the image with your image. If it doesn't display then you have either not enabled the right decoder for your image or there is something funny about the image. I hope that helps you find the problem.

If you need two ranges from the font file there are a few ways of doing this... 1. Find an original font that only has those ranges in it and then don't filter when converting, or 2. Convert the font twice with different ranges and then treat them as separate fonts in ugfx (see the above post). 3. Alter the mcufont library to allow the font converter to accept multiple ranges. If you go to the trouble to do this we would love a copy of the modified conversion utility.

A few things to check... 1. Does the demo work without the image? The reason to ask this is that setting orientation except at the beginning of a program is officially a no-no. This demo has been limited to give that the best chance of working by restricting all drawing to the smallest dimension box. Even so, it may not work on all hardware as it requires both the touch and display driver to support orientation properly. If the button demo works correctly with the button at its new location then move to step 2. 2. Try your demo without the gwinImageCache call. Caching an image takes a huge amount of memory. It may be slow without it but check correct operation first. If it works without this call it means that caching the image has run you out of memory. 3. Try running your program on one of the emulator platforms. If it runs there but not on your hardware I would suspect that something is crashing on your hardware effectively freezing the program. In this case you will need to get your hardware debugger working and see what is causing the exception. Another way of testing for this would be to also create a gtimer that flashes a led on your board say once a second. If that stops then it has crashed.

In your userfonts.h file #include each of the font files generated by the font converter. Eg in userfonts.h #include "font1.h" #include "font2.h"

One more thing, it is probably a good idea to leave changes to the driver as a very last resort. This driver is well tested and has not been known to need changes to get it to work.

A few things... 1. The spiSelect and spiUnselect can go in the aquire and release bus too. This reduces significant overhead especially when transferring data. 2. There is something wrong with the way you are talking to the controller in that you are sending that 0x73 before each transfer. That looks like i2c addressing. If your controller is setup to use i2c then you should be using the chibios i2c api not the spi api. If your controller talks via spi then it almost certainly will not want that preamble. Have a look at some of the other boards that use the spi interface to talk to their controller. 3. There seems to be a problem with the width of the data being sent for an write_index. Although the parameter type implies a 16 bit transfer, in reality I believe it is actually a byte operation (something to cleanup some day in the board file template). Have a look at the display board file for the stm32429-idiscovery board. Although it uses a different driver and has lots of other complications at the driver level, the controller is actually an ILI9341 that is addressed using spi so it's board file should be close to what you need.

To clarify, GDISP_NEED_MULTITHREAD makes gdisp thread safe. GWIN is thread safe because it has been written as thread safe code and talks to thread safe gdisp. GTIMER is thread safe, GQUEUE is thread safe (eexcept for the "I" versions of the functions which designed to only be called at interrupt time. GMISC is thread safe as it has been written as thread safe code, GINPUT is not thread safe but doesn't need to be as event sending is thread safe and that is how you communicate at run time with input devices. GEVENT is thread safe. GDRIVER is not but is typically only called at init time and very seldom by application code. GAUDIO and GADC are thread safe but not multi-stream. GFILE is not thread safe and neither are many of the underlying file system interfaces eg FATFS. We should probably document this somewhere! Making GFILE optionally thread safe is probably a good idea although locking granularity versus complexity will be an interesting design decision. If you are finding that gfileopenfilelist fails if you don't make a open call first, this is likely a problem in the fatfs code itself (third party llibrary). I will investigate and see what I can find.