1.4 development planning thread - page 10 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 20   Go Down

1.4 development planning thread

  • 195 Replies
  • 81469 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #90 on: 30 / January / 2015, 16:41:23 »
Advertisements
Quote from: srsa_4c on 30 / January / 2015, 16:14:29
Quote from: philmoz on 29 / January / 2015, 19:30:33
I think this sort of control / definition should go in a new makefile.inc in the camera directory instead of the firmware sub directory (it applies to the camera model, not just one version).

If we then add the following to makefile_base.inc (after the other includes at the top) it should work (note I haven't tested this yet).
Edit: Put this after the shortcut definitions so $(cam) is defined, and move the definition of $O to after this include.
Code: [Select]
ifdef PLATFORM
  -include $(cam)/makefile.inc
endif
Thanks, that seems to fix the compilation issue (only tried 'make fir' so far, batch targets are still todo).
I just found another issue: the text file reader locks up the camera. When started, it starts repeatedly redrawing the whole screen. I can leave it successfully with the ALT button, but the camera locks up if I press the MENU button.
Rev. 3449 doesn't redraw continuously, it just loses the border right after start. It also doesn't crash the camera.
I suspect that the guard pixel-thing has been enabled somehow for this module since r3449. No idea why it locks up. Issue is independent of the recent makefile rework.
The text reader is working normally on a different camera.

Ok, I'll add support for the camera makefile.inc to SVN later.

The text reader is probably the draw_set_guard/draw_test_guard code not working correctly. If you always return 1 from draw_test_guard does the flickering stop?

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 #91 on: 30 / January / 2015, 16:50:39 »
Quote from: philmoz on 30 / January / 2015, 16:41:23
The text reader is probably the draw_set_guard/draw_test_guard code not working correctly. If you always return 1 from draw_test_guard does the flickering stop?
Yes. The lock-up on MENU also goes away.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #92 on: 01 / February / 2015, 17:59:39 »
Quote from: srsa_4c on 30 / January / 2015, 16:14:29
the text file reader locks up the camera. When started, it starts repeatedly redrawing the whole screen. I can leave it successfully with the ALT button, but the camera locks up if I press the MENU button.
I suspect that the lockup indicates an actual bug. Is it possible that the module can be unloaded while it's still busy redrawing the screen?
I haven't yet been able to test this on a different camera due to another bug: the text file reader doesn't "accept" any rbf fonts, falls back to the default font (on current 1.4).
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #93 on: 01 / February / 2015, 21:36:19 »
Quote from: srsa_4c on 01 / February / 2015, 17:59:39
I haven't yet been able to test this on a different camera due to another bug: the text file reader doesn't "accept" any rbf fonts, falls back to the default font (on current 1.4).
This went missing after release 1.0 (!!).

Patch for gui_read.c, not sure if it's completely correct, but it does seem to work.
Code: [Select]
Index: .
===================================================================
--- . (revision 3968)
+++ . (working copy)
@@ -84,8 +84,10 @@
     w=camera_screen.disp_width-6-6-8;
     h=camera_screen.height-y;
     last_time = get_tick_count();
-   
- reader_is_active=1;   
+
+    rbf_load_from_file(conf.reader_rbf_file, conf.reader_codepage);
+
+    reader_is_active=1;   
     old_mode = gui_set_mode(&GUI_MODE_READ);
 
     return (read_file >= 0);
And... I managed to reproduce the text reader lock-up on the a3200, so there indeed is a bug. A module should not be unloaded when its draw function is active.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #94 on: 01 / February / 2015, 22:23:29 »
Quote from: srsa_4c on 01 / February / 2015, 21:36:19
Quote from: srsa_4c on 01 / February / 2015, 17:59:39
I haven't yet been able to test this on a different camera due to another bug: the text file reader doesn't "accept" any rbf fonts, falls back to the default font (on current 1.4).
This went missing after release 1.0 (!!).

Can't be many people using RBF fonts with the text reader if it's been broken that long :)

Quote
And... I managed to reproduce the text reader lock-up on the a3200, so there indeed is a bug. A module should not be unloaded when its draw function is active.

True; but very complex to do correctly in all cases.

Simple 'fix' would be to check the 'reader_is_active' variable in the inner loop of 'gui_read_draw' and exit the function if it is 0.

The code is also reading 100 characters from the input file for every line drawn, even if the line is not that long. Since there is a limit to the number of chars that can fit on the screen it might be better to read a 'screenful' once instead of reading on every line. The file reading might also be better done in the keyboard task, and only read from the file when the scroll position changes.

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 #95 on: 02 / February / 2015, 16:34:57 »
Quote from: philmoz on 01 / February / 2015, 22:23:29
Can't be many people using RBF fonts with the text reader if it's been broken that long :)
Well, the module used whatever was selected as menu font ... including RBF fonts.

Quote
True; but very complex to do correctly in all cases.

Simple 'fix' would be to check the 'reader_is_active' variable in the inner loop of 'gui_read_draw' and exit the function if it is 0.
I'm thinking about something else: what if we protect the following (gui_redraw() in gui.c) with a semaphore?
Code: [Select]
    if (gui_mode->redraw)
        gui_mode->redraw(flag_gui_enforce_redraw);We could then use the same semaphore to protect this (module_tick_unloader(), module_load.c):
