1.4 development planning thread - page 5 - General Discussion and Assistance - CHDK Forum

1.4 development planning thread

  • 195 Replies
  • 48612 Views
*

Offline srsa_4c

  • ******
  • 4426
Re: 1.4 development planning thread
« Reply #40 on: 07 / January / 2015, 19:17:47 »
Advertisements
Since you are now building stubs_auto.S in two steps, is it possible for the same address to be added twice?
Each step sorts and filters out duplicates; but the combined set does not.
The first step collects addresses used in B and BL instructions, the second filters for blx <label> type of instructions. Since the latter appears to be used exclusively for ARM thunks in thumb-2 code, I think the chance for an address appearing twice is close to zero. I don't have a proof for this, though. Do you think there is a need for a verification step?

Quote
Should be safe to just add it to stubs_asm.h - it should be ignored by existing cameras.
I'll re-post the patch (with modifications if your answer to the above question is yes).

edit:
the macro is too specific to DIGIC 6, can't just introduce it alone in stubs_asm.h
For now it seems the regexp change will be included in something more complicated...
« Last Edit: 11 / January / 2015, 09:12:00 by srsa_4c »

*

Online philmoz

  • *****
  • 3332
    • Photos
Re: 1.4 development planning thread
« Reply #41 on: 07 / January / 2015, 19:37:13 »
Since you are now building stubs_auto.S in two steps, is it possible for the same address to be added twice?
Each step sorts and filters out duplicates; but the combined set does not.
The first step collects addresses used in B and BL instructions, the second filters for blx <label> type of instructions. Since the latter appears to be used exclusively for ARM thunks in thumb-2 code, I think the chance for an address appearing twice is close to zero. I don't have a proof for this, though. Do you think there is a need for a verification step?

If it did happen the current system would try and generate two different stubs with the same name - I'm not sure how you could fix this.

If you think the likelihood is low, I'd leave the patch as is (you should get a compile error if it ever happens).

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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4426
Re: 1.4 development planning thread
« Reply #42 on: 07 / January / 2015, 19:52:51 »
If it did happen the current system would try and generate two different stubs with the same name - I'm not sure how you could fix this.
We could introduce a different naming convention for those labels, for example. If we ever get such conflicts, that is.
Quote
If you think the likelihood is low, I'd leave the patch as is (you should get a compile error if it ever happens).
If we get a build error that's good enough, I guess.

*

Offline srsa_4c

  • ******
  • 4426
Re: 1.4 development planning thread
« Reply #43 on: 13 / January / 2015, 18:37:51 »
- Games menu built at startup from all module files set to 'game' type.
- Tools menu built at startup from all module files set to 'tool' type.
Some additional thoughts on this. This change is causing a noticeable (small) delay at startup. Would it make sense to cache the menu entries somehow and only refresh the list
- when entering the tools or games menu OR
- when clicking the (not yet existing) "refresh" menu entry
?

I used the following macro when porting the memory dumper module to 1.4:
#define draw_txt_string(x,y,s,c) draw_string(x*FONT_WIDTH,y*FONT_HEIGHT,s,c)
It spared me some typing.


*

Online philmoz

  • *****
  • 3332
    • Photos
Re: 1.4 development planning thread
« Reply #44 on: 13 / January / 2015, 18:59:59 »
- Games menu built at startup from all module files set to 'game' type.
- Tools menu built at startup from all module files set to 'tool' type.
Some additional thoughts on this. This change is causing a noticeable (small) delay at startup. Would it make sense to cache the menu entries somehow and only refresh the list
- when entering the tools or games menu OR
- when clicking the (not yet existing) "refresh" menu entry

I created the menus at startup because it was easier to do than creating them the first time each menu is accessed. I haven't noticed any significant startup delay this way. The menus are never 'refreshed' once created.

Another option would be to create the menus in a separate task.

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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Online philmoz

  • *****
  • 3332
    • Photos
