A4000IS porting thread - page 19 - DryOS Development - CHDK Forum supplierdeeply

A4000IS porting thread

  • 205 Replies
  • 38080 Views
Re: A4000IS porting thread
« Reply #180 on: 24 / October / 2013, 22:20:08 »
Advertisements
Only one raw buffer.

The camera is 16 megapixel so a raw image requires 24MB of memory.
There is only 64MB of RAM in the camera, and once you take out all the memory needed by the firmware, it's unlikely there would be enough left for another raw buffer.

Well, it was worth asking (there could have been two).  The reported free memory is tiny, under 900K. Is there a video or JPEG buffer that I can hijack if I'm careful?  Basically, I need a reasonable space for keeping state that I'm tracking instead of processing raw images in the usual ways. Even a few MB would make a huge difference....  Any ideas?

Re: A4000IS porting thread
« Reply #181 on: 24 / October / 2013, 22:22:44 »
A regular malloc won't do it?

never mind ...
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 12540
Re: A4000IS porting thread
« Reply #182 on: 25 / October / 2013, 00:01:14 »
Well, it was worth asking (there could have been two).  The reported free memory is tiny, under 900K.
Assuming you are going by the "show memory info" menu, this is the size of the CHDK heap. Depending on your configuration, this may be the same as the Canon firmware heap, or a separate heap allocated in "exmem"

According to makefile.inc, the default  configuration for a4000 is the for CHDK to use exmem, with a size of 1mb (but the CHDK executable takes some of this as well).

You try increasing EXMEM_BUFFER_SIZE, but things might break.

The available canon firmware heap is likely to be quite a bit less then 900kb.

See this thread http://chdk.setepontos.com/index.php?topic=5980.0 for the history of the exmem system.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4221
Re: A4000IS porting thread
« Reply #183 on: 25 / October / 2013, 12:46:36 »
According to rkomar's report it's possible to use CHDK without EXMEM on this camera (actually, it would be good if someone else could confirm this and we could get rid of the forced EXMEM configuration for good - CHDK should not cause potential JPEG corruption...).

In an EXMEM-less configuration, it should be possible to use EXMEM memory (edit: as statically allocated memory), at least the amount shown in platform/a4000/sub/.../makefile.inc EXMEM_BUFFER_SIZE + EXMEM_HEAP_SKIP. The upper part (length = EXMEM_HEAP_SKIP) of the EXMEM area can however get corrupted (not sure when, maybe during video recording?), so tests are required.
« Last Edit: 25 / October / 2013, 13:04:58 by srsa_4c »


Re: A4000IS porting thread
« Reply #184 on: 26 / October / 2013, 09:46:34 »
According to rkomar's report it's possible to use CHDK without EXMEM on this camera (actually, it would be good if someone else could confirm this and we could get rid of the forced EXMEM configuration for good - CHDK should not cause potential JPEG corruption...).

In an EXMEM-less configuration, it should be possible to use EXMEM memory (edit: as statically allocated memory), at least the amount shown in platform/a4000/sub/.../makefile.inc EXMEM_BUFFER_SIZE + EXMEM_HEAP_SKIP. The upper part (length = EXMEM_HEAP_SKIP) of the EXMEM area can however get corrupted (not sure when, maybe during video recording?), so tests are required.

Oh, so that's where the bad JPEGs are coming from....  About 1 out of 4 JPEGs seem to be corrupted, although raws are ok.

If I don't put CHDK in EXMEM, if I'm following this right, it looks like I'd have a little less than 4MB of working space using the 101b firmware. I don't think corruption would be much of an issue for my use, because I'd really just be using the extra memory for time-domain compression of a (potentially infinite) sequence of raw captures to be sent to a host computer via USB. In other words, there really wouldn't be anything but unsaved raw capture and USB traffic going on while I need the space to remain uncorrupted.

