changelog of trunk including comments / devtalk - page 12 - General Discussion and Assistance - CHDK Forum

changelog of trunk including comments / devtalk

  • 298 Replies
  • 187152 Views
*

Offline reyalp

  • ******
  • 13443
Re: changelog of trunk including comments / devtalk
« Reply #110 on: 10 / June / 2012, 18:45:40 »
Advertisements
AFAIK the tools build does not require PLATFORM or PLATFORMSUB to be defined. There are no dependencies on these in any of the tools.
There better not be, or the theory of building the tools once is invalid.

Quote
The problem can be removed along with the warning messages with these changes.
Makefile:
Code: [Select]
alltools:
$(MAKE) -C tools PLATFORMOS=vxworks clean all
$(MAKE) -C tools PLATFORMOS=dryos clean all

makefile.inc
Code: [Select]
all-recursive:
ifndef SKIPBUILDRULES
ifndef PLATFORM
$(error PLATFORM has not been defined. Specify the PLATFORM to build on the command line or in localbuildconf.inc)
endif
ifndef PLATFORMSUB
$(error PLATFORMSUB has not been defined. Specify the PLATFORMSUB to build on the command line or in localbuildconf.inc)
endif
endif
    ...
My only concern with this would be if SKIPBUILDRULES is used elsewhere. Looks like the only place it's used outside of tools is modules. Probably if someone goes in there, and forgets to define platform, they can deal with the consequences.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13443
Re: changelog of trunk including comments / devtalk
« Reply #111 on: 06 / July / 2012, 22:30:42 »
I've moved the very old branches (allbest, cail, grand etc) out of branches to a new top level directory in svn called historical-branches. This keeps them available for reference but makes it clear they are mainly of historical interest. It should also keep chdkshell from checking them all out when you enable branches.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13443
Re: changelog of trunk including comments / devtalk
« Reply #112 on: 05 / August / 2012, 15:46:22 »
I'd still like a few more dryos testers for CAM_FIRMWARE_MEMINFO before I turn it on globally. The following have been tested and are now on by default: a590, sx20, g12, sx30 and d10.
Hey it's only been a bit over a year and no one has complained...

In trunk changeset 2056 I've turned on  CAM_FIRMWARE_MEMINFO for all dryos cams.

For vxworks, we need to find  sys_mempart_id for all the remaining cameras. This is easy to find, but not automated.

As srsa_4c observed http://chdk.setepontos.com/index.php?topic=650.msg88721#msg88721 this using this substantially improves CHDK ptp performance, so it's probably worth doing.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13443
bug in autoiso/live_histogram_process_quick
« Reply #113 on: 05 / August / 2012, 23:23:43 »
from histogram.c live_histogram_process_quick()
Code: [Select]
    viewport_size = vid_get_viewport_height() * vid_get_viewport_byte_width() * vid_get_viewport_yscale();
size of viewport, in bytes.
Code: [Select]
...
    viewport_size = (viewport_size<<1) + viewport_size + 1; // quick *3 and adjust to starting from idx 1
3x (viewport size in bytes) + 1 ?

I think the 3x probably got missed in one of the viewport function reworks. The shift and add makes it less obvious. Given that this is used in a for loop that will do several thousand memory reads/writes, clarity is preferable to saving a single multiply.

The +1 "adjust" seems like it's just wrong, no matter what, we shouldn't go off the end of the viewport.

The consequence of this is that the quick histogram used by autoiso would have a lot of junk it. It is also a lot slower than it needs to be. I'm not sure what the actual impact on autoiso was, because I'm not really clear how it is supposed to work.

I've removed all the modifications to viewport_size in release changeset 2057 trunk changest 2058
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 13443
Re: changelog of trunk including comments / devtalk
« Reply #114 on: 07 / August / 2012, 02:53:47 »
In trunk changeset 2059 and changeset 2060, I've added support for getting a live view histogram in Lua.

Usage
histogram,total=get_live_histo()

returns a histogram of Y values from the viewport buffer (downsampled by HISTO_STEP_SIZE)
histogram[Y value] = count, so it is zero based unlike a normal lua array
total is the total number of pixels, may vary depending on viewport size
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13443
Re: changelog of trunk including comments / devtalk
« Reply #115 on: 26 / August / 2012, 23:02:51 »
In trunk changeset 2104 I've added a workaround for a longstanding bug that would cause script Tv override of exactly 1 second to be ignored (it used 0 to check if there was an override, but APEX 0 is a 1 second exposure)