Re: 1.4 development planning thread
« Reply #45 on: 14 / January / 2015, 03:58:21 »
- Games menu built at startup from all module files set to 'game' type.
- Tools menu built at startup from all module files set to 'tool' type.
Some additional thoughts on this. This change is causing a noticeable (small) delay at startup. Would it make sense to cache the menu entries somehow and only refresh the list
- when entering the tools or games menu OR
- when clicking the (not yet existing) "refresh" menu entry

I created the menus at startup because it was easier to do than creating them the first time each menu is accessed. I haven't noticed any significant startup delay this way. The menus are never 'refreshed' once created.

Another option would be to create the menus in a separate task.

Phil.

Updated patch:
- Games and Tools menu contents loaded the first time the menu is accessed (instead of at CHDK startup).
- Move all EyeFi code and menus into module (add support for submenus in modules).

The second change is an experiment, while it has the advantage of removing all EyeFi related code from the code CHDK, it has the disadvantage that the EyeFi submenu items can't be added to the user menu. Personally I don't have a problem with this as the EyeFi code is pretty specialised.

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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4426
Re: 1.4 development planning thread
« Reply #46 on: 14 / January / 2015, 17:04:12 »
Updated patch:
- Games and Tools menu contents loaded the first time the menu is accessed (instead of at CHDK startup).
- Move all EyeFi code and menus into module (add support for submenus in modules).
I like this version better. The small delay on first submenu access doesn't hurt and users only get the delay when actually accessing that part of the menu.
Can't comment much on EyeFi (its submenu is working and I do get the error boxes).

edit:
actually, I do have an idea: modules that implement a submenu should get the arrow in their menu entry (the module could store this information somewhere)
« Last Edit: 14 / January / 2015, 17:07:28 by srsa_4c »

*

Online philmoz

  • *****
  • 3332
    • Photos
Re: 1.4 development planning thread
« Reply #47 on: 15 / January / 2015, 03:01:04 »
edit:
actually, I do have an idea: modules that implement a submenu should get the arrow in their menu entry (the module could store this information somewhere)

Good idea, included in updated patch attached.

If there are no concerns with this I'll put it in SVN on the weekend.

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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)


*

Offline msl

  • *****
  • 1276
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: 1.4 development planning thread
« Reply #48 on: 15 / January / 2015, 07:15:30 »
If there are no concerns with this I'll put it in SVN on the weekend.

Agreed, I like that.

msl
CHDK-DE:  CHDK-DE links

*

Offline srsa_4c

  • ******
  • 4426
Re: 1.4 development planning thread
« Reply #49 on: 15 / January / 2015, 17:48:39 »
If there are no concerns with this I'll put it in SVN on the weekend.
Looks perfect now.
(I mean the arrow in the menu entry.)

I have almost finished porting the sx280 to current trunk. My current problems are:
- COLOR_TRANSPARENT and COLOR_BLACK
The frame buffer I'm drawing to is in a 16bpp YUV format. There is no palette (the firmware may use a palette somewhere but that doesn't matter).
I'm currently using 8 bits to represent a color (2 bits Y, 3 bits U and V), and unpack the color components in draw_pixel_std(). I plan to make a benchmark for this, perhaps a lookup table can be faster.
I'm not using transparency for speed reasons (transparency information is kept in a separate 8bpp frame buffer). And, of course, color 0xff is not black.
Would it make sense to export these 2 "colors" for the modules? Or, should I hardcode them in DIGIC 6 modules? I don't like the latter very much as the drawing method may change in the future.

- Multiple cameras using the same firmware
The sx280 port is also usable on the sx270 and sx275 models (they have the exact same firmware). This problem is not new, but 3 is a new record. Should I add 2 identical ports or could we do something else about this?

edit:
clarified my first sentence
« Last Edit: 15 / January / 2015, 17:55:13 by srsa_4c »

 

Related Topics