Code: [Select]
            if (modules[idx].hdr->_module_info->lib->can_unload())
                module_unload_idx(idx);If I'm not mistaken, the module can't unload itself, it can only request that.
Quote
The code is also reading 100 characters from the input file for every line drawn, even if the line is not that long. Since there is a limit to the number of chars that can fit on the screen it might be better to read a 'screenful' once instead of reading on every line. The file reading might also be better done in the keyboard task, and only read from the file when the scroll position changes.
I've never been satisfied with the reader either (I don't like that long lines are forcibly wrapped), but I'm not sure if I could make it better.

edit:
The module continues to lock the camera when MENU is pressed while it's drawing the text, despite the above mentioned semaphore protection.
« Last Edit: 02 / February / 2015, 18:11:07 by srsa_4c »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #96 on: 03 / February / 2015, 04:55:55 »
Quote from: srsa_4c on 02 / February / 2015, 16:34:57
Quote from: philmoz on 01 / February / 2015, 22:23:29
Can't be many people using RBF fonts with the text reader if it's been broken that long :)
Well, the module used whatever was selected as menu font ... including RBF fonts.

Quote
True; but very complex to do correctly in all cases.

Simple 'fix' would be to check the 'reader_is_active' variable in the inner loop of 'gui_read_draw' and exit the function if it is 0.
I'm thinking about something else: what if we protect the following (gui_redraw() in gui.c) with a semaphore?
Code: [Select]
    if (gui_mode->redraw)
        gui_mode->redraw(flag_gui_enforce_redraw);We could then use the same semaphore to protect this (module_tick_unloader(), module_load.c):
Code: [Select]
            if (modules[idx].hdr->_module_info->lib->can_unload())
                module_unload_idx(idx);If I'm not mistaken, the module can't unload itself, it can only request that.
Quote
The code is also reading 100 characters from the input file for every line drawn, even if the line is not that long. Since there is a limit to the number of chars that can fit on the screen it might be better to read a 'screenful' once instead of reading on every line. The file reading might also be better done in the keyboard task, and only read from the file when the scroll position changes.
I've never been satisfied with the reader either (I don't like that long lines are forcibly wrapped), but I'm not sure if I could make it better.

edit:
The module continues to lock the camera when MENU is pressed while it's drawing the text, despite the above mentioned semaphore protection.

I suspect the problem is because the 'MENU' press closes the input file; but the draw loop keeps blindly reading from the now closed file. This happens before the module unloader code tries to unload the module.

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 #97 on: 03 / February / 2015, 17:36:52 »
Quote from: philmoz on 03 / February / 2015, 04:55:55
I suspect the problem is because the 'MENU' press closes the input file; but the draw loop keeps blindly reading from the now closed file. This happens before the module unloader code tries to unload the module.
Yeah, I should have started looking at that instead of making up something else. I have committed a fix (trunk only for now, in case someone sees it as problematic).
I guess this
Quote from: srsa_4c on 01 / February / 2015, 21:36:19
A module should not be unloaded when its draw function is active.
issue is much less likely causing trouble. Even if the memory is freed, it does not necessarily gets allocated (and overwritten) instantly.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #98 on: 10 / February / 2015, 18:55:19 »
Attached is a patch for the palette viewer module. The biggest change is that the cell size is calculated at runtime, which gives acceptable appearance at bigger resolutions. I have altered the layout slightly to help with resizability. A few additional areas are painted to cover holes visible at higher resolutions. I did not touch the "CHDK color test" part because that already scales well.
This change is meant to be part of the DIGIC 6 support. I'd like to check it in later if I hear no complaints.

edit:
I have checked in an improved version, tested @ 360x240 and 640x480 resolutions.
« Last Edit: 11 / February / 2015, 17:55:40 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #99 on: 04 / March / 2015, 19:03:08 »
I stumbled into a problem related to batch operations.

I'm currently considering using a single camera_list.csv file for all cameras (my previous attempts on separated camera lists did not end up well). In case of a batch build that also includes Thumb-2 cameras, 2 separate sets of modules are needed. The current zip targets expect a fully populated directory structure under the CHDK/ directory, including the modules at their intended place.
I've been considering some possible ways to solve this:

- give thumb-2 modules a different file extension
 This would allow having both kind of modules in CHDK/MODULES at the same time. Thumb cameras would get the thumb modules, thumb-2 cameras would get the thumb-2 ones in their zip files.
 One complication I could think of is that the modules' makefile would need to be rewritten to support building modules with a different extension (while retaining a single module list). Another complication is that all use of ".flt" would need to be changed in the CHDK source as well.

- place thumb-2 modules in a different directory
 Problems: I can't come up with a suitable directory name and the CHDK source would need to be changed to use the architecture-dependent directory.

- clean CHDK/MODULES and copy the appropriate modules there in the rules for the firzip* targets
 Problems: lots of additional copying, it would also kill auto_build_parallel.sh

- place thumb-2 cameras at the end of camera_list.csv, build thumb and thumb-2 cameras separately
 Problems: supporting this would require an extensive rework of the build process (including the "build all cameras simultaneously" shell script).

Finally, a different kind of problem: existing arm-elf toolchains (such as those on the autobuild server(s)) won't be able to build thumb-2 source successfully. How should this be dealt with?

Here's the current state of the thumb-2 working patch (as the above suggests, batch operations are not working properly), I tried to include changes from make_target_v2.diff, it might not be completely correct.

Any advice is welcome.
Logged
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 20   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal