1.5 development planning thread

  • 61 Replies
  • 20115 Views
*

Offline reyalp

  • ******
  • 11592
Re: 1.5 development planning thread
« Reply #20 on: 21 / February / 2016, 19:53:39 »
Advertisements
A related question: would it be a good idea to put NHSTUB(special_function, NULL_SUB) in stubs_entry.S when special_function is not found?

For example, the previously mentioned (heap corruption check) function does not exist in a number of DryOS firmwares. I can't use a weak, empty function as a replacement because it may override the NHSTUB (I've experienced this while working on the e32 patch).
I could of course put a #define in a number of platform_camera.h files, but I'd prefer to avoid that.
I'm not sure. You'd have to define NULL_SUB somehow. I guess you could just pick a random bx lr in the firmware, but it might be better to use a different macro.  Either would be OK with me.

I'm OK with more camera.h defines too, or if it's dryos version dependent you should be able to use a CAM_DRYOS_REL ifdef now or use it to define the defaults

Needed to allow them to be overridden - e.g. GetBatteryTemperature crashes on some cameras so it is replaced with a dummy routine in lib.c.
Hmm, I think it would be clearer and more maintainable to have these explicitly defined somehow.
Something like
INTERNAL_STUB(GetBatteryTemperature,my_GetBatteryTemperature) that just creates an alias (like DEF)

I would like to get away from weak as much as practical.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3728
Re: 1.5 development planning thread
« Reply #21 on: 27 / February / 2016, 14:17:42 »
I'll check in this feature in a few days - it will make creating those "special" builds easier (there are not a lot of those requests, but one had to work on it each occasion).
Checked in, changesets 4497 and 4498.

*

Offline srsa_4c

  • ******
  • 3728
fonts, localization
« Reply #22 on: 14 / March / 2016, 17:13:55 »
I don't know if I should open another topic for font related issues. For now, I'm posting this here.

