ROM usage of Appwizard

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • ROM usage of Appwizard

      I am working on a project with appwizard and I realised that about 66kB of ROM are used for unicode even when if the "support bidirectional text" is disabled in the project options.

      I read the doc for emWin, which says that about 60kB of rom is expected to be used as soon as GUI_UC_EnableBIDI is linked, but it is only present in the code when the option is ticked in the project option, and it currently isn't.

      Am I missing a define somewhere? the only place where i can find this _aTypes array for unicode is in 2 headers, but i believe thoses were only relevant when compiling the library, and are not used when using the library.

      I don't need bidirectional support, so i would like to disable it. 60kB difference is the difference between being able to fit the program in memory or not.


      Best regards

      Alexis Marquet
    • Hi,

      with the current version of AppWizard there is a 66KB difference depending on whether the BiDi option is activated or not.

      Can you tell me which version of AppWizard and which hardware you are using?

      Thanks and best regards,

      Florian
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • Appwizard V1.00_6.10f, headers from this version and lib is M7F version. Hardware is LPC54608 dev board. code still fits because it has 512 KB of flash ROM, but end device is LPL54607 which only has 256KB, which won't fit.

      The problem is that even with BIDI disabled (so there is no call to Enable_bidi in the init), the array of the unicode codepoints is still linked

      Best regards,

      Alexis Marquet
    • Hi,

      we were able to reproduce this issue with the version you are using.

      However, this was already fixed with the latest version V1.06a_6.14a. You can get the latest version from your distributor or directly with the emWin source code upgrade.

      Best regards,

      Florian
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • Thank you very much, that version was not yet available on NXP's website. using v6.14a fixed that, unicode array is no longer linked.

      however, even if i am not using JPEG images, i still get the GUI_JPEG__DecodeLine function and other jpeg routines, same for SPRITE support and so on. Is that a limitation on Appwizard with external resources (on SD card) where it still links those functions because the resources type is not known to APPW? or is that also something that could be "fixed" in the near future?


      Thanks again for your support,

      Best regards,
      Alexis Marquet
    • Hi,

      I'm happy to hear that it works for you now.

      alexis.marquet wrote:

      however, even if i am not using JPEG images, i still get the GUI_JPEG__DecodeLine function and other jpeg routines, same for SPRITE support and so on. Is that a limitation on Appwizard with external resources (on SD card) where it still links those functions because the resources type is not known to APPW? or is that also something that could be "fixed" in the near future?

      These functions must be linked since the user can still use JPEGs in their user code, e.g. set a JPEG to an IMAGE object.

      Best regards,

      Florian
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.