In fact, the EXMEM_HEAP_SKIP area by itself is nearly 3MB, so if I could just use that, perhaps I wouldn't even need to move CHDK out of EXMEM?  Would that be likely to work? If so, I assume I'd just set a pointer to the base address of that region (what would that be?) and just use it as temp space. Actually, if necessary, I could even save the region to SD beforehand and restore it after my raw stream has been processed.

*

Offline reyalp

  • ******
  • 12540
Re: A4000IS porting thread
« Reply #185 on: 26 / October / 2013, 17:04:44 »
If I don't put CHDK in EXMEM, if I'm following this right, it looks like I'd have a little less than 4MB of working space using the 101b firmware.
I'm not sure where you get 4mb from. The current configuration is 1MB, but you might be able to use more.
Quote
I don't think corruption would be much of an issue for my use, because I'd really just be using the extra memory for time-domain compression of a (potentially infinite) sequence of raw captures to be sent to a host computer via USB. In other words, there really wouldn't be anything but unsaved raw capture and USB traffic going on while I need the space to remain uncorrupted.

In fact, the EXMEM_HEAP_SKIP area by itself is nearly 3MB, so if I could just use that, perhaps I wouldn't even need to move CHDK out of EXMEM?  Would that be likely to work?
If you don't record video, that should probably be OK. Of course, you should test... you could fill the memory with some sentinel value, run the same kind of shooting sequence your actual process will use, and then memcmp it.

Note if you do not put CHDK in exmem, you might need to use exmem alloc to prevent the canon firmware form using that region for other stuff.

If you just need temporary memory that doesn't need to persist between shots, you may be able to find other regions to use.
Quote
I'd just set a pointer to the base address of that region (what would that be?)
MAXRAMADDR+1 - EXMEM_HEAP_SKIP

I'll post a build of CHDK without exmem. If you can report the free memory using this build, that would be appreciated. The default autobuild really shouldn't corrupt jpegs...
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 12540
Re: A4000IS porting thread
« Reply #186 on: 26 / October / 2013, 17:19:38 »
Here's the test build.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4221
Re: A4000IS porting thread
« Reply #187 on: 26 / October / 2013, 17:51:42 »
@ProfHankD
Some additional notes on using EXMEM.
- If CHDK is compiled to use EXMEM, it will get the top of EXMEM region. If a custom build allocates EXMEM for different use, it will have to do so at the point where exmem_malloc_init() is called in core/main.c.
- EXMEM allocations are expanding downwards. If a certain allocation is freed, but there's another allocated chunk below it, the camera won't be able to use the "freed" chunk, until all allocated chunks below it are freed.
- A certain amount (1MB?) of EXMEM is allocated by the camera if USB is connected (and of course certain camera functions allocate/free various amounts of EXMEM for their use). That's why it's important to allocate EXMEM as early as possible.
- The code in & around exmem_malloc_init() (platform/generic/wrappers.c) can be modified to allocate memory without making CHDK use EXMEM.


Re: A4000IS porting thread
« Reply #188 on: 27 / October / 2013, 13:38:38 »

I'll post a build of CHDK without exmem. If you can report the free memory using this build, that would be appreciated. The default autobuild really shouldn't corrupt jpegs...

For that, the "Memory Info" says:

Free Memory: 649856 bytes
CHDK size: 145548 bytes
loaded at: 0x157CA4

The one from autobuild (with a few very minor tweaks) says:

Free Memory:  891408 bytes
CHDK size: 147104 bytes
loaded at: 0x3C24BE0

I still have to test using the EXMEM space during raw captures....

It certainly doesn't sound like loading CHDK into EXMEM should be necessary....

*

Offline reyalp

  • ******
  • 12540
Re: A4000IS porting thread
« Reply #189 on: 27 / October / 2013, 17:28:07 »
Thanks for confirming. I've updated both the trunk and stable branches not to default to exmem.
Don't forget what the H stands for.

 

Related Topics