1.4 development planning thread - page 5 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 20   Go Down

1.4 development planning thread

  • 195 Replies
  • 69370 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #40 on: 07 / January / 2015, 19:17:47 »
Advertisements
Quote from: philmoz on 07 / January / 2015, 17:07:08
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 »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #41 on: 07 / January / 2015, 19:37:13 »
Quote from: srsa_4c on 07 / January / 2015, 19:17:47
Quote from: philmoz on 07 / January / 2015, 17:07:08
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.
Logged
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

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #42 on: 07 / January / 2015, 19:52:51 »
Quote from: philmoz on 07 / January / 2015, 19:37:13
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.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #43 on: 13 / January / 2015, 18:37:51 »
Quote from: philmoz on 05 / January / 2015, 04:03:40
- 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.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #44 on: 13 / January / 2015, 18:59:59 »
Quote from: srsa_4c on 13 / January / 2015, 18:37:51
Quote from: philmoz on 05 / January / 2015, 04:03:40
- 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.
Logged
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 philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #45 on: 14 / January / 2015, 03:58:21 »
Quote from: philmoz on 13 / January / 2015, 18:59:59
Quote from: srsa_4c on 13 / January / 2015, 18:37:51
Quote from: philmoz on 05 / January / 2015, 04:03:40
- 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.
Logged
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

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #46 on: 14 / January / 2015, 17:04:12 »
Quote from: philmoz on 14 / January / 2015, 03:58:21
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 »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #47 on: 15 / January / 2015, 03:01:04 »
Quote from: srsa_4c on 14 / January / 2015, 17:04:12
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.
Logged
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

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

Agreed, I like that.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #49 on: 15 / January / 2015, 17:48:39 »
Quote from: philmoz on 15 / January / 2015, 03:01:04
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 »
Logged
Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 20   Go Up
« previous next »
 

Related Topics