new branch - CHDK : Elf Edition - Developers wanted - page 30 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 25 26 27 28 29 [30] 31 32   Go Down

new branch - CHDK : Elf Edition - Developers wanted

  • 316 Replies
  • 99205 Views
*

Offline srsa_4c

  • ******
  • 4450
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #290 on: 02 / December / 2014, 19:35:27 »
Advertisements
Quote
One thing I noticed is that, although the file browser allows selecting a .FLT file from anywhere on the card, it will only be run if it lives in the A/CHDK/MODULES directory.
I remember this causing me confusion when I was making small changes to one of my modules. Custom simple modules could only be run from the file browser at that time, so I simply placed the module in the card root for fast access. Then, no matter what I tried to solve a particular bug, I was getting the same results after every modification. Then I found out that I was running the same old module from CHDK/MODULES and not the updated one in card root...

Quote
I think this is a side effect of changes I made to this part of the module loader a when I added the auto-load / unload stuff.

I can see two options:
1 - simplify the code and only allow modules to be loaded from A/CHDK/MODULES, add warning in file browser if selecting a .FLT from somewhere else.
2 - fix the code and allow loading modules from anywhere in the file browser, may require some additional memory

I vote for option 1.
For option 1): would it be possible to allow "installing" a module on first execution attempt if it isn't present in CHDK/MODULES or newer than the existing one? Just an idea though.
The instructions to run an external module might be a bit complicated for novice users.

The other proposed changes are welcome.

One more note: this isn't the time yet to change the codebase for DIGIC 6 support, but please take into consideration that DIGIC 6 modules will likely be built separately (due to hw division support), modules will have to carry this information to disallow loading on wrong architectures.
Logged
*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #291 on: 03 / December / 2014, 03:03:11 »
Patch with modules changes (see previous posts).

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

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #292 on: 03 / December / 2014, 03:24:52 »
Quote from: srsa_4c on 02 / December / 2014, 19:35:27
One more note: this isn't the time yet to change the codebase for DIGIC 6 support, but please take into consideration that DIGIC 6 modules will likely be built separately (due to hw division support), modules will have to carry this information to disallow loading on wrong architectures.

For runtime, I suspect this would be easiest with a new version check entry in the ModuleInfo structure. Not sure exactly how the options would be defined.

This complicates the build process as well - at the moment modules are built once for all cameras. This would also apply to all the code compiled once in the libraries. We will need a way to build Digic6 libraries and modules separate from the existing ones.

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

  • ******
  • 4450
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #293 on: 03 / December / 2014, 19:48:38 »
Quote from: philmoz on 03 / December / 2014, 03:24:52
For runtime, I suspect this would be easiest with a new version check entry in the ModuleInfo structure. Not sure exactly how the options would be defined.
The easiest way would probably be a file extension other than .flt. If we decide for a new entry in ModuleInfo, it could be CPU architecture (0 for armv5, 1 for armv7)...

Quote
This complicates the build process as well - at the moment modules are built once for all cameras. This would also apply to all the code compiled once in the libraries. We will need a way to build Digic6 libraries and modules separate from the existing ones.
My "fork" has no solution for this at the moment, it just allows build for the new architecture. I'm also using a different toolchain (arm-none-eabi), because arm-elf is no longer supported in newer gcc versions. Build is OK on linux 32bit and emulated Win32, no idea about the rest.

Anyway, to stay on topic: a short test on one of my cams did not reveal any problems when using your module rework patch. Is there something particular that needs to be tested?
Logged
*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #294 on: 04 / December / 2014, 02:42:02 »
Quote from: srsa_4c on 03 / December / 2014, 19:48:38
Anyway, to stay on topic: a short test on one of my cams did not reveal any problems when using your module rework patch. Is there something particular that needs to be tested?

Nothing specific, just want to make sure it gets tested by other people. We all do things a bit differently, so if I've made any mistakes someone else might pick it up.

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

  • ******
  • 4450
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #295 on: 04 / December / 2014, 17:19:45 »
To test the changes with something else, I have rebuilt my memory browser module with the patched source. The module works fine.
Logged
*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #296 on: 05 / December / 2014, 16:08:35 »
Quote from: srsa_4c on 04 / December / 2014, 17:19:45
To test the changes with something else, I have rebuilt my memory browser module with the patched source. The module works fine.

Thanks for testing.

I'm comfortable the changes don't break anything so I'll put this in SVN over 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 srsa_4c

  • ******
  • 4450
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #297 on: 17 / February / 2015, 17:31:23 »
I have experienced a crash on one of my cameras when I attempted to view a text file from the file browser. The camera locked up with approx. 2 lines of text drawn. Unfortunately, I don't remember the exact details, but I think the text was not from the selected file (I think it may have been the CHDK menu). It was the CHDK menu. It was drawn with the text reader's selected rbf font.

