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

1.4 development planning thread

  • 195 Replies
  • 81561 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #130 on: 17 / August / 2015, 16:41:41 »
Advertisements
Thank you for the review.
Quote from: reyalp on 17 / August / 2015, 01:44:51
* loader/sx280/check_compat.c looks like it shouldn't be sx280 specific. It would be good to enable the bin compat checks for other cameras in 1.4 if we can.
That would be my plan too, but
- the camera database inside (pid_leds[]) was made by hand and may miss a few entries. Eventually, I'd like to make this part auto-generated from a central database, such as an expanded camera_list.csv. That would avoid having to hand-edit yet another file when adding a new port.
- I'm still undecided about the action we should take when the compat check fails. We could, for example, switch off the camera, if we know how (I was experimenting with finding the equivalent of the "TurnOffE1" eventproc, but could not reach 100% detection rate and subcpu cameras need a working OS for that call).
- We have quite a few ports where the direct LED control method or the LED address is not known (because no-one has tested it). Some LEDs need to be controlled specially (for example, some old cameras need 2 GPIOs for the print LED), so choosing a known LED address does not guarantee 100% success.
Quote
* benchmark module change is unrelated to d6/sx280. It seems fine, no reason not to have it in trunk.
I'm not completely satisfied with this one either, due to the unfinished UI. The hidden options should probably be made visible somehow - I got stuck on this (there's not much screen space left and translations may need to be considered).
Quote
* is the d6 longjump code tested? errors in lua should exercise it, in something like chdkptp  =return pcall(function() error('test') end
=return pcall(function() error('test') end) returns the same on sx280 and a3200, so I guess it does work. Note that lib/lua/setjmp.S comes from newlib 2.1, as is.
Quote
* update_screen_dimensions in mode_get seems like it leaves a window where CHDK could try to draw after the dimensions have changed, but before it has noticed the change. Could be OK, but maybe a risk of writing over things you shouldn't. Not clear how you'd avoid this completely if it were really a problem.
This is not a problem, because the overlay buffers are static (address and size) and not shared with anything else. DIGIC 4+ cameras may need this too (if someone wishes readable CHDK display on an output device other than the LCD).
I have noted the sx280 "cleanup" list.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #131 on: 29 / August / 2015, 15:27:31 »
I figured it would be useful if I posted an update of the d6 patch.
The recent eabi fix is not needed on a Thumb-2 firmware, so I took appropriate measures.
I also had to change the core to introduce another RAW restriction. The cpuinfo change is not included.
Logged
*

Offline reyalp

  • ******
  • 14133
Re: 1.4 development planning thread
« Reply #132 on: 30 / August / 2015, 16:53:37 »
Quote from: srsa_4c on 29 / August / 2015, 15:27:31
I figured it would be useful if I posted an update of the d6 patch.
The recent eabi fix is not needed on a Thumb-2 firmware, so I took appropriate measures.
I also had to change the core to introduce another RAW restriction. The cpuinfo change is not included.
Thanks.

I would like to get this in the trunk soon, especially before anyone starts real work on another digic 6 cam. I'm satisfied the impact on on pre-digic 6 cameras and the main autobuild is not a problem. Minor stuff like the UI in the benchmark module can be dealt with later.

chdkshell will be broken. I sent a note to whim yesterday asking if he wants to continue supporting it, but haven't heard anything back yet.

I'm inclined to check in the digic 6 code anyway. chdkshell has been more or less broken for a long time, and unless someone wants to maintain it, we need to move on. It may be possible to come up with a minimal replacement that is more maintainable, I believe adong has done some work in this direction. A simple, standalone way to get a working toolchain and source solves ~90% of the problem. I might be able to fix chdkshell eventually, but I don't want to hold up 1.4 while I try to grok 10k lines of autoit.

If I don't hear anything else my plan is to check in the digic 6 code by the end of the next week. If anyone disagrees with this, please post.

The chdkde autobuild may also be affected if it does anything with camera_list.csv outside of the main build process.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14133
Re: 1.4 development planning thread
« Reply #133 on: 30 / August / 2015, 17:17:40 »
Waterwingz asked
Quote
Do you have a proposed timeline for 1.4 release ?
My preference is to have a couple of weeks of release stabilization / release candidate phase after the d6 code is merged. The actual difference in this phase will mostly be that I will edit the wiki to recommend 1.4 and direct people to the testing needed page.

One open question is whether the autobuild is switched to EABI for 1.4. If not, then it will either need two different compilers at some point down the road, or the "stable" will switch compilers.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: 1.4 development planning thread
« Reply #134 on: 30 / August / 2015, 17:27:12 »
Quote from: reyalp on 30 / August / 2015, 17:17:40
One open question is whether the autobuild is switched to EABI for 1.4. If not, then it will either need two different compilers at some point down the road, or the "stable" will switch compilers.
I have not really followed the issues with EABI closely.  Can you summarize?  Is it just an issue for the DIGIC6 cameras or more to do with keeping up with the gcc platform?  Or ??
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14133
Re: 1.4 development planning thread
« Reply #135 on: 30 / August / 2015, 17:55:17 »
Quote from: waterwingz on 30 / August / 2015, 17:27:12
Is it just an issue for the DIGIC6 cameras or more to do with keeping up with the gcc platform?
Both. Since gcc dropped support for elf in 4.8, we will need to switch eventually. Relevant thread http://chdk.setepontos.com/index.php?topic=12115.0  (I think there were actually some gcc versions that supported thumb2 + elf, but the current work has all been done using EABI compilers.)

The newer compilers also generate noticeably smaller code.
Logged
Don't forget what the H stands for.
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: 1.4 development planning thread
« Reply #136 on: 31 / August / 2015, 07:55:15 »
Quote from: reyalp on 30 / August / 2015, 16:53:37
chdkshell has been more or less broken for a long time ...

The chdkde autobuild may also be affected if it does anything with camera_list.csv outside of the main build process.
Once again: the CHDK shell works fine. Only the automatic update functions are not available because all necessary links are dead. The compiling works very well, also the EABI option.

Over the years the CHDK shell was a little bit 'overweight' because whim fulfilled all user wishes. This makes the maintenance of the program difficulty. But whim is back in town ...

rudi plans to provide the source code as zip file via CHDK-DE autobuild server. So should then be eliminated some difficulties.

The CHDK-DE autobuild works already with gcc 4.8.3.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline reyalp

  • ******
  • 14133
Re: 1.4 development planning thread
« Reply #137 on: 01 / September / 2015, 00:16:59 »
Quote from: msl on 31 / August / 2015, 07:55:15
Over the years the CHDK shell was a little bit 'overweight' because whim fulfilled all user wishes. This makes the maintenance of the program difficulty. But whim is back in town ...

rudi plans to provide the source code as zip file via CHDK-DE autobuild server. So should then be eliminated some difficulties.
This sounds like a good solution, and many thanks to rudi for providing it.

My plan is still to check in the d6 code by the end of the week. CHDK shell building of the trunk will be broken until it's updated to handle the new CSV and any other problems with the new makefile. Building from the command prompt should still work, as should building 1.3.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14133
Re: 1.4 development planning thread
« Reply #138 on: 05 / September / 2015, 02:05:10 »
I checked the patch from #131 in as is.

Some outstanding items

* decide what to do with bin_compat.h.
* benchmark module ui
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #139 on: 05 / September / 2015, 13:47:00 »
Quote from: reyalp on 05 / September / 2015, 02:05:10
I checked the patch from #131 in as is.
Thanks.

Quote
* decide what to do with bin_compat.h.
The files themselves can be removed from svn because they are generated during build (that was Phil's intention).
The compat check needs work, what I wrote previously still stands.
Quote
* benchmark module ui
I accept any ideas... The default settings and behaviour is the same as the old benchmark's.

edit
Quote from: reyalp on 17 / August / 2015, 01:44:51
* multiple definitions of KEY_ZOOM_* for the three different speeds doesn't seem ideal. There were additional keys defined for for SX30, which should let you script them or detect them individually.
Those are not currently used by any port, not sure why.
« Last Edit: 05 / September / 2015, 14:14:42 by srsa_4c »
Logged
Pages: 1 ... 9 10 11 12 13 [14] 15 16 17 18 19 20   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal