inmarket

I have fixed the release_bus() calls for the SSD1331 and the SSD1351 drivers. All others are correct. I was wrong in my thoughts above - the correct place is after the post_init_board() call.

I just dug up my board with that controller. Everything works well including orientation support. I don't think power modes are implemented (or if they are they are untested).

The ILI9341 is used by the Mikromedia STM32 M4 board which is one of my main development boards so last i looked it was working well. Having said that recently I have been using the STM32F746-Discovery board as its driver has been a work in progress with lots of complications but essential for future STM32 processors. There was also some thought to replace some of the hard coded values with an include file but i cant remember how far that got. So, in conclusion yes it dhould definitely work. I will recheck just to make sure later today.

No reason. It is an error. I will correct it tomorrow to be consistent with other drivers (which i think is release called before but not after). Thanks for finding it.

Can you please attach (in a zip file) your font that causes the offset table problem. Please also provide the mcufont encoder command line flags you used. This will just make the debugging easier. Thanks.

The changes have been integrated into the STM32LTDC driver in the repository along with other orientation and DMA2D fixes. The special STM32F429i-Discovery driver is now gone as the more general (and complete) STM32LTDC driver now works with this board too.

Thanks. I have made the change to the repository.

Thanks. This has been added to the repository

Normally those files are found using the compiler include path. As the project directory should be on the include path that is where the files are normally put.

This is a problem of compilers. With arduino the standard ide compiler requires a bool compatible definition for bool_t. On the other hand that is obviously incorrect for a strict compiler. I am happy to change the definition in gos_arduino.h provided there is a definition that works for both compilers. Could you please test defining it as an unsigned char with both compilers and if it works we will change the definition in the repository. Unfortunately i just have to much on my plate to test this right now so if you could test this as part of your arduino work we would be very appreciative.

Thanks Christopher. Can i please ask that you copy that post on creating hardware specific versions of the library into this thread so other ugfx users will have easy access to it as well. It is a good idea.

At this stage we will need a copy of your project to be able to help you more. Please cut out any code not relevant to this discussion and then zip the project and add it to a forum post. When we get a few minutes we will look at it. It may be a few days however as we are currently very busy.

Best way from here is to debug into the gfileOpen in order to discover why it is not finding your file. Given that you get no warning displaying (you did do a make clean?) I suspect that the romfs code is not been included for some reason.

Is the definition of MY_PLAY_FILE correct? This should be a #define that matches the name of the file in romfs_allwrong.h Also romfs_files.h should not be included in your main.c It should be automatically included by ugfx because you have turned on the romfs system in your gfxconf.h The easy way to tell is to add a #warning into romfs_files.h You will then be able to see any time it is included

While encoding as UTF8 requires more storage than UTF16 for chinese, UTF-16 requires a whole new set of string handling functions which means that unless you have lots and lots of text any gains from moving to UTF-16 is lost in the extra code required. Never the less, I have just finished another little side project (re-invigorating the Arduino port of ugfx) so I will work on this next. The first problem to be solved is the offset table produced by the mcufont encoder (and its corresponding ugfx decoding code). Once that is done I will look at adding UTF-16 support and if it is simple enough I will add that too. Expect the process to take a week or so.

An example sketch has been added in the boards/base/ArduinoTinyScreen directory. It shows how to use ugfx as an Arduino library using the standard Arduino development software. Please read the instructions in readme.txt and the example carefully as there are a few steps associated with setting it up due to the strange library system of the Arduino development software.

I have now re-tested Arduino. An example sketch has been added in the boards/base/ArduinoTinyScreen directory. It shows how to use ugfx as an Arduino library. Please read the instructions in readme.txt and the example carefully.

It was quite a while ago that i did this. I will dig up the old project, get it to compile with the current ugfx repository and i will then add it to the repository. Give me a few days and i will post again when it is done. Everything is always easier with an example.

Have a look at the olimex SAM7EX256 board as an example. This is a supported board and it uses PWM audio. You should be using the play-wave demo. The vs1053 audio controller is a chip that is capable of decoding complex file formats like mp3. That is why it has its own demo - to demonstrate those extra capabilities. The pwm audio (and most other audio codecs) can only accept pcm data. Play-wave is the demo that converts a .wav file into pcm data and feeds it to the audio sub-system. If you want to decode more complex audio file formats than wave files you will need to either use a decoding library or upgrafe your hardware to use a specialist chip like the vs1053.

The errors you are getting are because it appears that the board specific code in chibios has not been linked into your make. Whilst this is a chibios specific problem we will attempt to help you with this. To do this we need to know which version of chibios you are using and whether you are using the chibios makefile or the ugfx based makefile.

There is definitely a problem with your standard c library (whatever it is called). You can however just avoid the problem by changing the cpu setting at the top of the makefile. Try using the stm32m4 setting etc. Whilst this may get you round your library problem you will lose any cpu optimizations. This is likely why your other projects worked, they are not turning on the f7 specific compile flags. Ohh - dont forget to do a make clean in between changing any of these flags

Please turn off GINPUT_NEED_KEYBOARD. That setting is required for a hardware keyboard only. That is what it is complaining about - the lack of a linked hardware keyboard driver.

It should definitely be "hard" as the cpu has hardware floating point. It looks like you don't have the correct libc installed for hardware floating point. In fact it doesn't look like it is using f7 libraries at all. Perhaps you are using a pre-f7 compiler as the f7 is a very recently supported cpu or atleast your libc is out of date (note the "conflicting archetecture error in the 2nd build)

Yes. These are all problems we are well aware of. The irq for these devices often don't provide a release interrupt. They also sometimes just stop working and only a full chip reset can restart them. For these reasons we gave up on trying to turn off polling. It just didnt work (reliably). The only advantage we could get from an interrupt was to use it to increase the responsiveness by triggering gmouseWakeup exactly as you have done. Other than the obvious hardware bug where interrupts just stop working, it is obvious that the hardware designers have not thought through all the events needed to provide a good touch experience and so good hardware is effectively wasted. Note that other touch libraries (i looked at many to try and solve these issues) just dont deal with the problems leading to bad readings, jitter and unreliable touch detection. For others that might be ok but for ugfx we wanted to do it right.

We are glad to hear you got it working. Thank you for posting the attached files.