What I'm suspecting is that gui_read_init() in gui_read.c (context: PhySw) was executed while the previous module's drawing operation (context: SpyTask) was in progress. Since (AFAIK) CHDK can only use one RBF font at a time, the old draw routine picked it up while drawing.

Does that make any sense? If so, then we'll need to prevent this scenario from happening.

edit:
I guess I could work around this specific problem by loading the font in the drawing routine of gui_read.c, but I'm still concerned that the underlying issue may cause other problems.

edit2:
Text reader fixed in these commits: 4018, 4019.
« Last Edit: 18 / February / 2015, 18:10:54 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4450
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #298 on: 21 / February / 2015, 09:38:27 »
I'd like to add build-system support for optional "local" modules. I have some locally maintained modules that are unsuitable for inclusion in official source (mostly due to code quality). Currently, whenever I need them, I have to add them to the module makefile. Since my svn working copies usually also have other changes which I may want to commit sometimes, having unofficial changes laying around is a risk.

The proposed patch adds support for local modules: it introduces a new optional makefile include (modules/makefile_usermodules.inc).
Local modules can be added to the build by adding the .flt names to the USER_FLTS make variable. The module source files go in the modules directory.
Here's an example makefile_usermodules.inc:
Code: [Select]
USER_FLTS=$Omemdmper.flt $Omemview2.fltThe patch is rather simplistic: it requires source files to have the same name as the module name. It's also likely not optimal, for example I haven't yet been able to get rid of $O in USER_FLTS. The only supported module type is simple modules.

Since I'm by no means an expert in makefile writing, I won't commit this unless another developer says it's OK. Of course, I gladly accept any comments on improvement.

Code: [Select]
Index: modules/Makefile
===================================================================
--- modules/Makefile (revision 4030)
+++ modules/Makefile (working copy)
@@ -9,6 +9,10 @@
     OBJ_ISDIGIT+= $(llibc)/$Oissmth.o
 endif
 
+define user_flt_rule
+$(1): $(patsubst %.flt, %.o, $(1))
+endef
+
 CFLAGS+=-fno-reorder-functions
 
 LDOPTS=-nostdlib -Wl,--allow-shlib-undefined -Wl,-T,$(tools)/link-boot.ld -Wl,-N,-Ttext,0x24 -r -Wl,-d
@@ -20,6 +24,12 @@
      $Otxtread.flt $Omemview.flt $Omodinsp.flt $Otetris.flt $Osnake.flt $Osudoku.flt $O_tbox.flt $O_osd_le.flt \
      $O_hexbox.flt $Oubasic.flt $Olua.flt $Ocpuinfo.flt $Ouseredit.flt $Oeyefi.flt $Ohisto.flt $Oshothist.flt
 
+-include makefile_usermodules.inc
+
+ifdef USER_FLTS
+    FLTS+=$(USER_FLTS)
+endif
+
 all: $(FLTS)
 
 $O%.flt: $(llibc)/$Olibc.a
@@ -37,6 +47,11 @@
  @echo $< \-\> $@
  $(CC) $(CFLAGS) -nostdinc -c -o $@ $<
 
+# create rules for user defined flts loaded from makefile_usermodules.inc
+ifdef USER_FLTS
+$(foreach userflt,$(USER_FLTS),$(eval $(call user_flt_rule, $(userflt))))
+endif
+
 $Onothumb.o: nothumb.c
  @echo $< \-\> $@
  $(CC) $(CFLAGS) -marm -nostdinc -c -o $@ $<
Logged
*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #299 on: 21 / February / 2015, 16:45:10 »
Great idea :)

Slightly different approach.
This is more generic, the rules for your modules are confined to the new makefile and can include other files if needed. The $O is required to set the output directory.
 
Code: [Select]
FLTS+=$Omemdmper.flt $Omemview2.flt

$Omemdmper.flt: $Omemdmper.o
$Omemview2.flt: $Omemview2.o

Code: [Select]
Index: modules/Makefile
===================================================================
--- modules/Makefile (revision 4030)
+++ modules/Makefile (working copy)
@@ -20,6 +24,12 @@
      $Otxtread.flt $Omemview.flt $Omodinsp.flt $Otetris.flt $Osnake.flt $Osudoku.flt $O_tbox.flt $O_osd_le.flt \
      $O_hexbox.flt $Oubasic.flt $Olua.flt $Ocpuinfo.flt $Ouseredit.flt $Oeyefi.flt $Ohisto.flt $Oshothist.flt
 
+-include makefile_usermodules.inc
+
 all: $(FLTS)
 
 $O%.flt: $(llibc)/$Olibc.a

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)
Pages: 1 ... 25 26 27 28 29 [30] 31 32   Go Up
« previous next »
 

Related Topics