Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by inmarket

  1. GwinPrintg uses the internal printg framework which requires gfile. GwinPrintg effectively creates a pseudo file based on each window. This in practice is a very efficient use of code reuse. For now enable GFILE and the "string" sub-system as that enables sprintf equivalent functionality and the string sub-system is tiny. I will look at how easy it is to change the code so it can either be used without GFILE or at least without any sub-module file-systems turned on.
  2. inmarket

    CAN Dashboard Project

    And the development boards for these chips are generally cheap eg a STM32F4-Discovery board which includes the LCD is somewhere around US$25 from memory.
  3. inmarket

    uGFX BLIT API for RA8875

    The problem is that you are assuming that the source and destination bitmaps have the same line width or that you are even drawing the full width of the source bitmap. Note CX != X2. Similarly you are not using the starting position x1,y1 for the source bitmap. Passing the extra info to your draw routine you should be able to recode the X,y loop to fix the problem.
  4. inmarket

    Online Font Converter

    Note you can also use the command line binaries for windows or Linux that are found in the repository under the tools directory. The binaries have none of the restrictions of the web version.
  5. inmarket

    ginput: Touch invert/flip

    The trouble here is that you get any two devices from different sources and they will possibly have different alignments between the touch screen and the display screen. To make things worse very few devices are well aligned physically. Also the resolution of the display seldom matches the resolution of the touch panel. What this means is that floating (or fixed) point multiplication is needed in 99% of cases whether or not that is via fixed calibration settings. Despit this we have implemented fixed alignment code as an option for some drivers but that doesn't work for all devices (as you have already discovered) due to the reasons above. In V3 we are looking at providing better fixed alignment code that caters for more orientations but for now the correct solution is either a custom driver hack or, preferably, the fixed calibration matrix.
  6. inmarket

    STM32F746-Disco & Eclipse - Makefile approach

    Have a look in the example makefiles. It should be obvious.
  7. This has now been updated into the repository. Thanks for finding it.
  8. inmarket

    STM32F746-Disco & Eclipse - Makefile approach

    Use our file instead of the firmware file in your build. STM keep changing their firmware in incompatible ways which is why we include a particular version in our repository. @cpu20 is the expert in getting ide's to include the correct files. He has published a number of guides that may help. The other way is to not rely on the ide's build generator and to instead create a true makefile project in eclipse. It is by far the easiest way to build uGFX and it is where we as developers started. If you are nterested in this have a look at some of the prepared makefiles in the various board example directories.
  9. Thanks. I will look closely at that asap and update the repository accordingly.
  10. inmarket

    GSourceHandle ???

    If the line specified is right at the top of the function my guess is that it will work. If it is not at the top then you are running into a common C, C++ language misconception. C does not allow variable definitions except at the top of a block. Once a non-variable definition statement has occurred variable definitions are not allowed in the block. Whilst the C language does not allow this, C++ does. As many C compilers have associated C++ compilers many C compilers relax the rules and allow such definitions eg gcc. My guess is that the IAR C compiler follows the language standard and doesn't allow this. In general in C it is a good idea to seperate variable definitions from code to set the variables.
  11. inmarket

    support unicode and RTL language

    It is possible to use RTL languages with ugfx but it's a little more work for the programmer. 1. Use right justification instead of left justification for all your text boxes. 2. Reverse the characters in any string you want to print so they appear in the correct order when displayed. This can either be done programmatically (something like the gtrans module) or simply writing any fixed string with the characters reversed when programming. Eg. "abc def" would be written as "fed cba" and then right justified.
  12. inmarket

    Problem with low performance

    I presume you are using an M3 with the internal ltdc video controller. If that is not the case the below discussion may help even if it not directly applicable to your circumstances. The problem is likely to be related to your external sdram and it's bandwidth. The proof of this is the slow performance (noticeable redraw speed) of the gdispClear loop.The image drawing tests are therefore meaningless until that problem is solved. The first thing to try is putting the framebuffer into internal ram as a test. If that operates quickly the problem is your bus interface to the external sdram. Note that if your framebuffer is in external ram do not put any other objects, heaps, stacks, code or anything else in that external sdram. Framebuffers are extremely bandwidth intensive just with video refreshing. Other things to check are your CPU clock is running at full speed, wait states and speed and width of the sdram bus and also look for any other high speed requirement that may affect available bandwidth or speed.
  13. For a while now we have been working on a new version of uGFX that includes many fundamental changes including changes that will affect compatibility with the uGFX API. This new work we have loosely labelled uGFX V3/4. As the changes are so significant we have decided to start to integrate some of these changes back into the current version of uGFX in a manner that disrupts as few existing applications as possible. This note is therefore to say that uGFX V2.8 will be the last official release of uGFX v2.x and it will be released at the same time uGFX v3.0 is released. The next major release uGFX v3.0 will retain the existing uGFX user API but the driver interface will be changing. The consequence of this are: If you are using a custom board file (not one of the standard ones we provide as part of the repository), you will need to rewrite your board file for the new driver architecture to use uGFX v3.x. If you have a custom driver for your display or touch device it will need to be rewritten to conform to the new driver API to use uGFX v3.x. Some new API's may appear in uGFX v3.x that seem to replicate existing uGFX functionality. These new API's will be part of the future API for uGFX and the old calls will eventually be deprecated (although not in uGFX v3.x). Note that during uGFX v3.x these new API's may change as the technology develops. It is therefore recommended that these new API's be considered for usage in new applications particularly where long term usage with future versions of uGFX is important. Where stability with a particular version of uGFX is important it is recommended to use the old APIs. To aid in the migration process for custom drivers and board files for common hardware, if you contribute that to uGFX before uGFX V3.0 is officially released we will attempt to port the driver/board file to the new format for you. We may ask you to test that for us as the official release of uGFX v3.0 comes closer. Once uGFX V3.0 is released we will provide no more support or porting for the uGFX V2.x drivers and board files except via paid support. A new uGFX3 branch has been created in the source repository. Prior to the uGFX v3.0 release and starting immediately the uGFX3 will be the main development branch. Only bug fixes and contributed v2.x drivers/board files will be ported back to the master branch to form the basis of uGFX v2.8. This will leave the master branch as the most stable version of uGFX. The new uGFX3 branch may be unstable and may not always compile prior to the uGFX v3.0 release. Once uGFX v3.0 and uGFX v2.8 is released the uGFX3 branch will be merged into the master branch. uGFX v2.x will then enter a period of where only critical bug fixes will be posted and only for a short period much the same way that other version releases are made in uGFX. There is currently no defined timeline for when uGFX v2.8 and uGFX v3.0 is released - just that the process has started. We will post additional information in this thread about the changes as we progress.
  14. inmarket

    Display is intermittent - SSD1322

    Have a look at the CMD_SET_REMAP. The value 0x14 may not match your display.
  15. inmarket

    Display is intermittent - SSD1322

    It looks like the column order on your display might be a bit different to the standard arrangement. Check the initialisation sequence particularly around the column order settings. The other place to look is around the spi data format eg if you are outputting 9 bit spi bit the controller expects 8 bit spi (or visa versa) you will get similar symptoms.
  16. inmarket

    Display is intermittent - SSD1322

    What type of physical interface do you have to your display? Eg i2c, spirit, 8 bit parallel.
  17. More information... Aquire_bus and release_bus give you an opportunity to use a shared bus. Post_init is called once the controller has been initialised. Many controllers need to be initialised at a slower bus speed. Post_unit gives you the opportunity to increase the bus speed after the controller is initialised.
  18. inmarket

    TextEdit widget Issue

    This has now been fixed in the repository. Thanks for finding it!
  19. Unfortunately there are only two mechanisms, off-screen drawing (pixmaps) and double buffering. Double buffering is a big nasty topic in its own right - search the forum for some of the discussions on that subject. It is probably also not viable for you given your controller and bus interface. As far as pixmaps are concerned v3.0 will fix the incompatibility with single file make. The filled string drawing algorithm will be updated at some time in the future too but that is not a simple task as their are lots of complexities with fonts.
  20. inmarket

    A bug in gfxRealloc()

    I have seen the post and have left it open to sort out when I get time but haven't had that time yet due to various project deadlines. Thank you for finding it and I will report back when I have had time to properly investigate and correct the master sources.
  21. Have a look at the dial devices. A rotary encoder fits fairly nicely with the dial device.
  22. inmarket

    GADC demo on osx

    You need to create a gadc driver for OSX or a dummy driver that will work cross-platform. As an example look at the existing gadc driver in the drivers directory.
  23. inmarket

    One widget display on many page.

    Note that reparenting a widget is a real hack and is officially not supported by uGFX. The reason is that there are dependencies that may stop things working eg... 1. A child object must always be completely enclosed within its parent container 2. A child object must always have a higher z order than its parent container. 3. There are visibility dependencies. I am sure there are others too but those three alone are enough to make this a complex operation requiring deep understanding of the internal workings of uGFX to get right. That complexity is why it is not a standard part of the uGFX API. It is much better that you arrange your containers and widgets as non-overlapping, or duplicate such controls across the pages. As an example see the console object on the widgets demo.
  24. inmarket

    Special Character Usage

    Unlikely the compile will affect anything. Try just outputting directly a string with Unicode characters in it without using snprintf. If that doesn't work there can only be one of a few problems... 1. Utf8 support is not turned on 2. Your editor is not putting the Utf8 characters into the string correctly 3. Your compiler is stripping them out of the string or not encoding them correctly. 4. The font you are using doesn't map the particular characters used. In your case I think 1 or 2 would be the problem as you are seeing 'extra' characters.