While working on font related stuff, I noticed that the CHDK built-in font appears broken for Greek - many letters are missing (I don't know if the translation table itself is okay). The Greek translation only appears to be usable when one of the GR RBF fonts is selected. Disclaimer: I can't really read Greek as I'm not familiar with most of its alphabet not to mention the language.

Another issue: choosing a language file does not influence the selected codepage (which only matters when using the built-in font). Perhaps we could include the required codepage in the lang file (if it's known, that is).

*

Offline srsa_4c

  • ******
  • 3728
Re: 1.5 development planning thread
« Reply #23 on: 16 / March / 2016, 17:20:28 »
Attached patch contains partial rework of the language string library. Unfortunately, most active forum members won't benefit too much from it.

Cost:
Core size increases by approximately 192 bytes (GCC 4.9.3).

Changes:
  • Store language string references as (15 bit) offsets. Memory allocated for the string ref. table is halved (that's -637*2 bytes minus as of today).
  • Store loaded language strings in a single big allocated area instead of individual allocations. The allocation overhead is at least 12 bytes per allocation (when using SUBA), so allocated memory is reduced by several kilobytes. The import routine allocates a _temporary_ string ref. buffer (string count * 4 bytes).


Limitation:
As reference offsets are stored on 15 bits, the maximal usable (cleaned up) language object is approx. 32766 byte. I don't see this a big limitation, it's good for ~ twice the current string amount.
It would be possible to double the limit with some added code, but I'm not sure if we'll ever reach the limit.

tl;dr
Users who are not using language files will experience more than one kB decrease in RAM usage.
Users who are using translations will experience 4..8 kB less allocated RAM, depending on the amount of translated strings.


*

Offline reyalp

  • ******
  • 11592
Re: 1.5 development planning thread
« Reply #24 on: 17 / March / 2016, 00:56:28 »
Attached patch contains partial rework of the language string library.
With only skimming the code, this seems fine to me, but I haven't worked in this area much. It's a decent memory saving for language file users.

Quote
Another issue: choosing a language file does not influence the selected codepage (which only matters when using the built-in font). Perhaps we could include the required codepage in the lang file (if it's known, that is).
This seems like a good idea. Another part of the code I haven't spent much time with.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3728
Re: 1.5 development planning thread
« Reply #25 on: 17 / March / 2016, 20:12:18 »
With only skimming the code, this seems fine to me, but I haven't worked in this area much. It's a decent memory saving for language file users.
Thanks, I'll check this in soon. edit: done.
I only started doing it because I noticed an earlier similar attempt by philmoz in the file's history and I wanted to compensate for the added code while working on the other feature
Quote
Another issue: choosing a language file does not influence the selected codepage (which only matters when using the built-in font). Perhaps we could include the required codepage in the lang file (if it's known, that is).
« Last Edit: 18 / March / 2016, 17:11:39 by srsa_4c »

*

Offline srsa_4c

  • ******
  • 3728
Re: 1.5 development planning thread
« Reply #26 on: 20 / March / 2016, 18:01:03 »
We could reduce core size by more than 1kB if we could find a way to exclude unneeded language strings (such as GPS strings on GPS-less cams).
Candidate patch attached. It seems to work properly (both during build and on camera), but only tried it on 2 cams.
For built-in strings, unneeded strings are stored as empty string. When loading a language file, unneeded strings are ignored.

I'm mostly concerned about the style I used: tools/makelang.c includes a (new) header: lib/lang/lang_str_conditions.h ; the platform makefile (platform/makefile_sub.inc) reaches into lib/lang to build a few files platform-dependent. Does this look acceptable or does it need some improvements?

*

Online philmoz

  • *****
  • 3070
    • Photos
Re: 1.5 development planning thread
« Reply #27 on: 22 / March / 2016, 18:49:01 »
We could reduce core size by more than 1kB if we could find a way to exclude unneeded language strings (such as GPS strings on GPS-less cams).
Candidate patch attached. It seems to work properly (both during build and on camera), but only tried it on 2 cams.
For built-in strings, unneeded strings are stored as empty string. When loading a language file, unneeded strings are ignored.

I'm mostly concerned about the style I used: tools/makelang.c includes a (new) header: lib/lang/lang_str_conditions.h ; the platform makefile (platform/makefile_sub.inc) reaches into lib/lang to build a few files platform-dependent. Does this look acceptable or does it need some improvements?


I'm not sure this will work for a batch build.
The 'lib' directory is only built once at the start, so the lang_str.h file will probably be whatever is created for the first camera.
I don't think this file will get rebuilt for every camera.


I think lang_str.h will have to be moved to the camera directory, and it's build rules move to makefile_sub.inc.


Phil.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)


*

Offline srsa_4c

  • ******
  • 3728
Re: 1.5 development planning thread
« Reply #28 on: 22 / March / 2016, 19:36:17 »
We could reduce core size by more than 1kB if we could find a way to exclude unneeded language strings (such as GPS strings on GPS-less cams).
Candidate patch attached. It seems to work properly (both during build and on camera), but only tried it on 2 cams.
For built-in strings, unneeded strings are stored as empty string. When loading a language file, unneeded strings are ignored.

I'm mostly concerned about the style I used: tools/makelang.c includes a (new) header: lib/lang/lang_str_conditions.h ; the platform makefile (platform/makefile_sub.inc) reaches into lib/lang to build a few files platform-dependent. Does this look acceptable or does it need some improvements?
I'm not sure this will work for a batch build.
The 'lib' directory is only built once at the start, so the lang_str.h file will probably be whatever is created for the first camera.
I don't think this file will get rebuilt for every camera.
Thanks for commenting.
lang_str.h is indeed only built once, but that's intentional. Here's an excerpt:
Code: [Select]
/*482*/ "Current custom curve\0"
/*483*/ "Tetris\0"
/*484*/ "Show partition number\0"
#ifdef CAM_CHDK_HAS_EXT_VIDEO_TIME
/*485*/ "Video without time limit\0"
#else
        "\0"
#endif
#ifdef CAM_CHDK_HAS_EXT_VIDEO_TIME
/*486*/ "Sensor may overheat during long recordings!\0"
#else
        "\0"
#endif
#ifdef CAM_HAS_GPS
/*487*/ "GPS Settings\0"
#else
        "\0"
#endif
#ifdef CAM_HAS_GPS
/*488*/ "Navigation to current photo\0"
#else
        "\0"
#endif
I left the files where they are because lib/lang seems the appropriate place for this stuff.
As only the strings are camera specific, I have moved the build rule for lib/lang/lang_str.c to makefile_sub.inc and added platform.h as an include for lang_str.c. Batch build seems OK (did not test a full build yet), searched for "GPS" in main.bin files and found only those ports' files that have GPS support.

*

Online philmoz

  • *****
  • 3070
    • Photos
Re: 1.5 development planning thread
« Reply #29 on: 22 / March / 2016, 19:44:58 »
Thanks for clarifying. I did not look that closely at the output; just a quick scan of the patch.


Sorry for the confusion.


Phil.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)

 

Related Topics