Note this only applied to script (and possibly USB remote ?), 1 second override in the menu always takes a different code path.

This should probably be back ported to 1.1, but I'd like some testing first.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13443
Re: changelog of trunk including comments / devtalk
« Reply #116 on: 27 / September / 2012, 16:09:27 »
I will be very busy until early next month and AFAIK philmoz is still away, so patch commits will be slower than usual.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13443
Re: changelog of trunk including comments / devtalk
« Reply #117 on: 07 / October / 2012, 18:57:55 »
In trunk changeset 2202 I've changed module loading to make it play safely (but not optimally) with the CPU data and instruction caches. The previous unsafe behavior appears to be the cause of the grid crash discussed here: http://chdk.setepontos.com/index.php?topic=6318.msg91537#msg91537

Since this affects all module usage, I'd like to have some testing before merging it over to the stable branch. The basic test is to start the camera in play mode and load a grid. With the old code, some (but not all) cameras will crash repeatably. With the new code, the should not. Aside from that test, exercising stuff in modules (dng, md, games, text view, file browser etc) would be good.

The previous code was unsafe because it would
1) read the module code into cached memory (via an uncached buffer for read(), but this isn't relevant because it isn't at the final address)
2) perform reloactions etc in cached memory
3) Execute the the code.
At this point, there is no guarantee all the data has been written from the data cache out to main memory. The instruction cache is separate, and there is no snooping, so if there was a miss, it would read main memory. If by chance the address was already in instruction cache (for example, a previous module was loaded there) that would also be a problem.

The updated code does the following after loading and relocating a module:
1) Flush the entire instruction cache, forcing any instructions to be fetched from RAM.
2) Clean the data cache, forcing any dirty values to be written out to RAM
3) Drains the write buffer, forcing the CPU to wait until any writes are complete

This is sub-optimal because it isn't necessary to flush and clean the entire caches. It is possible to clean and flush individual addresses, but it's not clear to me that this is necessarily better, depending on the size of the module it could take more iterations than operating on the entire cache. It's also not clear that the write buffer drain is required, but some similar code in the Canon firmware does this, so it seems like a good idea.

Assuming this diagnosis was correct, this probably also caused some other intermittent instability. The fact that it worked as well as it did makes me question whether the diagnosis is in fact correct :-[

Note that the current code assumes the data cache size is 8kb. This is true of every camera I've seen CPU info for (see here http://chdk.setepontos.com/index.php?topic=2139.msg20148#msg20148 )
It also will not work on cameras without cp15 (only srsas S1 port as far as we know, which is not in in the trunk anyway)

With a bit more work using cp15 cache control will also allow us to improve the handling of read()/write() and the umalloc/malloc issues.

On an unrelated note, I noticed assembla stopped sending me commit alerts for chdk. If this happened to you, and you want them back, you can go to the "stream" tab https://www.assembla.com/spaces/chdk/stream and click email notifications.

Also, I'm through the crunch mentioned in the previous post.
Don't forget what the H stands for.


Re: changelog of trunk including comments / devtalk
« Reply #118 on: 07 / October / 2012, 22:13:50 »
Since this affects all module usage, I'd like to have some testing before merging it over to the stable branch. The basic test is to start the camera in play mode and load a grid. With the old code, some (but not all) cameras will crash repeatably. With the new code, the should not. Aside from that test, exercising stuff in modules (dng, md, games, text view, file browser etc) would be good.
In addition to the successful results for the A1200 report on IRC today,  I checked the G10.  All the items listed above load and operate correctly.

Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline msl

  • *****
  • 1276
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: changelog of trunk including comments / devtalk
« Reply #119 on: 08 / October / 2012, 05:10:21 »
In trunk changeset 2202 I've changed module loading to make it play safely (but not optimally) with the CPU data and instruction caches. The previous unsafe behavior appears to be the cause of the grid crash discussed here: http://chdk.setepontos.com/index.php?topic=6318.msg91537#msg91537

Good work.

I had the same problem with loading of curve files in play mode. (Hint: I have reworked a very old curve patch for 10 and 12 bit raw provided by CHDKLover  in 2010 - see here: http://forum.chdk-treff.de/viewtopic.php?f=7&t=1889&start=60#p26541)

With the recent revision I can load curve files without a crash of the camera in play mode (SX220).

msl
CHDK-DE:  CHDK-DE links

 

Related Topics