CHDK Forum
CHDK Development => General Discussion and Assistance => DryOS Development => Topic started by: michi1911 on 28 / April / 2011, 16:33:23
-
Hi all,
I would like to start porting CHDK to ELP300HS also known as IXUS220HS in Europe.
whim and fe50 dumped the firmware at
http://www.box.net/chdk -> ixus220hs_elph300hs_100c.7z
and created
http://chdk.wikia.com/wiki/ELPH300
My IXUS220HS has same Version
"100C"
and the camera identifier
"0x3040000"
which is displayed in CameraVersion1.3 as "Unknown".
...have fun...
Michi
-
I tried to verify the standard procedures of CHDK development on my IXUS220HS and failed completely!?
1. I tried to format and use a "ver.req" FAT16 SD with 2GB.
-> No success pressing SET & DISPLAY, which is even a pain on this little camera with huge fingers ;)
2. I tried the same using CardTricks
-> No success
3. I tried to format a dump disk with CardTricks
-> No success
I've no idea where my error is...may the SET/DISPLAY keys are not the correct ones on my the 220HS?
...have fun...
Michi
-
Hi michi,
Some newer cams simply won't react to ver.req, but why do you need that ?
You already know your version, don't you ?
Now you will need to dump your firmware, you must use the Canon Basic scripts (attached)
How to use:
1. Start by formatting your card in the camera (save your pictures first !)
2. Copy the 2 tiny files to the ROOT of your card
3. Write the special "SCRIPT" signature to the boot sector
To do this, use Pelican's EOScard (http://pel.hu/down/EOScard.exe)
--- now put card back in camera
4. Start the cam in review mode (with the 'triangle' button, not on/off !)
5. A normal, short press of "Func/Set" starts the script: watch top left corner.
hope that helps,
wim
PS About CameraVersion: update exiftool to 8.5.6 to see the real name
[edited 30-04-11: it helps if instructions actually work ...]
-
Hi wim,
indeed I don't "need" it...
...I got the version from the JPEG with your tool...
...it was just a try to warm up the communication with the camera!
Same for the dump...I will try your steps next evening...its too late for me tonight...
Thx for your help, it is very welcome...
Michi
-
For the sx220 this is what I needed to do see the version:
-turn on camera in with PLAY button
-hold FUNC/SET until the clock appears
-hold FUNC/SET until the clock disappears, still hold and press DISP.
To run scripts:
-delete all photos from card
-turn on camera in with PLAY button
-press FUNC/SET
-
For the sx220 this is what I needed to do see the version:
-turn on camera in with PLAY button
-hold FUNC/SET until the clock appears
-hold FUNC/SET until the clock disappears, still hold and press DISP.
Hmmmh,,,,does not work in my IXUS220HS !?
May be that Canon has choosen different hotkeys because it is very hard to press SET and DISP simultaneously on the IXUS220HS.
...have fun...
Michi
-
PS About CameraVersion: update exiftool to 8.5.6 to see the real name
Great, that does the job.
thx...
Michi
-
Now you will need to dump your firmware, you must use the Canon Basic scripts (attached)
How to use:
1. Copy the 2 tiny files to the ROOT of your card
2. Write the special "SCRIPT" signature to the boot sector
To do this, use Pelican's EOScard (http://pel.hu/down/EOScard.exe)
--- now put card back in camera
3. Photograph something really white (this is optional, Canon Basic has a tendency to pick
weird colours for text, white gives you probably the best chance to read any output ....)
4. If you did take a picture, shut down the cam.
5. Start the cam in review (not shooting mode); select (if necessary) the white pic.
6. Press "Func/Set" to start the script.
hope that helps,
wim
PS About CameraVersion: update exiftool to 8.5.6 to see the real name
Hi wim,
I am doing something wrong running the scripts!?
Following your procedure, I can not get running the script on my cam!
Pressing the FUNC./SET Button displays a cube-digit-clock, but I've no indication that a script is started!?
No dump files on the card. no display indication...nothing.
Except the dump files...should there be a notification of a started script (LED, Display whatever?).
I looked into the basic script and saw that some text messages should be displayed!?
Maybe the script itself does not work on my cam?
You dumped the FW for the IXUS220HS already...how did you do that?
...have fun...
Michi
-
Sorry Michi,
I seem to have remembered wrongly how I dumped it, turns out there should be
no pictures on the card, or it won't work ... Move the 'DCIM' folder (temporarily)
somewhere else, and it should work, just tried.
On start-up in Review/play mode the screen will be black with a white edge and it'll say 'No image',
just give a short press on Func/set (i.e. no need to hold it) and watch the top left corner.
Start address (8 characters) will be written there, but since it's in black, it's unreadable.
Never mind though, when it's ready (a couple off seconds) it'll change to "done".
You can tell because the string written now is shorter. When you now check your
card, you should find your dump as "PRIMARY.BIN" .
sorry for the confusion,
wim
PS edited my previous post so as not to confuse even more people
-
Aaaaaaaaaaaaaaaaah,
that worked!
Part of the trick is to push the SET button shortly...I always hold it for long!
Additional Info, it works with:
1. 32GB SDcard
2. FAT32
3. The lock switch can be in no-lock position
Just for the case, that someone has doubts about these parameters...like I did.
...have fun...
Michi
-
It seems, that the text is written in black on the black "no picture" screen!
So only fragments in the white display frame are visible.
I have to look into the basic stuff to see check if it is possible to control the text attributes...
...have fun...
Michi
-
It works also with a DCIM Folder containing pictures.
In this case the "Done" message appears visible, when the background contrasts.
That are good news:
I well keep with the IXUS220HS because there is a good chance to get control as I need it for my microcopter ;)
Meanwhile the battery is exhausted and I have to charge it...which is also a good signal to do some outdoor activities...
c'ya l8a
Michi
-
Hi,
pretty simple patch:
According to http://chdk.wikia.com/wiki/Canon_Basic/Reference I added color control to the dumper script.
Adding "LCDMsg_ChangeColor(a,3)" before printing gives readable messages in the dumper script. (2 is orange).
private sub Initialize()
UI.CreatePublic()
a=LCDMsg_Create()
LCDMsg_ChangeColorEdit(a, 2)
LCDMsg_SetStr(a,"Running")
System.Create()
Now the progress can be observed, start address is prompted as expected and done is prompted after finishing.
The script can now be executed anytime, with or without pictures on the card, no deletion or copying of DCIM is required.
...have fun...
Michi
-
The reason I have not incorporated this in the dumper is that the colors are not consistent across cameras. Since we can never guarantee the messages are visible, it makes more sense just to write the information to the log file. A/CBDUMPER.LOG is used for this purpose.
I have updated the description of the script to be more clear on this point.
-
Yes, I agree!
The console output is not deterministically.
Sometimes the color is not adapted before printing, so this method is not reliable, file output is hopefully more stable.
I just wanted to figure out under which conditions the script is started and direct prompting is much easier than change the card permanently.
I use a dumper without output redirection...where is the offical version located?
...have fun...
Michi
-
I use a dumper without output redirection...where is the offical version located?
http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper (http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper)
-
Cool!
Looks good, will try it immediately!
Thx
Michi
Added: Works great! I like the style! May be useful to me as template for own scripts too!
-
The console output is not deterministically.
Sometimes the color is not adapted before printing, so this method is not reliable, file output is hopefully more stable.
Sorry if the following info is out of date - its been a while but I thought I'd post as it might be useful. As I only really needed to use the ROM dumper script once, I played with getting visible color. In the original dumper, this went right afer the LCDMsg_Create() like this :
a=LCDMsg_Create()
LCDMsg_SetStr(a,"SD940 Memory Dump")
LCDMsg_Move(a,100,100)
LCDMsg_ChangeColor(a,5)
Seems like something similar would work for the new script. I believe I found the color value of 5 using a simple Canon basic script that cycled through all the options :
private sub Initialize()
System.Create()
Driver.Create()
UI.CreatePublic()
a=LCDMsg_Create()
LCDMsg_SetStr(a,"SD940 Colour Dumper")
LCDMsg_Move(a,100,100)
LCDMsg_ChangeColor(a,2)
b=LCDMsg_Create()
c=LCDMsg_Create()
for d=0 to 16
Wait(2000)
LCDMsg_SetNum(b,d)
LCDMsg_Move(b,100,200)
LCDMsg_ChangeColor(b,2)
LCDMsg_SetStr(c,"TEST")
LCDMsg_Move(c,200,200)
LCDMsg_ChangeColor(c,d)
next
' for c=0 to 5
' Wait(2000)
' LCDMsg_SetNum(b,c)
' LCDMsg_Move(b,40,50)
' LCDMsg_ChangeColor(b,2)
' next
end sub
private sub terminate( )
' Ending code
end sub
Something like that could be made to work for all cameras I think ?
-
I guess we could make the message function alternate colors for a while, but really, the user of the dumper needs to look at the card anyway. We just need to make it clear they may not see anything displayed when the script runs. No point in piling on more complexity for cosmetic stuff. Compared to the old blinkers and udumper this is already ridiculously user friendly...
-
I agree completely!
My problem was in the very beginning to figure out if the script is started or not!
Know it's pretty clear to me, that garbage in the "no picture" frame is an indicator.
The solution is to support people in understanding the first steps.
Unfortunately I was mislead by a lot informations, which are obsolete, resp. not correct for my IXUS220HS.
1. Pressing Func.Set and Display simultaneously -> wrong for IXUS220HS
2. Pressing Func.Set and hold -> wrong for IXUS220HS, only short click is correct
3. DCIM folder has to be empty or removed -> wrong for IXUS220HS
4. Some posts requested max. 2GB and FAT16 -> wrong for IXUS220HS
5. Some posts requested lock switch action -> wrong for IXUS220HS
I hope that the next newbie discovers this description of my faults to be faster at the point of using the improved dumper with log file ;)
...have fun...
Michi
-
Hi all,
I recently started to look a bit into the dump file...
It seems, that for analyzing mostly IDA is used here!?
I wonder if everybody has access to IDA pro...it is a bit expensive for just hacking a 180Euro cam :o
The freeware version does not seem to support ARM...is this right!?
Is there a useful alternative...may be less powerfull...
...have fun...
Michi
-
The freeware version does not seem to support ARM...is this right!?
Correct.
Is there a useful alternative...may be less powerfull...
You may have a look to
-- Pelican's ARMU
* http://chdk.setepontos.com/index.php?topic=5100.msg49472#msg49472 (http://chdk.setepontos.com/index.php?topic=5100.msg49472#msg49472)
* http://pel.hu/armu/ (http://pel.hu/armu/)
-- GPL tools
* http://chdk.wikia.com/wiki/GPL_Tools (http://chdk.wikia.com/wiki/GPL_Tools)
-
Is there a useful alternative...may be less powerfull...
Interesting timing - I've been working on something that might be useful but its only been shared with a few people right now. It an early version and not very well tested or documented.
Wiki page is http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera (http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera)
If it looks interesting, send me a PM and I'll send you a download link for the pre-release.
-
If it looks interesting, send me a PM and I'll send you a download link for the pre-release.
Hi waterwingz,
for sure I'm interested in the tool. I'd like to be beta-tester as long as you can stand my dimwitted questions.
Actually I try to figure out the best tool setup, IDA is much too expensive for my use.
So any supporting tool is welcome and will be part of my evalution.
I sent my Email/Skype address in a PM.
...have fun...
Michi
-
Just as a hint on my motivation porting CHDK to the IXUS220HS...see the attached picture.
...have fun...
Michi
Click me!
|
\/
-
Michi, nice quadrocopter. I'm in the model helicopter hobby too. I have a Protos 500 and I made a custom camera stand for my old camera but I had big problems with high frequency vibrations. I will have to modify my old camera holder to fit the SX220 in it and see if the image stabilization from the new camera will make the difference.
-
...my old camera holder to fit the SX220 in it and see if the image stabilization from the new camera will make the difference.
Hi,
I'm quite interested in your experiences.
I've done some early experiments with a "key chain cam" and had horrible vibrations in the video.
I assume, that this was related to bad mounting and very low weight of the key-cam...
I read a lot posts, recommend to disable the IS in the camera for copters!?
I hope for you, that this is wrong...and for me too, because the IXUS220HS does not have the opportunity to disable the IS in the standard menus.
I've not checked if this is possible with CHDK...!?
Afaik my cam has "only" an electronical IS, so this may be easy!?
...have fun...
Michi
-
Hi,
I'd start to setup a trunk for the IXUS220HS. Any advice which existing port may be the best master version.
How can I access the SX220HS as template? It still is not available in the trunk!?
...have fun...
Michi
-
I would like to use CHDK-Shell to compile.
Can anyone help me introducing a repository to the actual SVN-Trunk?
...have fun...
Michi
-
Hi michi,
Funnel seems to be using CHDK-Shell, so I suggest you download his latest source release.
hth,
wim
-
Hi,
1. I am not convinced, that sx220hs is the right template because of the changed ROM-Base address!?
2. I am not addicted to GUI stuff, I would prefer simple make within EMACS...
I just wanted to ensure that the CHDK-Shell stuff works properly...
...but as most times I get lost in the GUI :xmas
-> I cloned a platform directory...don't care which for the moment...into trunk/<last_trunk>/platform/ixus220hs
Now I've no idea how to use CHDK-Shell to compile this new platform.
May seem ridiculous to you...so please give me a hint how to bring this platform into the project list of the shell...Please!
...have fun...
Michi
-
May seem ridiculous to you...so please give me a hint how to bring this platform into the project list of the shell...Please!
You need to modify the Makefile and makefile.inc in the root of the trunk directory to include your new port.
-
yeah...thx!
I found it this minute...seems to be common make structure to me below the GUI stuff...
I just have to adjust the path variable for the compiler and it will work fine!
...have fun...
Michi
-
I found it this minute...seems to be common make structure to me below the GUI stuff...
I just have to adjust the path variable for the compiler and it will work fine!
Correct- the CHDK-Shell GUI is really just a wrapper around the standard gcc command line tools.
-
Hi,
I need some help understanding the build process better.
I tried to compile a cloned platform directory with the PRIMARY.BIN of the ixus220hs and get, as expected, some errors.
finsig reports a list of unresolved symbols:
Close
Fgets_Fut
Fread_Fut
Fwrite_Fut
GetCurrentAvValue
GetParameterData
...
I looked a bit inside of finsig, it does obviously a pattern matching search on the PRIMARY.BIN!
Can anyone give me a short overview, how this is done to understand why the function stubs are not found.
There seems to be a threshold percentage which is treated as fault. I'm not sure what the process is to fix the problem.
I understand, that the signatures as defined in signatures_dryos.h are defined are searched. What does it mean if the functions are not found in PRIMARY.BIN!?
Thx for your help in advance...
Michi
-
I understand, that the signatures as defined in signatures_dryos.h are defined are searched. What does it mean if the functions are not found in PRIMARY.BIN!?
It means that canons code has changed enough that you need to find the functions manually.
-
Okay...that seems to be pretty clear...
I just want to find out, where in the build process the overrides have to be placed?
The signatures_dryos.h is common for all platforms and it would be a bad idea to put in platform specific signatures!?
...have fun...
Michi
-
Okay...that seems to be pretty clear...
I just want to find out, where in the build process the overrides have to be placed?
The signatures_dryos.h is common for all platforms and it would be a bad idea to put in platform specific signatures!?
...have fun...
Michi
Ahem ... you might find the pre-release of CHDK-PT that you downloaded somewhat useful. Try the List Convert -> Stubs button. It has finsig and gensig intergrated. Point it at a few recent camera releases and see if it comes up with better matches than the old data in signatures_dryos.H that you are trying to use.
EDIT : start with the stubs_entry_2.S files for each reference port you compare to. If the routine you are looking for is there, then the one in stub_entry.S is almost certainly wrong.
-
Okay...that seems to be pretty clear...
I just want to find out, where in the build process the overrides have to be placed?
The signatures_dryos.h is common for all platforms and it would be a bad idea to put in platform specific signatures!?
If a stub is not found, you find the address manually (perhaps with waterwingz tool) and then add the address manually to stubs_entry_2.S
Do not change the signatures files. edit to add: unless you are sure you know what you are doing
-
Do not change the signatures files.
Background note : if you do play with the signature files, I believe that you have to recompile finsig.c manually. The signature files are included at build time, not runtime - and as far as I can tell finsig is not recompiled as part of a normal build., because the primary.bin files used to create them are not included in the tools directory.
Also, I believe that changing the signature files means your port will not be eligible to include in the autobuild server as it could break many other ports.
-
Don't panic 8)
I never had the idea to touch the signature file!!!
I just try to understand what's going up during compilation and where the standard-patch points are!
@waterwingz: I didn't understood from the scratch how your tool works, so I try to look a bit into the build process.
As soon as I have a basic understanding of the process, I will come back to your tool for sure.
Please be patient with a CHDK newbie...
I usually try to understand before destroying anything...
...all my actual (maybe stupid) questions are only part of getting informations, not the base for wild actions :xmas
Even when my questions are "a pain in the a...", hopefully you will help me further getting a basic overview...
...have fun...
Michi
-
Hi funnel,
now I have the makefile stuff running, so it is time for the next step:
Finding the best matching port as template!
Your SX220 port is a hot candidate...equal dryOS Version...equal launch date.
Do you think, I can clone your trunk as start point for the IXUS220hs.
I'd like to try it with my PRIMARY.BIN to see how good it is matching.
Did you publish your last work anywhere, so that I can copy/clone it?
...have fun...
Michi
-
@waterwingz: I didn't understood from the scratch how your tool works, so I try to look a bit into the build process.
As soon as I have a basic understanding of the process, I will come back to your tool for sure.
Let me know what you find confusing and / or not clear? I'm too close to it to see it.
I'm reworking the dialog boxes to try and make things more obvious. And I added an automatic short help file that appears when the app starts. Still, a wiki page on what everything does is probably required in addition to the porting page I started.
Even when my questions are "a pain in the a...", hopefully you will help me further getting a basic overview...
You are doing great ! If I thought you were asking stupid or PITA questions I would be simply ignoring them.
-
Yes, I'll post the source in the SX220 section, but it's heavily commented from the sx210 and now from me, so use it just for reference. I took a look at the ixus220 firmware and found that the beginning of boot.c is the same, just at an offset of 810000.
-
Hi,
my problem was not the tool, but the flow itself:
I tried to load the PRIMARY.BIN, but it was without a template platform directory build setup, especially the stub files, not clear what is generated and what is analyzed.
The general flow is clear PRIMARY.BIN + signature pattern = stub-files, but the role of the buttons was not clear to me.
What is scanning?
What is analyzing?
What is generating stubs?
For an insider this may be stupid questions, but for beginner it's hard to determine what the dedicated flow of actions has to be!
Most of it is getting clearer by building a platform and observing the log and the missing symbols, but starting the PT and wild clicking didn't do the job for me.
I didn't understood the scan and pattern matching until I looked into the Makefiles...
And even more important, what have I to do with unresolved symbols, it is clear that I have to dissassemble and scan it by hand, but what is very important for me is a hint, which stub files may be changed by hand without be killed by another generator run....
Please understand this not as critic on your tool, the intention seems to be brilliant...my problem is that without a flow description:
How is a new platform added to the trunk?
What's coming in?
What's going out?
What metadata is fed into the process?
Where are the patch points for handmade patches?
A rookie may have problems to understand what has to be done when?
This may be related also to my style...I always try to understand what a GUI-click does, so most interesting are LOGs and make protocols...
Poooh ... that was lot of prosa ... hopefully containing some informations :blink:
...have fun...
Michi
P.S.: Unfortunately I've only a few hours per day in the late evening, so please be patient with my progress.
-
Yes, I'll post the source in the SX220 section, but it's heavily commented from the sx210 and now from me, so use it just for reference. I took a look at the ixus220 firmware and found that the beginning of boot.c is the same, just at an offset of 810000.
Would be great, I picked an older IXUS for first experiments and this seemed pretty far from the actual binary(as expected)...
I hope, that the SX220 is much closer to the IXUS220HS!
...have fun...
Michi
-
my problem was not the tool, but the flow itself:
Okay - I think I understand much more now. The tool will be better if it is integrated into a well explained porting process that a newbie can understand. I can probably improve the wiki page for the process of using CHDK-PT quite a bit. However, there is a balance point at which it gets too long, people stop reading and just "dive in". If I can subdivide into logical sections then I think that will help.
What is scanning?
What is analyzing?
What is generating stubs?
I'll make sure to cover that - good feedback !
Poooh ... that was lot of prosa ... hopefully containing some informations :blink:
This has been a big help prior to my moving the tool into a more general release format. If anything else comes to mind let me know. I've made a few UI changes already and am working on the last of the known bugs in the disassembler.
Thank you.
-
Hi funnel,
now I have the makefile stuff running, so it is time for the next step:
Finding the best matching port as template!
Your SX220 port is a hot candidate...equal dryOS Version...equal launch date.
Do you think, I can clone your trunk as start point for the IXUS220hs.
I strongly suggest you refer to several completed, fully functional ports. Philmoz' SX30 or G12 ports would be good candidates.
I am not a fan of copying a port and trying to 'fix' it. Every address and piece of assembler needs to be checked and corrected, so in the end, it doesn't matter much which one you start with. Some further discussion of this http://chdk.setepontos.com/index.php?topic=3977.msg37430#msg37430 (http://chdk.setepontos.com/index.php?topic=3977.msg37430#msg37430)
SX220 may have some useful hints because it's the same OS version, but working from an uncompleted port by someone who is not familiar with the source is likely to introduce a lot of errors and confusion.
-
Accepted.
I will spend some time checking the coverage in different ports.
@reyalp: Thx for your advice because it is very hard for me to find out the best template port for starting.
I've no indication which port is best as starting point, so each advice is very welcome !!!
I picked randomly the 200is, but the coverage of finsig was suprisingly low.
I have to experiment a bit before starting the real port.
As always knowledge is proportional to time spent in analysis 8)
...have fun...
Michi
-
I picked randomly the 200is, but the coverage of finsig was suprisingly low.
The latest dryos version being used by gensig/finsig is an R39 camera.
Much of the code seems to have changed with more recent camera so the signature matching is not as good.
I'm looking into improving this; but it will take some time (have to be careful not to break any existing ports).
Any new camera requires a lot of research, analysis of the firmware code, and trail and error; but that's half the fun :)
Phil.
-
You are right with "half the fun", but my microcopter wants to fly with camera and remote control ;)
I compiled sx30 and G12 with my PRIMARY.BIN and only a handful mismatches happend:
Fgets_Fut
Fread_Fut
Fwrite_Fut
LocalTime
Write
_log
_log10
_pow
memcpy
memset
set_control_event
strtolx
vsprintf
Identical list of mismatches for both!
It seems to be feasible to find them!?
Any comments are welcome...
...have fun...
Michi
-
You are right with "half the fun", but my microcopter wants to fly with camera and remote control ;)
I compiled sx30 and G12 with my PRIMARY.BIN and only a handful mismatches happend:
Fgets_Fut
Fread_Fut
Fwrite_Fut
LocalTime
Write
_log
_log10
_pow
memcpy
memset
set_control_event
strtolx
vsprintf
Identical list of mismatches for both!
It seems to be feasible to find them!?
Any comments are welcome...
...have fun...
Michi
Not sure what you mean by mismatches; but you can't just copy your cameras firmware to an existing port and expect it to work.
Have you read http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera. (http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera.)
The signature finder attempts to find functions in the firmware by matching code from other firmware versions. It writes these out to stubs_entry.S along with the % match if it was not 100%. Sometimes multiple signatures will match and you will get a comment with the ALT signature match details. A lot of times it won't find a match at all and you get an 'ERROR' comment for the function in stubs_entry.S.
Every function must match 100% for CHDK to work.
Any function not found by finsig or found with less than 100% match must be manually found and/or confirmed in the firmware dump by you. You then put these correct addresses in stubs_entry_2.s (manually) - it helps to add comments on how you found/matched them for future reference.
The build process scans stubs_entry.s and stubs_entry_2.s to make sure that every function has an entry in at least one of the files. If there are missing functions the compile stops with errors and a dump of the missing functions is created.
If you put your PRIMARY.BIN into my G12 or SX30 port you are just using the addresses I have found for these two cameras - which will be wrong for yours, so you still need to verify everything. It's best to start with an empty stubs_entry_2.s file so you get a list of all the functions not matched. You can then put all these into your stubs_entry_2.s along with any that did not match 100%. Then you start the painstaking process of finding and verifying each one in the firmware code - this can take days, weeks or months depending on how much free time you have to work on it, and how many similar cameras you have to compare firmware dumps.
When trying to find missing functions I find it useful to have the firmware dumps loaded into IDA (or whatever tool you use) for a few similar cameras that have working ports (release date, features, etc). You can then find the functions in the working dump to see what the code looks like and try and find some way to identify the function to allow you to search for it in your camera firmware.
Hope this helps,
Phil.
-
I compiled sx30 and G12 with my PRIMARY.BIN and only a handful mismatches happend:
I assume what you mean is that you put your primary.bin file into an sx30 and a G12 build directory, started a build and then looked at the resulting stub_entry.S files ?
This is okay to a point. What you have done is run the signature finder program located in the trunknnnn/tools directory against your primary.bin file. The resulting stub_entry.S files will be identical because nothing from the sx30 or G12 ports was actually used in creating the stub_entry.S files. So just as reyalp and Phil have pointed out, you need to look for those missing routines manually in the dissassembly of the IXUS220HS primary.bin file.
Just for fun, I tried using CHDK-PT to convert the stub_entry.S and stubs_entry_2.S files from the G12 to the IXUS220HS. No surprise - it could not find the routines you mentioned either - confirming that the code for those is very different in the IXUS220HS. I wonder if a different camera might be closer ?
-
In the end, you need to be able to understand the disassembly and find the relevant functions. No tool will replace this any time soon.
Note that the Fut functions should mostly be available from event procs, which are very easy to find (find the name as a string, find the address the of the string and a function pointer together). We know Fwrite_Fut must exist, because the dumper worked. The others will be nearby.
For the ones that aren't event procs, you generally have to work from context: Disassemble a known port, find where the function you want is used in that port, then find the equivalent location in your dump. The easiest landmarks are strings, but if there aren't any obvious ones, you can go by sequences of calls to other identified functions, where it appears in the dump etc.
-
In the end, you need to be able to understand the disassembly and find the relevant functions. No tool will replace this any time soon.
I completely agree for a new port like this. I'm just hoping that once somebody does all the hard work to port to a new camera, we can provide tools to more easily add different firmware versions of the same camera.
-
Thx for your advice...
that supports, at least paritally, what I assumed...
I just posted the mismatches to document what I believe, I have to dissassemble, find and patch manually...
I hope, correct me when I'm wrong, that the matching signatures (:= not listed) are usable/reliable for my cam, so that I can concentrate on finding the addresses of the mismatches I listed...
I will do some more experiments to find the best matching platform...it is just important for me to learn if the stubs matched by finsig are reliable.
...have fun...
Michi
-
...
Not sure what you mean by mismatches; but you can't just copy your cameras firmware to an existing port and expect it to work.
Have you read http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera. (http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera.)
The signature finder attempts to find functions in the firmware by matching code from other firmware versions. It writes these out to stubs_entry.S along with the % match if it was not 100%. Sometimes multiple signatures will match and you will get a comment with the ALT signature match details. A lot of times it won't find a match at all and you get an 'ERROR' comment for the function in stubs_entry.S.
Every function must match 100% for CHDK to work.
Any function not found by finsig or found with less than 100% match must be manually found and/or confirmed in the firmware dump by you. You then put these correct addresses in stubs_entry_2.s (manually) - it helps to add comments on how you found/matched them for future reference.
The build process scans stubs_entry.s and stubs_entry_2.s to make sure that every function has an entry in at least one of the files. If there are missing functions the compile stops with errors and a dump of the missing functions is created.
If you put your PRIMARY.BIN into my G12 or SX30 port you are just using the addresses I have found for these two cameras - which will be wrong for yours, so you still need to verify everything. It's best to start with an empty stubs_entry_2.s file so you get a list of all the functions not matched. You can then put all these into your stubs_entry_2.s along with any that did not match 100%. Then you start the painstaking process of finding and verifying each one in the firmware code - this can take days, weeks or months depending on how much free time you have to work on it, and how many similar cameras you have to compare firmware dumps.
When trying to find missing functions I find it useful to have the firmware dumps loaded into IDA (or whatever tool you use) for a few similar cameras that have working ports (release date, features, etc). You can then find the functions in the working dump to see what the code looks like and try and find some way to identify the function to allow you to search for it in your camera firmware.
Hope this helps,
Phil.
With mismatches I mean the signatures which are not 100% matching the reference as reported in the build output.
It's pretty clear that I have to solve them by hand (brain if available).
Please don't treat my analysis attempts as idiots work...I'm not as naive to believe everything is going automatically, I just want to use the done work as much as possible.
Better to steal good than to implement bad!
...have fun...
Michi
-
For the SX220 stubs I checked them all and found that a lot of them were wrong, even when the match % was high and some were right when the % was small. So is best to recheck them all manually to be sure.
-
For the SX220 stubs I checked them all and found that a lot of them were wrong, even when the match % was high and some were right when the % was small. So is best to recheck them all manually to be sure.
Oh!
That's not what I expected...thanks for the warning, so I can skip the search for the best match!
Thx a lot...
With these facts I've to recalculate if the port will exceed my time budget :-[
...have fun...
Michi
-
With these facts I've to recalculate if the port will exceed my time budget :-[
As you've figured out, porting to a new camera is a really big job. Especially if you are coming up the learning curve from scratch. Even if you only value your time a $1/hr, its still a better deal to go out and purchase one of the supported camera / firmware combinations. Especially if what you really want to do is enhanced photography rather than software.
-
With these facts I've to recalculate if the port will exceed my time budget :-[
As you've figured out, porting to a new camera is a really big job. Especially if you are coming up the learning curve from scratch. Even if you only value your time a $1/hr, its still a better deal to go out and purchase one of the supported camera / firmware combinations. Especially if what you really want to do is enhanced photography rather than software.
I agree, but unfortunately the parameters of my 220hs,HD resolution, 24-120mm, 140gr. are fitting so perfectly to my microcopter requirements, that I hardly find a ported equivalent ;)
Maybe I've to wait until a Senior will do the job...even when I don't like this "let someone do the job" attitude.
This one would be a good winter project, but unfortunately here in Munich it is spring with someday summer feeling ;)
...have fun...
Michi
-
I agree, but unfortunately the parameters of my 220hs,HD resolution, 24-120mm, 140gr. are fitting so perfectly to my microcopter requirements, that I hardly find a ported equivalent ;)
I'm a little biased 8) but you might want to checkout the SD940. http://chdk.wikia.com/wiki/SD940IS (http://chdk.wikia.com/wiki/SD940IS). Pretty much the same size, slightly lighter, comparable shooting specs ... And pretty much every firmware version has been ported.
-
Yes, it's coming pretty close...except the 28mm vs. 24mm and HD (which is not relevant ;).
But it is acceptable...I try to change the CAM at my distributor.
And 20gr. less is good even!
...have fun...
Michi
P.S.: "All but the 1.00E have been ported."
How high is the probability to get an "E" release here in Europe!?
-
But it is acceptable...I try to change the CAM at my distributor.
Not sure if you can buy an IXUS120 -SD940 new any more but its worth a try.
P.S.: "All but the 1.00E have been ported."
How high is the probability to get an "E" release here in Europe!?
Pretty low I would think. There have only been two people reporting owning them that I know of and I believe they were originally sold in Asia. In any case, it would be an easy job to port to it once we have a firmware dump. I can help you out there should it happen.
-
But it is acceptable...I try to change the CAM at my distributor.
Not sure if you can buy an IXUS120 -SD940 new any more but its worth a try.
P.S.: "All but the 1.00E have been ported."
How high is the probability to get an "E" release here in Europe!?
Pretty low I would think. There have only been two people reporting owning them that I know of and I believe they were originally sold in Asia. In any case, it would be an easy job to port to it once we have a firmware dump. I can help you out there should it happen.
My distributor has an "IXUS 120 IS" in stock, im within 14 days return period...I'll give it a try. It is 2/3 of the price of the 220 hs ;)
So no reason not to switch over...
B.t.w.: My motivation, as I figured out in a post above, is the use with my microcopter and especially the remote control stuff via USB-Power-Pin. Do you see any contra-indication in "Shoot", "Start Video", "Zoom-IN/OUT" scripting for this device?
Just to be better informed this time :)
Thx a lot, especially for your patience answering dumb questions ...
...have fun...
Michi
-
B.t.w.: My motivation, as I figured out in a post above, is the use with my microcopter and especially the remote control stuff via USB-Power-Pin. Do you see any contra-indication in "Shoot", "Start Video", "Zoom-IN/OUT" scripting for this device?
I have not tried any scripts that involve video. I have confirmed that USB-Power-Pin can activate the shutter though. If you can find or write a script that does what you want, I can test for you.
-
Thx, but confirming shoot on USB-Pin seems to be enough...it improves, that it is possible to monitor the pin.
It would be great if you can explain the binding between the Pin checking routine and the shoot stub of CHDK...
The rest is done by just modulating the pulse width and connecting these events to different functions.
I will do that work later and I'm sure it works because of different examples are available in the web and in microcopter forums.
I've to analyze the availability of CHDK functions and than define how to signalize it via PWM.
For this purpose I will design a litte AVR-microprocessor circuit, connected to the servo outputs of my remote control receiver and as output to the USB power pin.
...have fun...
Michi
-
It would be great if you can explain the binding between the Pin checking routine and the shoot stub of CHDK...
Not sure what you are asking here, but if you look at the kbd.c code (in the ..\trunknnnn\platform\ixus120_sd940\ directory you will find a routine called my_kbd_read_keys(). This is where the status of the USB pin is detected.
The rest is done by just modulating the pulse width and connecting these events to different functions.
I don't think that I've seen anyone try to decode PWM signals from the USB power pin - at least not in CHDK basic or lua. However, you could probably customize the kdb.c code (mentioned above) to do what you want. It will just no longer be a standard version of CHDK.
-
Not sure what you are asking here, but if you look at the kbd.c code (in the ..\trunknnnn\platform\ixus120_sd940\ directory you will find a routine called my_kbd_read_keys(). This is where the status of the USB pin is detected.
That's exactly what I'm looking for...for the very beginning it is perfect to shoot remotly.
I don't think that I've seen anyone try to decode PWM signals from the USB power pin - at least not in CHDK basic or lua. However, you could probably customize the kdb.c code (mentioned above) to do what you want. It will just no longer be a standard version of CHDK.
Maybe PWM is a little misleading, I discovered several projects using the USB Pin do send more than one commands to CHDK by just measuring the duration of the pulse. I will later report on that topic if of interest!?
...have fun...
Michi
-
@Admin: please can you mark this thread as closed.
After analyzing the porting effort, I decided to switch to another camera, which is already ported (IXUS120IS), so this threads titel may be misleading until someone else starts to port to IXUS220HS.
Sorry, but the time effort on this topic is, following the recommendations of the gurus in this forum, to high for me...
...have fun...
Michi
-
or we could leave it open so other interested people may bump it in search of an guru to pull us out of the mud? ???
it would be a shame for this camera to remain locked. do you think that if we send an email to canon and ask for unofficial support, they could help us with tips on the porting? what information is needed, specifically, which varies between cameras of the same range and cameras of other ranges? (like sx vs elph 300 vs ixus classic)
i hope that i am not violating any hack tabu by bringing such thing into discussion... after all it could be an other form of heching :haha
-
it would be a shame for this camera to remain locked. do you think that if we send an email to canon and ask for unofficial support, they could help us with tips on the porting?
As a developer, I would ask that you please do not do this. Ignoring CHDK is about the most positive approach they can realistically take.
what information is needed, specifically, which varies between cameras of the same range and cameras of other ranges? (like sx vs elph 300 vs ixus classic)
It's not a matter of some "specific information" that Canon could provide. CHDK hooks directly into the internals of the firmware. Every port needs a bunch of addresses and other stuff to pull this off. Because they are obtained by reverse engineering this isn't something Canon could provide with even if they wanted to.
-
I'm really hoping someone can help revive this. Its a great little camera, I just wish eos had more supported features. ugh!
-
it would be a shame for this camera to remain locked. do you think that if we send an email to canon and ask for unofficial support, they could help us with tips on the porting?
As a developer, I would ask that you please do not do this. Ignoring CHDK is about the most positive approach they can realistically take.
what information is needed, specifically, which varies between cameras of the same range and cameras of other ranges? (like sx vs elph 300 vs ixus classic)
It's not a matter of some "specific information" that Canon could provide. CHDK hooks directly into the internals of the firmware. Every port needs a bunch of addresses and other stuff to pull this off. Because they are obtained by reverse engineering this isn't something Canon could provide with even if they wanted to.
okay, that is why i was asking. thank you for your answer, now i just wish i hadn't abandoned programming 5 years ago :(
-
I have started work on adding this camera. My time to work on it is limited and this is a first time for me, so please be patient. If anyone with more experiance would like to help please do. I have already found a few functions manually, and will update as I have more done.
-
good news, godspeed with that!
reyalp & chris, i would like to ask if you see any practical utility in using machine learning to get the addresses for the new (unknown) firmware. i mean it's useful but believe me when i tell you that i have no idea about reverse engineering. the short story is to chuck all the currently "deciphered" firmwares AND their lists of useful addresses (incl. function name) and train something with it (neural nets or SVM for instance... kohonen maps could also work). after training, plugging in a new firmware will give possible start addresses (nn/koh) or probabilities for randomly generated address lists (svm + a tad bruteforce). keep in mind that the results returned will be almost certainly "dirty" but at least it could "highway" a part of the road :)
do you see any reason this might not work for? i might start on it next month and it could take anything between 4 days and 4 weeks. this month i'm still busy flunkin' my msc.
(edit: changed svn to svm... i'm dyslexic :-X)
-
reyalp & chris, i would like to ask if you see any practical utility in using machine learning to get the addresses for the new (unknown) firmware. i mean it's useful but believe me when i tell you that i have no idea about reverse engineering.
You will not accomplish anything without a very thorough understanding of what is already there. Gaining that knowledge would take a substantial amount of time, at least equivalent to doing a port the normal way. In fact, doing a port would probably be a good place to start, since it will give you a good overview of the platform dependent areas of CHDK.
I don't know enough about the field to know if this kind of technique could be useful, but it certainly seems plausible. For some student doing work in this area, it could probably be an interesting and productive project. The end result might even be useful for future ports.
FWIW, we already have tools that find addresses based on reference to other firmwares, which work quite well without any machine learning, see http://chdk.wikia.com/wiki/Signature_finder (http://chdk.wikia.com/wiki/Signature_finder) and http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera (http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera)
-
FWIW, we already have tools that find addresses based on reference to other firmwares, which work quite well without any machine learning, see http://chdk.wikia.com/wiki/Signature_finder (http://chdk.wikia.com/wiki/Signature_finder) and http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera (http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera)
And at the risk of stealing someone else's thunder, philmoz has been working on a new sigfinder that probably does most of what is proposed here - albeit not with the same proposed AI & ML techniques but building on the existing knowledge from all the ports so far. I don't know a lot more about what else he has done but the results he has shared with me working on a couple of ports recently have been pretty spectacular compared to the old way. I'm sure philmoz will share details in his own time.
-
FWIW, we already have tools that find addresses based on reference to other firmwares, which work quite well without any machine learning, see http://chdk.wikia.com/wiki/Signature_finder (http://chdk.wikia.com/wiki/Signature_finder) and http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera (http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera)
And at the risk of stealing someone else's thunder, philmoz has been working on a new sigfinder that probably does most of what is proposed here - albeit not with the same proposed AI & ML techniques but building on the existing knowledge from all the ports so far. I don't know a lot more about what else he has done but the results he has shared with me working on a couple of ports recently have been pretty spectacular compared to the old way. I'm sure philmoz will share details in his own time.
Thanks waterwings, it's getting there - I hope to have a version ready for general use soon.
I've been looking at the firmware dumps of the new Dryos R47 cameras (SX220, SX230, Ixus220) and my code is working pretty well with these.
Attached is my stubs_entry.S file for the Ixus220 firmware version 1.00c.
After each stub is some additional information:
- method used to find the address (for my internal use)
- % match (only shown if the match is less than 100%)
- comparison to stubs_entry_2.S (not relevant here as I don't have the existing file for this camera)
- comparison to original finsig/gensig generated address.
Phil.
-
Phil you are my hero. This is pure gold. I'm going through the stubs now and I had maybe 1/5 of these and this confirms all of those. I will continue to go through it and see if I can get a stable build when I get the chance. I'll let you know how it goes.
-
Small problem. I get this error when I try to compile in a new directory I have created for the platform.
========== C:\CHDK\T\TRUNK\TRUNK1210\BIN\LOGS\ERR-IXUS220_300HS-100C.TXT ==========
C:\chdk\t\gcc451\bin\gmake.exe: *** ixus220_300HS: No such file or directory. Stop.
C:\chdk\t\gcc451\bin\gmake.exe[1]: *** [clean-recursive] Error 1
gmake: *** [clean-recursive] Error 1
When I place all of the files in an existing directory I get a different error.
========== C:\CHDK\T\TRUNK\TRUNK1210\BIN\LOGS\ERR-G12-100C.TXT ==========
Time to generate stubs 13.99 seconds
C:\chdk\t\gcc451\bin\gmake.exe[4]: *** [stubs_entry.S] Error 1
C:\chdk\t\gcc451\bin\gmake.exe[3]: *** [all-recursive] Error 1
C:\chdk\t\gcc451\bin\gmake.exe[2]: *** [all-recursive] Error 1
C:\chdk\t\gcc451\bin\gmake.exe[1]: *** [all-recursive] Error 1
gmake: *** [all-recursive] Error 1
If anyone knows what I am doing wrong I would appreciate some help. These errors are not very intuitive.
-
It's not clear what you've done until now.
To start you should:
-add the camera folder to trunk/platform and trunk/loader folder
-add the camera in trunk/makefile.inc
-put the PRIMARY.BIN in platform/camera/sub/VER folder
Be careful when calling gmake, uppercase and lowercase letters matter.
-
Hi ChrisWillh,
C:\chdk\t\gcc451\bin\gmake.exe: *** ixus220_300HS: No such file or directory. Stop.
You need specific folders for your camera in both the /loader and the /platform directories, the error
suggests at least one is missing, or maybe a typo (are the names identical ?)
hth,
wim
-
Thanks guys, I was missing the loader folder. I am still gettting the stubs_entry.s error however. I've tried searching to see if anyone else has had the same problem, but no luck so far. I'll try a few other things and see if I can get it working.
-
Hi Chris,
have you already been able to solve your problem?
I'm wondering how I could support you. I just owned an IXUS 220 HS and would like to support the CHDK development for this device. I already used CHDK on my S5 IS two years ago.
Please let me know if and how I can support you. Maybe you could share your loader and platform folder for the IXUS 220 HS device that I can also try to build the CHDK?
Thanks in advance!
Best regards,
tommi
-
Dear thread,
I have an elph 300 hs and will be greatly pleased if a successful port is released. If there is anything I can do to help please let me know.
-
RL is kind of crazy right now, so this has taken a back seat. I will hopefully have time to work on this agin in September. Untill then anyoine else is welcome to start this as I don't really have anything working yet.
-
After ixus100is and SX1IS I'd also like my 220hs to do the magic. Where can I find the actual beta, it's not online at http://www.box.net/chdk (http://www.box.net/chdk) -> ixus220hs_elph300hs_100c.7z anymore.
-
I've read the topic until here and didn't find if there is a dumped firmware of IXUS 220 HS Version GM1.01A.
I would like to provide this Version of Firmware. So where can i upload this primary.bin?
-
Upload it at zshare (http://"zshare.net"), for example, and then post it in firmware dumping forum section (http://"chdk.setepontos.com/index.php?board=5.0")
-
Thank you. I've done it. You can find the Post at the following link: http://chdk.setepontos.com/index.php?topic=288.msg72268#msg72268 (http://chdk.setepontos.com/index.php?topic=288.msg72268#msg72268)
-
Cool, i dled it. thanks!
-
Any status update on this? I am following the progress of the IXUS 115/ELPH 100, which is going quite rapidly. However I am also very interested in this camera but progress seems to almost have stopped. If there is a prospect of CHDK coming to the IXUS 220/ELPH 300 i might replace my current camera with this one.
-
Tis frustrating, I agree. But people are doing this in their spare time and so far it seems like no one has enough of it. This is a very nice, powerful little point and shoot camera. I did some thorough research on this piece, and I would LOVE to maximize it. The main things I need are RAW support and exposure bracketing.
Anyhow, I would love to see this happen, but seeing as I'm not skilled in the right areas, I'll just have to hold out hope!
-
Is there any, even partially working, CHDK for IXUS220HS ?
- I only need remote trigging by USB, and preferably RAW & no-sleep.
-
I just need exposure lock in video mode! Is it against the rules for us all to get together and offer a small pledge to help get one of these cameras into the hands of an interested volunteer developer?
-
I just need exposure lock in video mode! Is it against the rules for us all to get together and offer a small pledge to help get one of these cameras into the hands of an interested volunteer developer?
Its not about money. That question usually comes down to asking an interested volunteer to work for 1/10 of what they could make working at McDonalds or Walmart. Unless you get a developer doing this because they care about the appication, you are probably out of luck.
-
Yes I can see based on the hours put in that it's purely a labour of love!
I'm a bit more familiar with the phone dev side where it's fairly common practice for a few people to chip in for a new device with a particular firmware on it in exchange for someone to have a crack at the port.
No offense intended 8)
-
Hi guys,
Like you, I have a Elph 300 HS (V1.0.1A) that I would like to get ported.
I have some coding and IDA disassembling experience, plus some ASM basics (x86 not Arm). On top of that, I have the feeling that the version done for the Elph 100 HS (the little brother) should be quite close to what we need, considering that the 2 cameras are very, very similar.
However it would really help me to have some advice on where to start. Yes I read the wiki about it, but for example I'm not able to find the source code of the version made for the elph 100HS in the svn.
I already have dumped my own firmware. Now , any suggestion ?
BM.
-
Mmmm ok , I missed a good chunk of the wiki "for developper".... Working on it now.
Any hint on where to find the files for the 100HS ?
-
Mmmm ok , I missed a good chunk of the wiki "for developper".... Working on it now.
Any hint on where to find the files for the 100HS ?
The last post from anyone who had reported any success was in July (http://chdk.setepontos.com/index.php?topic=6341.msg70181#msg70181 (http://chdk.setepontos.com/index.php?topic=6341.msg70181#msg70181))
ChrisWillh has not logged into the forum since then and it does not look like he uploaded his source code anywhere.
You can try sending him a personal message as that may send an alert to his email address.
Phil.
-
Thanks Phil.
Do you think you would be able to generate with your tool a stubs_entry.S file for the Ixus220 firmware version 1.01A ? Because it's the model I have.
I sent a PM to ChrisWill. The developper of the Elph 100HS will also send me his source code. With the 2 I should be able to figure out something I hope.
Thanks,
BM
-
Thanks Phil.
Do you think you would be able to generate with your tool a stubs_entry.S file for the Ixus220 firmware version 1.01A ? Because it's the model I have.
I sent a PM to ChrisWill. The developper of the Elph 100HS will also send me his source code. With the 2 I should be able to figure out something I hope.
Thanks,
BM
Once you've got the build environment set up, copy your firmware dump to the subs/101a folder as PRIMARY.BIN.
The build process will automatically generate the stubs_entry.S file from your firmware dump.
Phil.
-
blueman - any progress on the port?
-
Hi I'm new here;-) I was trying CHDK for IXUS 220 * / 300 ELPH 1.01C thank you in advance.
I tried the 1.01a but I will not charge. ;)
-
Hi I'm new here;-) I was trying CHDK for IXUS 220 * / 300 ELPH 1.01C thank you in advance.
I tried the 1.01a but I will not charge. ;)
Probably best for you to follow this thread : ELPH300HS aka IXUS220HS - Porting Thread (http://chdk.setepontos.com/index.php?topic=6341.msg73921#msg73921)
and read this if you are unfamiliar with how CHDK is ported to different cameras : CHDK FAQ : My camera isn't ported yet (http://chdk.wikia.com/wiki/FAQ#Q._My_camera_isn.27t_ported_yet._Is_a_port_planned.C2.A0.3F_When_will_it_be_ready.C2.A0.3F_How_can_I_help.C2.A0.3F)
-
I read a lot but I think there is no confusion still seems to me that they have arrived to version 1.01a.
Then I can not get in update mode .. I read a lot even if you could give me the exact sequence with play then I light up func-set the clock but I do not get the files have no say in the main tab and the card is unlocked.
-
I read a lot but I think there is no confusion still seems to me that they have arrived to version 1.01a.
Then I can not get in update mode .. I read a lot even if you could give me the exact sequence with play then I light up func-set the clock but I do not get the files have no say in the main tab and the card is unlocked.
While it is possible that 1.01a will work in your 1.01c camera, it is not very likely. But if you want to try, let us know what you have done so far ? Are you using Windows or a Mac ? Did your start the camera by pressing the Play button rather than the On/Off button ?
-
I use win xp a card formatted in FAT 32 from 4 GMB I've copied the file into strings and primary and there are no other files or photos
I put the card into the camera is not locked I turned on the camera by pressing the play button poiil func to set until the clock does not start and I stop here ...
www.photofacebook.it (http://www.photofacebook.it)
-
What is the current state of this port? I really want some of the manual features CHDK offers, since there is few built in (no manual focus, etc)
Also, is there anyway someone with no coding experience could aid in the porting process?
-
What is the current state of this port? I really want some of the manual features CHDK offers, since there is few built in (no manual focus, etc)
Also, is there anyway someone with no coding experience could aid in the porting process?
I know its frustrating waiting, here's a note from the CHDK wiki about how things work : CHDK FAQ : My camera isn't ported yet (http://chdk.wikia.com/wiki/FAQ#Q._My_camera_isn.27t_ported_yet._Is_a_port_planned.C2.A0.3F_When_will_it_be_ready.C2.A0.3F_How_can_I_help.C2.A0.3F)
Read the part towards the bottom about helping with testing. When I ported the G10, the volunteers who worked with me doing beta testing were the difference between a solid result and a bad hack. Some of them put a lot of effort into helping me get it right even though they were not able to help with the actual coding.
-
Note: I've asked the forum moderator to move this conversation to the ELPH300HS aka IXUS220HS - Porting Thread.
I use win xp a card formatted in FAT 32 from 4 GMB I've copied the file into strings and primary and there are no other files or photos
I put the card into the camera is not locked I turned on the camera by pressing the play button poiil func to set until the clock does not start and I stop here ...
Okay, lets take it from here :
1) Formatted FAT32 is fine - although a 4G card can be formatted FAT16 and will be able to use the "SD Card Lock" boot method in the future.
2) Please post a link to exactly which file you copied ? Typically you have to unzip an archive file into the root of the SD card.
3) What do you mean by "strings and primary" ? Those are not directories you would normally find on an SD card holding CHDK.
4) I'm not following what happens after you put the card into the camera. You press the play button and nothing happens ? Or the camera starts up normally ? If it starts up normally do you go to the Canon menus and look for the firmware update menu item ? Do you see it ? If so, what happens when you select it ?
-
Hello I'm new I just got a sx220 software ixus Canon IXUS 220HS 101c I would like to shoot in raw I tried to load on a 4 GB CF files Hi!
I dumped the firmware IXUS 220 HS 101A
8 MB dump: ixus220hs_elph300hs_101a.7z
unzip it and put in the director's main 32-bit formatted cf.
I put the camera in and push play cf unprotected lights tells me no picture and then I press func set until the clock that appears at this point I do not know what to do does not give me the chance to upload the firmware as I do? ??
I can not find the option to update the firmware.
Thanks for the help if you can
This is not going to work for you !
If I understand this correctly, you are not actually loading CHDK by this process. The file you reference is a dump of the firmware from a IXUS220 camera. There is no reason to try and reload this into your camera - it is not CHDK.
You need to load a CHDK distribution file - which is not available from the official channel and not available as a beta version from what I can tell. You will have to wait until somebody develops and releases CHDK fro the IXUS220HS.
-
ill put my hand up for testing if anyone is still actively developing for this camera model.
-
Thanks I understand now I hope that will be implemented the software for this machine which is equipped with the new CMOS sensor that seems to give excellent retroinluminato risultati.peccato that the file that generates the machine is very compressed propio I'd like to see how it works with the raw.Ringrazio all for the quick help and I am waiting for someone to develop;-)
-
ill put my hand up for testing if anyone is still actively developing for this camera model.
Same here. Anything to help along the full release.
-
Hello folks,
I have recently purchased this camera and am very interested in seeing a port completed. I have noticed some attempts and some departures from these attempts. Although I am quite new to chdk porting, I thought I would give it a shot. There has been a wealth of information in this thread from very knowledgeable people. I would rate my skill level in programming to be low.
So far, I have done the following:
- got the gcc ARM cross compiler working
- downloaded the chdk source tree. I have noticed that the structure is a bit different than discussed early in this thread. I am using a linux environment.
- dumped the camera firmware. I believe I have 1.01c since the exif in the jpgs says 1.01 revision 3.00
- created a structure under "platform" and "loader" for ixus220_elph300hs by copying the sx220hs structure.
- added my PRIMARY.BIN to the sub/101c folder in this new tree
- started changing "platform_camera.h" just to get things to compile. I know the resultant binary is garbage but I just wanted to see if the compilation would happen.
what I still need to do is:
- get a disassembler going. I'm looking at the alternatives to IDA since I can't purchase that.
problems so far:
- I thought that stubs_entry.S would be automatically generated but all I see is a zero-length file. Not quite sure what I need to get this populated.
-sush.
-
what I still need to do is: - get a disassembler going. I'm looking at the alternatives to IDA since I can't purchase that.
Maybe somebody with IDA can print out a LST file of a dissassembly for you ? With a good editor, that would take you a long way.
Alternatively, CHDK-PT (http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera)seems to run on Linux under Wine. I've only used it that way a few times so bug reports will be appreciated.
- I thought that stubs_entry.S would be automatically generated but all I see is a zero-length file. Not quite sure what I need to get this populated.
It should. How far did your compile get ? Were you able to produce a diskboot.bin file ?
-
It would be great of CHDK-PT worked under wine - would surely make things easier.
Yes, a diskboot.bin file was produced.
-
It would be great of CHDK-PT worked under wine - would surely make things easier.
Tried it (again .. been a while). It does.
Yes, a diskboot.bin file was produced.
Hmmm ... seems unlikely you would get that far with an empty stubs_entry.S file ...
-
I was just about to edit my post above -
I see the reason why things went haywire after looking at the log:
>> Entering to platform/ixus220_elph300hs/sub/101c
-> stubs_entry.S
Segmentation fault
stubs_entry.S -> stubs_entry.o
stubs_entry_2.S -> stubs_entry_2.o
A seg fault occurred but it kept going. Now, I need to figure out why it seg faulted!
-
- dumped the camera firmware. I believe I have 1.01c since the exif in the jpgs says 1.01 revision 3.00
I don't think this version has been posted yet. Can you post it here : Firmware dumps available (http://chdk.setepontos.com/index.php?topic=288.345)
-
done! posted the firmware.
101c:
http://www.box.com/s/7prmv1zst2a3y3iizo5n (http://www.box.com/s/7prmv1zst2a3y3iizo5n)
-
done! posted the firmware.
What start address did the Canon BASIC script report ? ( FFC00000, FF810000, FF000000) ?
-
What start address did the Canon BASIC script report ? ( FFC00000, FF810000, FF000000) ?
is this something that is displayed on the screen? Because due to the black screen I can't see anything.
-
A seg fault occurred but it kept going. Now, I need to figure out why it seg faulted!
Most likely the ROMBASEADDR in makefile.inc is wrong.
If you copied the SX220HS it will be set to 0xFF000000; but your firmware dump is only 8MB so should be 0xFF810000.
Phil.
-
You are correct about the base address. I added some change colour code to extend.m and could see it.
I will try to modify the makefile and see what happens.
Thanks for your help!
-
is this something that is displayed on the screen? Because due to the black screen I can't see anything.
Darn - I knew that would bite me at some point. My version of the Canon Basic dumper script included a line to set the text color - for just this reason. It varies from camera to camera so reyalp did not include something similiar in his version.
-
The seg fault is gone but the stubs_entry.S is still blank.
On another note, I find it curious that camera constants are hard-coded inside of core/kbd.c
If I change the define CAMERA_sx220hs in platform_camera.h, this of course causes compilation issues in kbd.c
I don't quite think it would be good practice for me to change kbd.c but what is the alternative for adding a new camera type?
thanks.
-
The seg fault is gone but the stubs_entry.S is still blank.
On another note, I find it curious that camera constants are hard-coded inside of core/kbd.c
If I change the define CAMERA_sx220hs in platform.h, this of course causes compilation issues in kbd.c
I don't quite think it would be good practice for me to change kbd.c but what is the alternative for adding a new camera type?
thanks.
Try deleting the empty stubs_entry.S file to force it to be recreated.
The CAMERA_??? define is created automatically from your PLATFORM - you need to use this in various files (e.g. core/kbd.c) to set up camera specific stuff. Ideally everything specific to the camera should be in the platform files; but there are a few things that are still sprinkled across the core source files.
Phil.
-
- get a disassembler going. I'm looking at the alternatives to IDA since I can't purchase that.
You may also have a look to PEL's ARMu: http://pel.hu/armu/ (http://pel.hu/armu/)
What start address did the Canon BASIC script report ? ( FFC00000, FF810000, FF000000) ?
is this something that is displayed on the screen? Because due to the black screen I can't see anything.
Using a cBasic dumper script like the one from the wikia, there should be a file named CBDUMPER.LOG with the start address on the SD card...
-
Because I had much problems to get my CHDK environment running during the last weeks, I started again today and wrote down every step I did. And finally I got my CHDK environment working. :)
Hopefully my description helps others to setup their CHDK environment as well to start porting for IXUS220HS soon.
I use CHDK-Shell-v338.exe on Windows 7 64Bit
My Camera Firmware version is: 100c
SX220HS was used as basis for my environment setup.
What I did until now:
- get CHDK Trunk revision 1418 (trunk1418 is the root folder of all below paths)
- copy /loader/sx220hs to /loader/ixus220_elph300hs
- copy /platform/sx220hs to /platform/ixus220_elph300hs
- delete /platform/ixus220_elph300hs/sub/101a
- delete /platform/ixus220_elph300hs/sub/101b
- rename /platform/ixus220_elph300hs/sub/100a to /platform/ixus220_elph300hs/sub/100c
- delete /platform/ixus220_elph300hs/sub/100c/stubs_entry.S
- copy PRIMARY.BIN (100c Firmware) to /platform/ixus220_elph300hs/sub/100c/
- change PLATFORMID to PLATFORMID=12841 in line 6 of file /platform/ixus220_elph300hs/sub/100c/makefile.inc
- change ROMBASEADDR to 0xFF810000 in line 19 of file /platform/ixus220_elph300hs/sub/100c/makefile.inc
- add entry "ixus220_elph300hs,100c,ALPHA,," in line 66 to file /camera_list.csv
- add entry " || defined(CAMERA_ixus220_elph300hs)" at end of line 1265 (where sx220hs is also handled) in file /core/gui.c
- add entry " || defined(CAMERA_ixus220_elph300hs)" at end of line 105 in file /core/kbd.c
- changed all "task_RotaryEncoder" entries to "task_PhySw" in file /platform/ixus220_elph300hs/sub/100c/boot.c
After Start of CHDK-Shell-v338.exe I can mark the ixus220_elph300hs entry for compilation and start compilation.
Compilation generates stubs_entry (with size of 18 KB) and stops with following message:
========== D:\CHDK\TRUNK\TRUNK1418\BIN\LOGS\ERR-IXUS220_ELPH300HS-100C.TXT ==========
Time to generate stubs 16.35 seconds
After compilation the following files are available in the /bin folder:
ixus220_elph300hs-100c-0.9.9-r1418.zip (208 KB)
ixus220_elph300hs-100c-0.9.9-r1418-full.zip (576 KB)
Looks good, doesn't it? 8)
-
Ideally everything specific to the camera should be in the platform files; but there are a few things that are still sprinkled across the core source files.
For a new port, I think the only file that needs to be changed in core source files is core/kbd.c - where you need to set nTxtbl and ZSTEP_TABLE_SIZE.
You can put just about anything in there - its only used by the USB_remote code to control the zoom lens if that option is selected. I'm looking at that code this week again - I'm not even sure it works on current cameras so don't spend too much time worrying about getting the correct values there.
more discussion here : http://chdk.setepontos.com/index.php?topic=6528.msg69252#msg69252 (http://chdk.setepontos.com/index.php?topic=6528.msg69252#msg69252)
-
Using a cBasic dumper script like the one from the wikia, there should be a file named CBDUMPER.LOG with the start address on the SD card...
I just added some colour code to extend.m and was able to see the start address on the screen after that.
Hopefully my description helps others to setup their CHDK environment as well to start porting for IXUS220HS soon.
Indeed, it did help! I had already done some of those steps but made a few more as per your list. The only thing I have not changed yet is the RotaryEncoder part since I have not spent time yet to understand it.
You can put just about anything in there - its only used by the USB_remote code to control the zoom lens if that option is selected. I'm looking at that code this week again - I'm not even sure it works on current cameras so don't spend too much time worrying about getting the correct values there.
good to know!
Try deleting the empty stubs_entry.S file to force it to be recreated.
This did the trick! It is being generated and populated now.
Thanks for the help, folks!
-
Indeed, it did help! I had already done some of those steps but made a few more as per you list. The only thing I have not changed yet is the RotaryEncoder part since I have not spent time yet to understand it.
I'm not sure what RotaryEncoder is for. Therefore it's possible that this change was not correct. Maybe someone else knows?
-
I'm not sure what RotaryEncoder is for. Therefore it's possible that this change was not correct. Maybe someone else knows?
Some cameras have a rotary dial on the back that surrounds the up/down/left/right/set buttons - lets you scroll through pictures and menus without pressing the left/right or up/down buttons.
A quick look at the IXUS220 shows the camera does not have such a dial. So you can delete the rotary encoder code and not start the rotary encoder task.
-
Ah, ok. Thanks for the information!
I attach here my current folder structure inside CHDK Trunk revision 1418 for Firmware 100c of Ixus220HS.
Maybe this will let additional people start with some porting activities.
Only PRIMARY.BIN file is missing in this ZIP-File. You have to add it by yourself into folder "platform\ixus220_elph300hs\sub\100c"
-
Indeed, it did help! I had already done some of those steps but made a few more as per you list. The only thing I have not changed yet is the RotaryEncoder part since I have not spent time yet to understand it.
I'm not sure what RotaryEncoder is for. Therefore it's possible that this change was not correct. Maybe someone else knows?
The task_RotaryEncoder stuff is for cameras with a rear dial/wheel around the Func/Set and buttons.
The IXUS220 doesn't have this so you can delete all the related code from boot.c.
Phil.
-
@philmoz : is there an echo in here ? :P
-
:D
-
@philmoz : is there an echo in here ? :P
Odd, I'm sure the post I responded to was showing as the last post when I replied.
Oh well - probably a brain f..t at my end.
Phil.
-
Wondered if you had me "blocked" = not even sure its possible to do that.
I also noticed that I just started getting DSLR postings again - the "ignore boards" option has been really good about getting rid of that until today.
-
After putting DISKBOOT.BIN to bootable SDCard and starting camera nothing happens (Screen stays black and no LED is turned on).
Afterwards camera can only be activated again after disabling write-protection on SDCard (to disable autoboot of DISKBOOT.BIN) and remove battery for a short time.
It seems that DISKBOOT.BIN is loaded and executed but probably a wrong address/code is called and that's why the camera doesn't show any reaction.
I already adapted boot.c according to the disassembled firmware (like described here: http://chdk.wikia.com/wiki/Adding_support_of_a_new_firmware_version (http://chdk.wikia.com/wiki/Adding_support_of_a_new_firmware_version)).
Files capt_seq.c and movie_rec.c still need to be adapted. But I'm wondering if this is really necessary to just see something happen during startup. For me it would be enough if the camera would send me any "life sign" to keep my motivation up. :)
Currently I don't know what should be my next step!?
Any advice is welcome. :)
I attached latest version of my boot.c file from today.
-
It seems that DISKBOOT.BIN is loaded and executed but probably a wrong address/code is called and that's why the camera doesn't show any reaction.
This is actually encouraging - you have it so that CHDK's DISKBOOT.BIN is being loaded. That's often a tough step for people to get to.
Files capt_seq.c and movie_rec.c still need to be adapted. But I'm wondering if this is really necessary to just see something happen during startup. For me it would be enough if the camera would send me any "life sign" to keep my motivation up. :)
As long as you don't start them in boot.c, you don't need working code in either file.
Currently I don't know what should be my next step!?
Inserting LED blinking code into the loader and then boot.c is the usual next step. Scan through some different camera loader files for examples ....
-
Make this change in boot.c to comment out the other tasks :
void taskHook(context_t **context)
{
task_t *tcb=(task_t*)((char*)context-offsetof(task_t, context));
// Replace firmware task addresses with ours
// if(tcb->entry == (void*)task_CaptSeq) tcb->entry = (void*)capt_seq_task;
// if(tcb->entry == (void*)task_InitFileModules) tcb->entry = (void*)init_file_modules_task;
//if(tcb->entry == (void*)task_PhySw) tcb->entry = (void*)JogDial_task_my;
// if(tcb->entry == (void*)task_MovieRecord) tcb->entry = (void*)movie_record_task;
// if(tcb->entry == (void*)task_ExpDrv) tcb->entry = (void*)exp_drv_task;
}
-
waterwingz, thanks for the hints!
The loader? Hmm, until now I didn't change anything inside loader folder!? I totally forgot about the loader folder. Are there changes necessary (e.g. in entry.S)?
I adapted main.c in loader folder (attached to this message) with code I found in main.c from loader of ixus200_sd980. Result: I was able to let flash both LEDs (1 on front of camera and 1 on back of camera). 8)
-
I adapted main.c in loader folder (attached to this message) with code I found in main.c from loader of ixus200_sd980. Result: I was able to let flash both LEDs (1 on front of camera and 1 on back of camera). 8)
Walk that code forward through the loader code and then try it at the start of the second function module ( sub_FFC00358_my() ) in boot.c ?
-
I did what you told me, and the following functions have been entered in boot.c (verified by LED on/off):
boot()
sub_FFC00358_my()
sub_FFC011B0_my()
:)
Functions that are currently not entered yet:
sub_FF815EE0_my()
taskcreate_Startup_my()
task_Startup_my()
taskcreatePhySw_my()
Assumption: Somewhere in function sub_FFC011B0_my() the execution stops or fails. Will try to investigate.
Attached: new version of boot.c with LED test sequences.
-
I did what you told me, and the following functions have been entered in boot.c (verified by LED on/off):
boot()
Warning : almost everyone gets a little "happy" with fancy LED blinking at this point. Which tends to clobber registers and create timing problems. Stick to :
"LDR R1, =0xC0220130\n" // Back LED
"MOV R0, #0x44\n"
"STR R0, [R1]\n"
If you can get connected to IRC, you can usually get more real-time help ( if reyalp, philmoz or I are there - response varies the rest of the time.
http://webchat.freenode.net/ (http://webchat.freenode.net/)
-
Thanks, I understand that using loops will probably have big influence on timing or generate other issues. Lessons learned: No more loops. ;)
I also tried to avoid register conflicts and I was able to reach code line 263 in attached boot.c.
But function sub_FF815EE0_my() seems not to be reached. Maybe this has to do with call of sub_FFC034C4?
@Sush, how about you? Any progress on your side?
BR,
tommi
-
I probably should have asked this before, but what are you using for a reference port ?
[Edit : reading back. you used the sx220 - also released on the same date as your camera.]
I see that the ixus310_elph500hs has a port released and that camera came out on the same date as yours. The code around the spot where you are having issues is similiar to yours but implemented differently. Or did you already figure that one out ?
-
been away for a chunk of the weekend but back now -
my progress to date:
- stubs_entry.S is being generated
- I have deleted just about all the code in stubs_entry_2.S because I figure it was for the sx220 anyway. I only kept a few lines to get the compilation to proceed
- DISKBOOT.BIN generated but not tested
I have a bit of catching up to do to get to the same stage as tommi2water!
update:
- tried to load DISKBOOT.BIN from the camera - black screen and frozen
- inserted the same LED flashing code that tommi2water has (thanks for the file!) and tried again
- was able to flash the front and back LEDs!
-
Thanks, I understand that using loops will probably have big influence on timing or generate other issues. Lessons learned: No more loops. ;)
I also tried to avoid register conflicts and I was able to reach code line 263 in attached boot.c.
But function sub_FF815EE0_my() seems not to be reached. Maybe this has to do with call of sub_FFC034C4?
@Sush, how about you? Any progress on your side?
BR,
tommi
Your camera rom base address is FF810000. In your boot.c all loc_s are named wrong, all starting with FFC00000. Fix all addresses by hand or use chdk_pt tool to generate them for you.
-
Your camera rom base address is FF810000. In your boot.c all loc_s are named wrong, all starting with FFC00000. Fix all addresses by hand or use chdk_pt tool to generate them for you.
It doesn't really matter what names are used for those loc_ labels as long as the source and destination match.
However, using the actual addresses from your ROM is pretty much "standard practice" for CHDK ports and makes it easier to reference things back to the original code.
-
Thanks Guys! :)
I was completely wrong when I compared boot.c to disassembled code because I imported PRIMARY.BIN with wrong base address 0xFFC00000 into disassembler and not with correct address 0xFF810000. I was just following the DryOS Porting Guide without any thinking. :D
Therefore I tried to call some 0xFFC0-addresses from my changed boot.c. :(
I will change base address in disassembler to correct address and start again comparing boot.c content to disassembled code.
-
I was completely wrong when I compared boot.c to disassembled code because I imported PRIMARY.BIN with wrong base address 0xFFC00000 into disassembler and not with correct address 0xFF810000. I was just following the DryOS Porting Guide without any thinking. :D
Are you using CHDK-PT ? It produced output in "C" compatable format, saving you the trouble for converting it from the standard output format of most dissassemblers.
-
Not yet, will download and take a look at it. :)
-
Wow, with CHDK-PT it was quick and easy to get some output in good format. Comparison with my boot.c was very easy now. :)
But I'm still not able to execute function sub_FF815EE0_my(). LED-Debug at the beginning of this function seems not to be executed.
I added additional functions (sub_FF8134C4_my + sub_FF816810_my) from ROM to my boot.c and added LED-Debug to them to see where execution stops, but at the moment I have no idea. They seem to be executed fine.
My last version of boot.c and some CHDK-PT output files are attached to this message.
Any ideas?
-
Did you take a look at the boot.c code for the ixus310_elph500hs ?
-
Yes, I looked into it, thanks for the hint.
What I found out is, that they just branch back to the original ROM instead of executing the same five instructions from their boot.c file after they did the "LDR R1, =sub_FF815EE0_my" instruction.
I tried the same as you can see in line 275 "B sub_FF81124C" of my latest boot.c file, but I didn't recognize a different behaviour. So I returned to original implementation.
-
This is my boot.c and movie_rec.c
-
Majsi, thanks for your files.
Good to see that another person has now started porting. :)
I looked at least into your first uploaded boot.c and found additional information which I could use.
I'm wondering why you can use all these "ADRLT" instructions in your sub_FF815EE0_my() function. If I try to use them I get an error during compilation. That's the reason why I use "LDRLT".
In line 602 of your boot.c:
"BNE loc_FF81FD2C"and in line 608 of your boot.c:
"B loc_FF81FD18"
Aren't you missing "\n" at the end?
To find out why sub_FF815EE0_my() is not reached, I digged deeper into the disassembled code and found out one thing.
In line 471 of my attached boot.c file:
" STRNE R1, [R3, #4] \n"
If this line is commented out, next lines are executed. But if STRNE instruction is executed, no more instructions seem to be executed.
It seems that some kind of linked list / array is changed which was loaded here first (line 432 in attached boot.c):
" LDR R0, =0x19F4 \n"
Does anyone has an idea what values are stored at 0x19F4 and why STRNE seems to stop execution?
-
I found another discussion about exactly the same issue which I have:
Grr, I'm not getting very far with my S5... In the function where wHwSetup_my is hooked
"LDR R1, =uHwSetup_my\n" // followup to own function
a call to sub_FF812D84 is made, which calls ... which calls .. and so on, until I reach sub_FF818BB0 (A720 equiv sub_FFC08C98, identical in both cameras). For some reason execution stops at
"STRNE R1, [R2,#4]\n"
and I don't know why. The addresses it's referencing look quite alike in both firmwares but for some reason it's acting up in the S5. If anyone has any ideas, please :) In the meantime, I guess I'll look over the complete code again to make sure I didn't make an error anywhere.
What makes me happy: Finally they did a successful port of CHDK to S5IS camera. :)
What makes me sad: I'm not able to find the solution for this issue from reading the followed discussion. :(
The only thing I see is that they talk about memory settings / addresses.
e.g. comment from jeff666:
One thing I forgot to mention is that you will need to change platform/<dev>/sub/<rev>/makefile.inc
You need to change
* MEMISOSTART, CHDK gets relocated there
and
* ROMBASEADDR
...
What happens is:
the firmware copies an amount of memory from ROM to RAM. This happens at FFC00130 (A720). Check the declarations at the beginning of boot() and you will recognize the numbers.
The firmware code that copies this memory is skipped and instead copied in boot().
The main memory pool (originally) starts right above this limit. Its address is indicated by R0 in the shown code.
We move the memory pool a little up by adding 196k (0x30000), thus creating room for CHDK to live. This room is referred to in MEMISOSTART
Originally only 128k were added, but as reported in this thread my code was overwritten. Thus everything is moved up a little more.
So before anything can work, you have to adjust these numbers.
As I don't really know which values have to be used, I would like to ask if someone could review my attached makefile.inc file or tell me how I can find out the correct values by myself.
-
I found another discussion about exactly the same issue which I have:
And another discussion, where they also solved the issue:
http://chdk.setepontos.com/index.php?topic=1132.msg15653#msg15653 (http://chdk.setepontos.com/index.php?topic=1132.msg15653#msg15653)
Now I have to understand how they solved.
-
As I don't really know which values have to be used, I would like to ask if someone could review my attached makefile.inc file or tell me how I can find out the correct values by myself.
Remove the EXMEM overrides at the start - you need a working CHDK version before you can determine what EXMEM values to use. The chances of the values from the port you started with working are pretty slim.
Get it working in the Canon heap memory first. You should disable games, the calendar and textreader in buildconf.inc (or localbuildconf.inc) to create as small a version as possible initially.
All the functions you've copied into boot.c from line 284 - 510 should not be needed.
Phil.
-
Hello Phil,
thanks, I reduced the DISKBOOT.BIN size from 200KB to 127KB.
I also disabled the EXMEM feature.
But I still have no different behaviour yet.
I was wondering if I would be able to start original firmware via my DISKBOOT.BIN to verify if it is working in general.
Because currently I only verify my local code from boot.c when I look at LEDs blinking.
I tried to use direct firmware call very early in boot.c but I'm still at black screen and no further reaction:
"B sub_FF810358\n" //original
//"B sub_FF810358_my\n" //patched
How can I start the original firmware from ROM via my DISKBOOT.BIN to verify my stuff at the very beginning?
-
Hello Phil,
thanks, I reduced the DISKBOOT.BIN size from 200KB to 104KB.
I also disabled the EXMEM feature.
But I still have no different behaviour yet.
I was wondering if I would be able to start original firmware via my DISKBOOT.BIN to verify if it is working in general.
Because currently I only verify my local code from boot.c when I look at LEDs blinking.
I tried to use direct firmware call very early in boot.c but I'm still at black screen and no further reaction:
"BL sub_FF8111B0\n" //original
//"BL sub_FF8111B0_my\n" //patched
How can I start the original firmware from ROM via my DISKBOOT.BIN to verify my stuff at the very beginning?
If you have autoboot enabled and jump back to the original firmware you will get in a loop with the camera repeatedly trying to boot CHDK.
You can use the manual boot method on an unlocked card to get around this.
Phil.
-
Manual boot means using "FirmwareUpdate" menu entry in original Canon Menu? Hmm, then I need to generate a fi2 file first.
I will jump into "fi2 encoder/decorder" topic (http://chdk.setepontos.com/index.php/topic,2995.0.html (http://chdk.setepontos.com/index.php/topic,2995.0.html)) to understand how I can generate the necessary file to be able to activate FirmwareUpdate-MenuItem.
Update:
Got the manual boot working with fi2 file. :)
I will do more investigations by tomorrow.
-
You should also comment out all the overrides in taskHook (boot.c).
Until you've finished porting each of the override functions you shouldn't replace the firmware ones.
Phil.
-
All,
after falling down in more and more confusion I did a complete new start by today [and this was a good decision]. ;)
Now I used/reviewed code from camera ixus310_elph500hs. Waterwingz inspired me to do this because he wrote a comment regarding this 3 days ago. Thanks for the inspiration! 8)
This time I also adapted my loader files.
Result:
After I start my DISKBOOT.BIN I still get a black screen. But after about 20 seconds I'm able to start the camera again (this works with manual boot and as well with autoboot[verified with LED blinking at startup]). btw: I'm not sure if in my previous version I would have been able to start the camera again after 20 seconds because I never tried that.
What is really new: with LED debugging I found out that it executes much more from boot.c this time. :)
It now reaches the following function and executes it:
void __attribute__((naked,noinline)) taskcreatePhySw_my() {
asm volatile (
" STMFD SP!, {R3-R5,LR}\n"
" LDR R4, =0x1C3C\n"
" LDR R0, [R4,#0x4]\n"
" CMP R0, #0\n"
" BNE sub_FF834A20\n" // continue in firmware
" MOV R3, #0\n"
" STR R3, [SP]\n"
" LDR R3, =mykbd_task\n" // task_PhySw
" MOV R2, #0x2000\n" // stack size for new task_PhySw so we don't have to do stack switch
// this line was reached, verified by LED blinker
"B sub_FF834A10 \n" // continue in firmware
);
}
But it doesn't get back to the location where the call of taskcreatePhySw_my() was done. Has this something to do with the "mykbd_task"?
I attached the current version of my "project".
New in this version is changed "boot.c" (now based on ixus310_elph500hs code) and changed "resetcode/main.c" from loader.
I'm now wondering what leads the camera to do a shutdown (because it can be started again after 20 seconds I assume that it does a clean shutdown)?
Awaiting your comments/ideas/review. :)
-
This code was also already executed:
void spytask(long ua, long ub, long uc, long ud, long ue, long uf)
{
core_spytask();
}
It seems that I'm on the right way. :)
-
Getting there :)
I haven't looked at the code in detail; but I noticed a couple of things in boot.c.
First you should get rid of everything related to the touch screen - this is unique to the IXUS 310 so you won't need it.
The line:
*(int*)(0x2638) = (*(int*)0xC0220130)&1 ? 0x200000 : 0x100000;
should be
*(int*)(0x25F4) = (*(int*)0xC0220130)&1 ? 0x200000 : 0x100000;
I would also move the call to CreateTask_spytask to just before taskcreatePhySw_my.
Finally in stubs_entry_2.S you have a bunch of values at the end pointing to a 'NULL' function; but you are using an address that is not in the firmware for your camera. I would delete everything from line 165 down in this file and re-compile. If there are any undefined functions add just those back pointing a valid function in the firmware (look for a function that just does a 'BX LR' instruction).
Phil.
-
I did the changes you proposed. Thanks for that. :)
In addition I commented out the taskcreatePhySw_my call to avoid creation of mykbd_task (advise from reyalp from #chdk irc channel).
"BL CreateTask_spytask\n" //added
//"BL sub_FF8349EC\n" //taskcreate_PhySw()
//"BL taskcreatePhySw_my\n" //patched
Result:
After start of DISKBOOT.BIN the lens comes out and for a short moment the display gets active and I can see the Canon HS-System logo. Then camera switches off with lens outside. Camera can be switched on again immediately and lens goes back into camera. ;)
More investigations tomorrow, now I have to get some sleep before going to work early in the morning. :)
-
A couple more things I noticed.
in sub/100c/lib.c:
- vid_get_viewport_fb is wrong, the correct value is shown in stubs_entry.S, copy it from there.
- same for camera_jpeg_count_str
in lib.c:
- the vid_get_XXX functions are probably wrong, these are from the IXUS 310 which has a 16:9 widescreen LCD. Look at the SX30 which would probably be a closer match.
- the vid_bitmap_refresh function is calling _LockAndRefresh and _UnlockAndRefresh. These aren't found automatically and the values you have defined in stubs_entry_2.S are from another camera (the addresses are not in the firmware). This is probably the cause of the crash. Try using _ScreenLock and _ScreenUnlock instead (see the SX30 port).
Phil.
-
Hi, I just got an ELPH 300 HS to shoot with when I don't feel like lugging my 60D kit around. I love the portability, but I have a hard time adapting to the lack of functionality. So I'd like to contribute to the CHDK port. I'm well versed in C and have done some microcontroller development (such as an ATMEGA48-based intervalometer for my 60D :D). Not experienced with ARM assembly (though I have done x86, MIPS, and z80, so I think I could pick it up).
I was wondering if there's some place I could start poking around without duplicating others' efforts. I've got the environment downloaded and set up, and have built the ELPH 500HS port.
-
I was wondering if there's some place I could start poking around without duplicating others' efforts. I've got the environment downloaded and set up, and have built the ELPH 500HS port.
There's an old saying "It never rains, it pours." I don't think I've seen a port in recent years with two active developer's - never mind three !
Welcome on board. Even once there is a port that runs, there is lots of work to do. The files in the platform subdirectory called shooting.c, main.c and lib.c all have things that need to be tweaked for each specific camera. I'm sure you guys can work out a way to split up the effort. And there will probably also be different firmware versions to worry about.
-
Speaking of firmware versions - I finally figured out how to tell which I have: 1.01a.
Since the other two devs in this thread have 1.01c, and there does not seem to be a firmware upgrade available from Canon, I imagine I've got to start from the beginning anyhow. So no worries about duplicating efforts...
-
Since the other two devs in this thread have 1.01c, and there does not seem to be a firmware upgrade available from Canon, I imagine I've got to start from the beginning anyhow. So no worries about duplicating efforts...
Take a look at CHDK-PT (http://chdk.wikia.com/wiki/CHDK-PT_:_A_tool_for_porting_different_firmware_versions_on_the_same_camera). I might be accused of a bias here, but it could also save you some time.
-
Welcome to the gang, jstanely0.
Tommi is using firmware 1.00c and I have 1.01c
Tommi seems to be making some progress but I am pretty much stuck at:
Functions entered:
boot()
sub_FF810358_my()
sub_FF8111B0_my()
Functions that are currently not entered yet:
sub_FF815EE0_my()
taskcreate_Startup_my()
task_Startup_my()
taskcreatePhySw_my()
-
Thanks for all the good Tips, Phil! I will try them this afternoon when I'm back from work.
Welcome jstanley! :-)
@Sush: I had the same Problem like you now have. Take a look at the new loader stuff I attached yesterday and give it a try.
-
I changed all items that Phil mentioned.
And in addition I took some more lines from ROM into boot.c to be able to comment out another nullsub-function.
And the result is:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fwww.bilderkiste.org%2Fshow%2Foriginal%2F4132215331525%2Fixus220hs_100c.jpg&hash=9db53774b4e2f8f6c0de4ccfa23ce067)
::)
Still not running: the mykbd_task
But this screenshot means that the Spytask is already running, right?
btw: As you can see from the photo, I changed my used trunk to revision 1424.
It already created the CHDK folder structure on the SD-Card. :)
-
Nice work!
I've been diving into the docs and other ports, and my head is spinning. I don't know where to begin.
To get a feel for how ports differ by firmware version, I've been diffing sub folders in various ports. In the 500HS, 100a vs 101a, a handful of addresses shifted forward by 0x18, leaving most of the code identical (then again, this isn't a complete port - the S2IS code changes a _lot_ more between firmware versions).
-
But this screenshot means that the Spytask is already running, right?
btw: As you can see from the photo, I changed my used trunk to revision 1424.
It already created the CHDK folder structure on the SD-Card. :)
Correct - spytask draws that text box on the screen. But the logo is missing. Did you populate the CHDK folders - that's where the logo image is read from. If so, are you dual booting ? The folders have to be on the larger partition if so.
-
To get a feel for how ports differ by firmware version, I've been diffing sub folders in various ports. In the 500HS, 100a vs 101a, a handful of addresses shifted forward by 0x18, leaving most of the code identical (then again, this isn't a complete port - the S2IS code changes a _lot_ more between firmware versions).
You typically only have to change three files to port between firmware versions - boot.c, capt_seq.c and movie_rec.c. And you can use CHDK-PT to do most of the work with its "Convert Address List" button.
Changes in the other firmware specific files are pretty much all caught by the new signature generator so study the stubs_entry.S output file. Its pretty good at pointing out discrepancies.
-
Currently no dual-booting in use.
And until now I didn't put CHDK folder content onto SDCard.
Now I tried with CHDK folder content and I can see the CHDK logo as well.
I will put my current code together in a zip file and provide here soon.
This could be used as basis for the ports of sush and jstanley. Then they should be able to easily change the files that they fit with their firmware version.
But still I have to figure out why I'm not able to start the mykbd_task.
-
But still I have to figure out why I'm not able to start the mykbd_task.
I'm having an amazing sense of "deja vu". All the way back to a long Saturday a couple of weeks ago spent on IRC with sgtrum and his sx150 port. There is a nasty little bit of assembly code in the function wrap_kbd_p1_f() buried in the platform/kbd.c file that apparently has to be changed for some of the newer cameras.
Here's the resulting post
http://chdk.setepontos.com/index.php?topic=6953.msg75387#msg75387 (http://chdk.setepontos.com/index.php?topic=6953.msg75387#msg75387)
Maybe this will save you some time.
-
Here I attached my current version which is for Firmware 1.00c and already starts the CHDK Spytask.
The kbd task is still not running. Therefore I commented out line 459 in boot.c and call the original taskcreate_PhySw function. Then camera starts up and I see the CHDK logo: Spytask is already running and camera can be used in a normal way. I think this is already a big step. :)
btw: I didn't work on capt_seq.c and movie_rec.c.
To adapt this code to your version of firmware, you should first concentrate on boot.c and compare addresses of 1.00c firmware (http://www.box.com/shared/tscho3m30j/4/55272271/669226134 (http://www.box.com/shared/tscho3m30j/4/55272271/669226134)) with addresses of your firmware.
I'm very interested if you get into the same problems of starting the kbd task.
Maybe we can solve the problem together. More people -> more creative ideas. :D
Next I will check the "deja vu"-post. ;)
-
Hmm, wrap_kbd_p1_f() looks good.
from platform/kbd.c:
" STMFD SP!, {R1-R7,LR}\n" //SX220 modified
" MOV R5, #0\n"
// " BL _kbd_read_keys\n" // replaces kbd_fetch_data()
" BL my_kbd_read_keys\n" // +
" B _kbd_p1_f_cont\n" // continue
-----------------------------------------------
from firmware 1.00c:
FF834E94 " STMFD SP!, {R1-R7,LR} \n"
FF834E98 " MOV R5, #0 \n"
FF834E9C " BL sub_FF834E18 \n" // address equal to kbd_read_keys from stubs_entry.S
FF834EA0 " LDR R2, =0x3418C \n" // address equal to kbd_p1_f_cont from stubs_entry.S
That is still one file which I took from SX220HS, because IXUS310 had many touch_screen stuff inside.
-
Puuuh, it seems I got it. :)
I had to change in platform/kbd.c:
from: _SleepTask(*((int*)(0x1c40+0x8)));//10);
to: _SleepTask(*((int*)(0x1c3C+0x8)));//10);
Now mykbd_task should be running.
Can I make keypresses visible on screen to find out which keymapping I have to use?
-
Wow! Great to see progress in this thread.
How do you determine the firmware revision?
-
How do you determine the firmware revision?
You could do it the same way Sush did it: http://chdk.setepontos.com/index.php?topic=6341.msg76096#msg76096 (http://chdk.setepontos.com/index.php?topic=6341.msg76096#msg76096)
... I believe I have 1.01c since the exif in the jpgs says 1.01 revision 3.00 ...
Make a photo and read out the EXIF information from the JPG.
-
Can I make keypresses visible on screen to find out which keymapping I have to use?
The key map is all done for you in stub_entry.S. These things are so easy these days ....
-
How do you determine the firmware revision?
link : Determining the firmware version in your camera. (http://chdk.wikia.com/wiki/FAQ#Q._How_can_I_get_the_original_firmware_version_number_of_my_camera.3F)
-
I had to change in platform/kbd.c:
from: _SleepTask(*((int*)(0x1c40+0x8)));//10);
to: _SleepTask(*((int*)(0x1c3C+0x8)));//10);
I'm not sure why they do it that way. This works too : _SleepTask(10) ;
-
The key map is all done for you in stub_entry.S. These things are so easy these days ....
Indeed, I remember some years ago when I followed the Porting Thread of DataGhost et al. for the S5IS camera. That was the time when the development for DryOS just started, if I remember correctly. Everything seemed to be much more complicated, at least to get all the addresses collected.
I already moved the key mapping values from stub_entry.S during the beginning of my porting activities. But I didn't remember again. ;)
I'm not really sure if mykbd_task is really running. I can use keys for normal Canon usage but I'm not able to activate the ALT menu.
-
I'm not really sure if mykbd_task is really running. I can use keys for normal Canon usage but I'm not able to activate the ALT menu.
Well done :)
<ALT> is normally activated using the Print button which you don't have.
Look at the SX220 / SX230 versions to see what they did - Func + Disp together if I recall correctly.
Phil.
-
I already tried SET + DISPLAY but no reaction.
Just for testing I mapped PRINT Button to 0x80 which is the same like the UP Button.
But still no reaction.
I think I have to add some debug output in mykbd_task to see if it is really executed.
Can I print some debug messages on the Display or is that to complicated?
-
Can I print some debug messages on the Display or is that to complicated?
I keep promising myself to write this down so I don't have to re-invent every time.
extern void draw_string(coord x, coord y, const char *s, color cl);
char buf[64];
sprintf(buf,"%s","Test Message");
draw_string(16,16,buf,MAKE_COLOR(COLOR_BLACK,COLOR_YELLOW));
-
Thanks, that worked fine.
But if I would have used the search function first I would have found enough examples in this forum. Sorry. ;)
I will continue tomorrow and report here about my investigations.
-
But if I would have used the search function first I would have found enough examples in this forum. Sorry. ;)
No problem - searching the forum would not have answered the question about whether your port is far enough along to print debug messages.
-
nice progress, Tommi!!
I'm trying to debug using the heap, as recommended, but I end up with the following compilation errors:
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `exmem_malloc_init':
wrappers.c:(.text+0x818): undefined reference to `suba_init'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `malloc':
wrappers.c:(.text+0x858): undefined reference to `suba_alloc'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `free':
wrappers.c:(.text+0x890): undefined reference to `suba_free'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `GetExMemInfo':
wrappers.c:(.text+0x8fc): undefined reference to `suba_getmeminfo'
I'm likely missing a library but which library is it and where do I specify it?
edit: nevermind, found the suba.c file in core. I think the problem is related to the rules to build wrapper.o
-
Sush, could you please provide your complete code package (loader + platform) like I did some posts ago? Please remove PRIMARY.BIN before. ;)
I would like to reproduce your error on my pc. Without reproducing it's hard to say what could be the problem.
Don't understand why you run into problems which I never had!?
-
nice progress, Tommi!!
I'm trying to debug using the heap, as recommended, but I end up with the following compilation errors:
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `exmem_malloc_init':
wrappers.c:(.text+0x818): undefined reference to `suba_init'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `malloc':
wrappers.c:(.text+0x858): undefined reference to `suba_alloc'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `free':
wrappers.c:(.text+0x890): undefined reference to `suba_free'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `GetExMemInfo':
wrappers.c:(.text+0x8fc): undefined reference to `suba_getmeminfo'
I'm likely missing a library but which library is it and where do I specify it?
edit: nevermind, found the suba.c file in core. I think the problem is related to the rules to build wrapper.o
Looks like a problem with your makefile or makefile.inc.
Make sure you don't have any overrides for EXMEM values in your makefile.inc - you won't be able to set these up until you have a working port.
Have a look at the makefile.inc in tommi2water's version.
Phil.
-
Cheers for the tips. I have firmware version 1.01c. I've dumped my firmware and am now setting up the devel environment (on ubuntu/linux). Cross compiler is compiling...
-
I am using 0.9.9 on an ubuntu platform. I've been having issues with this environment: make clean's don't really clean the tree, the compilation issue mentioned above (which disappeared now). In the past, the stubs_entry.S wasn't being built. I might just wipe it all and start again.
-
I got tommi's 100c port to build. Had to make a few changes to core\kbd.c (to define ZSTEP_TABLE_SIZE/nTxtbl; I borrowed the one from the 500hs for now, even though I'm almost certain it's wrong), and core\gui.c (for CAM_ADJUSTABLE_ALT_BUTTON; I borrowed the one from the sx200hs because it looked closest--the 500hs doesn't appear in this table, because its platform_camera.h doesn't have CAM_ADJUSTABLE_ALT_BUTTON in it, presumably because it's got a touchscreen).
Now I'm trying to use CHDK-PT to adapt to my camera's firmware version, 101a. (FWIW: I put a note in the wiki to mention the fact that camera models don't appear in Makefile/Makefile.inc anymore, and you need to instead edit cameras.csv. You may want to touch up my edit.)
During the convert phase, I get the following popup at 8 percent:
Error : requested address FF16C62C is outside the specified ROM range for camera model [FF810000 to FFFFFFFF]
I had selected "S series camera @ FF810000" from the menu, recalling seeing that number elsewhere in this thread and noting that an 8MB firmware jutting up against the top of the address space would start about there. If I try "other camera @ FF000000", then I get a stubs_entry_2.S out, but it appears to be rubbish (it's full of "WARNING: too many matches for DebugAssert" and the like, and then it lists a dozen stubs at the same address later on).
I'm out of time at the moment, but I should be able to get back to this later today. I think I'll just try hacking on stubs_entry_2.S manually. Diffing the stubs_entry.S files generated for the two versions only shows 12 entries under "Stubs below should be checked".
-
Had to make a few changes to core\kbd.c (to define ZSTEP_TABLE_SIZE/nTxtbl; I borrowed the one from the 500hs for now, even though I'm almost certain it's wrong),
Its only used if you have a USB remote switch enabled and are attempting to use the remote zoom function.
and core\gui.c (for CAM_ADJUSTABLE_ALT_BUTTON; I borrowed the one from the sx200hs because it looked closest--the 500hs doesn't appear in this table, because its platform_camera.h doesn't have CAM_ADJUSTABLE_ALT_BUTTON in it, presumably because it's got a touchscreen).
Enabling an alternate ALT button is up to the individual developer's preference. Some ports have it, some don't . There does not seem to be any rhyme or reason to why.
Now I'm trying to use CHDK-PT to adapt to my camera's firmware version, 101a. (FWIW: I put a note in the wiki to mention the fact that camera models don't appear in Makefile/Makefile.inc anymore, and you need to instead edit cameras.csv. You may want to touch up my edit.)
Thanks - missed that. I took the liberty of doing the suggested "touch up". Might as well make the default description apply to the current build structure.
During the convert phase, I get the following popup at 8 percent:
Error : requested address FF16C62C is outside the specified ROM range for camera model [FF810000 to FFFFFFFF]
I had selected "S series camera @ FF810000" from the menu, recalling seeing that number elsewhere in this thread and noting that an 8MB firmware jutting up against the top of the address space would start about there. If I try "other camera @ FF000000", then I get a stubs_entry_2.S out, but it appears to be rubbish (it's full of "WARNING: too many matches for DebugAssert" and the like, and then it lists a dozen stubs at the same address later on)..
I haven't had a "bug report" in a long time. :o
I assume you were trying to convert the stubs_entry_2.S file from tommi2water's zip file ? It gets tied up if it finds too many matching code sections for a short routines in NHSTUB entry - DebugAssert and Nullsubs ( BX LR ) for example. Ignore the warnings.
You could probably delete everything in your stubs_entry_2.S file, recompile and then add back in only the things that show up as misssing. Then convert that file (ignoring the repeated warnings). A much easier process.
The labels in the code in boot.c indicate the firmware starts at FF000000. So does this post http://chdk.setepontos.com/index.php?topic=6341.msg76229#msg76229 (http://chdk.setepontos.com/index.php?topic=6341.msg76229#msg76229)
-
Hi all,
for physw_status[2] I could print out the following values in function my_kbd_read_keys() (line 192 in attached kbd.c):
// 10cfff "no key is pressed"
// 10cfbf DISPLAY key is pressed
// 10cffd SET key is pressed
// 10cfbd SET + DISPLAY keys are pressed at the same time
This means that mykbd_task is really running and analyzing the key presses. :)
DISPLAY key was not available from entry_stubs.S and was configured with 0x800. But it seems that it has value 0x40 (0x10cfff[no key pressed] - 0x10cfbf [DISPLAY key pressed] = 0x40).
SET key has value 0x02.
Both keys pressed together should activate the ALT menu.
Therefore the answer is 0x42. I assume that in "The Hitchhiker's Guide to the Galaxy" the answer also was in hex value? :D
I changed values for ALT_mode_key_mask and KEY_PRINT to 0x42 (like it is now in attached kbd.c).
When I press the SET key a second time after pressing together with DISPLAY key I only see:
// 10cfff when SET key is pressed, means the value is not changing!?
It is somehow ignoring further presses of SET key after I have pressed SET key once together with DISPLAY key.
DISPLAY key is still executed. If I press DISPLAY key I still see value 0x10cfbf.
No ALT mode available for now.
btw:
I had to change in platform/kbd.c:
from: _SleepTask(*((int*)(0x1c40+0x8)));//10);
to: _SleepTask(*((int*)(0x1c3C+0x8)));//10);
I'm not sure why they do it that way. This works too : _SleepTask(10) ;
In the meantime I tried this as well and I can confirm, the _SleepTask(10) variant works as well. :)
-
I changed KEYS_MASK2 to (0x00000000)
Now the buttons are changing the keypress value also after pressed in combination.
But no ALT mode.
As I don't really know how it works I try to play around with some values and I'm hopefully lucky (at some day ...). ;)
-
Ok, ALT mode is now available, too. :D
I looked at the back of some Canon cameras and the ixus120_sd940 looked similar regarding the buttons.
ALT mode can be reached with KEY_ZOOM_OUT when using attached kbd.c
Next step will be to adapt to a better key for entering ALT mode because zoom_out_button is not really useful for this. ;)
-
Ok, ALT mode is now available, too. :D
I looked at the back of some Canon cameras and the ixus120_sd940 looked similar regarding the buttons.
ALT mode can be reached with KEY_ZOOM_OUT when using attached kbd.c
Next step will be to adapt to a better key for entering ALT mode because zoom_out_button is not really useful for this. ;)
The IXUS120-SD940 uses the DISP button to enter <ALT> mode. There is some code in its kbd.c file to time how long the DISP key is pressed - short for <ALT>, medium for Brightness, long for change display ( the medium and long presses emulate the original Canon functionality)
-
Yes, I tried that, but KEY_DISPLAY is the same as KEY_DOWN in IXUS220. On IXUS120-SD940 it is a separate button.
Can you imagine how surprised I was when I was in ALT menu and wanted to go down? ;)
On IXUS220 there is one special separate button, the Video button. I will try to use that one.
-
Using KEY_VIDEO 0x4000 works like a charm! :)
Short Press Video button => ALT mode toggling
Long Press Video button => original Canon functionality
I can activate ALT mode, enter ALT menu, scroll through, activate/deactivate ...
But: How can I disable mapping of Keys to original Canon software? Have the KEYS_MASK defines to be used for this?
Answer: Yes, KEYS_MASK defines are exactly for this! Working, no annoying Canon OSD activity when in ALT mode. ;)
Result:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fwww.bilderkiste.org%2Fshow%2Foriginal%2F2132224852592%2Fixus220hs_100c_chdk.jpg&hash=958b07d582e9f088900ac0922f99a1de)
-
Using KEY_VIDEO 0x4000 works like a charm! :)
Yet one more ALT key. For you is it a good solution. But please read this thread: http://chdk.setepontos.com/index.php?topic=6787.msg72296#msg72296 (http://chdk.setepontos.com/index.php?topic=6787.msg72296#msg72296)
Btw, you make a good porting job!
msl
-
Thanks for the hint, msl. I'm also no friend of special solutions / workarounds.
For me it's no problem to let another key work like a charm. ;)
I will find out the corresponding key value and test it.
Update: KEY_PLAYBACK has value 0x8000
Uuuh, I don't get the Playback button under control? It switches between REC and PLAY mode.
For further testing I would like to stay with my KEY_VIDEO solution. But full acknowledge to change it to KEY_PLAYBACK later.
-
One thing, you have to manually populate the keymap table in kbd.c.
The first entry is the index into the physw_status array of the key, the second entry is the keyname, and the third is the bitmask for the key.
Bits in physw_status go low when the keys are pressed; so when you see a bit go low set that bit in the third entry in keymap.
When you have all the bits defined OR them together for each index value to get the KEYS_MASK? values.
To see physw_status enable the debug code in gui_draw_debug_vals_osd (gui.c) at around line 2290.
Phil.
-
One thing, you have to manually populate the keymap table in kbd.c.
I think I'm already done with the keymap table.
I tested all available buttons/zoom and they work fine when CHDK is running.
Shooting images is also possible.
At this point I would like to cleanup my code a little bit and then commit this as a first (alpha?) version to CHDK repository (or give my code to someone who will do this). Is that already possible?
-
Great job Tommi. You're really making some fast progress on this.
-
Thank you Tommy (and anyone who helps) for your job!
I have a question:
Is porting to a different version of the firmware (like 1.01A,1.01C, etc.) as difficult as it is for a different camera model?
-
Is porting to a different version of the firmware (like 1.01A,1.01C, etc.) as difficult as it is for a different camera model?
What I learned during my recent porting activities is, that it is not very difficult to port a different firmware version from an existing port of another firmware of the same camera.
I expect that only some addresses need to be changed.
If you take my code (btw: porting is not yet finished, I only worked on loader, boot.c and kbd.c) you should have a good starting point.
Download Firmware for 1.00c (which I am porting to).
Get CHDK-PT.
Look (first in loader files and in boot.c) for each address which is greater than 0xFF810000 and check that address in Firmware 1.00c with CHDK-PT. Save the found instruction code to a text file.
Than search in your Firmware version for the same piece of code. Probably it will be just some additional offset. But to be sure, please compare found Firmware functions with the used sub_FFxxxxxx_my functions in boot.c to have the correct instructions used in the functions.
btw: I only used CHDK-PT the way to save instruction sequences and load them into Notepad++ for comparison with my boot.c code. Maybe CHDK-PT has much more power to do some work for you? Waterwingz will know more about CHDK-PT usage.
Maybe it is also useful if you compare stubs_entry.S from 1.00c with your firmware's version.
As I am not much experienced with these activites maybe someone else can give additional tipps which can save you some more time?
-
I cleaned up my code and moved it to trunk revision 1431, built and tested it.
Source Code (File: ixus220_elph300hs_100c_trunk1431_20111126.zip) and as well a first version of binary files (File: ixus220_elph300hs_100c_trunk1431_20111126.zip) for testing are attached to this post.
This should only be used for IXUS220HS / ELPH300HS with Firmware version 1.00c!
This first port of ixus220_elph300hs is based on trunk1431 of CHDK.
changes have been made to the following files/folders:
trunk1431/core/gui.c // add support for ixus220_elph300hs
trunk1431/core/kbd.c // add support for ixus220_elph300hs
trunk1431/camera_list.csv // add ALPHA Status entry for ixus220_elph300hs
trunk1431/loader/ // add new folder "ixus220_elph300hs" with loader files for ixus220_elph300hs
trunk1431/platform/ // add new folder "ixus220_elph300hs" with platform files for ixus220_elph300hs Firmware 1.00c
Firmware 1.00c for camera ixus220_elph300hs was taken from here:
http://www.box.com/shared/tscho3m30j/4/55272271/669226134 (http://www.box.com/shared/tscho3m30j/4/55272271/669226134)
btw:
This port is not yet finished, it is just an alpha version. I just started a request to bring this alpha version into source code repository.
And:
This port would never have been possible to be done by me without the great support of:
philmoz
waterwingz
reyalp (on CHDK IRC channel)
and of course all people who provided helpful information in some older threads ;)
Thanks for your support!
Now we have to check this port for missing working features to bring this port to a final version. :)
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
Incredible work, tommi (and the others too ;))
I've got very little programming experience, but I'd like to help with testing. I have firmware ver. 1.01a, though, so probably I've got to wait until someone ports it...
I briefly looked through the wiki articles on porting to a new firmware version, and it doesn't seem like it's as much of work as porting to a new model. It's mostly way over my head though.
If anyone without ver. 1.01a would like to try porting it, I'd love to help testing.
I have a fair bit of time, too.
Also, this confuses me: Would porting tommi's alpha version to another firmware require modifying ONLY the loader files and boot.c?
Meaning that once this basic (loader and boot.c) porting is done, any further bugfixes or developments on to this model would apply to ALL firmware versions, once this basic firmware porting has been completed?
Or does each firmware have to be developed separately like a different model? :blink:
Thanks again for all your efforts, and good job! I'm quite excited about the prospect of running CHDK on my camera! :P
-
I compared some address ranges in firmware files from 1.00c, 1.01a and 1.01c.
Found some small differences and changed boot.c and as well stubs_entry_2.S.
Please find attached for testing the first binaries for 1.01a and 1.01c firmware.
As soon as you provide positive feedback, that you were at least able to start CHDK (please provide information about your used firmware [1.01a or 1.01c]) I will upload the folders with source code for 1.01a and 1.01c [depending on your feedback].
Put content of zip-files on a SDCard and start camera with Play-Button. Press Menu-Button and select "Firm Update ..." entry and press OK.
Camera should start in normal record mode and after some seconds you should see CHDK logo. <ALT> mode can be activated by pressing Video button. Normal video functionality can be access by long press of Video button.
Please describe the behaviour of your camera in a small test report if possible. Thanks!
Use at your own risk.
If you have further questions please take a look at:
http://chdk.wikia.com/wiki/FAQ (http://chdk.wikia.com/wiki/FAQ)
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
tommi, what changes did you make to boot.c for 101a? just curious. I didn't see what to change there. I modified a dozen entries from stubs_entry_2.S based on the diffing the generated stubs_entry.S files. But the binary I built did nothing but black-screen.
anyhow, your build is up and running on my 101a.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FPfini.jpg&hash=6415aae90e2dac125d6d13d2a6637f45)
haven't figured out how to make it do anything useful yet - it just kind of displays flickering overlays on top of canon stuff.
-
I copied DISKBOOT.BIN and PS.FI2 onto the root of my card and ran Firm. Update. (Ver. 1.01a)
The result:
After a second, the lens comes out and the screen loads as normal.
After a few seconds, I see this:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FgSSYJ.jpg&hash=ab3e4389422fdf8e4d455af9b752a1ce)
Pressing the video button results in no ALT menu showing up, but text at the bottom left saying "Default Script <ALT>", like this:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FV1vcA.jpg&hash=8bc3fd9a7e0d192f57c4a5c04591b7b0)
Long pressing video key works as expected, with a little window in the center of the screen showing bitrate and elapsed time.
Taking photos, etc work fine. All normal canon functions seem to be working normally.
Sorry for the bad photo quality. The only other camera I have on me is my webcam :P
-
anyhow, your build is up and running on my 101a.
Thanks for the quick feedback, jstanley! :)
Flickering is normal, don't care about that.
Have you already activated <ALT> mode with Video Button and tried to access the menu inside <ALT> mode?
Please find attached the 101a folder for your 101a firmware. I commented the lines in boot.c which I had to change for 1.01a firmware.
I'm happy that I was able to help you! :D
---
Update: I just exchanged the 101a.zip file with a smaller one (I removed a 3 MB txt-file which is not necessary).
-
Pressing the video button results in no ALT menu showing up, but text at the bottom left saying "Default Script <ALT>", like this:
Thanks for feedback.
As long as you are in <ALT> mode you can enter the <ALT> menu by pressing the MENU button of your camera. :)
Attached you will find the "full" version of the binaries for 1.01a (just copy everything on your SDCard), then you will be able to see the same CHDK logo like jstanley and you could start playing around with e.g. SCRIPTS.
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
Oh wow! I didn't know that :P
This is awesome! I'll copy that on and see now...
-
Have you already activated <ALT> mode with Video Button and tried to access the menu inside <ALT> mode?
Yes. I can get into that menu. I tried doing a shutter speed override, but this did not seem to work. I imagine this is expected right now--we just haven't gotten that far. I hope to be able to contribute toward completing the port (rather than just staying one step behind you!)
Please find attached the 101a folder for your 101a firmware. I commented the lines in boot.c which I had to change for 1.01a firmware.
My stubs_entry_2.S file is identical to yours, so I guess I did something right. :)
As for boot.c, your changes made sense to me once I sorted the stubs by address. Those that are different in 101a are grouped together at the end. You just figured out where data was inserted into the firmware, and adjusted addresses in that range. I like to think I would have gotten there eventually.
-
... You just figured out where data was inserted into the firmware, and adjusted addresses in that range. I like to think I would have gotten there eventually.
Of course you would have figured it out, too! But why not saving some time. ;)
Why did I provide my current status also to other firmware like 1.01a and 1.01c? I know that some people are out there which own cameras with these firmware versions. These people should take this software as starting point for their investigations because (as you already wrote) we are just at the beginning. e.g. I was able to start Intervalometer Script. But it did only take one picture. Many CHDK features will not work for the moment, but to find the not working features we need more people. ;)
Maybe we get faster to a somehow complete port if more people work in parallel with the same basis.
I'm still waiting for feedback of 1.01c versions (already downloaded 2 times, but no feedback until now).
-
So I copied the CHDK folder on the card and got into the ALT menu and tried out some stuff.
The shutter speed override didn't work for me either.
I did play around with stuff like the live histogram, the OSD layout editor, the filebrowser and loaded the text editor script, which seemed to work quite okay.
What's with the flicker? That's the most annoying thing at this point :P
After that my battery died so I have to wait for it to charge now.
Great work guys! I'm really happy seeing CHDK running on my camera! :)
-
btw: I only used CHDK-PT the way to save instruction sequences and load them into Notepad++ for comparison with my boot.c code. Maybe CHDK-PT has much more power to do some work for you? Waterwingz will know more about CHDK-PT usage.
Once you have a ported version of the firmware, CHDK-PT can help with a port to a different firmwared in three ways:
- you can use it as a dissassembler that outputs each line in a format that can be directly compiled by gcc (the compiler used in the CHDK build chain).
- you can use it to automatically translate the addresses in your stubs_entry_2.S file (although you should look at the resulting code to make sure it makes sense). Use the Stubs button in the Convert box.
- you can use it to extract the source for all the routines from boot.c, movie_rec.c and capt_seq.c for the firmware of a different firmware model. This does all the address translation for you - no funny bugs for accidentally missing one address. Use the Address List button in the Convert box.
Sometime people have trouble with the Address List concept. Let me know if you are interested and I will create an example list file for this camera.
-
The shutter speed override didn't work for me either.
This is to be expected. Most shooting related functions will not work until the code in capt_seq.c has been completed. Likewise, the ability to mechanically zoom in movie mode will not work until the code in movie_rec.c has been completed.
-
Of course you would have figured it out, too! But why not saving some time. ;)
Why did I provide my current status also to other firmware like 1.01a and 1.01c? I know that some people are out there which own cameras with these firmware versions. These people should take this software as starting point for their investigations
Oh, don't get me wrong. I agree wholeheartedly with that sentiment. This isn't a race. I just missed that breakthrough, but I'm sure I'll have other opportunities!
-
Oh, don't get me wrong. I agree wholeheartedly with that sentiment. This isn't a race. I just missed that breakthrough, but I'm sure I'll have other opportunities!
I didn't! :)
btw: I think I found capt_seq_task() stuff at address FF882920 in each of 1.00c/1.01a/1.01c firmwares. :)
void __attribute__((naked,noinline)) capt_seq_task() {
// FF882920
asm volatile (
"STMFD SP!, {R3-R9,LR}\n"
"LDR R5, =0x3D48C\n"
"LDR R7, =0x2E28\n"
"MOV R6, #0\n"
"loc_FF074F2C:\n"
"LDR R0, [R7,#4]\n"
"MOV R2, #0\n"
"MOV R1, SP\n"
"BL sub_FF83B5B4\n"
"TST R0, #1\n"
"BEQ loc_FF88295C\n"
"LDR R1, =0x476\n"
"LDR R0, =0xFF882448\n" // aSsshoottask_c at 0xFF882448
"BL _DebugAssert\n"
"BL _ExitTask\n"
"LDMFD SP!, {R3-R9,PC}\n"
Maybe someone else would like to take over capt_seq.c file and work on this?
-
why does the battery drain so quickly while running chdk?
-
why does the battery drain so quickly while running chdk?
Maybe the Battery Max/Min voltage setting is wrong?
Look at the photo from jstanley (http://chdk.setepontos.com/index.php?topic=6341.msg76596#msg76596 (http://chdk.setepontos.com/index.php?topic=6341.msg76596#msg76596)). Canon battery icon shows "Battery Full" and CHDK battery information shows only 47%. Maybe it's only a settings issue.
Interesting thread on battery power: http://chdk.setepontos.com/index.php?topic=379.0 (http://chdk.setepontos.com/index.php?topic=379.0)
Which version are you using? I'm still interested in feedback from 1.01c firmware users. :)
-
Excellent work, Tommi!! I will download and try it out.
-
Excellent work, Tommi!! I will download and try it out.
I will cross my fingers that it works an 1.01c as well! :)
-
fantastic! :) chdk screen comes up but I have not tried much else yet.
Edit - works in autoboot mode too!
-
Great!
Thanks for feedback! Now we know that we have the same basis for firmware versions 1.00c/1.01a/1.01c.
Please find attached sources for 1.01c and "full binary package".
BR,
tommi
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
Please find attached one file which contains all necessary files for further development for 1.00c/1.01a/1.01c firmware versions. Used trunk revision is 1431.
This file I also already sent to Developers with a request for integration as Alpha version into the CHDK subversion repository (http://chdk.setepontos.com/index.php?topic=650.msg76587#msg76587 (http://chdk.setepontos.com/index.php?topic=650.msg76587#msg76587)).
-
This file I also already sent to Developers with a request for integration as Alpha version into the CHDK subversion repository (http://chdk.setepontos.com/index.php?topic=650.msg76587#msg76587 (http://chdk.setepontos.com/index.php?topic=650.msg76587#msg76587)).
Its up to reyalp & philmoz, but it might be a little premature to add this to the autobuild - even as an Alpha ? I'll happily make a SVN diff file for you but why not wait until you have movie_rec.c and capt_seq.c running first. At the rate you are going, I'd expect you will have that done this weekend !
-
I can also confirm that CHDK loads on ELPH300HS 1.01a; things like file browser, games, "make card bootable..." work, but saving in RAW and AV exposure bracketing do not, and I can load and run the "Ultra Intervalometer" script, bit it only takes the first shot.
Overall thanks for the great work!
What needs to be changed in capt_seq.c and movie_rec.c files to make it work? I only have a bit of C++ experience, but maybe there's something I can help with?
-
capt_seq.c and movie_rec.c are now finished for 1.00c :D
Please test this new version. On my 1.00c firmware I'm now able to save photos as RAW. But I don't know if they are saved correctly because I never worked with RAW image files before.
I did some address checks again and it seems that the same files can be used for 1.01a and 1.01c.
Therefore please test the new files with your 1.01a and 1.01c firmware versions.
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
And here is the binary for 1.00c.
Intervalometer also works now, just tested the LUA-script.
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
Hmm, one new issue, the camera doesn't take correct photos any more if CHDK is running. ;)
Intervalometer works, but photos are useless.
-
On my 1.00c firmware I'm now able to save photos as RAW. But I don't know if they are saved correctly because I never worked with RAW image files before.
Here's a link to advice reyalp gave me on converting a RAW file from a new cameras (not likely to be supported by any RAW tools yet) into something you can at least test out :
http://chdk.setepontos.com/index.php?topic=5855.msg59260#msg59260 (http://chdk.setepontos.com/index.php?topic=5855.msg59260#msg59260)
-
Hmm, one new issue, the camera doesn't take correct photos any more if CHDK is running. ;)
Turn off RAW for now. Does that help ?
-
For review, my current version of code.
@waterwingz: RAW is already disabled, still somehow black pictures.
-
Strange, IrfanView tells me the image taken with CHDK has only 3 colors.
On the left in the attached screenshot you see information about image take with CHDK, on the right about image taken without CHDK running.
-
The new build won't start on 101a. After I select "Firm Update", the lens pops out and the "HS System" splash screen comes up. The chime sound starts playing, but is cut short. The camera freezes. I've left it for maybe 30 seconds with nothing happening. Then I press the Power button and the camera turns off with the lens still extended. Hitting it again, and it retracts and extends the lens again, and is ready to record with no CHDK loaded.
-
Same thing here for 1.01a
-
@waterwingz: RAW is already disabled, still somehow black pictures.
Turn the capt_seq.c tasks back off at the start of boot.c ?
-
Try commenting out these lines in boot.c:
if(tcb->entry == (void*)task_CaptSeq) tcb->entry = (void*)capt_seq_task;
if(tcb->entry == (void*)task_InitFileModules) tcb->entry = (void*)init_file_modules_task;
if(tcb->entry == (void*)task_MovieRecord) tcb->entry = (void*)movie_record_task;
if(tcb->entry == (void*)task_ExpDrv) tcb->entry = (void*)exp_drv_task;
It was the first time that I activated them.
-
Hmm, one new issue, the camera doesn't take correct photos any more if CHDK is running. ;)
Intervalometer works, but photos are useless.
That would most likely be some mistakes in capt_seq.c.
In this file you are replicating the entire shooting task from the camera firmware in order to be able to modify it with CHDK functions.
Any mistakes here will cause problems with normal shooting - double check addresses, registers etc.
This one can be tricky to get right (as is the movie_rec.c stuff).
Best to leave out any CHDK specific code for now until you get it working with normal shooting.
You are doing really well - impressive effort.
Phil.
-
Try commenting out these lines in boot.c:
if(tcb->entry == (void*)task_CaptSeq) tcb->entry = (void*)capt_seq_task;
if(tcb->entry == (void*)task_InitFileModules) tcb->entry = (void*)init_file_modules_task;
if(tcb->entry == (void*)task_MovieRecord) tcb->entry = (void*)movie_record_task;
if(tcb->entry == (void*)task_ExpDrv) tcb->entry = (void*)exp_drv_task;
It was the first time that I activated them.
Each line in taskHook relates to a specific function that you are replacing from the firmware code.
Enable these lines only after you've converted the relevant function in the CHDK code for your camera - otherwise it will most likely crash or shutdown.
capt_seq_task - handles still shooting, override is in capt_seq.c
init_file_modules_task - handles notifying the spytask that CHDK is ready start and handles partitioned SD cards (found in boot.c)
movie_record_task - handles video shooting, override is in movie_rec.c
exp_drv_task - handles exposure calculations, override is in capt_seq.c
For your camera you probably don't need the SD partition handling code in init_file_modules_task as the camera should be able to boot from FAT32 cards. A minimal version of the override should still be added to keep the notification it sends to spytask (see the IXUS310 or SX40).
Phil.
-
With this configuration pictures ok, but no intervalometer working: ???
//if(tcb->entry == (void*)task_CaptSeq) tcb->entry = (void*)capt_seq_task;
//if(tcb->entry == (void*)task_InitFileModules) tcb->entry = (void*)init_file_modules_task;
//if(tcb->entry == (void*)task_MovieRecord) tcb->entry = (void*)movie_record_task;
//if(tcb->entry == (void*)task_ExpDrv) tcb->entry = (void*)exp_drv_task;
With this configuration pictures ok, but no intervalometer working: ???
//if(tcb->entry == (void*)task_CaptSeq) tcb->entry = (void*)capt_seq_task;
if(tcb->entry == (void*)task_InitFileModules) tcb->entry = (void*)init_file_modules_task;
if(tcb->entry == (void*)task_MovieRecord) tcb->entry = (void*)movie_record_task;
//if(tcb->entry == (void*)task_ExpDrv) tcb->entry = (void*)exp_drv_task;
With this configuration Intervalometer working, but pictures wrong: >:(
//if(tcb->entry == (void*)task_CaptSeq) tcb->entry = (void*)capt_seq_task;
if(tcb->entry == (void*)task_InitFileModules) tcb->entry = (void*)init_file_modules_task;
if(tcb->entry == (void*)task_MovieRecord) tcb->entry = (void*)movie_record_task;
if(tcb->entry == (void*)task_ExpDrv) tcb->entry = (void*)exp_drv_task;
With this configuration Intervalometer working, but pictures wrong: >:(
if(tcb->entry == (void*)task_CaptSeq) tcb->entry = (void*)capt_seq_task;
if(tcb->entry == (void*)task_InitFileModules) tcb->entry = (void*)init_file_modules_task;
if(tcb->entry == (void*)task_MovieRecord) tcb->entry = (void*)movie_record_task;
if(tcb->entry == (void*)task_ExpDrv) tcb->entry = (void*)exp_drv_task;
With this configuration Intervalometer working AND pictures ok: :)
if(tcb->entry == (void*)task_CaptSeq) tcb->entry = (void*)capt_seq_task;
if(tcb->entry == (void*)task_InitFileModules) tcb->entry = (void*)init_file_modules_task;
if(tcb->entry == (void*)task_MovieRecord) tcb->entry = (void*)movie_record_task;
//if(tcb->entry == (void*)task_ExpDrv) tcb->entry = (void*)exp_drv_task;
So, I have to check the expDrv-Stuff.
-
This one can be tricky to get right (as is the movie_rec.c stuff).
Best to leave out any CHDK specific code for now until you get it working with normal shooting.
Let me see if I have the right strategy in mind here.
1. In the reference camera (sx220 in this case, iirc), find the original shooting tasks in the firmware and disassemble them.
2. Find the original shooting tasks in the ixus220/elph300 firmware, presumably because they'll look similar to the reference camera's. Disassemble these too.
3. Take these tasks and plug them in to capt_seq.c. We're effectively replacing the shooting tasks with identical ones, as a sanity check. Shooting should continue to work normally, albeit without CHDK enhancements of course.
4. Diff the reference camera's original (disassembled) shooting tasks and the enhanced ones in the reference CHDK port. Apply the differences to the code last used in step 3.
-
So, I have to check the expDrv-Stuff.
Sounds like it.
If you haven't converted movie_record_task yet, then don't enable that line or video recording may crash.
Phil.
-
As you can see in the last line I was not sure during adaptation of the file.
void __attribute__((naked,noinline)) sub_FF8B84D0_my() {
//FF8B84D0 IXUS220: DONE
asm volatile (
" STMFD SP!, {R4-R6,LR} \n"
" LDR R5, =0x3EE0 \n"
" MOV R4, R0 \n"
" LDR R0, [R5,#4] \n"
" CMP R0, #1 \n"
" LDRNE R1, =0x146 \n"
" LDRNE R0, =0xFF8B8308 \n" //aShutter_c IXUS220 at FF8B8308
" BLNE _DebugAssert \n"
" CMN R4, #0xC00 \n"
" LDREQSH R4, [R5,#2] \n"
" CMN R4, #0xC00 \n"
" MOVEQ R1, #0x14C \n"
" LDRNE R0, =0xFF8B8308 \n" //aShutter_c IXUS220 at FF8B8308
" STRH R4, [R5,#2] \n"
" BLEQ _DebugAssert \n"
" MOV R0, R4 \n"
" BL apex2us \n" // patched
" B sub_FF8B8510 \n" // IXUS220 continue in firmware at ff8b8510 ???
);
}
Where should I jump after this apex2us (what is this function for?) was executed. Maybe my jump target is wrong?
Firmware Code:
void __attribute__((naked,noinline)) sub_FF8B84D0_my( ) {
asm volatile (
" STMFD SP!, {R4-R6,LR} \n" // rom:ff8b84d0 0xE92D4070
" LDR R5, =0x3EE0 \n" // rom:ff8b84d4 0xE51F51DC
" MOV R4, R0 \n" // rom:ff8b84d8 0xE1A04000
" LDR R0, [R5, #4] \n" // rom:ff8b84dc 0xE5950004
" CMP R0, #1 \n" // rom:ff8b84e0 0xE3500001
" LDRNE R1, =0x146 \n" // rom:ff8b84e4 0x159F13D4
" LDRNE R0, =0xFF8B8308 \n" // rom:ff8b84e8 0x124F0F7A
" BLNE sub_FF81EC88 \n" // rom:ff8b84ec 0x1BFD99E5
" CMN R4, #0xC00 \n" // rom:ff8b84f0 0xE3740B03
" LDREQSH R4, [R5, #2] \n" // rom:ff8b84f4 0x01D540F2
" CMN R4, #0xC00 \n" // rom:ff8b84f8 0xE3740B03
" MOVEQ R1, #0x14C \n" // rom:ff8b84fc 0x03A01F53
" LDREQ R0, =0xFF8B8308 \n" // rom:ff8b8500 0x024F0C02
" STRH R4, [R5, #2] \n" // rom:ff8b8504 0xE1C540B2
" BLEQ sub_FF81EC88 \n" // rom:ff8b8508 0x0BFD99DE
" MOV R0, R4 \n" // rom:ff8b850c 0xE1A00004
" BL sub_FFA3B18C \n" // rom:ff8b8510 0xEB060B1D
" MOV R4, R0 \n" // rom:ff8b8514 0xE1A04000
" BL sub_FF90A6AC \n" // rom:ff8b8518 0xEB014863
" MOV R0, R4 \n" // rom:ff8b851c 0xE1A00004
...
-
This one can be tricky to get right (as is the movie_rec.c stuff).
Best to leave out any CHDK specific code for now until you get it working with normal shooting.
Let me see if I have the right strategy in mind here.
1. In the reference camera (sx220 in this case, iirc), find the original shooting tasks in the firmware and disassemble them.
2. Find the original shooting tasks in the ixus220/elph300 firmware, presumably because they'll look similar to the reference camera's. Disassemble these too.
3. Take these tasks and plug them in to capt_seq.c. We're effectively replacing the shooting tasks with identical ones, as a sanity check. Shooting should continue to work normally, albeit without CHDK enhancements of course.
4. Diff the reference camera's original (disassembled) shooting tasks and the enhanced ones in the reference CHDK port. Apply the differences to the code last used in step 3.
Essentially that's the process.
Step 4 can be the hardest unless you can find a reference port that has very similiar code - the capt_seq.c and movie_seq.c code often change significantly between camera models. You may need to reference more than one other port to get ideas on where to add the CHDK changes.
Phil.
-
2. Find the original shooting tasks in the ixus220/elph300 firmware, presumably because they'll look similar to the reference camera's.
Last time I guess I'll mention this - CHDK-PT will do this for you.
-
As you can see in the last line I was not sure during adaptation of the file.
void __attribute__((naked,noinline)) sub_FF8B84D0_my() {
//FF8B84D0 IXUS220: DONE
asm volatile (
" STMFD SP!, {R4-R6,LR} \n"
" LDR R5, =0x3EE0 \n"
" MOV R4, R0 \n"
" LDR R0, [R5,#4] \n"
" CMP R0, #1 \n"
" LDRNE R1, =0x146 \n"
" LDRNE R0, =0xFF8B8308 \n" //aShutter_c IXUS220 at FF8B8308
" BLNE _DebugAssert \n"
" CMN R4, #0xC00 \n"
" LDREQSH R4, [R5,#2] \n"
" CMN R4, #0xC00 \n"
" MOVEQ R1, #0x14C \n"
" LDRNE R0, =0xFF8B8308 \n" //aShutter_c IXUS220 at FF8B8308
" STRH R4, [R5,#2] \n"
" BLEQ _DebugAssert \n"
" MOV R0, R4 \n"
" BL apex2us \n" // patched
" B sub_FF8B8510 \n" // IXUS220 continue in firmware at ff8b8510 ???
);
}
Where should I jump after this apex2us (what is this function for?) was executed. Maybe my jump target is wrong?
Firmware Code:
void __attribute__((naked,noinline)) sub_FF8B84D0_my( ) {
asm volatile (
" STMFD SP!, {R4-R6,LR} \n" // rom:ff8b84d0 0xE92D4070
" LDR R5, =0x3EE0 \n" // rom:ff8b84d4 0xE51F51DC
" MOV R4, R0 \n" // rom:ff8b84d8 0xE1A04000
" LDR R0, [R5, #4] \n" // rom:ff8b84dc 0xE5950004
" CMP R0, #1 \n" // rom:ff8b84e0 0xE3500001
" LDRNE R1, =0x146 \n" // rom:ff8b84e4 0x159F13D4
" LDRNE R0, =0xFF8B8308 \n" // rom:ff8b84e8 0x124F0F7A
" BLNE sub_FF81EC88 \n" // rom:ff8b84ec 0x1BFD99E5
" CMN R4, #0xC00 \n" // rom:ff8b84f0 0xE3740B03
" LDREQSH R4, [R5, #2] \n" // rom:ff8b84f4 0x01D540F2
" CMN R4, #0xC00 \n" // rom:ff8b84f8 0xE3740B03
" MOVEQ R1, #0x14C \n" // rom:ff8b84fc 0x03A01F53
" LDREQ R0, =0xFF8B8308 \n" // rom:ff8b8500 0x024F0C02
" STRH R4, [R5, #2] \n" // rom:ff8b8504 0xE1C540B2
" BLEQ sub_FF81EC88 \n" // rom:ff8b8508 0x0BFD99DE
" MOV R0, R4 \n" // rom:ff8b850c 0xE1A00004
" BL sub_FFA3B18C \n" // rom:ff8b8510 0xEB060B1D
" MOV R4, R0 \n" // rom:ff8b8514 0xE1A04000
" BL sub_FF90A6AC \n" // rom:ff8b8518 0xEB014863
" MOV R0, R4 \n" // rom:ff8b851c 0xE1A00004
...
The stubs_entry.S file will tell you where in the firmware the task code is, look for the DEF(task_???) entries - task_ExpDrv in this case.
Compare the firmware code to your code to find the addresses. Walk through the code in the firmware until you get to the patched point then you will know where to jump back to.
As a general rule you should change all the sub_??? and loc_??? addresses and any addresses in comments in your converted code to match the specific firmware version instead of leaving the values from the reference port you used. This will avoid a lot of confusion in the future if you are trying to match up the CHDK code to the firmware code. Also change any references to camera names and camera firmware version to match the port.
Phil.
-
btw, the 101a crashing problem may be related to a few references to sub_FFB9C360 in capt_seq.c; if I'm correct, those should probably be sub_FFB9C378 in 101a. (making those changes did not fix the crash problem, though, so either I'm not correct or there's another problem.)
-
Aaaaargh, small mistake but probably the issue!
"B sub_FF8B8510 \n" // IXUS220 continue in firmware at ff8b8510 ???
should be:
"B sub_FF8B8514 \n" // IXUS220 continue in firmware at ff8b8510 ???
Yes, it seems that was the issue. I just tested. :D
Now Intervalometer works, save as RAW works (IfranView complains WrongRawFormat), Pictures look fine.
Execution of LUA HDR Script is not working fine. Then camera is still on, but I have to deactivate it by pulling the battery.
But this is the best version I had during the last hours.
What a perfect day! :D
-
btw, the 101a crashing problem may be related to a few references to sub_FFB9C360 in capt_seq.c; if I'm correct, those should probably be sub_FFB9C378 in 101a. (making those changes did not fix the crash problem, though, so either I'm not correct or there's another problem.)
You are right, these need to be adapted.
Update:
Just checked this location for 1.01c. There also a different address is used.
-
Hopefully we got it now much better.
I will generate another set of binaries and provide them here for testing.
For me the day is over soon. I will continue tomorrow.
Current sources attached.
-
Binaries for 1.00c and 1.01a.
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
Binary for 1.01c.
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
Jstanley, if you still have a crash problem, try it like I did in http://chdk.setepontos.com/index.php?topic=6341.msg76642#msg76642 (http://chdk.setepontos.com/index.php?topic=6341.msg76642#msg76642)
Then we will see, which task is responsible for the crash.
-
1.01c - photos as RAW - working now!
Thanks Tommi!
-----
But do not create the file badpixel.bin (for .DNG)
writes "badpixel.bin failed. Please try again."
-
1.01a:
booting up fine
RAW working
Intervolometer working
Tommi, crazy thanks dude!
-
Working for me on 101a. Nice job! 8)
I'm seeing a weird issue, though. .DNG files have a fisheye effect ???
in-camera JPEG:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FgkuH8.jpg&hash=5131ed187b384840aec0c120c8cd94e6)
converted DNG:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FjskSn.jpg&hash=ea39dd8b4081910c0c06f07cffce529f)
I guess the lens on this camera has some crazy barrel distortion at the wide end, which in-camera processing corrects for. I guess this sort of thing is probably why Canon reserves RAW for expensive cameras.
On the plus side, though, this camera appears to have a lens that's actually _wider_ than 24mm equivalent.
Can't tell what the .CRW files look like, because I can't find a program that will read them. (Not even dcraw.)
-
I'm seeing a weird issue, though. .DNG files have a fisheye effect ???
I guess the lens on this camera has some crazy barrel distortion at the wide end, which in-camera processing corrects for.
Can't tell what the .CRW files look like, because I can't find a program that will read them. (Not even dcraw.)
Reposted to help answer the same questions :
CHDK Forum thread on RAW (http://chdk.setepontos.com/index.php?topic=1532.msg13819#msg13819)
CHDK Wiki Page about RAW (http://chdk.wikia.com/wiki/Raw)
CHDK Wiki Page about Raw Software (http://chdk.wikia.com/wiki/Software#RAW_Conversion)
How do you fix lens distortion with CHDK RAW files? (http://chdk.setepontos.com/index.php?topic=6996)
and this :
Decoding CHDK RAW images from a new cameras (http://chdk.setepontos.com/index.php?topic=5855.msg59260#msg59260)
-
I guess the in-camera lens correction for that distortion means a bit of the jpg needs to be cropped. I'm so looking forward to the RAW capability - will download now and give it a try!! :)
-
Thanks for the posts about the RAW surprise.
I've been playing with the camera a bit more, and I've hit at least one bug. When trying to fix the aperture value, I found the F-number started at 3.3, which is incorrect for this camera (it should go to 2.7). Then when I tried to actually take a shot in Av, the camera crashed.
Also, the focal length tag in DNG files is nonsense, but this may be a limitation unrelated to this port.
-
Oh, and I tried to record a movie under CHDK, and the camera crashed immediately.
-
Anyone try a dual-partition SD card (first partition small and fat16, second big and fat32) ? Not sure if chdk is recognizing the second partition.
-
Anyone try a dual-partition SD card (first partition small and fat16, second big and fat32) ? Not sure if chdk is recognizing the second partition.
Not necessary anymore. This years camera releases can boot from a FAT32 partition - has been tested up to 64GB on the SX40HS.
Use the option under the Miscellaneous Stuff menu to make the card bootable.
Phil.
-
well silly me! I've been out of the chdk loop for a few yrs. :)
Thanks, will give the big card a try.
Edit update:
- yes, large fat32 cards will boot chdk
- getting some flakiness with dng photo capture (gray/purple images) but only occasionally
- playback sometimes doesn't read all the captured files
-
I just tried out tommi's latest build (1.01a) and:
- Boots properly (I have my card bootable. 4GB, FAT32)
- Shutter speed override works up till 1/2000, doesn't go above that though?
- Aperture doesn't seem to work. No matter what I set, it finally ends up at either F8.0 or F2.7. It doesn't crash for me though. The setting just doesn't have any effect.
- ISO override simply freezes the camera when I half-press the shutter button (exactly how stanley described earlier - Everything freezes, wait for a few seconds, power off, lens doesn't retract)
- The force manual flash works
- Starting a video recording just causes the camera to freeze for me too
- RAW files are being saved, though I've not checked their contents yet
edit: I opened the DNG files with rawtherapee and they seem fine. The fisheye distortion is there, though.
Couldn't find anything to open the CHDK RAW files though
- HDR script takes one photo and freezes
- Interval script works!
- Motion script works, too, but is so slow it couldn't even capture my hand, let alone lightning :D
- All the knick-knacks work - OSD layout, colours, fonts, icons, file browser, text viewer, calendar, games :P
Also, is manual focus possible on this model?
Thanks :)
-
I just updated movie_rec.c for 1.01a.
Please find attached 1.01a binary.
update: and of course the movie_rec.c source file :)
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
Am I doing something wrong? Because it crashes just the same when I start video recording :-[
EDIT: It doesn't crash the same way. Last time it froze. This time it simply switches off immediately with the lens still extended.
-
On my 1.00c camera I am able to start video recording. I do this via long press of video button.
For 1.01a firmware I found 5 locations with different addresses. These I changed to the ones from 1.01a firmware. I am not able to test this by myself because I have no 1.01a camera.
jstanley, wake up. we need you here. ;)
My new movie_rec.c should be reviewed. I will do it as well once again, but sometimes you don't find the error by yourself. :)
-
Wondering why 1.01c users are not complaining about video recording issue, maybe not yet tested this feature?
Because in 1.01c firmware function is at another firmware location. I adapted movie_rec.c accordingly.
Please find attached binary and movie_rec.c for 1.01.c.
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
New 1.01a binary because I found one small difference (don't think that this will be the final solution, but we should give it a try).
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
No luck it's just the same :(
Edit: here's exactly what happens, if it's of any use
- Long press video button
- Screen blinks
- "Calc" appears in video bitrate calculator box
- Screen blinks again
- Bitrate calculator disappears and the ordinary Canon "Rec" in red, with a red dot, appears on the right side of the screen
- Camera switches off
-
This time it simply switches off immediately with the lens still extended.
Same behaviour on 1.01c.
Tested out some of the other functions and they seem to work well !!!
RAW shooting creates 18M raw files (although I've got no way to develop them).
Great progress Tommi.
-
RAW shooting creates 18M raw files (although I've got no way to develop them).
Can someone confirm that RAW files have good content?
Wanted to take some DNG pictures but I was not able to create the necessary badpixels.bin file. Tried to do it several times but it always failed.
Just created an empty badpixels.bin file in CHDK folder, DNG picture shooting is now possible but no usable results.
-
RAW works for me and stanley (as mentioned earlier in the thread)
It creates proper DNG files that have valid content (checked with rawtherapee on linux), albeit a weird fisheye distortion. (jstanley's post: http://chdk.setepontos.com/index.php?topic=6341.msg76663#msg76663 (http://chdk.setepontos.com/index.php?topic=6341.msg76663#msg76663))
I had some trouble creating badpixels.bin, too. After a couple of restarts I randomly tried again and it worked. Don't know why?
Maybe try disabling RAW and then trying to create badpixels.bin?
-
During review of movie_rec.c I found still one location where I missed to apply the correct address.
movie_rec.c 1.00c line 298
" LDR R1, =0xFFBE033C \n"
movie_rec.c 1.01a line 300
" LDR R1, =0xFFBE0354 \n" // IXUS220 differencemovie_rec.c 1.01c line 298
" LDR R1, =0xFFBE0364 \n" // IXUS220 difference
I already switched to latest trunk revision from assembla repository. Don't care about the ZIP-file names.
Exmem is also activated in my localbuildconfig. Works for me. Should also work on your machines.
Please test. :)
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
Nope, it doesn't work :(
Great job so far, though!
Must be annoying to have to edit and rebuild and then wait for someone to check it :P
-
Must be annoying to have to edit and rebuild and then wait for someone to check it :P
Somehow yes. :D
Disabling RAW before badpixels.bin creation didn't help.
Could you provide me your's badpixels.bin file that I could do some testing here?
-
Well, I remember trying it with RAW enabled, and it didn't work. Then I DISABLED raw (because badpixel.bin creation takes a photo, and it was probably saving that photo as RAW too) and tried again but it still didn't work.
Then I played around with some other stuff, restarted a few times, and then decided to try again and it worked!
So maybe disable RAW and restart??
Anyway, here you go. Probably you won't get the best results because the bad pixels are different for each individual camera, as far as I know :P
-
Thanks, I get the same results if I use your badpixel.bin or my empty badpixel.bin.
Attached screenshot shows how it looks (in camera player and on computer).
-
I tried to delete my badpixel.bin to see what happens. It created a new one without complaint!
I tried deleting it and restarting, disabling/enabling RAW, but nothing seems to stop it now ???
badpixel.bin created.
Bad pixel count: 12454
-
If taking RAW images is not working at all, how should the camera calculate the bad pixels from such images?
-
After I changed an address from 0x413591F0 to 0x413391A0 in lib.c:
char *hook_raw_image_addr()
{
if (*((int*)0x3F04) != 0)
return (char*) 0x46000000;
else
return (char*) 0x413391A0; // before it was 0x413591F0;
}
I am able to shoot DNG pictures. :)
But:
After restart the first DNG picture fails. That is reproducable for me. Second, third, fourth picture ... are fine.
Next restart first picture fails again.
What could be the reason for this? An wrong initialized value which gets new correct value after first shoot?
-
Good morning tommi (or afternoon, whatever time it is where you are; it's 6:30 AM here). I've just been outside taking pictures of the stars. Even with CHDK, my Elph isn't going to replace my 60D any time soon for this purpose ;) - but RAW support makes an ENORMOUS improvement.
Here's some sample photos:
JPEG, no CHDK (long-exposure scene mode @ 15 seconds)
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FU0vQn.jpg&hash=8a223df956306a379d38595a58039c9b)
above image, brightened in post - note serious posterization; the histogram is a staircase
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FrbgXT.jpg&hash=8dac89b88b1d5ccad884979aaa58487c)
RAW (DNG), 20 seconds, ISO 100
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FMwWZY.jpg&hash=c931d3ebcab04919716776d0875016e4)
RAW (DNG), 32 seconds, ISO 100
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F70K3G.jpg&hash=bd182a960917b36b56588ef2e49d7a13)
Uh... yeah, shutter speed overrides longer than 20 seconds don't work.
Also, ISO overrides result a crash when half-pressing the shutter.
But still... look at that sky! That little sensor is capable of so much more than Canon lets it do!
-
Good afternoon, jstanley! ;) (it is already 2:45 PM here in Germany, weekend nearly over)
Fantastic comparison of photos! :)
-
Reviewing movie_rec.c (100c vs 101a), and I'm seeing a lot of addresses that I'm not sure about.
in both firmwares, GetZoomLensCurrentPosition is at 0xffadcc9c.
in 101a, MoveIrisWithAv is at 0xffaeecc4, compared to 0xffaeecac in 100c.
so _somewhere_ between 0xffadcc9c and 0xffaeecc4, 0x18 bytes were inserted, shifting everything else back.
problem is, when I diff movie_rec.c 100c vs 101a, I see a TON of unconverted addresses in that range. how can we narrow down exactly where the insert took place?
on second thought, I suppose that the movie recording task likely is the change that pushed other stubs back in the binary...
-
Reviewing movie_rec.c (100c vs 101a), and I'm seeing a lot of addresses that I'm not sure about.
problem is, when I diff movie_rec.c 100c vs 101a, I see a TON of unconverted addresses in that range. how can we narrow down exactly where the insert took place?
on second thought, I suppose that the movie recording task likely is the change that pushed other stubs back in the binary...
I believe that there is an easier way to do all of this. Don't try to convert the movie_rec.c file by modifying addresses. That's just got to be a source of errors unless you are really luckly. Create your own file from scratch. From an earlier post, there seems to be only 3 routines that you need to find in your firmware :
void __attribute__((naked,noinline)) movie_record_task(){
//ff985e5c IXUS220: DONE
void __attribute__((naked,noinline)) sub_FF985498_my(){
void __attribute__((naked,noinline)) sub_FFAE6A58_my(){
// FFAE6A58 IXUS220: DONE
Find those in YOUR firmware, export them, build your own movie_rec.c and then make the small changes for that to hook into CHDK.
-
Hmm, I don't think that it is important which 0x18 bytes have been inserted in the firmware, because we know and call the correct addresses of those functions.
I stepped through movie_rec.c with disassembled Firmware in parallel in Notepad++. That's how I could find differences of movie_rec.c from original firmware. I did this for 100c, 101a and 101c.
When I compare movie_rec.c (100c vs 101a) I get only 7 differences. And these differences I checked again and again in original firmware. I cannot find any error.
What about substituting sub_0xFxxxxxxx_my calls with original sub_0xFxxxxxxx firmware calls and see if it still crashes?
In movie_rec.c we have only two _my calls:
sub_FF985498_my
sub_FFAE6A44_my
Just change them to original calls:
sub_FF985498
sub_FFAE6A44
and look what happens. If it still crashes we are probably searching at the wrong place?
--
Uups, waterwingz was faster. Maybe start from scratch for that one file would be easier then just trying some stuff.
-
void __attribute__((naked,noinline)) movie_record_task(){
//ff985e5c IXUS220: DONE
void __attribute__((naked,noinline)) sub_FF985498_my(){
1.01c:
void __attribute__((naked,noinline)) sub_FFAE6A58_my(){
1.00c and 1.01a:
void __attribute__((naked,noinline)) sub_FFAE6A44_my(){
Find those in YOUR firmware, export them, build your own movie_rec.c and then make the small changes for that to hook into CHDK.
The third function has different address for 100c/101a and 101c (if I'm not wrong ;)).
-
okay, I figured out how to answer my question; it's actually not quite as simple as a single 0x18-byte insert.
I used CHDK-PT to disassemble both firmwares in the region, then diffed the two disassemblies.
both firmwares largely match up to address FFAE6D54. at that location, there is a chunk of data that is 4 bytes *shorter* on 101a. from this point through FFAE7850, code is shifted backward four bytes on 101a. then 101a has substantially different code. when things sync up again, 100c is at FFAE7904 and 101a is at FFAE791C. 101a stays 24 (0x18) bytes ahead of 100c from that point, as far as I've looked anyway.
heh, while I was doing this, I see multiple replies telling me why this was the wrong thing to do. pardon my n00bishness. :-[
-
I stepped through movie_rec.c with disassembled Firmware in parallel in Notepad++. That's how I could find differences of movie_rec.c from original firmware. I did this for 100c, 101a and 101c.
But if you point CHDK-PT at the addresses in your original firmware where the routines are, and then tell it which firmware file you want to port to, it will do all that for you. It outputs the matching code from the target firmware.
-
I didn't know how powerful CHDK-PT can be. :(
During my next port ( ;)) I will use more of the CHDK-PT advantages. :)
-
I didn't know how powerful CHDK-PT can be. :(
During my next port ( ;)) I will use more of the CHDK-PT advantages. :)
Don't feel bad about it. It'd be hard to use CHDK-PT effectively unless you understand what it's doing. It was a magic box when I first tried to use it a couple days ago. After these discussions, I have a much better idea how it works.
-
Don't feel bad about it. It'd be hard to use CHDK-PT effectively unless you understand what it's doing. It was a magic box when I first tried to use it a couple days ago. After these discussions, I have a much better idea how it works.
I can see now that the brief instructions assumed some background knowledge of CHDK. When you are starting new, there is learning curve that everyone must follow and overcome in their own way. Even if I wrote a 50 page manual, I suspect it would not get read - people have to just figure things out for themselves (sometimes the hard way the first time).
-
... people have to just figure things out for themselves (sometimes the hard way the first time).
Sometimes the hard way is the more interesting way. :)
-
This file I also already sent to Developers with a request for integration as Alpha version into the CHDK subversion repository (http://chdk.setepontos.com/index.php?topic=650.msg76587#msg76587 (http://chdk.setepontos.com/index.php?topic=650.msg76587#msg76587)).
Its up to reyalp & philmoz, but it might be a little premature to add this to the autobuild - even as an Alpha ? I'll happily make a SVN diff file for you but why not wait until you have movie_rec.c and capt_seq.c running first. At the rate you are going, I'd expect you will have that done this weekend !
Guys, I would like to send once again our current version of ixus220/elph300 port to the CHDK developers for integration.
Many features are working and as waterwingz already predicted we were able to adapt movie_rec.c and capt_seq.c as well. :) Okay, video recording is currently not working for 101a and 101c firmwares, but that could be fixed later.
Jstanley, waterwingz, Phil, what do you think?
I would at least wait until Jstanley has created a new movie_rec.c for 101a firmware. Then we can commit our stuff together in one package to the developers. :)
-
After I changed an address from 0x413591F0 to 0x413391A0 in lib.c:
char *hook_raw_image_addr()
{
if (*((int*)0x3F04) != 0)
return (char*) 0x46000000;
else
return (char*) 0x413391A0; // before it was 0x413591F0;
}
I am able to shoot DNG pictures. :)
But:
After restart the first DNG picture fails. That is reproducable for me. Second, third, fourth picture ... are fine.
Next restart first picture fails again.
What could be the reason for this? An wrong initialized value which gets new correct value after first shoot?
If you copy an existing port as a reference then you have to assume that every value in the platform/CAMERA files is going to be wrong and needs to be checked and fixed.
In this case the RAW buffer addresses looks OK; but the location of the active buffer is wrong.
From looking at the firmware is should probably be 0x2E94 not 0x3F04 (see sub_FF884C18 in 1.00c firmware).
Make sure you make the same changes in hook_alt_raw_image_addr
Phil.
-
Thanks for the hint, but I cannot follow you.
How do you get to value 0x2E94 ?
At mentioned firmware location I only see 0x2E88. From where do you take the difference of 0xC?
-
Thanks for the hint, but I cannot follow you.
How do you get to value 0x2E94 ?
At mentioned firmware location I only see 0x2E88. From where do you take the difference of 0xC?
Experience.
0x2E88 is loaded into R6. Further down in the function you will see it changes the value at R6 + 0xC from 0 to 1 and vice versa, then uses this to load values from a table at FFBA311C. This table contains your raw buffer addresses (among other things).
Phil.
-
long and painful experience if I recall that code correctly ...
-
Experience.
I only saw 0x18 two times and one time 0x04 and then stopped for further looking. I should have been looking for 0x0c, but that's what I'm missing: Experience. 8)
But now I can play with RAW images. Thanks, it's working fine now.
Why does nobody from 101a and 101c versions complain about such RAW issues? Because the values are the same (at least in the lib.c files). Ok, maybe they already fixed it on their own.
Update:
I found the same values in 101a and 101c firmware.
Please find attached new binaries for 101a and 101c.
Changes in these binaries only for shooting RAW images.
Please test if shooting RAW images is still working fine. From firmware point of view it should be fine.
Don't know if it is necessary but to free some disk space I will remove binaries from older posts because they contain less or no functionality.
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
Binary for 100c and current source code version (for 100c, 101a, 101c firmware).
--
Update: removed binary because no or wrong functionality, newer version available in later posts
-
I just registered to give also feedback.
I am using your latest version for firmware 1.00c (ixus220_elph300hs-100c-0.9.9-r9999_assembla_assembla.zip).
At first a note: i am a starter user of chdk. So i am knowing chdk not in detail yet.
I am very interested in the HDR function: i selected the script from /CHDK/SCRIPTS/4PACK/LUA/HDR.LUA
and activated it. After pressing the release knob one photo is shot and then the camera doesn't react any more. After a while the lcd-monitor is shut off (lens still outside). Then i have to switch off the camera for working again.
-
Why does nobody from 101a and 101c versions complain about such RAW issues? Because the values are the same (at least in the lib.c files). Ok, maybe they already fixed it on their own.
Well, there was my last image in this message (http://chdk.setepontos.com/index.php?topic=6341.msg76697#msg76697). I thought this was a shutter override problem, but it might be a bad RAW buffer. Actually... it looks too "analog" to be a bad RAW buffer; I think it's more likely that the shutter never opened at all, and dcraw (the RAW conversion software I used) brightened the sensor noise into that thing*.
So I guess I can't explain why I never saw a "RAW" photo comprised of random memory contents.
*It's worth noting that dcraw automatically scales the image brightness; if you shoot the same scene at EV 0 and EV -1, you'll get nearly identical looking output files (except the one shot at EV -1 will have more shadow noise and less highlight clipping). The Orion shot in my message looks bright because dcraw scaled the RAW pixel values up to something "visible" before truncating to 8 bits for JPEG. In-camera, on the other hand, the fixed tone curve applied by the default firmware stuffed the majority of pixels into the bottom handful buckets in the histogram, effectively throwing out most of the faint signal.
-
Hello Fux,
thanks for the feedback. :)
The HDR script issue is known.
It seems it is connected to one instruction of the second command sequence:
print("2) bright")
set_tv96_direct(t-192)
print("2) set_tv96_direct(t-192) done")
set_sv96(s)
print("2) set_sv96(s) done")
set_av96(p)
print("2) set_av96(p) done")
shoot()
print("2) shoot done")
Maybe set_tv96_direct() or set_sv96() is responsible for crash.
You can easily add print commands to the HDR script to see, after which line the script stops.
Current workaround until we have been able to fix that issue: don't use that script ;)
Thanks for testing! :)
-
Jstanley, have you been able to test shooting RAW images with the latest binary I uploaded? Because I changed some addresses also in the lib.c file for 1.01a after I got a hint from Phil.
btw: I just took a picture with 200 seconds exposure time and it looks very good. CHDK is awesome! :)
btw2: Did you have some progress/luck with your movie_rec.c file?
-
Jstanley, have you been able to test shooting RAW images with the latest binary I uploaded? Because I changed some addresses also in the lib.c file for 1.01a after I got a hint from Phil.
Do you ever sleep? :o
I just took a couple of 32-second RAW images with the latest build. Worked fine.
-
Do you ever sleep? :o
Yes, my next sleep sequence will start in a few minutes (here it is 11 PM) because I have to get up early in the morning for work. I think your time is 3 PM now? Then you should have enough time to get your movie_rec.c up and running. When I wake up tomorrow morning I will read your post that everything is fine. I'm sure! Good luck! :)
I just took a couple of 32-second RAW images with the latest build. Worked fine.
Good to hear, then we have now the right values in our lib.c files. :)
-
waterwingz, some feature requests for chdk-pt:
- make it possible to select multiple rows in the disassembly:
- show the number of bytes of machine code is selected (this will help write addresses.txt files)
- allow copying the selected text to the clipboard (often easier than saving to a file, then finding the file)
or I suppose I could do these things myself, if I could figure out how to access the source (programming for Windows is my day job :))
-
make it possible to select multiple rows in the disassembly:
show the number of bytes of machine code is selected (this will help write addresses.txt files)[/li][/list]
allow copying the selected text to the clipboard (often easier than saving to a file, then finding the file)[/li][/list]
I played with this for a bit - its been about the only request I've received. Unfortunately, the gui part is "written" in autoit - and the scrolling list box is a huge hack I found after trolling lots of autoit forums. From what I can tell, there is no easy way to support select, cut & paste.
I did think about simply writing my own edit window - wouldn't be the first time across many languages and operating systems. But its never risen to the top of my list.
or I suppose I could do these things myself, if I could figure out how to access the source (programming for Windows is my day job :))
I think I made access to the svn on assembia.com available - there is a link in the forum thread : http://chdk.setepontos.com/index.php?topic=6367 (http://chdk.setepontos.com/index.php?topic=6367). Let me know if it doesn't work ?
-
Just tested the lastest 1.01c RAW functionality. Installed RawTherapee 3 alpha on my linux box to process raw images. I was not able to process the .crw files, but switching to saving as .dng allowed RawTherapee to develop them.
Creating badpixels script ran without problems.
RAW capture to .dng worked perfectly. First raw capture worked (so no initial buffer probs) and subsequent raw captures.
-
Just tested the lastest 1.01c RAW functionality. Installed RawTherapee 3 alpha on my linux box to process raw images. I was not able to process the .crw files, but switching to saving as .dng allowed RawTherapee to develop them.
Reposted :
link> CHDK Forum thread on RAW (http://chdk.setepontos.com/index.php?topic=1532.msg13819#msg13819)
Quote :
Fact 4 - if you want to use the CHDK RAW files in your standard RAW workflow tool it is likely that they cannot be opened (as a lot of commercial raw converters/editors do not support CHDK RAWs yet).
Other good stuff here :
link> CHDK Forum Board for RAW (http://chdk.setepontos.com/index.php?board=15.0)
link> CHDK Wiki Page about RAW (http://chdk.wikia.com/wiki/Raw)
link> CHDK Wiki Page about Raw Software (http://chdk.wikia.com/wiki/Software#RAW_Conversion)
link> How do you fix lens distortion with CHDK RAW files? (http://chdk.setepontos.com/index.php?topic=6996)
link> Decoding CHDK RAW images from a new cameras (http://chdk.setepontos.com/index.php?topic=5855.msg59260#msg59260)
-
I played with this for a bit - its been about the only request I've received. Unfortunately, the gui part is "written" in autoit - and the scrolling list box is a huge hack I found after trolling lots of autoit forums. From what I can tell, there is no easy way to support select, cut & paste.
An alternative could be to just list the relative byte offset at the beginning of each line. Currently I had to tweak the number of bytes to load up and down, and scroll back to the bottom and see if I got the correct size. And I worry about slicing an instruction in half that way too.
-
Just dump more than you need and cut it off in text file ?
All ARM instructions are 32 bit - you can't cut one in half.
-
Just dump more than you need and cut it off in text file ?
All ARM instructions are 32 bit - you can't cut one in half.
It's easy to dump more than I need and cut it off in a text file. I'm talking about figuring out the size of the function, for addresses.txt.
... and now I've just figured out the Length box counts instructions, not bytes. Good thing addresses.txt also expects instruction count. (x86 assembly programmer here, used to variable-sized instructions...)
Okay, in that case, precede each line with the 0-based instruction number, so you can tell at a glance how long the function you're looking at is.
-
Alright, I got movie recording working on 1.01a. :)
I used CHDK-PT to check tommi2water's work, and found only one mistake:
BL sub_FFAE6E5C
should be
BL sub_FFAE6E58
This is in the region that I saw was shifted back 4 bytes in 1.01a. Nice to see CHDK-PT corroborating my earlier analysis. 8)
Others with 1.01a are invited to test this and see if it fixes the movie recording crash for you too. Note that the attached binary does not include PS.FI2 (because I have not yet learned the secrets needed to make one), so it must be loaded by auto-boot, not firm update.
-
And here's (hopefully) the movie-crash fix for 1.01c. Those with that firmware version are welcome to test (at your own risk).
-
Meant to ask about another strange thing I saw.
This instruction in the original firmware's movie recording task (present in all three versions; it's a few lines below loc_FF98565C in 1.00c):
STRD R2, [R6, #0xF8]
Turned into this in CHDK's version:
LDRD R2, [R6,#0xF8]
Was this intentional?
And tommi, where did you find the key information to make PS.FI2?
-
And here's (hopefully) the movie-crash fix for 1.01c. Those with that firmware version are welcome to test (at your own risk).
jstanley0- thanks for your efforts.
Movie recording still crashes on 1.01c. Recording seems to start - image display gets cropped into 16:9 view and record time counter displays 0". A moment later, screen goes blank and camera freezes.
Power button turns camera off. No need to remove battery etc.
-
Meant to ask about another strange thing I saw.
This instruction in the original firmware's movie recording task (present in all three versions; it's a few lines below loc_FF98565C in 1.00c):
STRD R2, [R6, #0xF8]
Turned into this in CHDK's version:
LDRD R2, [R6,#0xF8]
Was this intentional?
That looks wrong - was it generated by CHDK-PT? If so it's probably a bug; in which case waterwingz will probably fix it pretty quickly.
And tommi, where did you find the key information to make PS.FI2?
Send me a personal message with your email address and I'll send you the file.
Phil.
-
Meant to ask about another strange thing I saw.
This instruction in the original firmware's movie recording task (present in all three versions; it's a few lines below loc_FF98565C in 1.00c):
STRD R2, [R6, #0xF8]
Turned into this in CHDK's version:
LDRD R2, [R6,#0xF8]
Was this intentional?
That looks wrong - was it generated by CHDK-PT? If so it's probably a bug; in which case waterwingz will probably fix it pretty quickly.
Tell me more - those instructions are exact opposite in meaning. Getting it wrong will certainly break your code. LDRD & STRD were a major pain to get fixed right in the early versions of CHDK-PT as they are "new" ARM instructions. I did a lot of work to make sure I got it right - please post more info and files about what you have found ! Would not be my first mistake.
-
That looks wrong - was it generated by CHDK-PT? If so it's probably a bug; in which case waterwingz will probably fix it pretty quickly.
Here's the firmware dump (100c) from CHDK-PT with a little context:
ROM:FF985674 0xE59630B8 LDR R3, [R6, #0xB8]
ROM:FF985678 0xE58D3000 STR R3, [SP]
ROM:FF98567C 0xE5960090 LDR R0, [R6, #0x90]
ROM:FF985680 0xE1C62FD8 STRD R2, [R6, #0xF8]
ROM:FF985684 0xEB0585F4 BL sub_FFAE6E5C
It's possible that CHDK-PT disassembled 0xE1C62FD8 erroneously into STRD, but the LDRD in CHDK is correct. I wouldn't know - CHDK-PT is my only ARM disassembler.
-
Movie recording still crashes on 1.01c. Recording seems to start - image display gets cropped into 16:9 view and record time counter displays 0". A moment later, screen goes blank and camera freezes.
Same symptoms I saw before the fix. I compared 101c\movie_rec.c to CHDK-PT's output again and did not find any other errors.
Just want to make sure you loaded CHDK via a bootable locked SD card, not via firmware update. If you tried the latter, then you probably booted tommi's latest build instead of mine, because mine did not include PS.FI2 as mentioned a few posts ago.
-
Updated builds for 101a and 101c - these include PS.FI2, so you can launch manually via the firmware update menu.
-
Now I am very embarrassed. CHDK-PT v1.04 is definitely dissassembling STRD instructions where there should be LDRD instructions. It gets the STRD instructions right so its not a simple bit reversal.
This is bad - I can't believe we have not seen this before. I guess I need to check v1.03 to make sure something did not slip the wrong way between versions.
My apology's to all.
UPDATE : Bug was not there in v1.03. It was fixed back at 1.01 so I have no idea (yet) how it slipped back in. The change from 1.03 to 1.04 was just supposed to be a better addresses.txt file.
Link to correctly working 1.05 version : http://www.box.com/shared/38etrnb3yu (http://www.box.com/shared/38etrnb3yu)
-
If you tried the latter, then you probably booted tommi's latest build instead of mine, because mine did not include PS.FI2 as mentioned a few posts ago.
You're 100% correct. I just replaced tommi's DISKBOOT.BIN with yours. Appologies.
Just tried your latest build and movie recording is working !!!
-
Hi all!
Stanley, just tried your build (1.01a) and video recording works!
But only if the video quality is set to 76 or higher ::)
If the quality is reduced to 75 or below (either in the CHDK menu or by pressing "down" while recording), the camera shuts down, with the following message:
A camera error has been detected.
Will shut down automatically.
Please restart camera.
E10
Apart from that video recording seems to work perfectly, though :)
-
Alright, I got movie recording working on 1.01a. :)
Well done, jstanley! :D
Update:
I integrated files from jstanley and created a SVN patch from my local trunk version and sent this patch to developers for first integration: http://chdk.setepontos.com/index.php?topic=650.msg76782#msg76782 (http://chdk.setepontos.com/index.php?topic=650.msg76782#msg76782)
-
Hi,
I'm new to CHDK. My IXUS 220HS has the firmware 1.01d, can someone help me running CHDK on my cam?
Dump from 1.01d: PRIMARY.BIN - 7.94MB (http://www.zshare.net/download/96723673e7b0f43b/)
Dump Log: Started - FF810000 dry - done
Thank you!
For further information, please don't hesitate to ask me...
-
My IXUS 220HS has the firmware 1.01d, can someone help me running CHDK on my cam?
You defined the firmware version with the program "CameraVersion"?
Try CHDK_1.01c.
It works for me.
("CameraVersion" also shows 1.01d, vers.req does not work)
-
Hi all!
Stanley, just tried your build (1.01a) and video recording works!
But only if the video quality is set to 76 or higher ::)
If the quality is reduced to 75 or below (either in the CHDK menu or by pressing "down" while recording), the camera shuts down, with the following message:
A camera error has been detected.
Will shut down automatically.
Please restart camera.
E10
Apart from that video recording seems to work perfectly, though :)
In movie_rec.c the lines:
" LDR R0, =0x6E10 \n"
" BL set_quality \n"
should be:
" LDR R0, =0x6E10-4 \n"
" BL set_quality \n"
Phil.
-
Changed 0x6E10 to 0x6E0C.
Binaries for 1.00c and 1.01a attached.
-
Binary for 1.01c attached.
-
My IXUS 220HS has the firmware 1.01d, can someone help me running CHDK on my cam?
You defined the firmware version with the program "CameraVersion"?
Try CHDK_1.01c.
It works for me.
("CameraVersion" also shows 1.01d, vers.req does not work)
I used the program "Automatic Camera Identifier and Downloader (ACID)".
CHDK_1.01c works for me too, thank you.
-
Changed 0x6E10 to 0x6E0C.
Works now, with any quality, thanks :)
I tried normal video recording, movie digest, slow motion, and it all seems to be working perfectly.
I was playing around with the photo overrides, and the aperture refuses to change to anything except 2.7 and 8.0.
If I set the override value as something large, it sets it at 8.0, if I set it to something small, it sets it at 2.7.
I was thinking that maybe now that video recording is safely out of the way, someone might want to start figuring out why the photo overrides don't work so well? :P
I know I must be quite a brat complaining about this and that not working and not being able to program myself :-X :D
But the prospect of turning my camera into something far less crippled than canon made it is an exciting one :)
Great job guys! :xmas
-
I know I must be quite a brat complaining about this and that not working and not being able to program myself :-X :D
No, any comment/bug report is welcome!
From your feedback we know what issues still have to be fixed.
It's not possible that we find all issues on our own. To be honest, I had not much time to play around with CHDK during the last two days because of stepping through assembler code. :haha
So, please test and feel free to provide your feedback. :D
-
I was playing around with the photo overrides, and the aperture refuses to change to anything except 2.7 and 8.0.
That may not be a bug. Please see http://chdk.wikia.com/wiki/ND_Filter (http://chdk.wikia.com/wiki/ND_Filter)
-
I was playing around with the photo overrides, and the aperture refuses to change to anything except 2.7 and 8.0.
That may not be a bug. Please see http://chdk.wikia.com/wiki/ND_Filter (http://chdk.wikia.com/wiki/ND_Filter)
interesting, thanks for posting.
-
@tommi2water
@jstanley0
Congratulations, great job !
... That may not be a bug. Please see http://chdk.wikia.com/wiki/ND_Filter (http://chdk.wikia.com/wiki/ND_Filter)
Note that the default camera properties (in /include/camera.h) has
#define CAM_HAS_IRIS_DIAPHRAGM 1 // Camera has real diaphragm mechanism (http://en.wikipedia.org/wiki/Diaphragm_%28optics%29 (http://en.wikipedia.org/wiki/Diaphragm_%28optics%29))
which means that we need (in platform/ixus220_elph300hs/platform_camera.h)
#undef CAM_HAS_IRIS_DIAPHRAGM
in order to instruct CHDK that there's no aperture - override aperture options will then not be
shown in the menu anymore.
hope that helps,
wim
-
Regarding firmware 1.01d: I've confirmed the known stubs haven't moved since 1.01c. I've diffed the two firmwares in a hex editor, and not much has changed. From what I can see, the code is identical, but some data toward the end is different. I did not do a complete analysis, though.
So it's not a fluke that a couple 1.01d users have had success with the 1.01c build. (I see in the wiki there are a handful of other cases like this.) We need to be sure both firmware versions are well-tested, though, in case some of the data changes wind up making a significant difference after all.
-
Regarding firmware 1.01d: I've confirmed the known stubs haven't moved since 1.01c. I've diffed the two firmwares in a hex editor, and not much has changed. From what I can see, the code is identical, but some data toward the end is different. I did not do a complete analysis, though.
There is a bunch of stuff up toward the top of a typical dump for most cameras that changes each time you dump from the same camera. I assume its a RAM / NVRAM / EEPROM area and not ROM.
So it's not a fluke that a couple 1.01d users have had success with the 1.01c build. (I see in the wiki there are a handful of other cases like this.) We need to be sure both firmware versions are well-tested, though, in case some of the data changes wind up making a significant difference after all.
You are correct - there are a number of ports where one firmware version matches another. Checking the stubs and maybe the three C task files should be all that is necessary to assure a match.
-
We still have some image capturing problems:
- ISO speed override results in a crash when you half-press the shutter
- I suspect this has something to do with shooting_expo_iso_override in shooting.c, which was lifted verbatim from the 500hs, which was lifted verbatim from the sx220hs ...
- Also in this file, the aperture table is incorrect - this camera has a different lens than the 500hs. Don't know how to find the proper values for this, however.
- Focus distance override doesn't appear to do anything
- Possibly due to incorrect focal length table in main.c? (That one appears to be lifted straight from sx220. the 500hs devs seem to have adapted theirs properly.)
- ND filter override doesn't appear to do anything
- although I'm not positive this camera even has one
It's getting late here and I need to go to work tomorrow morning, but I'll dive deeper into these issues tomorrow evening.
-
That may not be a bug. Please see http://chdk.wikia.com/wiki/ND_Filter (http://chdk.wikia.com/wiki/ND_Filter)
We still have some image capturing problems:
- ND filter override doesn't appear to do anything
- although I'm not positive this camera even has one
Hmmm. So I tried the ND filter option on tommi's latest build and IT WORKS.
The scene gets darker with the filter in. I tested a fairly dim scene where the camera automatically swings the filter out, but CHDK forces it in, making it too dark (=> it works)
(EDIT: I can hear it go "click" every time it swings in/out :P
Also, it's quite clearly visible through the lens. It is automatically deployed whenever the camera is pointed at a bright scene)
(EDIT 2: I did some searching and it seems all IXUS models have an ND filter to make up for lack of an iris.
I also found this thread - pics of a disassembled IXUS 800 lens showing the filter: http://chdk.setepontos.com/index.php/topic,548.0.html (http://chdk.setepontos.com/index.php/topic,548.0.html))
A couple of days ago, when I was trying one of the older builds (don't remember which one now :'() I could actually set the "aperture" to THREE different values, not two. F16, F8, and F2.7.
I even used the F16 stop for a long exposure shot of traffic in the night with a 10 second shutter!
Which would mean that there is something other than the ND filter at work in this camera?
EDIT: I forgot about zoom! It was "F16" at around 4x zoom! Sorry for the confusion ::)
I still have the problems with ISO and the focus distance override, though.
It's not possible that we find all issues on our own. To be honest, I had not much time to play around with CHDK during the last two days because of stepping through assembler code. :haha
So, please test and feel free to provide your feedback. :D
Alright! I play around way too much with it anyway :lol
-
I found another problem.
Both zebra mode and edge overlay behave this way:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FpuUBv.jpg&hash=e4a72b54bb22a4d8890f05f3a43a0eba)
I get a distorted version, x9, tiled on the screen.
Exactly the same thing happens for edge overlay, too, though it's not so clear in this picture:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FdulWQ.jpg&hash=65b41b93742d30d04b23b77d6d122787)
And then there's the constant flickering of the OSD items, especially when the canon menu is opened with the FUNC./SET button.
The OSD is drawn over it, and it flickers quite terribly.
Perhaps these are slightly related?
-
The scene gets darker with the filter in. I tested a fairly dim scene where the camera automatically swings the filter out, but CHDK forces it in, making it too dark (=> it works)
My mistake. I thought "in" means it's stowed, and "out" means it's deployed. The image was not made any darker with the filter "out", so it must not be working. ::)
A couple of days ago, when I was trying one of the older builds (don't remember which one now :'() I could actually set the "aperture" to THREE different values, not two. F16, F8, and F2.7.
I even used the F16 stop for a long exposure shot of traffic in the night with a 10 second shutter!
Which would mean that there is something other than the ND filter at work in this camera?
There is something at work, namely the fact that, despite there not being an aperture diaphragm, the effective aperture is narrower when you zoom the lens. The front of the lens is labeled F2.7-F5.9; that's roughly two stops, so equivalent to the difference between the fake apertures F8 and F16.
-
The image was not made any darker with the filter "out", so it must not be working. ::)
:haha :)
That didn't strike me at all, or I might have thought the same thing :P
the effective aperture is narrower when you zoom the lens.
This is very interesting.
I played around with the aperture settings and found something a bit strange:
- I set the aperture override to OFF and:
- The camera sets it to F2.7
- I set the aperture override to 16.00 and:
- The camera sets it to F8.0
- The photo is darker than the previous one
So I think, hmm maybe the ND filter is being deployed and the camera is pretending that the ND filter makes it F8.0?
So I set the CHDK ND filter override to "Out" and try again, and I get exactly the same results!
Aperture override: Off
Aperture value used by camera: F2.7
Shutter speed: 1/10
ND filter override: Out
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2Fj2Pqz.jpg&hash=c0fff55ace4fbf38e9f4e345792d38f6)
Aperture override: 16.00
Aperture value used by camera: F8.0
Shutter speed: 1/10
ND filter override: Out
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FqQnaL.jpg&hash=ed10c5f09d5c57cd505ebc0a594c1e18)
Am I missing something here? ???
Update: I'm very confused.
Taking photos without aperture override (auto-set to F2.7) and WITH the ND filter yields exactly the same results as an aperture override of 16.0 (auto-set to F8.0).
This leads me to believe that the camera is for some reason trying to fool me into believe it can set the aperture to values that it actually cant, while simply using the ND filter.
Or CHDK is fooling the camera into believing that it can do things it can't? ???
-
Hi there,
first of all, i want to thank everyone working hard to get CHDK running on this camera!
My camera has FW-Version 1.01d and I'm using yesterdays build. When I use the autoload function, and start up the camera already connected to the pc or connect it after starting, I just get:
A camera error was detected
Will shut down automatically
Restart camera
E41
The short "splashscreen" giving mit the CHDK - Version and so on is in this case red and not orange.
In case I load CHDK manually and connect the camera to the PC, it just goes the review - mode, shows one picture and does not react to anything but the ALT-key. It is also not being "recognized" by the computer.
Any idea about that?
Keep up the good work!
-
You are correct - there are a number of ports where one firmware version matches another. Checking the stubs and maybe the three C task files should be all that is necessary to assure a match.
I'm wondering if creating a separate 101d variant would make sense?
Until now we only know that some 101d users are satisfied with 101c firmware.
Should we stay with three variants (100c, 101a, 101c) and wait with creating 101d variant until 101d users report differences or problems we don't see on other variants? Or should we add 101d variant immediately to our platform that Autobuild server can create 101d builds as well?
I would prefer to add the 101d variant to our platform to avoid confusion for 101d users.
-
I was reading this thread http://chdk.setepontos.com/index.php?topic=7124.0 (http://chdk.setepontos.com/index.php?topic=7124.0) and remembered my own problems with creating badpixel.bin file.
Phil provided a solution for my bad RAW images:
In this case the RAW buffer addresses looks OK; but the location of the active buffer is wrong.
From looking at the firmware is should probably be 0x2E94 not 0x3F04 (see sub_FF884C18 in 1.00c firmware).
I just thought that badpixel.bin generation could now also be possible after shooting RAW images was fixed.
And I'm happy to tell you that a badpixel.bin file has been generated during the first try. :)
Who hasn't generated a badpixel.bin file until now should try it once again.
-
Currently I'm working on the Modemap table from shooting.c file which is checked and reported in stubs_entry.S file. As Phil mentioned we get many errors reported. I didn't mind about that until now because I never knew what these modes are necessary for. ;)
How to find out correct values or verify existing Modemap table (CapturemodeMap modemap[]) entries in shooting.c :
I found out that in <ALT> Menu -> Misc -> Debug Parameters these mode values can be made visible very easy. Just activate "Debug Data Display [Props]" and "Propcase Page 5". Entry no. 50 will show the value for the current active mode. I will check each mode which can be activated in the Canon software and update shooting.c file.
My battery just died so I will work on this task tomorrow when my battery is recharged again. :D
-
You are correct - there are a number of ports where one firmware version matches another. Checking the stubs and maybe the three C task files should be all that is necessary to assure a match.
I'm wondering if creating a separate 101d variant would make sense?
Until now we only know that some 101d users are satisfied with 101c firmware.
Should we stay with three variants (100c, 101a, 101c) and wait with creating 101d variant until 101d users report differences or problems we don't see on other variants? Or should we add 101d variant immediately to our platform that Autobuild server can create 101d builds as well?
I would prefer to add the 101d variant to our platform to avoid confusion for 101d users.
There are a number of cameras where one CHDK version will work for two or more Canon firmware versions.
If 1.01c loads and runs on a 1.01d camera then it's likely the firmware differences don't affect CHDK (possibly just some corrections to different language text).
If this is the case then the autobuild process can be set up to automatically generate a 1.01d version by copying the 1.01c files - this is a convenience so people can find their version without constantly asking which one to use. It also saves creating and maintaining another firmware version directly.
Phil.
-
How to find out correct values or verify existing Modemap table...
Here's the values I get on 1.01c going down the modes:
P - 32772
Digest - 33333
Portrait - 32783
Kids&Pets - 32786
Smart Shutter - 33321
High-Speed Burst - 33288
Best Image Selection - 33289
Handheld Nightscene - 33325
Low Light - 32801
Fish-eye Effect - 33323
Miniature Effect - 33324
Toy Camera Effect - 33327
Monchrome - 33330
Super Vivid - 33318
Poster Effect - 33319
Color Accent - 33309
Color Swap - 33310
Beach - 32791
Underwater - 32793
Foliage - 32789
Snow - 32790
Long Shutter - 32774
Stitch Assist --> - 33292
Stitch Assist <-- - 33292
Super Slow Motion Movie - 2626
-
Hello all, I found out about this CHDK thing today, spent some time looking around for info on my specific camera (the ELPH300) and found out that I apparently have firmware version 1.01e. If one of y'all can point me to a fairly painless way to pull and dump this for y'all if you're interested, I'd be happy to do so.
I'm going to try to use the 1.01c on it to see if it works.
Ok, so I put the 1.01c on it and loaded it using the manual mode (having to go through the firmware update to turn it on) and I got the splash screen (it was up for too short of a time to tell exactly what it said), and now I've got what I assume to be my open memory (962M) the always own battery display with percentage, the time, and "opt:28°". I haven't discovered any other differences yet (not in the menus or function).
Alrighty, so I got into the menu for CHDK, the histogram options work, I've not been able to get RAW to work though, but that might just be me. I'll stop playing with trying to figure out what options work and which ones don't for a bit to attempt to get this firmware up to y'all.
-
If one of y'all can point me to a fairly painless way to pull and dump this for y'all if you're interested, I'd be happy to do so.
http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper (http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper)
-
Ok, so I put the 1.01c on it and loaded it using the manual mode (having to go through the firmware update to turn it on) and I got the splash screen (it was up for too short of a time to tell exactly what it said), and now I've got what I assume to be my open memory (962M) the always own battery display with percentage, the time, and "opt:28°". I haven't discovered any other differences yet (not in the menus or function).
A short press in the video button will take you into <Alt> mode, you'll see <Alt> bottom center of screen.
Then press "Menu", and you're in the CHDK menu.
Then, you'll probably want to read(on the web) (http://chdk.wikia.com/wiki/CHDK_User_Manual) or download(as pdf) (http://chdk.wikia.com/wiki/File:CHDK_UserGuide_April_2009_A4.pdf) the User Manual/Guide ...
enjoy,
wim
[edit: spelling + added some more text]
PS To increase your comfort and decrease power consumption while playing with the CHDK menu, I would
also recommend switching to REVIEW mode before switching to <Alt> mode. To do this,
press and hold the 'Play' (=blue triangle) button until the cam starts retracting the lens assembly.
Note While in <Alt> mode, all keys are hijacked by CHDK, e.g. you can not take pictures; to
use the cam 'normally', leave <Alt> mode with another short press on video button (CHDK will
keep running in the background)
-
http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper (http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper)
How do I know when it's done? In the upper left where it's trying to display messages isn't changing any more (I've not been waiting this long, I just now figured out what I was doing wrong with the script)?
Nevermind, the screen just went off and I moved the card to my computer and the cbdumper.log and primary.bin are there.
So where do I upload the primary.bin to?
Also, whim, thanks that's very helpful.
-
How do I know when it's done? In the upper left where it's trying to display messages isn't changing any more (I've not been waiting this long, I just now figured out what I was doing wrong with the script)?
It only takes a couple of seconds. There should be an 8M PRIMARY.BIN file in the root of your SD card if it worked.
Update : fixed file size
-
A quick bump because I don't believe waterwingz saw that I edited my earlier post: I've got the bin file...8G? it's 8 meg...
But yeah, I need to know where I can upload/email it.
Full discloser, to be sure about the firmware version, I used exiftool (ver 8.71) which just listed it as 1.01 with no letter, I got the 1.01e from acid: http://www.zenoshrdlu.com/acid/acid.zip (http://www.zenoshrdlu.com/acid/acid.zip)
Thanks for y'all's patience.
-
So where do I upload the primary.bin to?
Box.com works well and doesn't have the annoying delays that others have if you don't buy their premium service.
Compress primary.bin to a zip file to save space.
Phil.
-
<never mind - nothing to see here .. move along please>
-
I feel kinda dumb. Yeah, I was assuming that y'all had some special place to put them. Anyway, here's the link to the file:
http://www.box.com/s/o1acdvmvxsqpxrtl4933 (http://www.box.com/s/o1acdvmvxsqpxrtl4933)
-
I feel kinda dumb. Yeah, I was assuming that y'all had some special place to put them.
We do - but fe50 maintains it so you need to put the file somewhere that he can find it.
http://www.box.com/chdk (http://www.box.com/chdk)
-
We do - but fe50 maintains it so you need to put the file somewhere that he can find it.
http://www.box.com/chdk (http://www.box.com/chdk)
Well, that makes sense. Ah well.
So an update (had to recharge my battery): I can get it to create .crw files, but I haven't managed to get them open (the Canon bundled software, ACDSee version 12, Paintshop Pro x4, and GIMP's UFRaw plugin all claim it is unsupported. When I changed it over to .dng raw files, those images can be opened.
-
So an update (had to recharge my battery): I can get it to create .crw files, but I haven't managed to get them open (the Canon bundled software, ACDSee version 12, Paintshop Pro x4, and GIMP's UFRaw plugin all claim it is unsupported. When I changed it over to .dng raw files, those images can be opened.
link : http://chdk.setepontos.com/index.php?topic=7144.msg76794#msg76794 (http://chdk.setepontos.com/index.php?topic=7144.msg76794#msg76794)
-
I can’t find any information about changes in CHDK for Ixus220.
What with manual mode, like extended range of shutter speeds, shutter priority, 1/1000s, EV comp, auto focus and others?
BTW Is it possible to block video exposure and solve limit of 10 minutes for hd movies?
-
Comparing the 1.01c, 1.01d and 1.01e firmware dumps it looks like they are all compatible with the 1.01c CHDK version.
I have added 1.01d and 1.01e to the autobuild as copies of 1.01c.
Also fixed a couple of entries in stubs_min.S for the 1.01a and 1.01c versions.
Phil.
-
Thanks for this. Great job! I have v1.01A. I had never installed CHDK on any other cameras before.
edit: removed my feature request since it was off topic and I don't want it clogging search results
-
I'd love an option to automatically create a new file when the 4GB limit is reached and keep recording.
Scripts to do that have been posted several times on this forum. Use the search box at the top of the page - this has been a popular request. (hint : video time limit)
-
Here's the values I get on 1.01c going down the modes:
These values are all the same on 1.01a.
I should add that Auto is mode 32768
-
I've been chasing the flicker problem - it's really bad in Auto mode, when the moving focus box clobbers the CHDK menu, but it's noticeable whenever Canon's OSD updates change.
I've compared lib.c for various cameras and I've seen two flavors of vid_bitmap_refresh(). One flavor, used with the sx230hs, calls _LockAndRefresh() / _UnlockAndRefresh(). I notice our lib.c looks very very similar to that one, only we have _ScreenLock() / _ScreenUnlock() primitives instead. But other cameras that use these - for instance, sx40hs, have an active_viewport_buffer in stubs_min.S, and a vid_get_viewport_live_fb function in lib.c.
So I'm guessing we need to find active_viewport_buffer in memory, so we can enable double-buffered drawing for CHDK?
-
I've compared lib.c for various cameras and I've seen two flavors of vid_bitmap_refresh(). One flavor, used with the sx230hs, calls _LockAndRefresh() / _UnlockAndRefresh(). I notice our lib.c looks very very similar to that one, only we have _ScreenLock() / _ScreenUnlock() primitives instead. But other cameras that use these - for instance, sx40hs, have an active_viewport_buffer in stubs_min.S, and a vid_get_viewport_live_fb function in lib.c.
Here's a simple hack I've used during the early part of porting a new camera.
extern unsigned int screen_width, screen_height, screen_size;
extern void draw_filled_rect( int, int, int, int, int );
void vid_bitmap_refresh()
{
draw_filled_rect(0, 0, screen_width, screen_height, 0x00) ;
}
Does that fix the problem ?
-
Here's a simple hack I've used during the early part of porting a new camera.
extern unsigned int screen_width, screen_height, screen_size;
extern void draw_filled_rect( int, int, int, int, int );
void vid_bitmap_refresh()
{
draw_filled_rect(0, 0, screen_width, screen_height, 0x00) ;
}
Does that fix the problem ?
Doesn't seem to make a difference.
-
Here's the values I get on 1.01c going down the modes:
These values are all the same on 1.01a.
I should add that Auto is mode 32768
Thanks, guys! :)
I can confirm the same values for 1.00c.
Attached you'll find new shooting.c file.
Update:
stubs_entry.S is now only complaining about three modemap entries:
// Mode 33320 in firmware but not in current modemap
// Mode 33322 in firmware but not in current modemap
// Mode 32792 in firmware but not in current modemap
If they are the same as in ELPH500 than these could be:
{ MODE_SCN_FACE_SELF_TIMER, 33320 },
{ MODE_SCN_WINK_SELF_TIMER, 33322 },
{ MODE_SCN_FIREWORK, 32792 },
Does that mean we could be able to use e.g. the WinkSelfTimer?
Modemaps are available in Firmware but we cannot activate them via standard Canon Firmware.
-
{ MODE_SCN_FACE_SELF_TIMER, 33320 },
{ MODE_SCN_WINK_SELF_TIMER, 33322 },
{ MODE_SCN_FIREWORK, 32792 },
Does that mean we could be able to use e.g. the WinkSelfTimer?
Modemaps are available in Firmware but we cannot activate them via standard Canon Firmware.
I believe the ELPH300 combines face self timer and wink self timer into the "smart shutter" mode.
Odd that fireworks mode is missing. It appears Canon must have taken it out, because it's in some documentation (http://canoncanada.custhelp.com/app/answers/detail/a_id/32075/~/shooting-in-various-scenes-%28powershot-elph-300-hs-%2F-100-hs%29).
[Edit: fireworks mode may only be selectable automatically, if the camera detects fireworks. landscape mode is gone too, but I've seen the camera put the landscape icon up during auto mode.]
-
I believe the ELPH300 combines face self timer and wink self timer into the "smart shutter" mode.
Yes, you are right.
Show your camera this page when SmartShutter mode is active:
http://www.google.de/search?q=l%C3%A4cheln&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&ie=UTF-8&hl=de&tbm=isch&source=og&sa=N&tab=wi&biw=1440&bih=728&sei=JFHWTvjINsbLtAbrzs26Dg (http://www.google.de/search?q=l%C3%A4cheln&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&ie=UTF-8&hl=de&tbm=isch&source=og&sa=N&tab=wi&biw=1440&bih=728&sei=JFHWTvjINsbLtAbrzs26Dg)
:D
-
[Edit: fireworks mode may only be selectable automatically, if the camera detects fireworks. landscape mode is gone too, but I've seen the camera put the landscape icon up during auto mode.]
Oh, then I propose to add these three modes also to the modemap in shooting.c. Just to be sure that they are not missing. What do you think, jstanley?
-
Oh, then I propose to add these three modes also to the modemap in shooting.c. Just to be sure that they are not missing. What do you think, jstanley?
Sounds good to me.
-
Hey, being a complete NEWBIE to CHDK, I wanted to ask how can I get CHDK for my CANON IXUS 220HS? :/
And what does it do ? :/
-
Hey, being a complete NEWBIE to CHDK, I wanted to ask how can I get CHDK for my CANON IXUS 220HS? :/
And what does it do ? :/
Quite easy task for you.
Go here and read: http://chdk.wikia.com/wiki/FAQ (http://chdk.wikia.com/wiki/FAQ)
As soon as you know your camera firmware version and know how you start CHDK on your camera,
go here for the link to the CHDK Autobuild server: http://chdk.wikia.com/wiki/Downloads (http://chdk.wikia.com/wiki/Downloads)
This thread is only about porting CHDK to a specific camera model.
Questions about CHDK please ask in another forum area. Thanks.
-
Hey, being a complete NEWBIE to CHDK, I wanted to ask how can I get CHDK for my CANON IXUS 220HS? :/
And what does it do ? :/
Quite easy task for you.
Go here and read: http://chdk.wikia.com/wiki/FAQ (http://chdk.wikia.com/wiki/FAQ)
As soon as you know your camera firmware version and know how you start CHDK on your camera,
go here for the link to the CHDK Autobuild server: http://chdk.wikia.com/wiki/Downloads (http://chdk.wikia.com/wiki/Downloads)
This thread is only about porting CHDK to a specific camera model.
Questions about CHDK please ask in another forum area. Thanks.
Okay. Thanks bye.
-
We still have some image capturing problems:
- ISO speed override results in a crash when you half-press the shutter
- I suspect this has something to do with shooting_expo_iso_override in shooting.c, which was lifted verbatim from the 500hs, which was lifted verbatim from the sx220hs ...
Connected to above issue is the following:
I looked into the HDR script issue and did some testing with different variations of this HDR script to figure out which command could be responsible for crash.
As long as I remove all set_sv96(s) calls from the script, everything works fine.
The next shoot() command after a set_sv96(s) command will lead to camera shutdown (with lens staying outside).
I get the same crash when I override ISO values via ALT menu settings (like jstanley already reported).
The root cause for crash from HDR script is clear now, it is the Override of ISO settings. As soon as we have been able to fix the ISO override issue the HDR script should also work fine.
In capt_rec.c I commented out:
//" BL shooting_expo_iso_override\n"
" BL sub_FF88319C \n"
" BL shooting_expo_param_override\n"
and the behaviour is the same => crash.
Also this variant leads to crash:
" BL shooting_expo_iso_override\n"
" BL sub_FF88319C \n"
//" BL shooting_expo_param_override\n"
Only with this configuration in capt_seq.c no crash any more: :(
//" BL shooting_expo_iso_override\n"
" BL sub_FF88319C \n"
//" BL shooting_expo_param_override\n"
If one of these two functions is called => crash.
btw:
How to find out correct values or verify existing entries in shooting.c :
I found out that in <ALT> Menu -> Misc -> Debug Parameters these mode values can be made visible very easy. Just activate "Debug Data Display [Props]" and "Propcase Page 14". Entry no. 149 will show the current ISO value.
I checked these values and verified that ISOTable iso_table[] in shooting.c is correct.
-
Oh, then I propose to add these three modes also to the modemap in shooting.c. Just to be sure that they are not missing. What do you think, jstanley?
Sounds good to me.
Added new shooting.c and shooting.c.patch for subversion integration.
-
I noticed .DNG files had ludicrous focal lengths reported in the Exif data. This because CHDK still had the address of the sx220's focus length table. I found the table in the ELPH300 (it's in the same place in all three firmwares) and updated main.c and all stubs_min.S files to reflect this. Now the metadata reports a sane value.
This patch also fixes a few minor problems in platform_camera.h, and adjusts the aperture table in shooting.c to something a bit closer (it's not exact; it's stolen from the ixus200, which has a similar lens; I'm not sure where to find the real info for this - I didn't see it in propcase 26, where some comments referenced).
[EDIT: patch applies to trunk revision 1441]
-
Added the
full 8MB dump (dumped with cBasic udumper) provided by siloxr from this forum post (http://chdk.setepontos.com/index.php?topic=6341.msg76908#msg76908) to the box.net/chdk (http://www.box.net/chdk) repository.
-
I noticed .DNG files had ludicrous focal lengths reported in the Exif data. This because CHDK still had the address of the sx220's focus length table. I found the table in the ELPH300 (it's in the same place in all three firmwares) and updated main.c and all stubs_min.S files to reflect this. Now the metadata reports a sane value.
This patch also fixes a few minor problems in platform_camera.h, and adjusts the aperture table in shooting.c to something a bit closer (it's not exact; it's stolen from the ixus200, which has a similar lens; I'm not sure where to find the real info for this - I didn't see it in propcase 26, where some comments referenced).
[EDIT: patch applies to trunk revision 1441]
Added in changeset 1442.
FYI - patches for stuff in the main trunk normally get posted in http://chdk.setepontos.com/index.php?topic=650 (http://chdk.setepontos.com/index.php?topic=650)
Phil.
-
Here's another iteration that also crashes:
" BL shooting_expo_iso_override\n" // added
" BL sub_FF88319C \n"
" BL shooting_expo_param_override\n" // added
" BL sub_FF8800A8 \n"
//" MOV R0, #0\n" // added
//" STR R0, [R5,#0x28]\n" // added, fixes overrides behavior at short shutter press (from S95)
I figured shooting_expo_iso_override was setting some variable that we don't have the right address for, and clobbering something important. But it doesn't seem to access any model-specific data.
Still stymied on this one...
-
I got the zebras working by changing lib.c from this:
int vid_get_viewport_buffer_width() { return 960; }to this:
int vid_get_viewport_buffer_width() { return 360; }
Edge detection works for every other shot. That is, once you take a shot, the edges from the previous shot keep being displayed--it doesn't update in real-time. Then when you take another shot, it resumes working. I would guess the camera has two viewports that it alternates between, and CHDK is only looking at the first. (As a wild guess, I might say this is how they implement panorama stitch mode - show the previous viewport so you can line up the next shot with the current one.)
Zebras don't quite work right when you choose an aspect ratio other than 4:3. The borders at the edge of the shot are "underexposed". I can fix this by adjusting vid_get_viewport_xoffset() / _yoffset() / etc. - actually, I stole the ones from the sx40, because it has the same resolution/aspect ratio screen, and same viewport width. Problem is, _that_ breaks edge detection: the edges no longer line up with the display. Oh, and the camera crashes too.
-
I got the zebras working by changing lib.c from this:
int vid_get_viewport_buffer_width() { return 960; }to this:
int vid_get_viewport_buffer_width() { return 360; }
Edge detection works for every other shot. That is, once you take a shot, the edges from the previous shot keep being displayed--it doesn't update in real-time. Then when you take another shot, it resumes working. I would guess the camera has two viewports that it alternates between, and CHDK is only looking at the first. (As a wild guess, I might say this is how they implement panorama stitch mode - show the previous viewport so you can line up the next shot with the current one.)
Zebras don't quite work right when you choose an aspect ratio other than 4:3. The borders at the edge of the shot are "underexposed". I can fix this by adjusting vid_get_viewport_xoffset() / _yoffset() / etc. - actually, I stole the ones from the sx40, because it has the same resolution/aspect ratio screen, and same viewport width. Problem is, _that_ breaks edge detection: the edges no longer line up with the display. Oh, and the camera crashes too.
In the sub/xxxx/lib.c files you are using the IXUS 310 model for vid_get_viewport_live_fb and vid_get_viewport_fb.
This code is subtracting vid_get_viewport_xoffset()*3 from the actual buffer address.
This is probably wrong - this hack only seems to apply to widescreen cameras where the image is always left justified in the viewport memory. On 4:3 display cameras the image is centered in the viewport. CHDK code assumes the image is centered so the offset is used to fool it.
Phil.
-
Here's another iteration that also crashes:
" BL shooting_expo_iso_override\n" // added
" BL sub_FF88319C \n"
" BL shooting_expo_param_override\n" // added
" BL sub_FF8800A8 \n"
//" MOV R0, #0\n" // added
//" STR R0, [R5,#0x28]\n" // added, fixes overrides behavior at short shutter press (from S95)
I figured shooting_expo_iso_override was setting some variable that we don't have the right address for, and clobbering something important. But it doesn't seem to access any model-specific data.
Still stymied on this one...
To investigate this sort of problem dump the crash ROM log (option in the debug menu).
This will give the location of where firmware has crashed and the stack trace.
At the top of the log is the line number and source file where the assert was raised in the firmware - you can search the firmware dis-assembly to find these.
Using the stack trace, firmware dis-assembly and the core/main.dump file from the build that crashed you can locate where the error occurred and the call sequence that triggered it. This may give some clues as to what is going wrong.
If you dump the log and upload that along with the main.dump file then I can help you analyse it (also need to know which camera firmware version it is from).
Phil.
-
In the sub/xxxx/lib.c files you are using the IXUS 310 model for vid_get_viewport_live_fb and vid_get_viewport_fb.
This code is subtracting vid_get_viewport_xoffset()*3 from the actual buffer address.
This is probably wrong - this hack only seems to apply to widescreen cameras where the image is always left justified in the viewport memory. On 4:3 display cameras the image is centered in the viewport. CHDK code assumes the image is centered so the offset is used to fool it.
Aha! Thank you for pointing that out. That was indeed the problem.
I've submitted a patch.
-
That was indeed the problem.
I've submitted a patch.
I tried the latest build and zebra and edge overlay seem to be working fine! :)
-
If you dump the log and upload that along with the main.dump file then I can help you analyse it (also need to know which camera firmware version it is from).
Before uploading log and main.dump I would like to ask about the log file.
My logfile starts with:
Exception!! Vector 0x10
Occured Time 2011:11:27 12:58:22
Task ID: 15204383
Task name: SpyTask
Exc Registers:
0x00000008
0x000000FF
...
Date in camera is set correctly. Maybe this is only an old CrashRomLog from my first tests (better call them crashes ;)) on 27.November? There is no other "Occured Time" mentioned in that ROMLOG.LOG file. Probably this logfile is not belonging to the crash when pressing Shutter_Half after override of ISO is set.
-
Hey Guys ! i registered here to thank you for your work !
im using a ixus220hs (1.01c) with CDHK and the 7upLight for intervall shots !
Works great, the only thing to do is to deactivate the "LCD shutdown" in the script menu than everything is working fine :)
i never worked with CDHK and it took me only 10 minutes to get everything to work ! real beginner friendly pice of software. :)
Thanks a lot !! :xmas
-
If you dump the log and upload that along with the main.dump file then I can help you analyse it (also need to know which camera firmware version it is from).
Before uploading log and main.dump I would like to ask about the log file.
My logfile starts with:
Exception!! Vector 0x10
Occured Time 2011:11:27 12:58:22
Task ID: 15204383
Task name: SpyTask
Exc Registers:
0x00000008
0x000000FF
...
Date in camera is set correctly. Maybe this is only an old CrashRomLog from my first tests (better call them crashes ;)) on 27.November? There is no other "Occured Time" mentioned in that ROMLOG.LOG file. Probably this logfile is not belonging to the crash when pressing Shutter_Half after override of ISO is set.
You can use the memory browser to cause a crash (increase the increment to a high value then browse past the end of RAM). Then dump this log.
Crash the camera with the ISO override and dump another log - if it hasn't changed then you've managed to crash the camera without it doing a DebugAssert call. This is pretty rare in my experience and is going to be a lot tougher to diagnose.
Phil.
-
Crash the camera with the ISO override and dump another log - if it hasn't changed then you've managed to crash the camera without it doing a DebugAssert call. This is pretty rare in my experience and is going to be a lot tougher to diagnose.
Unfortunately, my results agree with tommi's. The romlog shows an earlier crash in SpyTask. Twice I've reproduced the ISO crash, then dumped the romlog again, and it's unchanged.
I should point out that the camera doesn't shut down immediately when you half-press the shutter after overriding ISO. It stops responding to input then, but the live view continues to update for at least several seconds. It might go indefinitely; I wouldn't know, I usually turn it off or eject the battery. The most recent time, it shut down when I moved the zoom lever several seconds after the half-press.
-
Crash the camera with the ISO override and dump another log - if it hasn't changed then you've managed to crash the camera without it doing a DebugAssert call. This is pretty rare in my experience and is going to be a lot tougher to diagnose.
Unfortunately, my results agree with tommi's. The romlog shows an earlier crash in SpyTask. Twice I've reproduced the ISO crash, then dumped the romlog again, and it's unchanged.
I should point out that the camera doesn't shut down immediately when you half-press the shutter after overriding ISO. It stops responding to input then, but the live view continues to update for at least several seconds. It might go indefinitely; I wouldn't know, I usually turn it off or eject the battery. The most recent time, it shut down when I moved the zoom lever several seconds after the half-press.
I noticed another mistake in your stubs_min.S files which could be causing this.
The 'focus_busy' value should be 0x00006b68.
Also 'zoom_busy' should be 0x00006cf4.
Phil.
-
I am having trouble viewing the firmware for the Canon ELPH 300 HS.
I created a ver.req txt doc on my Mac, put it on my SD card, put it back in the camera and pressed Funct. Set + Disp, but it won't show me what firmware I have. Can anyone help me out?
-
I noticed another mistake in your stubs_min.S files which could be causing this.
The 'focus_busy' value should be 0x00006b68.
Also 'zoom_busy' should be 0x00006cf4.
Haha, I was just about to post that I found the problem: this loop in shooting_set_sv96():
while ((shooting_is_flash_ready()!=1) || (focus_busy));
Commenting out || (focus_busy) fixed the crash. I was going to search the forum for help on how to find the correct value when I saw your post.
I'll fix the stubs_min.S files, verify the fix, and submit a patch. Thank you!
-
BTW, the if I select ISO 400, the camera displays ISO 640. Selecting ISO 800 results in the camera displaying ISO 1250. This seems like it's by design (http://chdk.kernreaktor.org/mantis/bug_view_advanced_page.php?bug_id=230).
-
I am having trouble viewing the firmware for the Canon ELPH 300 HS.
I created a ver.req txt doc on my Mac, put it on my SD card, put it back in the camera and pressed Funct. Set + Disp, but it won't show me what firmware I have. Can anyone help me out?
ver.req (or vers.req) never worked for me either. I was able to retrieve my camera's firmware version by looking at the Exif data in an image it stored. I used CameraVersion (http://chdk.wikia.com/wiki/CameraVersion) to analyze the JPEG, but since you've got a Mac you could try ACID (http://www.zenoshrdlu.com/acid/acid.html).
-
I am having trouble viewing the firmware for the Canon ELPH 300 HS.
I created a ver.req txt doc on my Mac, put it on my SD card, put it back in the camera and pressed Funct. Set + Disp, but it won't show me what firmware I have. Can anyone help me out?
ver.req (or vers.req) never worked for me either. I was able to retrieve my camera's firmware version by looking at the Exif data in an image it stored. I used CameraVersion (http://chdk.wikia.com/wiki/CameraVersion) to analyze the JPEG, but since you've got a Mac you could try ACID (http://www.zenoshrdlu.com/acid/acid.html).
Thanks! I was able to find out my firmware. It's 101c, so I uploaded CHDK onto the SD card, but when I go onto my camera by playback mode to update the firmware it doesn't show an option for it. Did that happen with you?
-
Thanks! I was able to find out my firmware. It's 101c, so I uploaded CHDK onto the SD card, but when I go onto my camera by playback mode to update the firmware it doesn't show an option for it. Did that happen with you?
You should switch on your camera by pressing the playback button, not switch it on and THEN go to playback mode (ie, the lens should be retracted).
-
Thanks! I was able to find out my firmware. It's 101c, so I uploaded CHDK onto the SD card, but when I go onto my camera by playback mode to update the firmware it doesn't show an option for it. Did that happen with you?
You should switch on your camera by pressing the playback button, not switch it on and THEN go to playback mode (ie, the lens should be retracted).
Yeah I pressed playback but the firmware didn't show up. I used ACID and also tried to download CHDK through that but it said there was no CHDK for the Canon ELPH 300 hs 101c
-
Thanks! I was able to find out my firmware. It's 101c, so I uploaded CHDK onto the SD card, but when I go onto my camera by playback mode to update the firmware it doesn't show an option for it. Did that happen with you?
You should switch on your camera by pressing the playback button, not switch it on and THEN go to playback mode (ie, the lens should be retracted).
Yeah I pressed playback but the firmware didn't show up. I used ACID and also tried to download CHDK through that but it said there was no CHDK for the Canon ELPH 300 hs 101c
If you are using a Mac you may need to read this - http://chdk.wikia.com/wiki/FAQ/Mac#Still_Having_Trouble.3F (http://chdk.wikia.com/wiki/FAQ/Mac#Still_Having_Trouble.3F)
Phil.
-
Thanks! I was able to find out my firmware. It's 101c, so I uploaded CHDK onto the SD card, but when I go onto my camera by playback mode to update the firmware it doesn't show an option for it. Did that happen with you?
You should switch on your camera by pressing the playback button, not switch it on and THEN go to playback mode (ie, the lens should be retracted).
Yeah I pressed playback but the firmware didn't show up. I used ACID and also tried to download CHDK through that but it said there was no CHDK for the Canon ELPH 300 hs 101c
If you are using a Mac you may need to read this - http://chdk.wikia.com/wiki/FAQ/Mac#Still_Having_Trouble.3F (http://chdk.wikia.com/wiki/FAQ/Mac#Still_Having_Trouble.3F)
Phil.
Nice! Thanks! I used Stuffit Expander to open it this time and it works! Do you know of any CDHK website tips/tutorials?
-
Nice! Thanks! I used Stuffit Expander to open it this time and it works! Do you know of any CDHK website tips/tutorials?
Maybe one or two :
link> CHDK in Brief (http://chdk.wikia.com/wiki/CHDK_in_Brief)
link> CHDK User Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual)
link> CHDK for Dummies (http://chdk.wikia.com/wiki/CHDK_for_Dummies)
link> CHDK UserGuide April 2009 (http://chdk.wikia.com/wiki/File:CHDK_UserGuide_April_2009_A4.pdf)
-
So I have CHDK installed on my camera, but when I press menu the CHDK menu doesn't come up. I can tell CHDK is installed cause I see the batter percentage and the CHDK display. Are the buttons just different on the 300 hs?
-
So I have CHDK installed on my camera, but when I press menu the CHDK menu doesn't come up. I can tell CHDK is installed cause I see the batter percentage and the CHDK display. Are the buttons just different on the 300 hs?
http://chdk.setepontos.com/index.php?topic=6341.msg76901#msg76901 (http://chdk.setepontos.com/index.php?topic=6341.msg76901#msg76901)
-
So I have CHDK installed on my camera, but when I press menu the CHDK menu doesn't come up. I can tell CHDK is installed cause I see the batter percentage and the CHDK display. Are the buttons just different on the 300 hs?
http://chdk.setepontos.com/index.php?topic=6341.msg76901#msg76901 (http://chdk.setepontos.com/index.php?topic=6341.msg76901#msg76901)
Nice thanks so much! It works!!
-
I noticed another mistake in your stubs_min.S files which could be causing this.
The 'focus_busy' value should be 0x00006b68.
Also 'zoom_busy' should be 0x00006cf4.
...
I'll fix the stubs_min.S files, verify the fix, and submit a patch. Thank you!
Works as well on my camera with 1.00c firmware. Thanks for the fix, jstanley! :)
BTW, the if I select ISO 400, the camera displays ISO 640. Selecting ISO 800 results in the camera displaying ISO 1250. This seems like it's by design (http://chdk.kernreaktor.org/mantis/bug_view_advanced_page.php?bug_id=230).
The same here, ExifData of shooten image with ISO-override=400 (camera shows ISO 640) in IrfanView:
Auto ISO 400
Base ISO 100
Properties of image in Windows-Explorer show ISO=640.
ExifData of shooten image with ISO-override=200 (camera shows ISO 320) in IrfanView:
Auto ISO 200
Base ISO 100
Properties of image in Windows-Explorer show ISO=320.
Think we have to live with this minor issue until http://chdk.kernreaktor.org/mantis/bug_view_advanced_page.php?bug_id=230 (http://chdk.kernreaktor.org/mantis/bug_view_advanced_page.php?bug_id=230) is solved.
-
Commenting out || (focus_busy) fixed the crash. I was going to search the forum for help on how to find the correct value when I saw your post.
I'll fix the stubs_min.S files, verify the fix, and submit a patch. Thank you!
I can confirm this works on 1.01a. The HDR script also works now.
Thanks :D
Any ISO setting below 59 (Canon ISO 100) causes the Canon OSD to show "ISO AUTO" when the shutter is half pressed, instead of the value. The lower ISO value is written into the EXIF but I imagine it's fake.
Also, any value set between 60 and 73 results in Canon ISO 100. Similarly, any value between 74 and 93 results in Canon ISO 125.
I imagine there is no difference between, say, 65 and 70?
-
FYI: I cleaned up stubs_entry2.S files and of course this results in new generated versions of stubs_entry.S files.
Patch available here: http://chdk.setepontos.com/index.php?topic=650.msg77237#msg77237 (http://chdk.setepontos.com/index.php?topic=650.msg77237#msg77237)
Update:
This patch means no change of functionality, it only increases readability of source code. ;)
-
So I've been working on manual focus. If I put this in platform_camera.h:
#define CAM_CAN_SD_OVER_NOT_IN_MF 1
Then the subject distance override seems to work. Kind of. The camera still performs autofocus, but afterward, the focus distance changes to what you selected.
There's a problem, though. The camera occasionally crashes when changing the manual focus distance:
ASSERT!! FocusLensController.c Line 708
So apparently CAM_CAN_SD_OVER_NOT_IN_MF is not safe on this camera.
But there may be another solution: AFL mode (Auto-Focus Lock). If you press Left while half-pressing the shutter, the camera locks focus at the AF point. It seems safe to move the focus point with CHDK while in this mode--I played with it for several minutes, racking focus in and out, with no trouble (in AF mode, it crashed after a few seconds every time).
So perhaps I could update shooting_can_focus() in core/shooting.c to check AFL on cameras that don't have manual focus mode?
(BTW, there's another issue with this camera, namely the fact that DISP and DOWN are the same button, so the shortcut assignments for Infinity and Hyperfocal clash. The games lose functionality too, not that this concerns me much, since I intend to build them out on my camera anyway.)
-
FYI: Removed unnecessary functions/variable for JogDial from lib.c and kbd.c.
Patch is available here: http://chdk.setepontos.com/index.php?topic=650.msg77256#msg77256 (http://chdk.setepontos.com/index.php?topic=650.msg77256#msg77256)
-
...
The line:
*(int*)(0x2638) = (*(int*)0xC0220130)&1 ? 0x200000 : 0x100000;
should be
*(int*)(0x25F4) = (*(int*)0xC0220130)&1 ? 0x200000 : 0x100000;
...
Phil, some days ago you saved my life with above advice. :D
I couldn't figure out from where you know the correct value. How can I find this in firmware?
The reason why I'm asking, I'm trying to support the ELPH310 porting thread (http://chdk.setepontos.com/index.php?topic=7149.msg77262#msg77262 (http://chdk.setepontos.com/index.php?topic=7149.msg77262#msg77262)). It seems that we need to know the above value for ELPH310. But I don't know where/how I can find the correct value in ELPH310 firmware. We will now try to use the value from ELPH500 in our next try.
Could you please point us to the right location or explain how you found out the correct value?
Thanks in advance. :)
Update:
Uups, I think I found it already:
void __attribute__((naked,noinline)) sub_FF864E00_my( ) {
asm volatile (
" LDR R3, =0x25F4 \n"
" CMP R2, #0 \n"
" MOV R12, #0 \n"
" MOVNE R2, #0x400000 \n"
" STR R12, [R3] \n"
" STRNE R2, [R3] \n"
" CMP R0, #0 \n"
" LDRNE R0, [R3] \n"
" ORRNE R0, R0, #0x100000 \n"
" STRNE R0, [R3] \n"
" CMP R1, #0 \n"
" LDRNE R0, [R3] \n"
" ORRNE R0, R0, #0x200000 \n"
" STRNE R0, [R3] \n"
" BX LR \n"
)
}
-
Found another crash bug. The universal Tv script blows up when you half-press the shutter.
This is on firmware 1.01a, build 1446 from autobuild.
-
how do i get the firmware version of my ixus 220hs? recommended to update to the 1.01e?
-
how do i get the firmware version of my ixus 220hs? recommended to update to the 1.01e?
link> Determining the firmware version in your camera. (http://chdk.wikia.com/wiki/FAQ#Q._How_can_I_get_the_original_firmware_version_number_of_my_camera.3F)
-
In the trunk build for this camera, subject distance override doesn't do anything (as has been mentioned before). The CHDK documentation indicates you have to be in manual focus mode in order for this to work... but the IXUS 220 doesn't _have_ manual focus mode; that's one of the reasons I want CHDK. :D
So I played with forcing it via CAM_CAN_SD_OVER_NOT_IN_MF, and it mostly worked, but the camera crashed occasionally (presumably when its own continuous autofocus clashed with CHDK's override).
As I surmised earlier,
So perhaps I could update shooting_can_focus() in core/shooting.c to check AFL on cameras that don't have manual focus mode?
That's what I did in the attached builds. And it seems to work. Subject distance override still does nothing when not in AF lock mode... but when you are in AF lock mode (half-press + left arrow), it works, and I haven't seen it crash.
(The easiest way to see it work is:
- Enable AF lock (half-press + left)
- Enter ALT mode
- Press UP for manual focus toggle
- Press DOWN for infinity focus
- Now use the zoom lever to go out and back in; it's most noticeable when you go wrap around from 0 (closest) to 65536 (infinity)
Note that the property indicating AF lock (11) was not in propset4.h, so I added it. I found that number in http://chdk.wikia.com/wiki/PropertyCase (http://chdk.wikia.com/wiki/PropertyCase) under property set 2, but confirmed that this is correct on the IXUS 220. So perhaps it should go in propset2.h and propset3.h as well.
I've attached a patch, but it's probably not ready for the trunk; it needs review from CHDK gurus, especially since it is not an ELPH 300/IXUS 220-specific change.
I've also attached builds--if you're interested in manual focus, please give it a try.
-
manual focus-enabled builds for 1.01a and 1.01c (1.01d/1.01e can use the 1.01c build)
-
Found another crash bug. The universal Tv script blows up when you half-press the shutter.
This is on firmware 1.01a, build 1446 from autobuild.
Unless I'm mistaken, this assert in capt_seq.c is what tripped:
"loc_FF8CBE7C: \n"
" LDR R0, =0xFF8C75F4 \n" //"ExpDrv.c"
" BL _DebugAssert \n"
" B loc_FF8CBDAC \n"
Guessing this because 0xFF8C75F4 is near the top of the stack trace in the ROM log.
Time to brush up on my ARM assembly and see if I can figure out what causes us to go there.
-
Hi Tommi,
While on the subject of kbd handling (your post #430)
ixus220_elph300hs (100c, all revisions tested so far) still exhibit non-standard
key response while booting:
Playback button: short press => REC mode, long press => REVIEW mode
On/Off button: short press => REC mode, long press => REC mode
while AFAIK 'Standard' CHDK behaviour for DRYOS camera with Playback button is:
Playback button: short press => REVIEW mode, long press => REVIEW mode
On/Off button: short press => REVIEW mode, long press => REC mode
Normally, it would be possible to simply switch between these 2 'modes' (see here (http://chdk.setepontos.com/index.php?topic=3994.msg42107#msg42107))
by changing (in /platform/ixus220_elph300hs/sub/{firmware}/boot.c)
*(int*)(0x25F4) = (*(int*)0xC0220130)&1 ? 0x200000 : 0x100000;
to
*(int*)(0x25F4) = (*(int*)0xC0220130)&1 ? 0x100000 : 0x200000;
I tried this, and it works, except that now all of the above key presses take us to REVIEW mode,
in other words, the only way to go to REC is pressing half-shutter after booting to REVIEW.
I suppose this means something in kbd.c (keymasks and/or keymap ?) needs tweaking ?
wim
-
In the trunk build for this camera, subject distance override doesn't do anything (as has been mentioned before). The CHDK documentation indicates you have to be in manual focus mode in order for this to work... but the IXUS 220 doesn't _have_ manual focus mode; that's one of the reasons I want CHDK. :D
So I played with forcing it via CAM_CAN_SD_OVER_NOT_IN_MF, and it mostly worked, but the camera crashed occasionally (presumably when its own continuous autofocus clashed with CHDK's override).
As I surmised earlier,
So perhaps I could update shooting_can_focus() in core/shooting.c to check AFL on cameras that don't have manual focus mode?
That's what I did in the attached builds. And it seems to work. Subject distance override still does nothing when not in AF lock mode... but when you are in AF lock mode (half-press + left arrow), it works, and I haven't seen it crash.
(The easiest way to see it work is:
- Enable AF lock (half-press + left)
- Enter ALT mode
- Press UP for manual focus toggle
- Press DOWN for infinity focus
- Now use the zoom lever to go out and back in; it's most noticeable when you go wrap around from 0 (closest) to 65536 (infinity)
Note that the property indicating AF lock (11) was not in propset4.h, so I added it. I found that number in http://chdk.wikia.com/wiki/PropertyCase (http://chdk.wikia.com/wiki/PropertyCase) under property set 2, but confirmed that this is correct on the IXUS 220. So perhaps it should go in propset2.h and propset3.h as well.
I've attached a patch, but it's probably not ready for the trunk; it needs review from CHDK gurus, especially since it is not an ELPH 300/IXUS 220-specific change.
I've also attached builds--if you're interested in manual focus, please give it a try.
The propcase value looks ok (matches on the G12).
The code should probably be enabled with a new camera.h/platform_camera.h define to avoid unexpected surprises on existing cameras that have AFL (the G12 has both AFL and MF). This new #define should default to #undef in camera.h
Phil.
-
Found another crash bug. The universal Tv script blows up when you half-press the shutter.
This is on firmware 1.01a, build 1446 from autobuild.
Unless I'm mistaken, this assert in capt_seq.c is what tripped:
"loc_FF8CBE7C: \n"
" LDR R0, =0xFF8C75F4 \n" //"ExpDrv.c"
" BL _DebugAssert \n"
" B loc_FF8CBDAC \n"
Guessing this because 0xFF8C75F4 is near the top of the stack trace in the ROM log.
Time to brush up on my ARM assembly and see if I can figure out what causes us to go there.
At the top of the log is the module name "ExpDrv.c" and the line number of the assert.
The module name is loaded into R0 and the line number into R1 before DebugAssert is called.
There may be multiple asserts in a given module - the line number will help you find which one was called.
Phil.
-
At the top of the log is the module name "ExpDrv.c" and the line number of the assert.
The module name is loaded into R0 and the line number into R1 before DebugAssert is called.
There may be multiple asserts in a given module - the line number will help you find which one was called.
Thanks for the tip. There are dozens of asserts in ExpDrv.c. The one above is not the right one. It's this one (line 5569 = 0x15c1):
"loc_FF8CB830:\n"
" CMP R6, #1 \n"
" STRH R0, [R4, #0xC] \n"
" BNE sub_FF8CB85C \n"
" LDR R2, =0xBB8 \n"
" LDR R0, [R9, #0x1C] \n"
" MOV R1, #2 \n"
" BL sub_FF88DB18 \n" // we called some sub
" TST R0, #1 \n" // expected it to return 1
" LDRNE R1, =0x15C1 \n" // if it didn't, we're loading up some parameters... line number
" LDRNE R0, =0xFF8C75F4 \n" // ExpDrv.c
" BLNE sub_FF81EC88 \n" // <-- and call DebugAssert here
"loc_FF8CB85C:\n" // (normal flow presumably continues here)
Unfortunately, my ARM is too weak and my symbols too sparse for me to have much of an idea what FF88DB18 does, or why it might return something other than 1 (I'm not even sure where its return statement(s) are).
-
At the top of the log is the module name "ExpDrv.c" and the line number of the assert.
The module name is loaded into R0 and the line number into R1 before DebugAssert is called.
There may be multiple asserts in a given module - the line number will help you find which one was called.
Thanks for the tip. There are dozens of asserts in ExpDrv.c. The one above is not the right one. It's this one (line 5569 = 0x15c1):
"loc_FF8CB830:\n"
" CMP R6, #1 \n"
" STRH R0, [R4, #0xC] \n"
" BNE sub_FF8CB85C \n"
" LDR R2, =0xBB8 \n"
" LDR R0, [R9, #0x1C] \n"
" MOV R1, #2 \n"
" BL sub_FF88DB18 \n" // we called some sub
" TST R0, #1 \n" // expected it to return 1
" LDRNE R1, =0x15C1 \n" // if it didn't, we're loading up some parameters... line number
" LDRNE R0, =0xFF8C75F4 \n" // ExpDrv.c
" BLNE sub_FF81EC88 \n" // <-- and call DebugAssert here
"loc_FF8CB85C:\n" // (normal flow presumably continues here)
Unfortunately, my ARM is too weak and my symbols too sparse for me to have much of an idea what FF88DB18 does, or why it might return something other than 1 (I'm not even sure where its return statement(s) are).
Noticed you mentioned using a script to get the crash - missed that before.
Can you provide a link to the script - if it's an old one there might be something incompatible in it.
I can test it on my cameras to make sure we're not chasing the wrong thing.
Phil.
-
I've also attached builds--if you're interested in manual focus, please give it a try.
I tested your build on 100c firmware and I was able to change focus manual. :)
-
I tried this, and it works, except that now all of the above key presses take us to REVIEW mode,
in other words, the only way to go to REC is pressing half-shutter after booting to REVIEW.
I suppose this means something in kbd.c (keymasks and/or keymap ?) needs tweaking ?
wim
Hi Wim,
I tried this and it works like you described, entering Record-Mode only possible by pressing Shutter_Half after Camera has been started in Review-Mode. Can you please point me to a camera model where it is already working fine? I want to compare its kbd.c to mine to get a quick overview what probably needs to be changed. I already looked into kdb.c of SD940, SD980 and SX220 but still don't have an idea how it is handled there.
-
Noticed you mentioned using a script to get the crash - missed that before.
Can you provide a link to the script - if it's an old one there might be something incompatible in it.
I can test it on my cameras to make sure we're not chasing the wrong thing.
Phil.
Using script CHDK/SCRIPTS/EXAM/tv_uni_e.lua from current trunk revision 1454 leads to crash for me as well.
For me it doesn't crash when pressing HalfShutter.
I started script and pressed <UP> to use Zoom function of script. After pressing <UP> one or more times camera freezes and shutsdown (with lens staying outside) after showing LiveView for some more seconds.
Please try to reproduce on other camera than elph300.
-
manual focus-enabled builds for 1.01a and 1.01c (1.01d/1.01e can use the 1.01c build)
Works for me, too (on 1.01a)!
Haven't run in to any issues so far :)
-
Noticed you mentioned using a script to get the crash - missed that before.
Can you provide a link to the script - if it's an old one there might be something incompatible in it.
I can test it on my cameras to make sure we're not chasing the wrong thing.
It's a script that's bundled with CHDK, EXAM\tv_uni_e.lua.
I mentioned earlier that the camera stopped responding on half-press, but in further testing I believe the camera may have already been hung before I got that far. If I don't use the up/down arrows to zoom in the script, then it doesn't crash.
I suspect the set_zoom call is what's at fault. Specifically, lens_set_zoom_point() in platform/generic/wrappers.c. Even if you're sure you gave me the correct zoom_busy address a few days ago ;), there are still a couple of camera-specific hacks in there trying to avoid a hang. The SX30, SX130, G10, and G12 do this:
// have to sleep here, zoom_busy set in another task, without sleep this will hang
while (zoom_busy) msleep(10);
And other cameras do this:
#if defined (CAMERA_s95)
// this will hang sometimes on s95 when zoom_busy gets stuck as a 1
// we add a timeout as a work-around for this problem
startTime = get_tick_count();
while (get_tick_count() < (startTime + 2000)) {
if (!zoom_busy)
break;
}
#else // !CAMERA_s95
while (zoom_busy);
#endif // !CAMERA_s95
I changed the while loop to look like the SX30 etc. one:
while (zoom_busy) msleep(10);
... which fixed the problem for the IXUS 220 (allowing me to zoom all the way out in the lua script with no hang), and I suspect might fix the S95 too, although I can't test that.
Would the following loop be generally safe?
startTime = get_tick_count();
while (get_tick_count() < (startTime + 2000)) {
if (!zoom_busy)
break;
msleep(10);
}
The minimally intrusive change I could make to fix the IXUS220 would be this:
#if defined (CAMERA_s95)
// this will hang sometimes on s95 when zoom_busy gets stuck as a 1
// we add a timeout as a work-around for this problem
startTime = get_tick_count();
while (get_tick_count() < (startTime + 2000)) {
if (!zoom_busy)
break;
}
#elif defined(CAMERA_ixus220_elph300hs)
while (zoom_busy) msleep(10);
#else // !CAMERA_s95
while (zoom_busy);
#endif // !CAMERA_s95
... but while that won't change behavior for anyone else, it only adds to the mess.
-
zoom problems in scripts were discussed at some length here :
http://chdk.setepontos.com/index.php?topic=7071 (http://chdk.setepontos.com/index.php?topic=7071)
Recently, philmoz has (I believe) decided its safe to remove all that G12, G10,SX30 etc customization from core/kbc.d if you simply add the following to your platform_camera.h file :
#undef CAM_CAN_SD_OVER_NOT_IN_MF
This does not fix the problems mentioned in the above thread for the SD780/SD940/SD980 but it might help you ?
-
Recently, philmoz has (I believe) decided its safe to remove all that G12, G10,SX30 etc customization from core/kbc.d if you simply add the following to your platform_camera.h file :
#undef CAM_CAN_SD_OVER_NOT_IN_MF
This does not fix the problems mentioned in the above thread for the SD780/SD940/SD980 but it might help you ?
That's already in our platform_camera.h.
If all the G12 etc. lens_set_zoom customizations can be eliminated by putting that in their platform_camera.h files, though, that sounds good for the code base as a whole, although by itself it does not fix the IXUS220. (I personally think CAM_CAN_SD_OVER_NOT_IN_MF should be off by default in camera.h.)
-
Noticed you mentioned using a script to get the crash - missed that before.
Can you provide a link to the script - if it's an old one there might be something incompatible in it.
I can test it on my cameras to make sure we're not chasing the wrong thing.
Phil.
Using script CHDK/SCRIPTS/EXAM/tv_uni_e.lua from current trunk revision 1454 leads to crash for me as well.
For me it doesn't crash when pressing HalfShutter.
I started script and pressed <UP> to use Zoom function of script. After pressing <UP> one or more times camera freezes and shutsdown (with lens staying outside) after showing LiveView for some more seconds.
Please try to reproduce on other camera than elph300.
That is an old script that has hardwired property values that are now wrong for propset 4.
I'd ignore it until someone gets around to rewriting it.
Phil.
-
I changed the while loop to look like the SX30 etc. one:
while (zoom_busy) msleep(10);
... which fixed the problem for the IXUS 220 (allowing me to zoom all the way out in the lua script with no hang), and I suspect might fix the S95 too, although I can't test that.
This fix has been confirmed to work for the S95 as well; but I haven't got around to fixing the code.
Adding the msleep(10) to the default case loop should also be done in my opinion (infinite loops are not a good practice in my opinion).
Phil.
-
Haha, I found another awesome zoom bug. _MoveZoomLensWithPoint does not notify the JPEG engine of the new focal length, causing incorrect distortion fixes to be applied. For example, if you zoom the lens manually to the longest setting, and take a shot, you'll end up with something like this:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FAj6Qi.jpg&hash=0589f448f5faba0ca5fbe4d00dd17c8c)
But if you start at the wide end, zoom out using this lua script:
set_zoom(get_zoom_steps())
And then take a shot, you see this:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F0ZVOm.jpg&hash=be6401565019d801daf95dcc164a2b2c)
The JPEG engine thinks it needs to fix the barrel distortion that occurs at the wide end of the range, even though we're not actually at the wide end of the range.
The fix is to use _PT_MoveOpticalZoomAt() instead, like the SX30 / SX130 do.
I have a patch submitted on the other thread. Just thought this was an interesting bug. :)
-
I've got the current Alpha version (ixus220_elph300hs-101d-0.9.9-1455) running.
Really simple question:
Does the current version support focus lock (or autofocus disable) in VIDEO MODE?
If so, how do I do it?
+ a HUGE thank you to everyone who's working on this. CHDK is the main reason I keep buying Canon point and shoots.
-
I've got the current Alpha version (ixus220_elph300hs-101d-0.9.9-1455) running.
Really simple question:
Does the current version support focus lock (or autofocus disable) in VIDEO MODE?
If so, how do I do it?
The manual focus in AF lock went in 1457, so that build doesn't have it. You can use my test build (http://chdk.setepontos.com/index.php?topic=6341.msg77282#msg77282) for now (the 1.01c version is compatible with firmware 1.01d).
It works the same way whether recording stills or video: Half-press the shutter and press Left to engage AF lock, and then CHDK's subject distance override functionality is functional. In a nutshell, enter alt mode (tap the video button), press Up, then use the zoom lever to control focus (Left and Right adjust the sensitivity). Press Up again to exit. Focus will remain at the selected point as long as AFL mode is engaged. You can record stills or video.
If you want to refocus while recording video - there are scripts (http://chdk.wikia.com/wiki/UBASIC/Scripts:_Easy_Zoom_%26_MF_while_Video_Recording) that do that on other cameras, and *might* work for this one - I haven't tried.
-
Do you know if exist a DNG profile lens for ixus 220 hs? Thanks a lot.
-
So I've been looking into the overdraw issues--specifically, how the CHDK menu gets clobbered by the focus rectangle and other Canon UI elements.
I tried copying functions from other cameras' implementations of lib.c. Most of those were disastrous--specifically, those that did stuff like this:
_ScreenLock();
_RefreshPhysicalScreen(1);... prevented Canon UI elements from working at all, from the moment you enter Alt mode. Pressing the Menu key, for instance, froze the live view, but did not show the menu. (This code aligns with the wiki page (http://chdk.wikia.com/wiki/Frame_buffers#Forcing_Firmware_Redraw_And_Locking) that says _RefreshPhysicalScreen and _ScreenUnlock are the same function; on this camera, they do not appear to be.)
The wiki page also indicates that we may need to implement vid_turn_on_updates() and vid_turn_off_updates() to prevent this from happening. (Why don't all ports implement these? ???)
Just adding these implementations:
void vid_turn_off_updates()
{
_ScreenLock();
}
void vid_turn_on_updates()
{
_ScreenUnlock();
}
... prevents the overdraw problem, but the screen fails to refresh after exiting the CHDK menu. That is, the menu is still visible after it's dismissed.
So I tried replacing vid_refresh_bitmap() with the following (keeping it simple):
void vid_bitmap_refresh()
{
_RefreshPhysicalScreen(1);
}
And that seems to do the trick. However, the camera feels less responsive. The menu feels a little sluggish... maybe I'm imagining that? I know I'm not imagining the fact that Canon's UI totally freezes not just when the CHDK menu is up, but during all of Alt mode ... that in itself feels a little suboptimal.
I've never used CHDK on another model camera, so I really don't have an idea how smooth it should be.
In any case, I've attached some builds so others can try this out and provide feedback.
-
So I've been looking into the overdraw issues--specifically, how the CHDK menu gets clobbered by the focus rectangle and other Canon UI elements.
This is normal; but annoying - CHDK isn't integrated into the Canon display system.
CHDK attempts to detect if the screen gets completely erased and will redraw the menu; but parts if it can still get erased.
The wiki page also indicates that we may need to implement vid_turn_on_updates() and vid_turn_off_updates() to prevent this from happening. (Why don't all ports implement these? ???)
Thanks for pointing this out - I hadn't come across this before.
A quick check shows that these are only implemented for two cameras - IXUS 120 and IXUS 870.
At least one other camera has commented out these functions with the comment they make things worse.
When I get some time I'll play around with these on my cameras.
Phil.
-
In any case, I've attached some builds so others can try this out and provide feedback.
The build on my camera just got into a state where it failed to refresh the screen after closing the CHDK menu.
So, although vid_turn_off_updates() -> ScreenLock() is promising, there are still some kinks to work out.
It'd be nice if we could hook in somewhere and get the opportunity to draw our stuff on the back buffer right before the firmware swaps buffers, but I have no idea whether that is feasible (or whether the original firmware actually operates that way, for that matter). Failing that, at least doing ScreenLock while the menu is up would prevent the worst of the visual issues, provided we can make it work reliably. (It strikes me as odd that pretty much no two models handle screen updates the same way. This isn't something I think Canon would do differently with every iteration???)
-
A quick check shows that these are only implemented for two cameras - IXUS 120 and IXUS 870.
I think I can safely say that that IXUS120 code is just random guesses put in there when the original port was in a sorry mess and vid_bitmap_refresh() was not working at all.
-
Do you know if there's a ixus 220 hs DNG profile, to correct RAW distortion and vignetting in camera? Thanks a lot.
-
Do you know if there's a ixus 220 hs DNG profile, to correct RAW distortion and vignetting in camera? Thanks a lot.
No, you have to create one on your own.
Maybe this makes it easy for you to create a profile: http://labs.adobe.com/technologies/lensprofile_creator/ (http://labs.adobe.com/technologies/lensprofile_creator/)
-
Ixus 220 has a 24 - 120mm zoom lens...which focal lenghts should I make, to use settings correctly for all camera zoom?
-
In any case, I've attached some builds so others can try this out and provide feedback.
The build on my camera just got into a state where it failed to refresh the screen after closing the CHDK menu.
So, although vid_turn_off_updates() -> ScreenLock() is promising, there are still some kinks to work out.
It'd be nice if we could hook in somewhere and get the opportunity to draw our stuff on the back buffer right before the firmware swaps buffers, but I have no idea whether that is feasible (or whether the original firmware actually operates that way, for that matter). Failing that, at least doing ScreenLock while the menu is up would prevent the worst of the visual issues, provided we can make it work reliably. (It strikes me as odd that pretty much no two models handle screen updates the same way. This isn't something I think Canon would do differently with every iteration???)
I tried it on the G12 and although it does make the CHDK display a lot more stable it also causes major problems.
For example if a script uses the 'shoot' command the camera tries to switch to review mode after the picture is taken. The screen goes black and the review is not shown (because of the lock presumably). The screen stays black and nothing is displayed again until the script exits.
Phil.
-
I tried it on the G12 and although it does make the CHDK display a lot more stable it also causes major problems.
For example if a script uses the 'shoot' command the camera tries to switch to review mode after the picture is taken. The screen goes black and the review is not shown (because of the lock presumably). The screen stays black and nothing is displayed again until the script exits.
Hmm. I was afraid there'd be trouble if we lock the screen. Thanks for trying it out, though. I think I'll just learn to accept the flicker. (Staying out of Auto mode helps a lot...)
So, remaining work to be done for this port?
- One pending patch (http://chdk.setepontos.com/index.php?topic=650.msg77407#msg77407) for a remaining scripted zoom issue (http://chdk.setepontos.com/index.php?topic=6341.msg77405#msg77405)
- The fact that DISP and DOWN are the same key: some CHDK functionality depends on a DISP button, and we don't have an independent one. I'm thinking we could click the button for DOWN and long-press it for DISP?
- .DNG metadata is still a bit messed up. in particular, the camera model name doesn't appear to be terminated properly.
Any other known issues to work on?
Wondering what the criteria are to progress to BETA.
-
- .DNG metadata is still a bit messed up. in particular, the camera model name doesn't appear to be terminated properly.
This isn't specific to our port; it's part of core/dng.c. I've compared the camera name tag in Canon's JPEGs and CHDK's DNGs. Both write the same 32-byte buffer, "Canon Powershot ELPH 300HS\x00\xff\xff\xff\xff\xff". But there's a difference--the JPEG gives the size of the item as 27 bytes (not including the FF padding), whereas CHDK's DNG gives the size as 32 bytes (including the padding).
-
- .DNG metadata is still a bit messed up. in particular, the camera model name doesn't appear to be terminated properly.
This isn't specific to our port; it's part of core/dng.c. I've compared the camera name tag in Canon's JPEGs and CHDK's DNGs. Both write the same 32-byte buffer, "Canon Powershot ELPH 300HS\x00\xff\xff\xff\xff\xff". But there's a difference--the JPEG gives the size of the item as 27 bytes (not including the FF padding), whereas CHDK's DNG gives the size as 32 bytes (including the padding).
If the DNG code is writing 32 bytes to the file then the size of 32 is correct.
The 0 terminator on the string should make sure that any program processing the DNG ignores the padding bytes.
What program is having trouble with the field?
Phil.
-
If the DNG code is writing 32 bytes to the file then the size of 32 is correct.
The 0 terminator on the string should make sure that any program processing the DNG ignores the padding bytes.
Not according to the TIFF specification (http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf):
2 = ASCII 8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary 0).
...
The value of the Count part of an ASCII field entry includes the NUL. If padding is necessary, the Count does not include the pad byte. ...
Each tag has its own offset field, so it's not necessary to know the true size of a tag on disk in order to find the next tag.
What program is having trouble with the field?
Picasa 3.5. I also remember reading about this problem somewhere else, but I've been unable to find where...
-
If the DNG code is writing 32 bytes to the file then the size of 32 is correct.
The 0 terminator on the string should make sure that any program processing the DNG ignores the padding bytes.
Not according to the TIFF specification (http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf):
2 = ASCII 8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary 0).
...
The value of the Count part of an ASCII field entry includes the NUL. If padding is necessary, the Count does not include the pad byte. ...
Each tag has its own offset field, so it's not necessary to know the true size of a tag on disk in order to find the next tag.
What program is having trouble with the field?
Picasa 3.5. I also remember reading about this problem somewhere else, but I've been unable to find where...
Thanks, I wasn't aware of that. It's been broken for a long time then.
Shouldn't be hard to fix. Will take a look tonight.
Phil.
-
If the DNG code is writing 32 bytes to the file then the size of 32 is correct.
The 0 terminator on the string should make sure that any program processing the DNG ignores the padding bytes.
Not according to the TIFF specification (http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf):
2 = ASCII 8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary 0).
...
The value of the Count part of an ASCII field entry includes the NUL. If padding is necessary, the Count does not include the pad byte. ...
Each tag has its own offset field, so it's not necessary to know the true size of a tag on disk in order to find the next tag.
What program is having trouble with the field?
Picasa 3.5. I also remember reading about this problem somewhere else, but I've been unable to find where...
Try this change to create_dng_header in dng.c (the 2nd and 3rd lines are new):
switch (IFD_LIST[j].entry[i].tag) {
case 0x110 : // CameraName
case 0xC614: IFD_LIST[j].entry[i].count = strlen((char*)IFD_LIST[j].entry[i].offset) + 1; break; // UniqueCameraModel
case 0x132 :
case 0x9003: IFD_LIST[j].entry[i].offset=(int)get_date_for_exif(exif_data->time); break; //DateTimeOriginal
This doesn't cause any problems for me; but I've never seen the problem happen.
If this works for you I'll update SVN.
Phil.
-
Great work guys. I have it working on my camera.
Anyone know any time lapse scripts that work?
could you recommend one please.
Thanks.
-
Try this change to create_dng_header in dng.c (the 2nd and 3rd lines are new):
switch (IFD_LIST[j].entry[i].tag) {
case 0x110 : // CameraName
case 0xC614: IFD_LIST[j].entry[i].count = strlen((char*)IFD_LIST[j].entry[i].offset) + 1; break; // UniqueCameraModel
case 0x132 :
case 0x9003: IFD_LIST[j].entry[i].offset=(int)get_date_for_exif(exif_data->time); break; //DateTimeOriginal
This doesn't cause any problems for me; but I've never seen the problem happen.
If this works for you I'll update SVN.
Phil.
It works. Thanks.
-
Anyone know any time lapse scripts that work?
The are called intervalometers in CHDK. Searching the wiki or forum will turn up many options :
Try > http://chdk.wikia.com/index.php?title=Special%3ASearch&search=intervalometer&go=Go (http://chdk.wikia.com/index.php?title=Special%3ASearch&search=intervalometer&go=Go)
Also, if you want to keep it simple initially, there is a very small script put on your SD card with CHDK. Look for /CHDK/SCRIPTS/4Pack/Lua/interval.lua or /CHDK/SCRIPTS/4Pack/Lua/interval.bas (same script - different language)
-
Anyone know any time lapse scripts that work?
The are called intervalometers in CHDK. Searching the wiki or forum will turn up many options :
Try > http://chdk.wikia.com/index.php?title=Special%3ASearch&search=intervalometer&go=Go (http://chdk.wikia.com/index.php?title=Special%3ASearch&search=intervalometer&go=Go)
Also, if you want to keep it simple initially, there is a very small script put on your SD card with CHDK. Look for /CHDK/SCRIPTS/4Pack/Lua/interval.lua or /CHDK/SCRIPTS/4Pack/Lua/interval.bas (same script - different language)
Thanks waterwingz. I tried the Ultra Intervalometer but couldn't get it to work. Nevertheless I took your suggestion and loaded the interval.lua - it is working so far. Will play with it over the weekend
thanks again.
UPDATE:
My intial attempt of loading the Ultra Intervalometer script failed because of beginner error. Scripts have to be saved in plaint text {mac}. The script work fine for me now.
-
Hi,
I got an error E41 when I connect my Ixus 220HS to my computer while running chdk.
Does anyone know if there is a solution for this problem?
I found the problem is not related to the computer because I got the same result when I turn of the computer. The only thing needed to reprocuce the error is current on the usb powercable.
The error:
A camera error was detected
Will shut down automatically
Restart camera
E41n
It happens only whith a bootabe sd card running chdk, latest version, clean install.
-
I got an error E41 when I connect my Ixus 220HS to my computer while running chdk.
Does anyone know if there is a solution for this problem?
Huh! I've never actually connected my ELPH 300HS to my computer. I've just always used an SD card reader to transfer images...
but I tried it just now, and sure enough, I get the same results on my camera. I've attached the ROM log from the crash. It doesn't look like the other ones I've seen; I'm not sure where to start with this problem.
I don't see the crash if the card isn't bootable, but PTP transfer still doesn't work while CHDK is running.
-
I got an error E41 when I connect my Ixus 220HS to my computer while running chdk.
Does anyone know if there is a solution for this problem?
Huh! I've never actually connected my ELPH 300HS to my computer. I've just always used an SD card reader to transfer images...
but I tried it just now, and sure enough, I get the same results on my camera. I've attached the ROM log from the crash. It doesn't look like the other ones I've seen; I'm not sure where to start with this problem.
HARDWARE DEFECT!! ShutdownReason[9] ErrorNo[41]
Occured Time 2011:12:11 21:02:23
Never seen one of like that before either. Have you tried disabling CAM_CHDK_PTP ?
-
I got an error E41 when I connect my Ixus 220HS to my computer while running chdk.
Does anyone know if there is a solution for this problem?
Huh! I've never actually connected my ELPH 300HS to my computer. I've just always used an SD card reader to transfer images...
but I tried it just now, and sure enough, I get the same results on my camera. I've attached the ROM log from the crash. It doesn't look like the other ones I've seen; I'm not sure where to start with this problem.
I don't see the crash if the card isn't bootable, but PTP transfer still doesn't work while CHDK is running.
I don't know if it's the cause or not; but the value of USB_MASK in kbd.c is wrong - see stubs_entry.S for the correct value.
Phil.
-
I don't know if it's the cause or not; but the value of USB_MASK in kbd.c is wrong - see stubs_entry.S for the correct value.
Didn't have any apparent effect.
Never seen one of like that before either. Have you tried disabling CAM_CHDK_PTP ?
I #undef'd that in platform_camera.h and it seems the camera lasted a little longer after plugging in the USB cable--it retracted the lens and switched to playback mode--but then it failed with the same error message, and the same logged shutdown reason.
Out of time for tonight, but I'll dig into it a little more tomorrow if I get the chance.
-
Good to see I am not the only one whith the E41 error :). I am running firmware version C. The reason I connect my camera with my pc while running chdk is that I want to use the ptpCamGui.
Perhaps someone with another firmware version can try to reproduce the error. It quit easy connect your cam while running chdk on a bootable sd card to your computer.
-
Good to see I am not the only one whith the E41 error :). I am running firmware version C. The reason I connect my camera with my pc while running chdk is that I want to use the ptpCamGui.
Perhaps someone with another firmware version can try to reproduce the error. It quit easy connect your cam while running chdk on a bootable sd card to your computer.
How much free memory is there before plugging in the USB cable?
(Check the Show Memory Info option under the Miscelllaneous Stuff menu)
Phil.
-
quote
How much free memory is there before plugging in the USB cable?
(Check the Show Memory Info option under the Miscelllaneous Stuff menu)
Phil.
quote
Memory info:
Free memory: 414120 bytes
CHDK size: 263204 bytes
loaded at: 0x1774EC
-
Memory info:
Free memory: 414120 bytes
CHDK size: 263204 bytes
loaded at: 0x1774EC
Compiling with OPT_CHDK_IN_EXMEM (trunk 1489), I get this:
Free memory: 686184 bytes
CHDK size: 259840 bytes
loaded at: 0x78e67e0
Same result. Also #undef'd CAM_REMOTE; no difference there either.
-
The text for E41 is USB_PHY_ERROR (USB physical layer error). I would guess something (a status bit?) needs to be masked, but that's only a guess.
Edit.
Nestkast wrote this:
It happens only whith a bootabe sd card running chdk, latest version, clean install.
So it may be related to the SD-card sensing switch.
-
Hi, n00b question here. I've been following this thread for a while now. I have build 100.c. I've installed chdk and have been able to navigate the menus and set some options following the information in the chdk wiki. I still can't figure out how to take shots however. On screen I constantly have the message "insufficient space on card". On the mac it shows my card as having 10.8 gigs free on one partition, and 3.7 on the other.
Is there another button responsible for taking pictures? Or am I doing something more fundamentally wrong?
Sorry for the beginner question in this rather technical thread!
-
Hi, n00b question here. I've been following this thread for a while now. I have build 100.c. I've installed chdk and have been able to navigate the menus and set some options following the information in the chdk wiki. I still can't figure out how to take shots however. On screen I constantly have the message "insufficient space on card". On the mac it shows my card as having 10.8 gigs free on one partition, and 3.7 on the other.
Is there another button responsible for taking pictures? Or am I doing something more fundamentally wrong?
With the 2011 line of cameras, it's no longer necessary to partition the card--they'll boot from FAT32. As such, partition support was not implemented in this port. Have you tried using a single FAT32 partition?
-
Hi, n00b question here. I've been following this thread for a while now. I have build 100.c. I've installed chdk and have been able to navigate the menus and set some options following the information in the chdk wiki. I still can't figure out how to take shots however. On screen I constantly have the message "insufficient space on card". On the mac it shows my card as having 10.8 gigs free on one partition, and 3.7 on the other.
Is there another button responsible for taking pictures? Or am I doing something more fundamentally wrong?
With the 2011 line of cameras, it's no longer necessary to partition the card--they'll boot from FAT32. As such, partition support was not implemented in this port. Have you tried using a single FAT32 partition?
I had the same problem with the "Insufficient space on card" message. But as Jstanley0 pointed out you don't need a partition with this camera [300 hs]. Don't use the SDIMinst program to prepare the card.
I just copied these files to the root of the SD card:-
1. DISKBOOT.BIN
2.PS.FI2
Then I manually booted the camera using the >Display/PLAY, Firmware Update method.
-
Hi, n00b question here. I've been following this thread for a while now. I have build 100.c. I've installed chdk and have been able to navigate the menus and set some options following the information in the chdk wiki. I still can't figure out how to take shots however. On screen I constantly have the message "insufficient space on card". On the mac it shows my card as having 10.8 gigs free on one partition, and 3.7 on the other.
Is there another button responsible for taking pictures? Or am I doing something more fundamentally wrong?
Sorry for the beginner question in this rather technical thread!
As the others have mentioned, it is possible to use one partition on a fat32 formatted card. There are some old "make card bootable" instructions floating around - well, don't use those instructions as they are outdated. It does not seem to work to get the large SD card to boot (hexedit or other method doesn't seem to work)
Do the following to make a bootable card:
1) Copy the chdk files to the large fat32 SD card using your computer. unmount and remove. Leave the card unlocked
2) put the card into your camera and turn on using 'play' then use the firmware update option to get chdk going
3) in chdk menu, find the 'make card bootable' option and do it
4) now, you can turn off your camera and take the SD card out.
5) lock the card, and put it back into your camera
6) when you turn on your camera, with the power button, it should now automatically boot chdk.
-
I just copied these files to the root of the SD card:-
1. DISKBOOT.BIN
2.PS.FI2
Then I manually booted the camera using the >Display/PLAY, Firmware Update method.
If you are using the firmware update method, you don't need the DISKBOOT.BIN file.
However, you might want to unzip all the other files - things like the CHDK logo, the example scripts, language support, fonts, grids, menu icons and LUA program libraries are stored on the card and so those part of CHDK do not work if the files are not there.
-
I just copied these files to the root of the SD card:-
1. DISKBOOT.BIN
2.PS.FI2
Then I manually booted the camera using the >Display/PLAY, Firmware Update method.
If you are using the firmware update method, you don't need the DISKBOOT.BIN file.
However, you might want to unzip all the other files - things like the CHDK logo, the example scripts, language support, fonts, grids, menu icons and LUA program libraries are stored on the card and so those part of CHDK do not work if the files are not there.
I keep making beginner mistakes. I fixed it now – no wonder my battery indicator only displayed 0% & chdk icons were missing in the menu.
it looks a lot better now that it is loaded on the SD card properly.
Thanks again waterwingz
-
Thanks for the help! I can't find the firmware update option in the canon menus. Is it called something different?
-
Thanks for the help! I can't find the firmware update option in the canon menus. Is it called something different?
The firmware update option in the Canon menu only appears if there is a ps.fi2 file in the root of the SD card and you start the camera by holding down the playback switch rather than the on/off switch.
-
Hmmm. I tried this, still no dice. I'm on a mac, don't know if something there could be screwing this up. I'll attach a picture of what's on my card, perhaps that will help?
-
http://chdk.wikia.com/wiki/FAQ/Mac#You_may_have_issues_with_permissions. (http://chdk.wikia.com/wiki/FAQ/Mac#You_may_have_issues_with_permissions.)
-
I got it. I had to unflag some hidden files from the download using the instructions:
In terminal (after renaming the card CANON_DC):
Open the Terminal. (It is found in your Applications > Utilities folder)
Enter these commands: (Assuming you have already installed CHDK on your SD Card)
cd /Volumes/CANON_DC
xattr -d com.apple.quarantine DISKBOOT.BIN PS.FIR
But changing the name PS.FIR to PS.FI2
-
Canon PowerShot Elph 300 hs chdk Ultra Intervalometer Time Lapse (http://www.youtube.com/watch?v=GMzyqxYpGF8#ws)
Long Shutter Mode,
15 sec shutter speed,
Focus Lock,
iso 100,
Auto WB.
CHDK:
Ultra Intervalometer script,
30 sec intervals,
125 shots,
Playback 25fps, 5sec.
2 hours 14 minutes
-
Is it possible to lock the exposure in movie mode?
-
I'm planning to buy a HS115 or 220 hopefully in some months. Was wondring since i'll be purchasing a sealed pack. How do do i check the firmware on the box, since i cant open the box at the shop to check the firmware. ?.. :S and is this compatible with the DIY shutter button?
-
I'm planning to buy a HS115 or 220 hopefully in some months. Was wondring since i'll be purchasing a sealed pack. How do do i check the firmware on the box, since i cant open the box at the shop to check the firmware. ?
This is a common question without a good answer. In short, you can't tell from the box what firmware version you are getting. If not being able to run CHDK is a show stopper for you, make sure they have a generous return policy.
Here's a link to a thread about this : Getting a camera with a supported firmware version (http://chdk.setepontos.com/index.php?topic=7091)
And some background information on the development process if you get one that is not supported and are willing to wait : CHDK FAQ : My camera isn't ported yet (http://chdk.wikia.com/wiki/FAQ#Q._My_camera_isn.27t_ported_yet._Is_a_port_planned.C2.A0.3F_When_will_it_be_ready.C2.A0.3F_How_can_I_help.C2.A0.3F)
Note that sometimes a camera with an unsupported firmware version will work properly with a CHDK firmware port for the version numerically nearest to it. Please post that information here if you find something like that out.
and is this compatible with the DIY shutter button?
It has a USB port so "Yes". Search the wiki and forum for "USB Remote". Here's a headstart : http://chdk.wikia.com/wiki/USB_Remote_Cable (http://chdk.wikia.com/wiki/USB_Remote_Cable)
-
Thanks for all that help and info. ! :) I hope i get lucky enough to get one with one of the listed Firmwares. I hope all goes well. If it does, then you'll be seeing me alot around here. What do you think of the HS220?.
Also was wondering how many firmwares might be released of HS220 by Canon as of this date
-
Thanks for all that help and info. ! :) I hope i get lucky enough to get one with one of the listed Firmwares. I hope all goes well. If it does, then you'll be seeing me alot around here. What do you think of the HS220?.
Looks nice. But what do I know ?
Also was wondering how many firmwares might be released of HS220 by Canon as of this date
Really no way to tell except for reports here and if somebody is keeping notes on the wiki page for this camera.
-
Ok thanks for all your assistance :)
-
Hi, I'd like to know if CHDK works on every Ixus 220 HS.
Are there problems some problems depending on the firmware?
Thanks a lot.
-
Hi, I'd like to know if CHDK works on every Ixus 220 HS.
Unfortunately, there is really no way to tell. Canon does not publish a list so the only way we know about a firmware version is when somebody does the work to discover the firmware version of their camera and posts that information here or on the appropriate wiki page.
Are there problems some problems depending on the firmware?
There are occasionally bugs that creep in between CHDK versions for different firmware releases but IMHO its not very common based on what I've seen here on the forum. Once CHDK becomes available for a camera, the port to other firmware versions has become pretty easy to do correctly.
Based on your question, I'm guessing that you might want to read through this forum thread -> http://chdk.setepontos.com/index.php?topic=7091 (http://chdk.setepontos.com/index.php?topic=7091)
And as always, this is an important first read so that you understand a bit about the process used around here : link> CHDK FAQ : My camera isn't ported yet (http://chdk.wikia.com/wiki/FAQ#Q._My_camera_isn.27t_ported_yet._Is_a_port_planned.C2.A0.3F_When_will_it_be_ready.C2.A0.3F_How_can_I_help.C2.A0.3F)
-
What is Ixus 220 firmware best supported from chdk?
Which versions work properly?
Thanks.
-
I think they all work equally at the moment. So far no one has reported a version that doesn't work at all but Canon could change that.
-
How Canon can change that? With a new firmware?
-
I just meant they can include a firmware on a new camera that isn't currently compatible with CHDK.
-
Pro shooter noob here. I just got the chdk working on my elph 300 hs but the raw files can't be read by photoshop cs5. I tried with the .crw and the .cr2 applied and no luck. Is this on my end or is the port not working fully yet. I realize it's an alpha release.
Thanks so much for doing this!!!
-
Pro shooter noob here. I just got the chdk working on my elph 300 hs but the raw files can't be read by photoshop cs5. I tried with the .crw and the .cr2 applied and no luck. Is this on my end or is the port not working fully yet. I realize it's an alpha release.
Take a look at this thread : http://chdk.setepontos.com/index.php?topic=5691.msg78315#msg78315 (http://chdk.setepontos.com/index.php?topic=5691.msg78315#msg78315)
-
My Ixus 220 hs has 1.01e firnware. Which version of chkdk should I use and which keys combination to activate it? Thanks a lot.
-
My Ixus 220 hs has 1.01e firnware. Which version of chkdk should I use and which keys combination to activate it?
So far, CHDK has not been ported to the 1.01e firmware version of the IXUS220. You could try the 1.01c versions and see if it works but its not guaranteed. Otherwise, you have to either port CHDK to the 1.01e yourself or wait for somebody else to do it.
According to the code in kbd.c for the IXUS220, the Video key is used to activate <ALT> mode.
-
How can I load it? What's the right procedure? thanks.
-
How can I load it? What's the right procedure? thanks.
Bearing in mind that it may not work at all, here's some things you can read to get familiar with CHDK :
link> CHDK User Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual)
link> CHDK for Dummies (http://chdk.wikia.com/wiki/CHDK_for_Dummies)
link> CHDK Wiki FAQ (http://chdk.wikia.com/wiki/FAQ)
link> CHDK UserGuide April 2009 (http://chdk.wikia.com/wiki/File:CHDK_UserGuide_April_2009_A4.pdf)
link> CHDK Firmware Usage (http://chdk.wikia.com/wiki/CHDK_firmware_usage)
link> CHDK Installation Guide (http://chdk.wikia.com/wiki/File:CHDK_Installation_Guide.pdf)
-
Sorry to bump my question... but is there a way I can lock the exposure/light settings in video mode?
-
I know, but could you tell me exactly keys combination and menu steps to load chdk on ixus 220? Thanks a lot.
-
I know, but could you tell me exactly keys combination and menu steps to load chdk on ixus 220? Thanks a lot.
1.Turn camera on by pressing the PLAY button (button with the blue "play" icon)
2.MENU
3.DISP (press 6 times until you reach "Firm Update")
4.FUNC SET
5.LIGHTNING BOLT (to select "OK")
6.FUNC SET
... you are now running CHDK
This works on my IXUS 220 HS 1.01d
-
Why is it with the 1.01e firmware version, when in the standard mode, when taking actual pictures, the standard camera shutter value takes over, even when I have the override values set? It functions when I just press the shutter button completely, but not when I am using the auto-focus- Then the standard (camera set) shutter speed takes over.
-
Sorry to bump my question... but is there a way I can lock the exposure/light settings in video mode?
Not that I'm aware of. At the moment you can only change the 'video quality'.
However, you can lock 'focus' in video mode. Which is possible even without chdk.
-
I've got chdk working on my ixus 220 hs 1.01e firmware.
Is there scripts for Av priority?
I'me also intersted in manual focus, possible? Thanks.
-
Is there scripts for Av priority? I'm also interested in manual focus, possible? Thanks.
There are many such scripts - use the search function here and in the wiki http://chdk.wikia.com/wiki/CHDK (http://chdk.wikia.com/wiki/CHDK) to find one that meets your needs.
-
Is there scripts for Av priority? I'm also interested in manual focus, possible? Thanks.
There are many such scripts - use the search function here and in the wiki http://chdk.wikia.com/wiki/CHDK (http://chdk.wikia.com/wiki/CHDK) to find one that meets your needs.
On my port [101c] there is not an 'Override Aperture' option in the 'Extra Photo Operations' menu.
If I recall, there may not be a option for Av Priority [aperture] in this type of camera. If I'm not mistaken that is due to the fact that the camera doesn't have a 'proper' aperture mechanism – I think it is something to do with ND filters being used. But don't quote me on that. I'm still learning this chdk thing as I go.
Update: From the chdk manual explaining a little more about the aperture override.
http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_Aperture (http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_Aperture)
can't find" Override Aperture"
http://chdk.setepontos.com/index.php?topic=940.msg7980#msg7980 (http://chdk.setepontos.com/index.php?topic=940.msg7980#msg7980)
-
On my port [101c] there is not an 'Override Aperture' option in the 'Extra Photo Operations' menu.
If I recall, there may not be a option for Av Priority [aperture] in this type of camera. If I'm not mistaken that is due to the fact that the camera doesn't have a 'proper' aperture mechanism – I think it is something to do with ND filters being used. But don't quote me on that. I'm still learning this chdk thing as I go.
Correct. In fact, the platform_camera.h file for the IXUS220HS, which tells the CHDK build process how your camera is configured, has a line that says :
#undef CAM_HAS_IRIS_DIAPHRAGM
which means CHDK is compiled assuming it cannot control an aperature mechanism.
-
Ok! Thanks! And for manual focus control on ixus 220? Which script does it work?Thanks.
-
Ok! Thanks! And for
manual focus control on ixus 220? Which script does it work?Thanks.
You are probably going to learn a lot more about CHDK by reading the links I posted for you on Dec 26th and by searching for things yourself rather than posting each question 1 by 1 here on the forum. Here's one last hint :
http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_Subject_Distance (http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_Subject_Distance)
-
Hi everyone.
Even I’m a newbie to CHDK, I got good results for the remote control of shutter and zoom of my IXUS890IS on a KAP cradle with the suitable CHDK and a script based on USB power pulse width, like those described here (http://www.zenoshrdlu.com/kapstuff/zchdk2.html (http://www.zenoshrdlu.com/kapstuff/zchdk2.html))
To reduce the weight of the aerial platform, I got the IXUS220HS /ELPH300 as the suitable CHDK build (1.0.1 e) was released a few weeks ago. Unfortunately, up to now, I could not get any control of shutter or zoom with USB power pulses (shooting is OK via scripts). The green led above “Disp” button lights and a very low bip can be heard when sending the pulse without any further action. Does anybody know of the capability of the IXUS 220HS/ELPH 300 for CHDK USB remote control ?
Thanks in advance.
-
I tried Override Subject Distance but for me doesn't work. I'm asking if there's another way to focus manually, with a script for example. thanks.
-
I tried Override Subject Distance but for me doesn't work. I'm asking if there's another way to focus manually, with a script for example. thanks.
- Enter Canon's Focus Lock mode (half press shutter + left)
- Enter Alt mode
- Press Up to enter MF mode
- Use the zoom lever to adjust subject distance (ie, to focus)
- Use Up and Down buttons to change the Factor
-
Unfortunately, up to now, I could not get any control of shutter or zoom with USB power pulses (shooting is OK via scripts). The green led above “Disp” button lights and a very low bip can be heard when sending the pulse without any further action. Does anybody know of the capability of the IXUS 220HS/ELPH 300 for CHDK USB remote control ?
There is really only one thing that has to be done correctly in each port in order for USB remote functionality to work. The value of USB_MASK has to get set correctly in platform/camera/kbd.c ( and if its not in the third key register, that code has to get tweaked).
Here's a quick test script to see if that's working. Run it in playback mode without USB remote enabled. If you don't have a USB switch, just plug and unplug any USB cable with the right connectors between your camera and you PC's USB port.
@title USB Test
:loop1
print "waiting for USB"
:loop2
wait_click 1
is_key k "remote"
if k<>1 then goto "loop2"
print "USB power active"
:loop3
wait_click 1
is_key k "remote"
if k=1 then goto "loop3"
print "USB power removed"
goto "loop1"
end
-
Thank you, now I can use it!
I tried Override Subject Distance but for me doesn't work. I'm asking if there's another way to focus manually, with a script for example. thanks.
- Enter Canon's Focus Lock mode (half press shutter + left)
- Enter Alt mode
- Press Up to enter MF mode
- Use the zoom lever to adjust subject distance (ie, to focus)
- Use Up and Down buttons to change the Factor
-
how do i get the firmware version of my ixus 220hs? recommended to update to the 1.01e?
link> Determining the firmware version in your camera. (http://chdk.wikia.com/wiki/FAQ#Q._How_can_I_get_the_original_firmware_version_number_of_my_camera.3F)
I'm Sorry ...
ver / vers.req both don't do it. while holding Func Set I'll get the Time Screensaver everytime. Key Combinations do not work. I tired both, 16GB fat32 SDHC & 2GB fat16.
-
That wiki link also says to try acid (http://www.zenoshrdlu.com/acid/acid.html).
-
thank you so much, vers. 101a =)
so simple :/ ^^
-
Wow, just amazing! Great work guys!!!
I took a sample picture RAW, the quality is just so much better. Canon uses a default warp filter @ 24mm, but that is kinda way to much. While heaving the usual fish-eye effect in RAW, the JPG looks really bad next to it.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fabilehrte.ab.funpic.de%2Fprv%2FCRW_verlgeich_dev.jpg&hash=47c7b1edf374b0c7e3d2875ee0c87f1c)
-
Even I think my relply might merge the topic on "IXUS 220 USB remote control" , I post it here as a reply to the suggested action.
After installing the script proposed, I ran the code, got "waiting for USB " after STARTED, and sent 5V pulses I got following results :
-black screen for a bit more than second,
-return of camera live image,
-script stopped (need to click again for a new start),
-no expected print on screen.
Hope this can help
...and Happy New Year to all.
-
After installing the script proposed, I ran the code, got "waiting for USB " after STARTED, and sent 5V pulses I got following results :
-black screen for a bit more than second,
-return of camera live image,
-script stopped (need to click again for a new start),
-no expected print on screen.
Sounds like you have not selected the Enable Remote|*| option in the CHDK Remote parameters menu ?
-
After installing the script proposed, I ran the code, got "waiting for USB " after STARTED, and sent 5V pulses I got following results :
-black screen for a bit more than second,
-return of camera live image,
-script stopped (need to click again for a new start),
-no expected print on screen.
Sounds like you have not selected the Enable Remote|*| option in the CHDK Remote parameters menu ?
I get the same results as Newkap. And yes remote is enabled. This problem is related to the e41. The e41 error can be reproduced by connecting the camera to a PC while running chdk on a bootable sdcard. The e41 error is trigged by the 5v on the usb cable for just a little bit longer then used for the usb remote.
Since I am not a developer I am not able to solve the problem on my own. But I will try any suggestion to solve the problem. I have the chdk source running on my pc.
-
I made this RAW profiles for this great compact camera.
In Windows 7, to use in Camera Raw and Lightroom unzip them in this directory:
C:\Users\"name user"\AppData\Roaming\Adobe\CameraRaw\LensProfiles\1.0
I hope they are useful for all owners of this Canon!
Let me know!
Thanks.
-
I get the same results as Newkap. And yes remote is enabled.
...
Since I am not a developer I am not able to solve the problem on my own. But I will try any suggestion to solve the problem. I have the chdk source running on my pc.
Can you make a simple change and recompile the code ? If not, tell me your f/w version number and I will do it for you. Here's the change - the USB_MASK value being used appears to be wrong.
In the file platform/ixus220_elph300hs/kbd.c, change line 53 from
#define USB_MASK (0x00080000)
to
#define USB_MASK (0x04000000)
I found the correct value in the camera's stubs_entry_S.S file.
-
I get the same results as Newkap. And yes remote is enabled.
...
Since I am not a developer I am not able to solve the problem on my own. But I will try any suggestion to solve the problem. I have the chdk source running on my pc.
Can you make a simple change and recompile the code ? If not, tell me your f/w version number and I will do it for you. Here's the change - the USB_MASK value being used appears to be wrong.
In the file platform/ixus220_elph300hs/kbd.c, change line 53 from
#define USB_MASK (0x00080000)
to
#define USB_MASK (0x04000000)
I found the correct value in the camera's stubs_entry_S.S file.
Thanks waterwingz
I tried this and it solves the usb remote problem! The first trigger is focus and second one does actually take the shot. Unforunatly the e41 error stays as soon as usb remote is not longer enabled and the camera is connect to a pc while running CHDK it I get after a e41 error on my camera. I think it has something to do with ptp. I hope this one also can be solved with a little help, any suggestions?
Thanks
-
Unforunatly the e41 error stays as soon as usb remote is not longer enabled and the camera is connect to a pc while running CHDK it I get after a e41 error on my camera. I think it has something to do with ptp. I hope this one also can be solved with a little help, any suggestions?
I don't know anything about CHDK ptp but you maybe could try building without it ? Insert the following line at the bottom of your platform_camera.h file :
#undef CAM_CHDK_PTP
and see what happens ?
-
Has anyone managed to Turn off the LCD screen while time lapsing?
-
Unforunatly the e41 error stays as soon as usb remote is not longer enabled and the camera is connect to a pc while running CHDK it I get after a e41 error on my camera. I think it has something to do with ptp. I hope this one also can be solved with a little help, any suggestions?
I don't know anything about CHDK ptp but you maybe could try building without it ? Insert the following line at the bottom of your platform_camera.h file :
#undef CAM_CHDK_PTP
and see what happens ?
I tried it. It seems not to have any effect, still the same error.
-
@danistuta
great thing! how do I use them? In Camera Raw, there are no Profiles displayed with those *.DNG Raw Files (4th Tab). Just chromatic aberration etc, nothing else.
-
Hm, doesn't Photoshop use the badpix info inside the raw files? selected RAWconv
(ISO 3200)
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fabilehrte.ab.funpic.de%2Fpic%2FIMG_0374.jpg&hash=896281f4fd79436d0b27cf183c9e39ef)
44399 bad pixel count
-
Hm, doesn't Photoshop use the badpix info inside the raw files? selected RAWconv
CHDK removes the bad pixels from the raw data in the DNG file (using the badpixel.bin file). It doesn't save the badpixel location info in the DNG file.
On the cameras with BSI-CMOS sensor there are a lot more bad pixels at ISO 3200 than at lower ISO settings.
If you plan to use ISO 3200 a lot then you should re-create the badpixel.bin file with the camera set to ISO 3200.
Phil.
-
@danistuta
great thing! how do I use them? In Camera Raw, there are no Profiles displayed with those *.DNG Raw Files (4th Tab). Just chromatic aberration etc, nothing else.
You have to go in lens correction of camera raw and active "enable lens profile corrections". Then you can choose profiles I've done it in the menu.
-
okay, the profle/manual tab is missing in my version :( (CS5)
why?
looks just like this:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fwww.digitalterrain.info%2Fassets%2Ftutorials%2FACR%2Fadobe-camera-raw-video-tutorial-fringing-and-lens-vignetting-tool%2Fadobe-camera-raw-adjustment-tabs_lens-corrections.jpg&hash=a74f9cb5ce443bfdc419cae34d8866ce)
and should look like this:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fptgmedia.pearsoncmg.com%2Fimages%2Fexc8_9780321713094%2FelementLinks%2F04fig28.jpg&hash=776a65974b1fc67b32cefab045df4ddd)
-
hey guys, i can't figure out how to enable that focus lock, i am pressing half shutter until it focuses then Left (the button with the flower on it right?) and nothing happens.. both with ALT mode on and off, am i missing something?
by the way thanks a lot for this CHDK! i'm trying to test everything right now, so far no problems, except that i can't plug in the usb cable and get the photos with CHDK turned on, so i have to first turn it off to work.
EDIT: oh looks like AFL didn't work because i had Servo AF turned On, turned it Off and now i have the focus locked in video mode, so much better!
do you guys think there is any way to make the camera record 60fps at 720p? it can record 120fps at 480p although the quality is really low..
-
okay, the profle/manual tab is missing in my version :( (CS5)
why?
looks just like this:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fwww.digitalterrain.info%2Fassets%2Ftutorials%2FACR%2Fadobe-camera-raw-video-tutorial-fringing-and-lens-vignetting-tool%2Fadobe-camera-raw-adjustment-tabs_lens-corrections.jpg&hash=a74f9cb5ce443bfdc419cae34d8866ce)
and should look like this:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fptgmedia.pearsoncmg.com%2Fimages%2Fexc8_9780321713094%2FelementLinks%2F04fig28.jpg&hash=776a65974b1fc67b32cefab045df4ddd)
Perhaps this is why?
From:
http://www.digitalphotopro.com/technique/revolution/using-lens-profiles (http://www.digitalphotopro.com/technique/revolution/using-lens-profiles)
Using Adobe’s Lens Profile Corrections
You can access Adobe’s Lens Corrections in three locations—Adobe Camera Raw, Lightroom 3 or Photoshop CS5’s Lens Corrections filter. Lens profile corrections were first introduced in Lightroom 3. To get lens profile corrections in Adobe Camera Raw CS5, you need to download a version that has been updated after the release of Lightroom 3. You can download the latest free update at www.adobe.com/products/photoshop/cameraraw.html (http://www.adobe.com/products/photoshop/cameraraw.html).
-
1.01G firmware dump: http://www.box.com/s/cx1bjvtfmzga7ftmygac (http://www.box.com/s/cx1bjvtfmzga7ftmygac)
and port: https://github.com/stefantalpalaru/CHDK-ixus220_elph300hs-101g (https://github.com/stefantalpalaru/CHDK-ixus220_elph300hs-101g)
compiled (including PS.FI2 for manual loading): http://www.box.com/s/qh1ots6bxvjogvzyaqal (http://www.box.com/s/qh1ots6bxvjogvzyaqal)
I don't have access to the hardware, but the camera owner reports running CHDK successfully and the only problem so far is a camera freeze while switching to the "Movie Digest" mode.
-
Good work, stefantalpalaru !
Added the
- IXUS 220HS / ELPH 300HS 1.01G
full 8MB dump (dumped with cBasic udumper) provided by stefantalpalaru from this forum post (http://chdk.setepontos.com/index.php?topic=6341.msg79508#msg79508) to the box.net/chdk (http://www.box.net/chdk) repository.
-
Please forgive me if I am missing something obvious, but after a couple of hours of searching online, in this forum, the 300HS manual and in the CHDK download readme file, I can't seem to figure out how to read the current firmware version of my 300 HS or how to enter the firmware update mode, as of the traditional "Set +DISP" commands seem to do anything but display the current time. Could someone please advise how to do this or where I might find the proper instructions?
Thanks.
-
Could someone please advise how to do this or where I might find the proper instructions?
Here's a couple of things to look at :
link> Determining the firmware version in your camera. (http://chdk.wikia.com/wiki/FAQ#Q._How_can_I_get_the_original_firmware_version_number_of_my_camera.3F)
link> Automatic Camera Identifier and Downloader (http://www.zenoshrdlu.com/acid/acid.html)
,, or how to enter the firmware update mode, as of the traditional "Set +DISP" commands seem to do anything but display the current time.
"Set+DISP" is used to enter <ALT> mode once you have CHDK loaded successfully - it has nothing to do with firmware update. Firmware update is a menu item in the original Canon menus on your camera. However, it will only appear in those menus if you have a ps.fi2 file in the root of your SD card and if you start the camera in playback mode by pressing the Play switch - not the On/Off switch.
-
Thanks, but perhaps I should have been more detailed, I did download, extract and place a copy of PS.FI2, vers.req and DISKBOOT.BIN that I extracted from ixus220_elph300_101e.7z in the root of the SD card, but pressing"Set+DISP" only brings up the time screen.
I also downloaded ACID and SDinst (MAC Versions) but not sure how to use it to read the meta data from a jpeg, as the BIN files from ACID and CHDK are grayed-out.
Do I have to have the proper vers.req or PS.FI2 installed in order to read and update the Firmware version, or am I missing something else?
Thanks Again
-
Update:
I was able to get ACID to run after doing a low-level format, downloading everything ACID a second time, and letting it download and extract the recommended files as shown below. I copied all the files extracted to the root of the SD card, hit the play mode, but "Set+DISP" still only brings up the Blue Time Screen?
Booting with the SD Card Locked did bring up a brief firmware update splash, and I can now access the CHDK parameters. However, I can now record to the SD card with the SD card protect switch in either position and was wondering if that is normal?
Thanks
-
I can now record to the SD card with the SD card protect switch in either position and was wondering if that is normal?
Yes, that's normal.
"Set+DISP" still only brings up the Blue Time Screen?
"Set+DISP" is just a way to see the version number on some Canon cameras. It doesn't work on ELPH300HS and you don't need it since you can get the version number from a JPG using ACID or similar programs.
-
Thanks, hope this is not a pain, but after the first boot I can't seem to access the CHDK screen again with the card in protected or unprotected setting. I see the CHDK splash screen but 'Set+DISP" still brings up only the blue screen. Is there some other command to enter the Extra parameters screen?
Thanks
-
Use the red movie recording button to toggle ALT mode.
-
Hmmmm. I have to laugh at myself a little here :-[ because all the RED record button seems to do is start video recording. I've tried combinations and holding the red record button during boot, but no ALT mode yet. Is there another button you or some mode it has to be in for that to work?
-
CHDK has to be loaded already for that to work. Either with the SD lock or powering on the camera by holding the play button and then running CHDK through the "Update firmware" menu.
-
Can any one walk me through the process of getting CHDK files to work.
I added the primary.BIN file which I got from CHDK site for the 1.01g firmware for ELPH 300hs.
I finally got the firmware update menu to appear then pressed it and asked me if I want to update, I pressed yes, but then the camera turned off and it has been more than 10 min and the camera does not function or turn on unless I take the battery off and out it back on.
Can anyone exlpain the process of getting CHDK to work? I did everything that was mentioned.
Help please.
B
-
baraasafaa, you've got the original firmware which is of no use to end users. The CHDK firmware is here:
http://www.box.com/s/qh1ots6bxvjogvzyaqal (http://www.box.com/s/qh1ots6bxvjogvzyaqal)
-
do you guys think there is any way to make the camera record 60fps at 720p? it can record 120fps at 480p although the quality is really low..
anybody? : - D
or better, if there is a way to modify the frame rate it records with?
-
I'm about to buy an Ixus 220 HS but before I do I'd like to check something.
Will CHDK allow me to do remote capture with programs such as gPhoto2 and Cam4you? I think it should, but I can't find any definitive answer.
Chris
-
Hi!
Thank you very much danistuta for creating lens profiles for this camera, works like a charm in my LR trial.
I have a newbie question for anyone who can help. I would like to convert the Lightroom lens profiles
to Aperture 3, but I haven't had any luck trying to find such guide.
Is it even at all possible to do this conversion ?
Kind regards,
Fredrik
I made this RAW profiles for this great compact camera.
In Windows 7, to use in Camera Raw and Lightroom unzip them in this directory:
C:\Users\"name user"\AppData\Roaming\Adobe\CameraRaw\LensProfiles\1.0
I hope they are useful for all owners of this Canon!
Let me know!
Thanks.
-
Hey guys, i've got a canon 220HS, clicked a pic, and it was resized on the email. I entered that into the "CameraVersion v1.3" and the version says 101A (But the camera is "Unknown")
does this mean it's 1.01 A,
Also am i able to use both the stock firmware and the CHDK on the same card, with the option to boot to a certain software?
-
Yes it means 1.01A. CHDK doesn't actually write to firmware, so you can go back to original just by deleting CHDK from your SD card, using another SD card or moving the lock switch on your SD card to the unlocked position.
-
with ACID it is saying "no firmware revision" :S
and does the lock have to be on for CHDK to run?..
and if i uNlock it then CHDK will go?.
Usually im prone to loosing memory cards if i cary more than 1. :P and on on the move i can't keep installing and removing CHDK, since i wont be having a laptop .. :P
If i install the wrong firmware, will anything happen?
-
If the lock is off then CHDK will only run if you manually run it by selecting "firmware update" through the camera menu.
I'm not sure what you meant by "resized on the email". Use an unmodified image from the camera when trying to determine version.
Wrong version of CHDK just won't run. It won't harm your camera.
-
Thanks for providing that information. :) i will keep the lock off, so i can decide each time which system i want to boot into .. :) (Will my CHDK settings be saved after reboot?)
Actually i left my camera at a friend's house, and i told him to email me the picture, he sent a resized version. I will try to get a proper version.
Ok i thought it might harm my camera. LOL
-
@ryandigweed
I entered that into the "CameraVersion v1.3" and the version says 101A (But the camera is "Unknown")
CameraVersion uses exiftool to extract camera model and firmware; since version 1.3 was released well before
the introduction of the ELPH300HS / IXUS220HS the exiftool supplied with it is out of date.
Just use the button to surf to the exiftool site and download the latest exiftool version.
(Since I also own this camera I know it properly recognises this camera)
hope that helps,
wim
-
AhaH, thanks for that. I had a feeling it could have been outdated, but I didnt know i could update only the exiftool and have the cameraversion upto-date. :) Thanks
Great tip !.. :)
How is the camera?. Any good?.. Im excited to use this camera. First time that i've shifted to canon. (was a sony user before). I shifted mainly because of the CHDK .. :P
Got any fancy scripts?. Made any yourself?
------
Also what good is the lens profile?. Does it recognize RAW photos with their exif data and then apply some certain adjustments? WB? exposure etC?
-
I'm about to buy an Ixus 220 HS but before I do I'd like to check something.
Will CHDK allow me to do remote capture with programs such as gPhoto2 and Cam4you? I think it should, but I can't find any definitive answer.
Chris
Can anybody answer this one, please?
-
I'm about to buy an Ixus 220 HS but before I do I'd like to check something.
Will CHDK allow me to do remote capture with programs such as gPhoto2 and Cam4you? I think it should, but I can't find any definitive answer.
Chris
Can anybody answer this one, please?
What exactly are you trying to achieve?
You may want to check out the User Manual http://chdk.wikia.com/wiki/CHDK_User_Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual)
-
I'm about to buy an Ixus 220 HS but before I do I'd like to check something. Will CHDK allow me to do remote capture with programs such as gPhoto2 and Cam4you? I think it should, but I can't find any definitive answer.
Can anybody answer this one, please?
Unless I'm mistaken, the discussion on the forum had been that older Canon cameras supported remote capture via those programs but that Canon removed this capability several years ago in newer cameras.
-
Unless I'm mistaken, the discussion on the forum had been that older Canon cameras supported remote capture via those programs but that Canon removed this capability several years ago in newer cameras.
Indeed, but isn't remote capture in firmware, in which case it is replaced with CHDK? Canon's firmware won't allow it but surely CHDK can. Or am I missing something?
Chris
-
Indeed, but isn't remote capture in firmware, in which case it is replaced with CHDK? Canon's firmware won't allow it but surely CHDK can. Or am I missing something?
Remote capture was in the Canon firmware of the old cameras. It is not in the firmware of the new cameras. CHDK does not replace the cameras firmware - it loads in RAM to augment the built-in firmware and makes no permanent change to the camera. Fundamental camera functionality is still operated by the Canon firmware.
That being said, there are a couple of projects looking at video capture over ptp. However, the PC clients are custom - I don't believe there is any plan to have them work with the software packages you originally mentioned. Or a schedule for when the projects will be done.
-
Thank you for that explanation. It appeared to me to be a simple feature that would be one of the first things that CHDK would implement, but it must be a lot harder than I imagined.
I have used gPhoto2 and Cam4you with my A80 and had good results with both. It's a pity that I won't be able to do the same with a new camera. Perhaps I'll just stick to old ones.
Chris
-
As has become clearer to me following this thread, CHDK can only tweak and access parameters that actually exist in the Canon software. Canon builds all these cameras with mostly the same functionality, and then dumbs down it's less expensive units in order to get people to upgrade. CHDK can undo this dumbing down by giving you fuller access to all the aspects of the canon software functionality, but it cannot create or control properties which completely don't exist in the canon software.
-
As has become clearer to me following this thread, CHDK can only tweak and access parameters that actually exist in the Canon software. Canon builds all these cameras with mostly the same functionality, and then dumbs down it's less expensive units in order to get people to upgrade. CHDK can undo this dumbing down by giving you fuller access to all the aspects of the canon software functionality, but it cannot create or control properties which completely don't exist in the canon software.
Interesting interpretation but I'm not sure I agree. CHDK provides many things not in the original camera firmware - USB remote, RAW, HDR bracketing being a few examples. And the price differences in Canon cameras tends to reflect the quality of the lens, sensor and general construction. Software functionality does not really factor into that.
-
What I meant is that CHDK can utilize things provided for in the canon software in ways which cannot be done otherwise. The canon software certainly provides all the functions needed to take hdr bracketed photos, it simply does not allow it (is not programmed for it). More expensive point and shoots from canon can do HDR photos (internally). The canon software contains all the necessary components for using usb remote, it simply does not string them together to allow this functionality (other canon cameras do), but chdk puts together these components to do something that is technically possible in the canon software, but is not programmed for.
I guess I was just trying to clarify that CHDK can do novel things with what canon provides by re-programming them in different ways, but is still working fundamentally with the core functions of the canon software. Does this make more sense?
I forget where I was reading, but I think there is evidence that canon starts with a fully loaded eos software and works backwards, removing certain functions out of lower end models. I think there are stray parameters and other things indicating certain functions that were once plugged in but have been removed, but I forget the article source so I can't be sure.
-
I guess I was just trying to clarify that CHDK can do novel things with what canon provides by re-programming them in different ways, but is still working fundamentally with the core functions of the canon software.
If by "fundamentally the core functions" you mean taking the data from the sensor and processing it with the CPU, that's true. It is *not* true that CHDK just enables features that are already present (in most cases), e.g. CHDK isn't just flipping on an "enable raw" flag that already existed in the camera firmware to save raw, it just takes the framebuffer of the sensor and writes that to disk. In the same way, using SD override for manual focus isn't done by turning on a hidden manual focus mode, it's done by telling the lens hardware to focus at a specific distance.
I forget where I was reading, but I think there is evidence that canon starts with a fully loaded eos software and works backwards, removing certain functions out of lower end models. I think there are stray parameters and other things indicating certain functions that were once plugged in but have been removed, but I forget the article source so I can't be sure.
This is untrue. The DSLRs are very obviously a different codebase. The OS is the same, but the "application" that does all the camera stuff is very different, and likely done by entirely different teams. They may share some libraries.
-
I did have some misconceptions about how chdk operated then. I didn't think it was as simple as flipping a flag for "manual focus" or something, but I did think that all the parameters needed to put together a manual focus function were provided for within in the autofocus system. Thanks for clarifying!
-
Hi to all, and huge thanks for porting CHDK to IXUS 220 HS! =)
I`m new here and to CHDK, and I`m still getting familiar with it, learning about it and testing the possibilities. So far, I`ve noticed a few bugs (I think), and wanted to report them (sorry if I missed the topic, thought that port devs are going to see them reported here first).
(1) AutoISO setting doesn`t work in P mode if Servo AF is turned ON. It does it`s job at shutter half-press, setting the highest ISO value allowed, but at the very next second it changes to AF preferred value (bypassing the set override value).
Example: Shutter half-pressed, shutter speed 1/6, ISO 500, but after less than a second it changes to shutter speed 1/20, ISO 1600 (shutter is still being half-pressed). If Servo AF is turned OFF, then values stay at 1/6, ISO 500 until the shot is taken.
(2) OSD Layout Editor - Looks like it`s not possible to change to 1 pixel per move, to fine position OSD elements. Manual states that DISP. should toggle this (1px or 10px per move), but DISP. actually moves the element down, doesn`t change the pixels per move step value.
(3) OSD sometimes fails to redraw, getting wiped off the display.
Example: When CHDK menu is active in shooting mode and camera tries to lock something (moving rectangle on the screen), CHDK menu gets wiped off the screen as the rectangle moves behind (or over, as it looks like). Once we force CHDK menu to refresh (by pressing the down arrow, for example), it gets visible once again - just to be wiped off again by the moving rectangle. It makes navigating the CHDK menu in shooting mode a bit hard.
Not to forget to mention, I have 1.01d firmware on my IXUS 220 HS.
I`m interested in doing more tests if needed (of other features, too), to help improve and polish CHDK functionality. Thanks again to everyone involved in porting CHDK to this camera!
-
(3) OSD sometimes fails to redraw, getting wiped off the display.
Example: When CHDK menu is active in shooting mode and camera tries to lock something (moving rectangle on the screen), CHDK menu gets wiped off the screen as the rectangle moves behind (or over, as it looks like). Once we force CHDK menu to refresh (by pressing the down arrow, for example), it gets visible once again - just to be wiped off again by the moving rectangle. It makes navigating the CHDK menu in shooting mode a bit hard.
Can't comment on the rest of your observations but this is more of a limitation than a bug. Its been discussed many times on this forum and believe it or not, is much less of an issue since philmoz greatly improved the code last year. In simple terms, the problem is that the Canon firmware does not know CHDK exists and so writes to the display whenever it chooses to (not knowing or caring that there might be CHDK information also being displayed). Unless somebody discovers a way to override that in the Canon firmware (and nobody has after 7 years) then we will just have to live with that behavior.
-
Hello to all,
if my questions are stupid, bring patience, please ...
I am a professional photographer, I was tired to block my 5D or 7D for long periods in time lapse, so I installed the firmware in your ixus 220hs.
Now I have some questions:
1: In spite of tutorials and guides, I could not see my Firware (ver.req unicod etc etc + set disp holding don't work), so I went to trial and error, I finally found two working versions, is indifferent to use one or the other?
2: I'm looking for a intervallometer, making it possible to turn off the monitor (perhaps after the first two shots to check the focus), and of course lock the focus, possibly with some light indicator that confirms it working.
If this would be possible in a few weeks stared at him in a small yard and let indorr work for a few months (with regular maintenance), I'd rather leave the ixus, rather than the 5D with the 17-40.
I tried some scripts written for other machine, but not only do not turn off the monitor, but after a few shots entering the video function, for example, or similar problems.
Thanks for favor, wait for response, especially for the script.
ps: I used google translator, since I have little time to write, I hope it have not made too much trouble
-
(3) OSD sometimes fails to redraw, getting wiped off the display.
Example: When CHDK menu is active in shooting mode and camera tries to lock something (moving rectangle on the screen), CHDK menu gets wiped off the screen as the rectangle moves behind (or over, as it looks like). Once we force CHDK menu to refresh (by pressing the down arrow, for example), it gets visible once again - just to be wiped off again by the moving rectangle. It makes navigating the CHDK menu in shooting mode a bit hard.
Can't comment on the rest of your observations but this is more of a limitation than a bug. Its been discussed many times on this forum and believe it or not, is much less of an issue since philmoz greatly improved the code last year. In simple terms, the problem is that the Canon firmware does not know CHDK exists and so writes to the display whenever it chooses to (not knowing or caring that there might be CHDK information also being displayed). Unless somebody discovers a way to override that in the Canon firmware (and nobody has after 7 years) then we will just have to live with that behavior.
Ah, thanks for the info, I didn`t know that. Well, then I guess it`s not such a big deal after all =)
Fixing (1) and (2) would be nice, though (if possible).
I just noticed one more "issue" - when camera is off and CHDK is set to auto-load on camera startup (locked, bootable memory card), pressing the "Playback" button starts the camera - in shooting mode! Usually (without CHDK auto-load) you can start the camera in shooting mode by turning it on using ON/OFF button (lens comes out, LCD goes live, ready for shooting), or start the camera in playback mode by turning it on using the playback button (LCD turns on so you can preview recorded photos/videos, but camera lens stays retracted until shutter is half pressed). With CHDK in auto-load mode this playback ("passive mode") functionality is lost.
Is this also known already, or just something that happens with this specific camera?
1: In spite of tutorials and guides, I could not see my Firware (ver.req unicod etc etc + set disp holding don't work), so I went to trial and error, I finally found two working versions, is indifferent to use one or the other?
My knowledge is very thin here, but I guess that if all the functions are working fine (plus no freezing/crashing), you`re good to go with whatever version. Also, I think that some of the latest versions are just copied version for 1.01c, so it is the same version after all =) If you want to be sure, you can download this program (http://www.zenoshrdlu.com/acid/acid.html), and just drag one picture that you shot with you camera over the (running) program window.
-
Fantastic and very useful thank you, i just discovered than my firmware is 101e, then after load the file by 101e folder, i see on a chdk introducing screen on my lcd then the version is the same, 101c.
I think at this point then as you said c d and e version is the same.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fwww.photobyandreaoffredi.com%2Fpage26%2Ffiles%2Fschermata-01-2455946-alle-23.21.30.png&hash=95eb0ade9b17be86a08c6d13ad81ae02)
Thank you again.
Now i'm waiting for lcd off time-lapse script if someone can help me , its very important, non indispensable but it can do the difference for me.
-
Now i'm waiting for lcd off time-lapse script if someone can help me , its very important, non indispensable but it can do the difference for me.
HERE YOU GO :
http://chdk.setepontos.com/index.php?topic=6397.msg78414#msg78414 (http://chdk.setepontos.com/index.php?topic=6397.msg78414#msg78414)
-
Probably i did mistakes.
i copied the source in a script folder and renamed in .lua
when i try to start it appear : 10 sleep 1000o end:1 unexpected symbol near '@'
PRESS SHUTTER TO CLOSE
*** INTERRUPTED ***
Intervallometer
When i was wrong?
-
Probably i did mistakes.
i copied the source in a script folder and renamed in .lua
when i try to start it appear : 10 sleep 1000o end:1 unexpected symbol near '@'
PRESS SHUTTER TO CLOSE
*** INTERRUPTED ***
Intervallometer
When i was?
its a uBasic script . You cannot use a .lua extension for a filename. Try .bas.
-
And if i rename it in .bas when i press shot appear :
***STARTED***
***FINISHED***
-
WITH: uBasic: 1 Unk stmt at the top left corner in orange icon
-
Like to say excellent stuff on the chdk for the ixus220hs.
I noticed theres ND filter option for stills, could this be activated for video too?
Keep up the great work!
-
hallo,
i see there is a new firmware 1.01G for 220HS, is it possible to update the firmware from 1.00C to 1.01G? is there any tool or something for windows?
is there also a simple guide how to install CHDK?
thanx...
-
Hello & welcome !
is it possible to update the firmware from 1.00C to 1.01G? is there any tool or something for windows?
No.
Would only be possible with an official Canon firmware update.
is there also a simple guide how to install CHDK?
Yes.
* http://chdk.wikia.com/wiki/CHDK (http://chdk.wikia.com/wiki/CHDK)
* http://chdk.wikia.com/wiki/CHDK_User_Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual)
-
There is also this :
http://chdk.wikia.com/wiki/Downloads (http://chdk.wikia.com/wiki/Downloads)
http://chdk.wikia.com/wiki/CHDK_for_Dummies (http://chdk.wikia.com/wiki/CHDK_for_Dummies)
-
Thanks a lot, i got it, the "shortcut" button is actually the red video/camcorder button. that should be changed/explained, because it's confusing, you find nowhere the "shortcut".
Anyway, the images are "MINDBLOWING", i put my first test on : http://www.smex.de/220hs/CHDK_CRW_2785.png (http://www.smex.de/220hs/CHDK_CRW_2785.png), i cannot believe this small camera did that shot. i have here more expensive equipment (canon 1000D + Expensive Canon Lense), i don't know if i reach that detailed image quality with it...it would be quite hard...
anyway, i tested the video and i realized, that if i set the quality at 99 + quality, the video is jerky, i loose a lot of frames with a 10 class SDHC.
Which is the best setting there?
thanks again
-
anyway, i tested the video and i realized, that if i set the quality at 99 + quality, the video is jerky, i loose a lot of frames with a 10 class SDHC. Which is the best setting there?
That's probably something you need to discover by trial & error. All SD cards are not the same and I believe some that claim to be class 10 are actually not. Transfer speed of the card is also not the only factor - the camera's processing time enters into the equation somewhere too. On my cameras with Class 2 cards, I can't set the "quality level" much above 70 with any reliability but YMMV.
-
(3) OSD sometimes fails to redraw, getting wiped off the display.
Example: When CHDK menu is active in shooting mode and camera tries to lock something (moving rectangle on the screen), CHDK menu gets wiped off the screen as the rectangle moves behind (or over, as it looks like). Once we force CHDK menu to refresh (by pressing the down arrow, for example), it gets visible once again - just to be wiped off again by the moving rectangle. It makes navigating the CHDK menu in shooting mode a bit hard.
Can't comment on the rest of your observations but this is more of a limitation than a bug. Its been discussed many times on this forum and believe it or not, is much less of an issue since philmoz greatly improved the code last year. In simple terms, the problem is that the Canon firmware does not know CHDK exists and so writes to the display whenever it chooses to (not knowing or caring that there might be CHDK information also being displayed). Unless somebody discovers a way to override that in the Canon firmware (and nobody has after 7 years) then we will just have to live with that behavior.
I wonder if the problem can be approached this way:
# We know this problem does not effect the Canon Menus
# Therefore, we can infer that before the Canon Menus are displayed the features causing the corruption are disabled
# We can demonstrate we are right for System Menus, as the screen can be observed to ||pause|| before the (full-screen) menu pops up
# We can also demonstrate this for User Menus, as the "focus/lock box" feature is obviously disabled before the User Menu is displayed ...so clearly Canon had the same problem!
# Canon will achieve the 'disable' features by either
=1= poking a number in a register on a chip, possibly over i2c
=2= writing a value to a memory location, which may be easily examined by the Screen Task
=3= calling a function that does one of the above
# Let's assume the Canon codebase is fairly well written ...which seems likely as they have to support many many Cameras on a professional basis ...On that presumption, it's going to be a function ala screen_lockbox_disable() or screen_ccd_disable()
# We've already hooked the keyboard code, so we have a *good* starting point to work out what functions get called when the [disp] or [menu] buttons get pressed.
# To someone who has just closed IDA Pro after porting to a new camera, I imagine the journey to find the screen_*_enable/disable() functions would not be an especially long or arduous one.
# Then we simply call the screen() function of our choice when required
BC
PS. Someone here must have, at some point, attacked the firmware with IDA (Pro) ...I've not used IDA, but I understand you can tell it things about the code and get it to embed documentation ...If I'm right - who might be able to furnish me with copies of these files?
-
I just noticed an interesting error on my camera.
I just noticed that if I pull up the Canon user-menu, I can get one of the sub-menu icons stuck on the screen ...Nothing (bar a power cycle) will get rid of it.
IXUS 220 HS
Power on -> upgrade to CHDK -> FUNC -> Right -> Down -> Left -> Left
This error may offer further clues as to how the video system works
Why did the FocusLockBox not destroy this OSD corruption?
What did the SystemMenu not destroy it?
Why does CHDK menu not destroy it?
I think maybe: Either the Canon firmware is constantly redrawing this stray icon for some unknown reason (best guess: unlikely) ...or... There is another overlay somewhere. Your thoughts may differ
BC
-
can someone please tell me if i will be able to use CHDK (card locked on) with the usb cable so i can get my photos from the camera without taking out the card to unlock it everytime.. if my card is on lock position with CHDK on and i plug in my USB cable i get an error that the camera needs to shut down, because of this i always have to take my card out and unlock it.. i do this so often im thinking this could do damage to the card over time as opposed to before when i never had to take my card out.
i've tried the latest build.. the error is still there.
thanks
-
@Bluechip
You may be able to inspect the camera's RAM on your computer by dumping it to a file:
set it up like this: Miscellaneous stuff -> Debug parameters -> Alt +/- debug action -> DmpRAM
then, in the moment you need it, execute it.
You'll find a 128M file on your card afterwards. You can modify core/main.c to obtain smaller dumps from specific memory ranges.
To visualize, you can use a tool like the one attached to this (http://chdk.setepontos.com/index.php?topic=7067.msg75506#msg75506) post (Win32). Also see http://chdk.wikia.com/wiki/Frame_buffers (http://chdk.wikia.com/wiki/Frame_buffers)
-
can someone please tell me if i will be able to use CHDK (card locked on) with the usb cable so i can get my photos from the camera without taking out the card to unlock it everytime.. if my card is on lock position with CHDK on and i plug in my USB cable i get an error that the camera needs to shut down, because of this i always have to take my card out and unlock it.. i do this so often im thinking this could do damage to the card over time as opposed to before when i never had to take my card out.
i've tried the latest build.. the error is still there.
thanks
As far as I know there is no solution for this e41 error yet. Several people including me have reported it.
But we have to wait for a developer who can reproduce the error and has time to solve the problem.
-
can someone please tell me if i will be able to use CHDK (card locked on) with the usb cable so i can get my photos from the camera without taking out the card to unlock it everytime.. if my card is on lock position with CHDK on and i plug in my USB cable i get an error that the camera needs to shut down, because of this i always have to take my card out and unlock it.. i do this so often im thinking this could do damage to the card over time as opposed to before when i never had to take my card out.
i've tried the latest build.. the error is still there.
thanks
As far as I know there is no solution for this e41 error yet. Several people including me have reported it.
But we have to wait for a developer who can reproduce the error and has time to solve the problem.
one more thing i've noticed is that there is a huge difference between raw photos and the jpg ones from the camera, i think the camera tries to correct the photo at the edges because it is wide, so the photos aren't distorted, so this is really a great thing to have the raw photos because i'd never use the jpg's from the camera, they all look bad to me corrected like that, everything looks stretched at the edges and it seems that the videos have the same problem.. it would be a great thing if we could have the videos unstretched too! would that be possible?
i've attached 2 photos so you can see the difference between them.
thanks
-
As far as I know there is no solution for this e41 error yet. Several people including me have reported it. But we have to wait for a developer who can reproduce the error and has time to solve the problem.
Out of curiosity, what happens if you have USB remote enabled?
-
As far as I know there is no solution for this e41 error yet. Several people including me have reported it. But we have to wait for a developer who can reproduce the error and has time to solve the problem.
Out of curiosity, what happens if you have USB remote enabled?
i don't really know how to use that, but if i enable it, i don't get any error anymore, the camera starts in playback mode, but nothing happens and i can't do anything except turn the camera off - it's not in the mass storage mode so i can't get any files.
-
i don't really know how to use that, but if i enable it, i don't get any error anymore, the camera starts in playback mode, but nothing happens and i can't do anything except turn the camera off - it's not in the mass storage mode so i can't get any files.
Good enough. This tells us that whoever did the camera port correctly identified the hardware bit that gives the USB power state. It does not solve the problem but it does eliminate one possible source of the problem.
-
Hi there!
I've played with raw today a little bit. I'm using DNG. But when I try to do long exposure photos with overriding shutter speed and iso value to 80 My pictures are out of the ordinary. Well see for yourself. Anyone else experienced that?
-
can someone please tell me if i will be able to use CHDK (card locked on) with the usb cable so i can get my photos from the camera without taking out the card to unlock it everytime.. if my card is on lock position with CHDK on and i plug in my USB cable i get an error that the camera needs to shut down, because of this i always have to take my card out and unlock it.. i do this so often im thinking this could do damage to the card over time as opposed to before when i never had to take my card out.
i've tried the latest build.. the error is still there.
thanks
As far as I know there is no solution for this e41 error yet. Several people including me have reported it.
But we have to wait for a developer who can reproduce the error and has time to solve the problem.
one more thing i've noticed is that there is a huge difference between raw photos and the jpg ones from the camera, i think the camera tries to correct the photo at the edges because it is wide, so the photos aren't distorted, so this is really a great thing to have the raw photos because i'd never use the jpg's from the camera, they all look bad to me corrected like that, everything looks stretched at the edges and it seems that the videos have the same problem.. it would be a great thing if we could have the videos unstretched too! would that be possible?
i've attached 2 photos so you can see the difference between them.
thanks
Thanks for pointing out that difference. I just started using RAW. I use the DNG feature, because when i use the normal CRW, i can't open the files on the computer. Have you compiled any Scripts which you would like to share?
And how do i use the manual focus feature?. CHDK seems confusing. I've gone through the guide, but still things are unclear. The Auto Focus is starting to annoy me on this camera, its so hard to focus on a subject (that makes me wanna go out and buy a touch-focus camera :( )
-
Hi there!
I've played with raw today a little bit. I'm using DNG. But when I try to do long exposure photos with overriding shutter speed and iso value to 80 My pictures are out of the ordinary. Well see for yourself. Anyone else experienced that?
I will quote myself because I found something more with RAW. I took a picture outside without any overriding settings only DNG. And as you can see raw picture is somehow curved by the angles... which makes it useless if you can't crop it. I attached raw and jpg of the same photo.
Also I found out that the default raw photo is much more darker. Since this is my first time with RAW I can't tell if this is normal or is CHDK bug?
Another note on bad pixels. I get bad pixels in raw and I don't know if this is normal or not (again, I'm newbie with raws. Untill CHDK couldn't use it :D )
-
Forgot to attach JPG version:
Here are both:
P.S. Sorry for double post. I don't know how to add attachment in edit mode. I saw only remove attachment.
-
I just loaded up my DNG's and JPEG's, and realised there's alot of differences in the imgages !. The JPEG's are so badly distorted.DNG does seem to give a wider angle :o ! Explains why i found that a bit weird in my images. Looks like im going to be shooting DNG for a while.
By the way, any of you got the Lens Profile of photoshop for it? I'm looking for a correct lens profile for this camera.
-
ryandigweed try to shoot a long exposure photo with DNG. I tried and I got some nasty white purple don't know what picture out...
Also ryandigweed isn't DNG picture with curved angles useless? I mean I don't have PS (no money) I only have gimp + ufraw.
-
Will try to shoot some long exposures when i get it in my hands. How long? and at what ISO? That looks like its some firmware fault :( what's your firmware version?
by curved angles what do you mean by that? Curve adjustments? or actual curved/distorted images? Using Photoshop on my friends PC. Im shooting DNG because when i shoot in normal CRW mode, the resulting CRW files do not open up with anything :( and i've tried alot of softwares.
Did you try the bad pixel.bin thing? for the DNG files? Its supposed to clear up noise on the pictures, is that right?Found it too confusing :P Actually the camera isn't always with me, so then i cant try everything out :(
Keep me updated with your advancements. Im going to go to the shop one of these days to see if i can get a cheap tripod for this camera. And also some parts for a DIY USB remote cable (ive got everything except for the button )
-
ryandigweed, The long exposure was 5 seconds and ISO was 80. Night handeled scene. My firmware version (According to acid) is 100c. You can see the picture I took with long exposure a few posts above. (It's white purple picture).
By curved angles I mean like there would be wider angle. You can check 2 posts above I've posted raw and jpg comparison of pictures.
I've tried bad pixel.bin but I don't know of it's working or not. Kinda newbie here. I order a chip tripod from dealextreme for less than 1$.
-
Yeah DNG does provide a wide angle. And not a distorted one. I'm new here aswell . Thanks for sharing Dealextreme.com. I found a couple of cheap camera tripods :) Are they safe to deal with?
Yeah i saw your picture, it seems pretty weird, try an ISO like 200 or 400 and check?
-
I also bought two extra batteries http://www.miniinthebox.com/1400mah-3-7v-digital-camera-battery-nb-4l-for-canon-digital-50-40-and-more_p222021.html (http://www.miniinthebox.com/1400mah-3-7v-digital-camera-battery-nb-4l-for-canon-digital-50-40-and-more_p222021.html)
(I'm still waiting for tripods and batteries) While we are talking about gadgets and I belive this is not the topic I'll ask anyway, what case for camera would be great for ixux 220 hs? Some small case to just fit ixux 220 hs but yet protective for pressure...
If tripods are safe? I bought thisese two:
http://www.dealextreme.com/p/mini-7-inch-metallic-tripod-1308 (http://www.dealextreme.com/p/mini-7-inch-metallic-tripod-1308)
http://www.dealextreme.com/p/angle-adjustable-steel-stand-for-surveillance-security-camera-black-29603 (http://www.dealextreme.com/p/angle-adjustable-steel-stand-for-surveillance-security-camera-black-29603)
I belive first one is not so stable, but it will suffice my needs :) Second is from metal and and Is more safe :)
How can you tell my DNG is not dstorted? Also can I make DNG not wide angle in CHDK settings somewhere, or do I have to do it in gimp/ufraf? Can I disable wide angle at all in DNGs?
I've tried long exposure with ISO 400 and time 2.5 seconds Here is the resul:
When I tried to take another photo with the same settings picture were again white with purple artifacts...
-
Those look like some great add-ons ! :) can't wait to get myself one ! :)
As for your pictures, that looks really weird. I'm not sure why it's happening, but ill try doing the same with my camera and then let you know :)
-
As the vers.req file doesnt seem to work on the 220HS to see firmware, I used Exiftool (http://www.sno.phy.queensu.ca/~phil/exiftool/)to see from an image what the FW is, it said: FW Revision 1.01 rev 5.00. I assumed that to be 101e. As e is the 5th version judging from how many versions on the chdk download list.
So I installed 101e of chdk. Runs ok. But when I look at the build info in chdk, it says FW 101c vers.
So which one is the correct one? Can i try 101c chdk without damaging the camera?
Edit: Corrected spelling.
-
So I installed 101e od chdk. Runs ok. But when I look at the build info in chdk, it says FW 101c vers.
In this case, a new CHDK port wasn't needed for 101d and 101e, so those builds are just a copy of the 101c version. Sometimes Canon makes a new firmware rev to fix spelling errors or things like that, which don't impact the CHDK code. Nothing to be concerned about.
-
In this case, a new CHDK port wasn't needed for 101d and 101e, so those builds are just a copy of the 101c version. Sometimes Canon makes a new firmware rev to fix spelling errors or things like that, which don't impact the CHDK code. Nothing to be concerned about.
Great. Thanks for letting me know. :)
-
I've tried long exposure with ISO 400 and time 2.5 seconds Here is the resul:
When I tried to take another photo with the same settings picture were again white with purple artifacts...
I've tried the long exposure, for around 4 secconds at 400 ISO, and it seemed fine, just overexposed. No artifacts. but then later i wen't back to the menu and i couldnt get the long exposure to come ?! WTF. it's not comming any more, and how did you get down to 80ISO? i couldnt. :(
I'm also trying ISO 100 with no tripod or flash to shoot some shots, they're coming blurred when i'm trying to photograph an animal., can anyone tell me how to get crisp shots without the flash?. Any known good settings? Because the camera does load quite a while after i press the shutter button.
Using the motion script, i get similar results. :(
---------
Can anyone write a script, or mend the firmware to make the flash more flexible? Something a little less bright or something?.
Also is there any way to have an adjustable flash attached via usb , and have it go off when the i click either a usb shutter button, or the actual shutter button, any ideas?
-
hei guys
I have a canon 220 hs and i want to know if there is any way i could lock AE in video mode. :(
-
...Can anyone write a script, or mend the firmware to make the flash more flexible? Something a little less bright or something?.
* http://chdk.wikia.com/wiki/CHDK_User_Manual#Force_manual_flash (http://chdk.wikia.com/wiki/CHDK_User_Manual#Force_manual_flash)
* http://chdk.wikia.com/wiki/CHDK_User_Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual)
;)
Also is there any way to have an adjustable flash attached via usb
No.
CHDK doesn't let you access or control the USB port; CHDK's USB remote feature just detects the USB supply voltage...
-
Another note on bad pixels. I get bad pixels in raw and I don't know if this is normal or not (again, I'm newbie with raws. Untill CHDK couldn't use it :D )
the Script should mark those bad pixels and either override them or save their position so processing software later can remove them. second option didn't work for Camera raw (http://chdk.setepontos.com/index.php?topic=6341.msg79336#msg79336 (http://chdk.setepontos.com/index.php?topic=6341.msg79336#msg79336))
Lens Profiles:
Thanks to danistuta we have profiles & readme here:
http://chdk.setepontos.com/index.php?topic=6341.msg79233#msg79233 (http://chdk.setepontos.com/index.php?topic=6341.msg79233#msg79233)
very useful, for architecture etc. I use the Lens Profiles. For people and round objects etc. I leave the original image, so you're flexible on your needs with DNG.
-
OK, I have IXUS 220HS. I looked for CHDK for it. My question:
1. What specific features do the latest CHDK add in this camera? It is not listed anywhere.
-
1. What specific features do the latest CHDK add in this camera? It is not listed anywhere.
link> CHDK in Brief (http://chdk.wikia.com/wiki/CHDK_in_Brief)
link> CHDK User Quick Start Guide (http://chdk.wikia.com/wiki/CHDK_User_Quick_Start_Guide.pdf)
link> CHDK User Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual)
link> CHDK for Dummies (http://chdk.wikia.com/wiki/CHDK_for_Dummies)
link> CHDK Wiki FAQ (http://chdk.wikia.com/wiki/FAQ)
link> CHDK Firmware Usage (http://chdk.wikia.com/wiki/CHDK_firmware_usage)
link> CHDK Installation Guide (http://chdk.wikia.com/wiki/File:CHDK_Installation_Guide.pdf)
link> One Page Users Guide (http://chdk.wikia.com/wiki/One_Page_Ultra-Quick_Users_Guide)
-
1. What specific features do the latest CHDK add in this camera? It is not listed anywhere.
link> CHDK in Brief (http://chdk.wikia.com/wiki/CHDK_in_Brief)
link> CHDK User Quick Start Guide (http://chdk.wikia.com/wiki/CHDK_User_Quick_Start_Guide.pdf)
link> CHDK User Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual)
link> CHDK for Dummies (http://chdk.wikia.com/wiki/CHDK_for_Dummies)
link> CHDK Wiki FAQ (http://chdk.wikia.com/wiki/FAQ)
link> CHDK Firmware Usage (http://chdk.wikia.com/wiki/CHDK_firmware_usage)
link> CHDK Installation Guide (http://chdk.wikia.com/wiki/File:CHDK_Installation_Guide.pdf)
link> One Page Users Guide (http://chdk.wikia.com/wiki/One_Page_Ultra-Quick_Users_Guide)
I read that. It says Ultra-long & Ultra-fast shutter speeds will be got. But my question again is specific to this model:
1. How much fast & long shutter speed will I get? Value.
2. How will I user the Tv/Av exposures?
-
Are 16gb cards useable on the Ixus 220 HS? I partitioned it to fat and at 2MB for chdk, and the rest as fat 32. Chkdk loads, but camera says insufficient space so its not pointing to the larger partition.
Am I being too impatient as this is alpha build after all? :D
-
Are 16gb cards useable on the Ixus 220 HS?
Yes.
The ELPH300 can boot from FAT32 partitions, so partitioning the card is not necessary (and also not supported).
... - cameras released this year can autoboot CHDK from FAT32 partitioned cards.
If the port has been done correcly you should be able to set up autoboot from within CHDK:
- format the card in the camera
- copy the full build to the card
- lock the card and perform a manual boot (Firm Update...)
- Select 'Make Card Bootable' from the 'Miscellanous stuff' menu
- Restart the camera
-
Cool. I assumed it wouldnt work as I used chdk on a Canon S95 before and it needed to be dual partitioned etc. Many thanks. This is much easier!
-
I've tried the long exposure, for around 4 secconds at 400 ISO, and it seemed fine, just overexposed. No artifacts.
What firmware version do you have? I have 100c and as you saw it's ugly :(
but then later i wen't back to the menu and i couldnt get the long exposure to come ?! WTF. it's not comming any more, and how did you get down to 80ISO? i couldnt. :(
Again what version of firmware do you have? After reboot I have to Enabled Overrides in Extra photo Operations. Also I have to set Valuve factor to 1 in order for Override shutter speed to work. I set ISO to 80 Like this in Extra Photo Operations:
Override ISO Value: 8
Value Factor: 10
Then you see in gray orange that ISO is 80.
the Script should mark those bad pixels and either override them or save their position so processing software later can remove them. second option didn't work for Camera raw
What script?
Lens Profiles:
Thanks to danistuta we have profiles & readme here:
http://chdk.setepontos.com/index.php?topic=6341.msg79233#msg79233 (http://chdk.setepontos.com/index.php?topic=6341.msg79233#msg79233)
Hm since I use gimp + ufraw I'll have to find a way to include those profiles in gimp.
Can someone cofirm with version 100c that when shooting long exposures and dng enabled the picture is like mine in the attachment? (Or am I the only one with this weird problem?)
-
Hi,
Just got a loan of this camera. Firmware 101a. When I checked (in lib.c)
void *vid_get_viewport_fb_d()
{
//FF06C580 dword_FF06C580 DCD 0x3C70
//FF06D300 STR R12, [R5,#0x58
return (void*)(*(int*)(0x3C70+0x58));
}
in my tests this always returns 0. So I think the address may be wrong.
Has anyone else checked this? This is the play viewport address. As far as I know it only affects
the edge overlay in play mode. Probably not an often used feature. I use it to display stereo pairs in
play mode.
I know that someone (reyalp?) worked some magic (without even having the camera) for the SX150 and found out the right address. What did he do? I'd like to know that and would like to fix this.
EDIT:
Found it. The address should be 0x2C60. Found it by searching memory for two adjacent addresses pointing to the same memory address that was in a reasonable range: 0x40xxxxxx. I took the higher address.
Jon
-
Hi,
Now that I know the play viewport address I still have a problem: not enough buttons on the camera! I want to use the func/set button in play mode, but Canon uses that for erase in this camera. So my idea is to do the following: the camera has a switch in the upper right that switches between auto and non-auto mode when in record mode. I don't think it does anything in play mode. So I would like to use that switch like a button in play mode. Anyone know how to sense the position of that switch? I want to sense that it has changed twice within some small amount of time. Any suggestions on how to do that?
Thanks,
Jon
-
Hi,
Another correction to the port: From stubs_entry.S:
//DEF(recreview_hold ,0x00003828) // Found @0xff8a6510, ** != ** stubs_min = 0x000094c4 (0x93D4+0xF0)
stubs_min should be edited to the correct value:DEF(recreview_hold, 0x3828)
Jon
-
Found it. The address should be 0x2C60. Found it by searching memory for two adjacent addresses pointing to the same memory address that was in a reasonable range: 0x40xxxxxx. I took the higher address.
Looks good to me (from firmware 1.00c):
ROM:FF878880 LDR R5, =0x2C08
....
ROM:FF8788B8 STR R12, [R5,#0x58]
0x2C08 + 0x58 = 0x2C60
Hi,
Now that I know the play viewport address I still have a problem: not enough buttons on the camera! I want to use the func/set button in play mode, but Canon uses that for erase in this camera. So my idea is to do the following: the camera has a switch in the upper right that switches between auto and non-auto mode when in record mode. I don't think it does anything in play mode. So I would like to use that switch like a button in play mode. Anyone know how to sense the position of that switch? I want to sense that it has changed twice within some small amount of time. Any suggestions on how to do that?
You can enable display of the phsyw_status values in the gui_draw_debug_vals_osd() function in gui.c.
From this you can determine which bit(s) are used for the switch status. This is the easy part.
You will then need to add custom code to platform/ixus220_elph300hs/kbd.c that detects the change you want to trigger on, and then returns a standard KEY_xxx value to the rest of the CHDK code. This is the hard part :)
Phil.
-
Thanks Phil,
I followed your suggestion and found the bit: physw_status[2] & 0x002000
Jon
You can enable display of the phsyw_status values in the gui_draw_debug_vals_osd() function in gui.c.
From this you can determine which bit(s) are used for the switch status. This is the easy part.
Phil.
-
Can somebody help me?
I have a canon ELPH 300hs/IXUS 220hs and i want to know if there is any way i could lock AE in video mode.
-
Is it possible to lock the exposure in movie mode?
if there is any way i could lock AE in video mode.
You don't need CHDK to do this.
In P mode (not Auto), half press the shutter button and hold it, then press the macro button.
You will then get "AFL" in the top right of your display, which means focus is locked.
-
"In P mode (not Auto), half press the shutter button and hold it, then press the macro button."
Thats for focus, not exposure locking. For exposure, half press shutter and press the +/- box on the round button. Youll see AEL on the screen.
Hope that helps.
Edit: Also need to be in P mode.
-
"In P mode (not Auto), half press the shutter button and hold it, then press the macro button."
Thats for focus, not exposure locking. For exposure, half press shutter and press the +/- box on the round button. Youll see AEL on the screen.
Hope that helps.
Edit: Also need to be in P mode.
Oops! I read NicoDiac's AE as AF :-[
Then went onto ask the same question. I've had a long day!
Seems like pressing +/- doesn't work in video mode though.
I get AEL on the screen, but when I hit the red video button, AEL disappears, and the exposure still jumps around when I move from light to dark scenes.
-
Seems like pressing +/- doesn't work in video mode though.
Yeh, I noticed that too. Such a shame. Hoping chdk can sort that out soon! ;)
-
Hi,
I just got a new elph300, but this time 101.g. I notice that it does not save raw. It takes a picture normally but then nothing happens, no file is saved. If I try to run the bad pixel script nothing happens, no pictures are taken.
Jon
-
Hi,
I just got a new elph300, but this time 101.g. I notice that it does not save raw. It takes a picture normally but then nothing happens, no file is saved. If I try to run the bad pixel script nothing happens, no pictures are taken.
Jon
Do the Tv, Av and ISO overrides work?
(This will determine if capt_seq_task is running in CHDK.)
Phil.
-
Hi,
The shutter override works.
Jon
-
Hi,
The shutter override works.
Jon
What about aperture and ISO?
Does the CHDK splash screen appear quickly at startup or is there a 4 second delay?
Phil.
-
ND filter and ISO overrides work. Splash screen shows with no delay.
Jon
What about aperture and ISO?
Does the CHDK splash screen appear quickly at startup or is there a 4 second delay?
Phil.
-
ND filter and ISO overrides work. Splash screen shows with no delay.
Jon
What about aperture and ISO?
Does the CHDK splash screen appear quickly at startup or is there a 4 second delay?
Phil.
I'm stumped, previous posts show it works on other cameras, and I can't see anything obvious wrong with the code.
Phil.
-
My Humble Apologies,
It works fine. I had not realized that the raw file was being saved in a different directory. Also this camera is very fast to save raws, maybe in less than 2 sec. I think the badpixel.bin routine failed because I had the camera set in review-hold mode. It works fine if the review is set to 2 sec.
Sorry to have wasted your time.
Jon
I'm stumped, previous posts show it works on other cameras, and I can't see anything obvious wrong with the code.
Phil.
-
What about aperture and ISO?
Id like to know this for Aperture. I cant see an entry for Av (Aperture) anywhere in chdk on the camera. I can change shutter speed and ISO.
-
What about aperture and ISO?
Id like to know this for Aperture. I cant see an entry for Av (Aperture) anywhere in chdk on the camera. I can change shutter speed and ISO.
This cam (like most ixus/elph models) does not have an iris diaphragm, but uses a Neutral Density filter,
which you can control in CHDK menu Extra Photo Operations -> ND filter state, options are:
[off] -> auto, set by Canon
[in] -> CHDK makes sure the filter is used
[out] -> CHDK makes sure the filter is NOT used
Note that your effective Av will also be influenced by your zoom position.
HTH,
wim
-
Really? Thats a shame. Seems an odd way of setting "aperture".
-
Really? Thats a shame. Seems an odd way of setting "aperture".
odd = cheap
-
It works Good when you get use to it.......
-
can anyone confirm if the sunsetF16 script will run on the latest build?
I am just waiting for a good deal on a new SD card before I can try it...
-
I am just waiting for a good deal on a new SD card before I can try it...
ummm .. so I have to ask ... why not try it on a crufty & cheap old SD card first to see how far you get ? ... this is a hacker community after-all .. and the sunsetFxx scripts are very elaborate so any recent feedback will be well received in the CHDK community
-
I am just waiting for a good deal on a new SD card before I can try it...
ummm .. so I have to ask ... why not try it on a crufty & cheap old SD card first to see how far you get ? ... this is a hacker community after-all .. and the sunsetFxx scripts are very elaborate so any recent feedback will be well received in the CHDK community
yeah fair enough :) had some time today so dug out an old card i didnt need. the sunsetf16.lua script seems to work pretty well once all required lualib files are in place and script settings are in place.
-
Error E41 and camera shuts down when plugging elph300hs 101a to usb with chdk running. ideas?
-
issue seems related to this: http://trac.assembla.com/chdk/browser/trunk/platform/ixus220_elph300hs/kbd.c?rev=1684#L135 (http://trac.assembla.com/chdk/browser/trunk/platform/ixus220_elph300hs/kbd.c?rev=1684#L135)
(i got the problem also with the autobuild version)
-
tried with trunk and autobuild, issue persists. i get the same behaviour by simply connecting the 5v usb so i think we can rule out the ptp part from the issue..
kbd&usb..mmm
-
edit: my bad, i've been trying the whole day and restoring "stock" wrap_kbd_p1_f() makes the thing work. so the problem is definitely inside my_kbd_read_keys()
-
after losing a day, i think i can say this diff fixes the E41 error: excuse the big diff but i restarted the port from scratch to be sure i wasn't missing anything and due to the style difference i am too lazy to check where the tiny diff is.
i suspect it's bot the KEYS0 value and some wrong address in boot.c
please try it out and see if it works for you (firmware 101a): http://pastebin.com/210H2Tn9 (http://pastebin.com/210H2Tn9)
-
after losing a day, i think i can say this diff fixes the E41 error: excuse the big diff but i restarted the port from scratch to be sure i wasn't missing anything and due to the style difference i am too lazy to check where the tiny diff is.
i suspect it's bot the KEYS0 value and some wrong address in boot.c
please try it out and see if it works for you (firmware 101a): http://pastebin.com/210H2Tn9 (http://pastebin.com/210H2Tn9)
You've managed to find a typo in boot.c . I think that was the cause of the E41 trouble. KEYS_MASK0 should only affect things when in ALT mode, so I left it out from the patch (http://chdk.setepontos.com/index.php?topic=650.msg81798#msg81798). Can you please retest the stable release with that patch?
I took a quick look at the port's kbd.c, and unfortunately it looks like it contains some mistakes (IMHO). There aren't any buttons defined that would be related to physw_status[0], yet KEYS_MASK0 is not 0 and physw_status[0] is getting messed with instead of physw_status[2]. I don't think this is correct. Same goes for the Ixus230 port.
-
yup, i noticed that that too, i corrected the keymask0 because i thought it was sort of related to play mode..but i really didn't know what was happening in there. that's probably because of some copypaste (?)
however, thanks for finding the difference, i'll try trunk asap - out of curiosity did you inspect code visually or you just did some regexp magic? if that's the case, i should really learn how to master them, oh well.. :)
-
tested latest trunk, it works :)
-
Hi all,
I am new in CHDK and I must say that I bought this camera only because it was possible to generate RAW file with the CHDK firmware...
I tried to use the DNG conversion for RAW. I succeeded to create the badpixel.bin (14244 badpixels) but when I compared the result between the DNG loaded in Lightroom and the direct JPEG output, the DNG still have badpixels while the JPEG is clean?
The badpixel.bin was generated in the camera at different iso levels, but always exactly the same number of badpixels. Did it happen for anyone else? Is it due to a wrong usage of DNG?
Thank you for your help.
-
Hi,
I was able to successfully create badpixel.bin and take raw files. (See above for my unfortunate wasting of Phil's time).
Jon
Hi all,
I am new in CHDK and I must say that I bought this camera only because it was possible to generate RAW file with the CHDK firmware...
I tried to use the DNG conversion for RAW. I succeeded to create the badpixel.bin (14244 badpixels) but when I compared the result between the DNG loaded in Lightroom and the direct JPEG output, the DNG still have badpixels while the JPEG is clean?
The badpixel.bin was generated in the camera at different iso levels, but always exactly the same number of badpixels. Did it happen for anyone else? Is it due to a wrong usage of DNG?
Thank you for your help.
-
Hi,
I was able to successfully create badpixel.bin and take raw files. (See above for my unfortunate wasting of Phil's time).
Jon
Hi Jon,
Not sure to understand, but in my case I also succedded to create the DNG. The issue I have is that I still have the bad pixels in the DNG when I open it in Lightroom and the same image in Jpeg is totally clean...
Thanks again.
-
Hi,
I was able to successfully create badpixel.bin and take raw files. (See above for my unfortunate wasting of Phil's time).
Jon
Hi Jon,
Not sure to understand, but in my case I also succedded to create the DNG. The issue I have is that I still have the bad pixels in the DNG when I open it in Lightroom and the same image in Jpeg is totally clean...
Thanks again.
Are you talking about bad pixels or noise?
Post a 100% crop from a sample image showing the problem.
Phil.
-
Hi,
I was able to successfully create badpixel.bin and take raw files. (See above for my unfortunate wasting of Phil's time).
Jon
Hi Jon,
Not sure to understand, but in my case I also succedded to create the DNG. The issue I have is that I still have the bad pixels in the DNG when I open it in Lightroom and the same image in Jpeg is totally clean...
Thanks again.
Are you talking about bad pixels or noise?
Post a 100% crop from a sample image showing the problem.
Phil.
Hi Phil,
I am talking about bad pixels. Here is a crop of the DNG and JPEG. Photo was taken at 100 iso.
-
Hi Phil,
I am talking about bad pixels. Here is a crop of the DNG and JPEG. Photo was taken at 100 iso.
Set the camera to the highest ISO, zoom to the max optical telephoto position and try creating the badpixel file again.
If that still doesn't work, upload the DNG and badpixel.bin file to a file share and post the link here.
Phil.
-
"Minority bug report"
Hi,
first of all thank you for the great work you are doing. i`m using an older ixus with chdk for years now and it works fabulous, especially the autoiso-function. i recommended the elph300hs to a friend of mine and because his son can`t stand still for a 1/60th of a second i installed your alpha-version of chdk but enabling the auto-iso function will lead to a systemcrash (vers. 101a-1.0.0-1659-full_ALPHA).
Just for the bug-collection... maybe someone of you is willing and has got the muse to have a look at it...
thank you all..
ray
-
Hi Phil,
I am talking about bad pixels. Here is a crop of the DNG and JPEG. Photo was taken at 100 iso.
Set the camera to the highest ISO, zoom to the max optical telephoto position and try creating the badpixel file again.
If that still doesn't work, upload the DNG and badpixel.bin file to a file share and post the link here.
Phil.
Hi Phil,
Still same issue. I tried to create the badpixel.bin in the dark but also in normal conditions but still badpixels in DNG... I posted the badpixels file, the DNG and JPEG here:
http://aesparza.free.fr/issue%20elph%20300%20chdk/ (http://aesparza.free.fr/issue%20elph%20300%20chdk/)
Thank you for your help.
David
-
out of curiosity did you inspect code visually
:) /usr/bin/patch failed on boot.c, had to use a visual comparison tool or you just did some regexp magic? if that's the case, i should really learn how to master them, oh well.. :)
I usually use some regexp's when formatting code, but only in an editor :)
Thanks for the feedback. You may hack on that kbd.c when you're bored. :D
-
Still same issue. I tried to create the badpixel.bin in the dark but also in normal conditions but still badpixels in DNG... I posted the badpixels file, the DNG and JPEG here:
http://aesparza.free.fr/issue%20elph%20300%20chdk/ (http://aesparza.free.fr/issue%20elph%20300%20chdk/)
Thanks for the files.
It looks like these bad pixels have a value > 0 - the current code assumes all bad pixels will have a value of 0 in the raw sensor data.
Let me know which firmware version you have and I'll post a test version to try.
Phil.
-
Hi Phil,
The firmware version is 101g (checked with your ExifTool).
I can not use the Func/Disp option to get the real firmware like explained in the wiki....
Thanks.
David
-
Hi Phil,
The firmware version is 101g (checked with your ExifTool).
I can not use the Func/Disp option to get the real firmware like explained in the wiki....
Thanks.
David
Try this version.
Phil.
-
Hi Phil,
The firmware version is 101g (checked with your ExifTool).
I can not use the Func/Disp option to get the real firmware like explained in the wiki....
Thanks.
David
Try this version.
Phil.
Hi Phil,
Just tried and now it is fine with the DNG. :)
Thanks.
David
-
Hi Phil,
Just tried and now it is fine with the DNG. :)
Thanks.
David
I've added the fix to the SVN repository. It should be in the autobuild version in a little while.
Phil.
-
Hi there :) Again thanks to all the people who makes this camera more and more great as it is :) Thank you all!
I just found after plugging the usb cable into camera with lock mode on error:
"A camera error was detected. Will shut down automatically. Restart camera. Eror E41"
I saw a few posts above user c10ud found out what cause this and he apperantly solve it? My question is: is this issue solved for 100c version?
My current CHDK version: 1.00-1651 firmware 100c. I saw on autobuild: ixus220_elph300hs-100c-1.0.0-1699_ALPHA.zip does this version solve this issue?
The reason I'm asking this is because I'd like to try ptpcam for this camera.
Thanx!
-
With chhdk, possible put screen off during video recording? Thanks.
-
With chhdk, possible put screen off during video recording? Thanks.
You may be able to turn off the backlight with set_backlight in script. You can probably also disable it by plugging in the video out cable.
If you are looking to save battery, neither of these will help much. If you want to avoid stray light from the display, it may do what you want.
-
I'd like to put off my display to save battery, any way to do this? Thanks.
-
I've added the fix to the SVN repository. It should be in the autobuild version in a little while.
Come on guys, pay a little more attention when commiting sources - they getting worse and worse with a time... :(
Badpixel patching in a raw.c is wrong after this update, and even before this update it was broken for a long time, reported but noone wants to fix it - should be patched too.
248 void patch_bad_pixel(unsigned int x,unsigned int y) {
249 int sum=0;
250 int nzero=0;
251 int i,j;
252 int val;
253 if ((x>=2) && (x<camera_sensor.raw_rowpix-2) && (y>=2) && (y<camera_sensor.raw_rows-2)) {
254 if ((conf.bad_pixel_removal==1) || (conf.save_raw && conf.dng_raw)) { // interpolation or DNG saving
255 for (i=-2; i<=2; i+=2)
256 for (j=-2; j<=2; j+=2)
257 if ((i!=0) && (j!=0)) {
// Wrong!! Should be OR, not AND - just draw a CFA pattern and check out
257 if ((i!=0) || (j!=0)) {
258 val=get_raw_pixel(x+i, y+j);
259 if (val) {sum+=val; nzero++;}
// Wrong!! Should check for DNG_BADPIXEL_VALUE_LIMIT, not for zero. And possibly rename nzero too.
259 if (val>DNG_BADPIXEL_VALUE_LIMIT) {sum+=val; nzero++;}
260 }
261 if (nzero) set_raw_pixel(x,y,sum/nzero);
262 } else if (conf.bad_pixel_removal==2) // or this makes RAW converter (internal/external)
263 set_raw_pixel(x,y,0);
264 }
265 }
And the whole process is not optimal for the badpixels in a GREEN channel.
Draw CFA pattern to checkout - there are GREEN pixels closer to broken one than pixels that are used for patching (diagonal pixels).
-
Come on guys, pay a little more attention when commiting sources - they getting worse and worse with a time... :(
Statements like this will only serve to annoy the people who actively contribute to CHDK, and may get you banned. Try being more polite and less insulting in future.
Badpixel patching in a raw.c is wrong after this update, and even before this update it was broken for a long time, reported but noone wants to fix it - should be patched too.
Was a patch submitted to the appropriate topic? I don't recall seeing one.
Occasionally patches will get missed, so just post a polite reminder.
248 void patch_bad_pixel(unsigned int x,unsigned int y) {
249 int sum=0;
250 int nzero=0;
251 int i,j;
252 int val;
253 if ((x>=2) && (x<camera_sensor.raw_rowpix-2) && (y>=2) && (y<camera_sensor.raw_rows-2)) {
254 if ((conf.bad_pixel_removal==1) || (conf.save_raw && conf.dng_raw)) { // interpolation or DNG saving
255 for (i=-2; i<=2; i+=2)
256 for (j=-2; j<=2; j+=2)
257 if ((i!=0) && (j!=0)) {
// Wrong!! Should be OR, not AND - just draw a CFA pattern and check out
257 if ((i!=0) || (j!=0)) {
258 val=get_raw_pixel(x+i, y+j);
259 if (val) {sum+=val; nzero++;}
// Wrong!! Should check for DNG_BADPIXEL_VALUE_LIMIT, not for zero. And possibly rename nzero too.
259 if (val>DNG_BADPIXEL_VALUE_LIMIT) {sum+=val; nzero++;}
260 }
261 if (nzero) set_raw_pixel(x,y,sum/nzero);
262 } else if (conf.bad_pixel_removal==2) // or this makes RAW converter (internal/external)
263 set_raw_pixel(x,y,0);
264 }
265 }
And the whole process is not optimal for the badpixels in a GREEN channel.
Draw CFA pattern to checkout - there are GREEN pixels closer to broken one than pixels that are used for patching (diagonal pixels).
While this may not be the way you would do it, it works.
I did not write the original; but I understand the logic behind it and don't see an issue.
The code samples the four pixels of the same color diagonally at offsets -2 and +2 from the original.
For red and blue these are the nearest pixels diagonally.
Your change (line 257) forces it to also sample the pixels vertically and horizontally but this would be slower (averaging 8 pixels instead of 4) and often the bad pixels are clustered in horizontal or vertical lines.
Sampling the diagonals is a good compromise.
For the green channel there are closer pixels at offsets of -1 and +1 from the original. The problem is that this would significantly increase the code complexity (handling green differently from red and blue), and also requires different code paths for the two CFA patterns. These closer pixels are also more likely to also be bad, so again the existing code is a reasonable compromise.
The change on line 259 to use DNG_BADPIXEL_VALUE_LIMIT is technically correct; but in practice probably won't make any difference to the result (the majority of sampled pixels are not bad).
Phil.
-
Statements like this will only serve to annoy the people who actively contribute to CHDK, and may get you banned. Try being more polite and less insulting in future.
Ok, sorry.
I didn't want to offend anyone, maybe I need to be more restrained in the future.
Sorry once more.
-
first of all thank you for the great work you are doing. i`m using an older ixus with chdk for years now and it works fabulous, especially the autoiso-function. i recommended the elph300hs to a friend of mine and because his son can`t stand still for a 1/60th of a second i installed your alpha-version of chdk but enabling the auto-iso function will lead to a systemcrash (vers. 101a-1.0.0-1659-full_ALPHA).
I've got the same camera and I can't reproduce the crash (using build 1699). Can you provide a bit more detail on how you reproduce this--what mode the camera is in beforehand, and what sequence of menu items you go through to get there?
It would also be helpful if you could attach a crash log. In the CHDK menu, go to Miscellaneous Stuff -> Debug parameters -> Save ROM crash log, then grab the ROMLOG.LOG file from your SD card and attach it to a post here.
(Actually, enabling the custom auto ISO function does not seem to do anything at all for me; auto ISO does not respect the boundaries I put in - but I admit I haven't seen a use for this; the "kids and pets" scene mode may be all your friend really needs here...)
-
Thanks so much for all of the hard work on this CHDK.... I am wondering if there is a way to shut off auto exposure on video recording? I would like to start a video recording and not have it fluctuating with shutter, iso and aperture changes if possible?
(AE Lock)
Thanks in advance...
-
First, many thanks to the those that spend the time making toys like this to keep me entertained in retirement. Thank you again for the time spent on this forum helping folks solve their issues. My small one is only on the Elph300, now using 101g-1699. Under no circumstances can I turn off DFS (Dark Frame Subtraction) like I can with my A560, even with all settings identical. My question is if DFS is a known issue with the Elph300HS or does anybody else have it turned off with FW 1.01g in which case its likely my user error? I love the camera for its 24mm width but can't shoot at night yet.
Because a search did not bring it up I tend to think its me error and it works different than the A560 CHDK.
Thanks all!
-
Oh and I forgot to mention that it is commonly believed that you can lock AE during video by half pressing the shutter button and then clicking the +/- button. It does not work for video. Once you start the video the AE lock disengages and goes to auto expose. Is there any way to lock it?
Thanks in advance....
-
It seems that I am getting a jpg and a raw file when I am shooting raw. Is this normal? Is anyone else noticing this?
-
It seems that I am getting a jpg and a raw file when I am shooting raw. Is this normal? Is anyone else noticing this?
Perfectly normal. CHDK saves the RAW files and the Canon firmware saves the JPG's.
-
It seems that I am getting a jpg and a raw file when I am shooting raw. Is this normal? Is anyone else noticing this?
Thats the way it works with my Elph300HS and the latest CHDK.
-
It seems that I am getting a jpg and a raw file when I am shooting raw. Is this normal? Is anyone else noticing this?
Perfectly normal. CHDK saves the RAW files and the Canon firmware saves the JPG's.
Another question quickly answered. Now can anybody tell me if they are successfully turning OFF dark frame subtraction on the Elph300 or if its just not built yet into our Alpha version?
-
Thanks for the quick responses... Also would it be possible to lock ae while shooting video through a script? I haven't looked into the scripting, but I would like to know if this would even be possible before starting.
Also just to let everyone know, the video is coming out superbly with the new CHDK. I am getting video data rates of 95 Mbit/sec which is very good!!
Thanks again for all of the help and all of the hard work!
-
Elph300, now using 101g-1699
Now can anybody tell me if they are successfully turning OFF dark frame subtraction on the Elph300 or if its just not built yet into our Alpha version?
Try this build: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB (http://www.zshare.net/download/993085410dde5181/).
If it's working then all firmware versions can switch to the nrflag address finsig_dryos has found.
-
Try this build: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB (http://www.zshare.net/download/993085410dde5181/).
If it's working then all firmware versions can switch to the nrflag address finsig_dryos has found.
Ok, got and about to go play. Its only the DISKBOOT file.
Thanks much and will report back shortly.
-
Try this build: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB (http://www.zshare.net/download/993085410dde5181/).
If it's working then all firmware versions can switch to the nrflag address finsig_dryos has found.
No Joy. Still can't make this cute little camera take a 10sec shot in less than 20sec. Thanks for the try!
-
No Joy. Still can't make this cute little camera take a 10sec shot in less than 20sec.
The code required for setting the "nrflag" was not present, no wonder it didn't work. Here's the next try: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB (http://www.zshare.net/download/99321074bd2cb828/)
Tech. details (only for this fw rev):
Index: platform/ixus220_elph300hs/sub/101g/capt_seq.c
===================================================================
--- platform/ixus220_elph300hs/sub/101g/capt_seq.c (revision 1715)
+++ platform/ixus220_elph300hs/sub/101g/capt_seq.c (working copy)
@@ -2,7 +2,7 @@
#include "platform.h"
#include "core.h"
-static long *nrflag = (long*)(0x7514+0x8); // FF18775C & FF1877C8
+static long *nrflag = (long*)(0x7200+0x08);
#define NR_AUTO (0) // have to explictly reset value back to 0 to enable auto
#define PAUSE_FOR_FILE_COUNTER 100 // Enable delay in capt_seq_hook_raw_here to ensure file counter is updated
@@ -101,6 +101,7 @@
// jump table entry 1
"loc_FF882A14: \n"
+" BL capt_seq_hook_set_nr\n" // + (as in Ixus310)
" LDR R8, [R0,#0xC] \n"
" MOV R0, R8 \n"
-
The code required for setting the "nrflag" was not present, no wonder it didn't work. Here's the next try: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB (http://www.zshare.net/download/99321074bd2cb828/)
So close yet so far. OK, first the good news - I got some long shots without DFS. Bad news - I can only get 3 with the intervalometer before it reverts to DFS. From then on all shots >1sec have DFS until I reboot and reload script. If I start fresh after loading CHDK, I can take a single shot without <alt> turned on and will have no DFS but everything after that will have it on. In the old days I would guessed that......oh nevermind. Punched IBM cards can't fit in the camera anyway :P.
Tried every combo of mode (Program mode was consistant) and changes in the CHDK menu to save or not save parms but that made no difference. So whatever code you added also adds functionality to turn off DFS but only for 1 shot (not under a script) or 3 shots (running intervalometer). Because I have it running on a A560 I feel the issue is not the setup unless the two bodies need DIFFERENT setup parms.
At least its close enough I can see light at the end and am in no hurry to buy some other camera where its already working. Sure wish I understood the internals well enough to debug this.....sigh. Lost my techie card long ago. Thank you for getting it almost there. One more push maybe.
-
- I can only get 3 with the intervalometer before it reverts to DFS. From then on all shots >1sec have DFS until I reboot and reload script. If I start fresh after loading CHDK, I can take a single shot without <alt> turned on and will have no DFS but everything after that will have it on.
Do (some of the) other overrides also work like that, or is it just the dark frame setting?
Anyway, I've relocated the dark frame override call, here's the third try: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB (http://www.zshare.net/download/9932701461f04f2a/)
-
Do (some of the) other overrides also work like that, or is it just the dark frame setting?
Anyway, I've relocated the dark frame override call, here's the third try: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB (http://www.zshare.net/download/9932701461f04f2a/)
Hey! Thanks for jumping in so fast again. No, the other overrides all are stable although its been trial and error on some to nail the values....for example ISO i have set at "1" with a "100" factor but often get 160. A "2" gives me "320" in the EXIF. I have no complaints there as its consistant and just needs to be remembered. Anyway, will try your latest and repost in 15min. As always, many thanks.
-
Report on DFS function -
The news just keeps getting better. Now, if I go straight to Program mode and run the Interval.lua with a 20sec exposure I just ran it 20x twice without a twitch. Wonderful work SRSA_4c (if I may be so formal with your name). Noticed 2 things out of the ordinary: first, any exposure greater than 15" still shows up in the display and EXIF as 15". Not sure yet if that has any side affects. Also if i shoot with <alt> turned off (need a better term for this) then I still get one shot without DFS before it kicks in again. It then also hoses the script with <alt> back on such that I got (this is weird) a single DFS delay on the 16th frame of 20, then the script hung on frame 20. I guess something else could have given the BUSY sign thats when i moved shutter from 4sec to 20sec to make sure it wasnt just a full buffer or something. So anyway, the most important function for me is to shoot long shots with the intervalometer and YOU DID IT!
Wish i was still involved enough to understand the binaries you keep posting and how to do the programming but guess I will be lucky to make a few script mods that dont smoke the camera.
Many thanks for resolving the only thing in the world keeping me from shooting 24mm wide star trails instead of 35mm not so wides.
-
Just ONE more item that jumped w/r to DFS;
Flash must be turned off or DFS runs regardless of settings. This is important when using low output flash to light some foreground (statue, trees) when making a timelapse video or star trails.
Hey, can I help any dev out by running some scripted (formal) testing?
-
Good to hear it mostly works. But since the behaviour of this override is so inconsistent, it's not good enough for official inclusion into CHDK. Hopefully some developer (who actually has access to this camera) turns up, and completes this feature. I only started implementing this because it seemed simple :-)
Also if i shoot with <alt> turned off (need a better term for this) then I still get one shot without DFS before it kicks in again.
Have you tried to change the dark frame override (to something else) after this happened? (I mean like: set it back to auto -> take a picture -> set nr off -> take a picture). Pretty weird behaviour btw.
The lockup of the script is probably caused by the use of the shoot() command. This command checks for certain conditions before it takes a shot. When some of these is not fullfilled, it just waits...
The keypress-based shooting sequence used in shoot.lua (also part of the standard CHDK package) may help.
Wish i was still involved enough to understand the binaries you keep posting
I publish my changes to document what I did (and to give a clue to the next person who will look into this).
Flash must be turned off or DFS runs regardless of settings.
My guess is that the camera's decision about this subtraction is a bit more complicated. What happens when you disable flash and enable the CHDK forced flash override?
any exposure greater than 15" still shows up in the display and EXIF as 15"
CHDK doesn't (yet) affect the Exif data, so that's normal (the firmware doesn't expect longer exposures).
for example ISO i have set at "1" with a "100" factor but often get 160
http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_ISO_value (http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_ISO_value)
One more thing: does the lockup with interval.lua only happen when you pause the running script (by exiting ALT mode), take pictures by hand, and try to resume by entering ALT mode again? If so, does it happen with the official release?
The third try was made with these changes:
Index: platform/ixus220_elph300hs/sub/101g/capt_seq.c
===================================================================
--- platform/ixus220_elph300hs/sub/101g/capt_seq.c (revision 1715)
+++ platform/ixus220_elph300hs/sub/101g/capt_seq.c (working copy)
@@ -2,7 +2,7 @@
#include "platform.h"
#include "core.h"
-static long *nrflag = (long*)(0x7514+0x8); // FF18775C & FF1877C8
+static long *nrflag = (long*)(0x7200+0x08);
#define NR_AUTO (0) // have to explictly reset value back to 0 to enable auto
#define PAUSE_FOR_FILE_COUNTER 100 // Enable delay in capt_seq_hook_raw_here to ensure file counter is updated
@@ -104,7 +104,7 @@
" LDR R8, [R0,#0xC] \n"
" MOV R0, R8 \n"
-" BL sub_FF98B018 \n"
+" BL sub_FF98B018_my \n" // ->
" BL capt_seq_hook_raw_here\n" // added
@@ -333,6 +333,116 @@
);
}
+
+
+void __attribute__((naked,noinline)) sub_FF98B018_my( ) {
+asm volatile (
+ " STMFD SP!, {R3-R7,LR}\n"
+ " LDR R5, =0x3D48C\n"
+ " MOV R4, R0\n"
+ " LDR R0, [R5, #0x28]\n"
+ " LDR R7, =0x820C\n"
+ " CMP R0, #0\n"
+ " MOV R6, #0\n"
+ " BNE loc_FF98B0A8\n"
+ " LDR R0, [R5, #0xBC]\n"
+ " CMP R0, #1\n"
+ " BNE loc_FF98B090\n"
+ " LDRH R0, [R5]\n"
+ " CMP R0, R7\n"
+ " LDRNEH R0, [R5, #0x96]\n"
+ " CMPNE R0, #3\n"
+ " LDRNE R0, [R4, #8]\n"
+ " CMPNE R0, #1\n"
+ " BLS loc_FF98B074\n"
+ " BL sub_FF832D6C\n"
+ " TST R0, #1\n"
+ " BEQ loc_FF98B0A8\n"
+ " BL sub_FF888708\n"
+ " B loc_FF98B0A0\n"
+"loc_FF98B074:\n"
+ " MOV R0, #0xC\n"
+ " BL sub_FF8886A0\n"
+ " TST R0, #1\n"
+ " BEQ loc_FF98B0A8\n"
+ " BL sub_FF98B84C\n"
+ " BL sub_FF8807AC\n"
+ " B loc_FF98B0A0\n"
+"loc_FF98B090:\n"
+ " MOV R0, #0xC\n"
+ " BL sub_FF8886A0\n"
+ " TST R0, #1\n"
+ " BEQ loc_FF98B0A8\n"
+"loc_FF98B0A0:\n"
+ " MOV R0, #1\n"
+ " LDMFD SP!, {R3-R7,PC}\n"
+"loc_FF98B0A8:\n"
+ " BL sub_FF88318C\n"
+ " LDR R0, [R5, #0x28]\n"
+ " CMP R0, #0\n"
+ " BNE loc_FF98B170\n"
+ " MOV R0, R4\n"
+ " BL sub_FF98A948\n"
+ " TST R0, #1\n"
+ " LDMNEFD SP!, {R3-R7,PC}\n"
+ " MOV R0, R4\n"
+ " BL sub_FF98ACFC\n"
+ " BL sub_FF98B790\n"
+ " LDR R0, [R5, #0xBC]\n"
+ " CMP R0, #1\n"
+ " BNE loc_FF98B0FC\n"
+ " LDRH R0, [R5]\n"
+ " CMP R0, R7\n"
+ " LDRNEH R0, [R5, #0x96]\n"
+ " CMPNE R0, #3\n"
+ " LDRNE R0, [R4, #8]\n"
+ " CMPNE R0, #1\n"
+ " BHI loc_FF98B104\n"
+"loc_FF98B0FC:\n"
+ " MOV R0, #2\n"
+ " BL sub_FF889FEC\n"
+"loc_FF98B104:\n"
+ " BL capt_seq_hook_set_nr\n" // +
+ " LDRH R0, [R5]\n"
+ " SUB R1, R0, #0x8200\n"
+ " SUBS R1, R1, #0x2D\n"
+ " BNE loc_FF98B160\n"
+ " MOV R5, #1\n"
+ " MOV R2, #2\n"
+ " MOV R1, SP\n"
+ " ADD R0, R2, #0x15C\n"
+ " STR R5, [SP]\n"
+ " BL sub_FF895E60\n"
+ " TST R0, #1\n"
+ " MOVNE R1, #0xBC\n"
+ " LDRNE R0, =0xFF98B28C\n"
+ " BLNE sub_FF81EC88\n"
+ " LDRH R0, [SP]\n"
+ " CMP R0, #1\n"
+ " BLS loc_FF98B158\n"
+ " MOV R0, R4\n"
+ " STR R5, [R4, #0xE4]\n"
+ " BL sub_FFAF1030\n" // nr-related (read)
+ " B loc_FF98B168\n"
+"loc_FF98B158:\n"
+ " MOV R0, #0\n"
+ " STR R0, [R4, #0xE4]\n"
+"loc_FF98B160:\n"
+ " MOV R0, R4\n"
+ " BL sub_FFAF0C70\n" // nr-related (read)
+"loc_FF98B168:\n"
+ " MOV R6, R0\n"
+ " B loc_FF98B180\n"
+"loc_FF98B170:\n"
+ " LDR R0, =0x71AC\n"
+ " LDR R0, [R0]\n"
+ " CMP R0, #0\n"
+ " MOVNE R6, #0x1D\n"
+"loc_FF98B180:\n"
+ " MOV R0, R6\n"
+ " LDMFD SP!, {R3-R7,PC}\n"
+ );
+}
/*************************************************************/
void __attribute__((naked,noinline)) exp_drv_task(){
-
Hi,
I'd like to pass this on to any one who is updating the release code. The address for recreview_hold in the release (I have 1714) is wrong for this camera. The correct address in stubs_min.S is:
DEF(recreview_hold, 0x3828) as can be seen by reviewing stubs_entry.S. I have checked this on version 101g. I think the address is probably the same for all versions.
Jon
-
Wish i was still involved enough to understand the binaries you keep posting
I publish my changes to document what I did (and to give a clue to the next person who will look into this).
One more thing: does the lockup with interval.lua only happen when you pause the running script (by exiting ALT mode), take pictures by hand, and try to resume by entering ALT mode again? If so, does it happen with the official release?
Sorry, I was not clear. My lack of "keeping up" refers to the the 27 years since I last wrote device specific, low-level code. Nothing to do with your published code.
The only real script hang I had was not due to pause/resume the script....I never pause the interval.lua, only interrupt to stop it.
I tried just making a menu change to see if it retriggered DFS but it did not. Had to recycle the camera and reload CHDK.
Have not tried "force flash" but will tonight.
Thanks for your time!
-
@imtheguy
Some additional questions.
When the dark frame override stops working
- do the other overrides (like ISO, Tv) still work?
- does RAW work?
-
@imtheguy
Some additional questions.
When the dark frame override stops working
- do the other overrides (like ISO, Tv) still work?
- does RAW work?
Yes, I am sure the ISO and shutter speed overrides always work. As mentioned before, The ISO when set to "1" and factor of "100" gives me a 160 in the exif. Change the override to "2" and its now 320 in exif. Exposure works well but I would love to know if the exif is wrong or if 2 x 100 = 320 for CHDK purposes.
Have not tried Tv (meaning minimum shutter speed for action shots? ), only 5-20 sec exposures.
RAW works great. Goes in the jpg folder is directed and no trouble using ACR to convert RAW files.
-
Exposure works well but I would love to know if the exif is wrong or if 2 x 100 = 320 for CHDK purposes.
Yes, thanks to Canon's marketing department. See the note on "real" and "market" ISO here http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_ISO_value (http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_ISO_value)
-
Yes, thanks to Canon's marketing department. See the note on "real" and "market" ISO here http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_ISO_value (http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_ISO_value)
You nailed it. Thanks for the education. I should have remembered that from all the DxO sensor evaluations I have read. But am suprised at the size of the difference anyway.
Thanks again!
-
Yes, I am sure the ISO and shutter speed overrides always work.
That makes my new theory invalid...Have not tried Tv (meaning minimum shutter speed for action shots? ), only 5-20 sec exposures.
Should have written "shutter speed override", CHDK doesn't provide true Tv.
Can you try what happens if you use the camera's "long shutter" mode instead of a CHDK shutter speed override?
I've made a new build with disabled support for >64s exposures. You can choose either the diskboot.bin or the ps.fi2 version this time. CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.35MB (http://www.zshare.net/download/99358664141441be/)
-
Can you try what happens if you use the camera's "long shutter" mode instead of a CHDK shutter speed override?
I've made a new build with disabled support for >64s exposures. You can choose either the diskboot.bin or the ps.fi2 version this time. CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.35MB (http://www.zshare.net/download/99358664141441be/)
Before i load this new DISKBOOT i tried with DisableOverrides=ON. The ISO and shutter were exactly as set by the Canon f/w (8", iso100) but now I cannot turn off the DFS again...even after resetting everything as it was last night. Maybe I mixed up versions of the DISKBOOT (doubtful) thus good time to try your new one. Thanks...later.
-
Can you try what happens if you use the camera's "long shutter" mode instead of a CHDK shutter speed override?
I've made a new build with disabled support for >64s exposures. You can choose either the diskboot.bin or the ps.fi2 version this time. CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.35MB (http://www.zshare.net/download/99358664141441be/)
Before i load this new DISKBOOT i tried with DisableOverrides=ON. The ISO and shutter were exactly as set by the Canon f/w (8", iso100) but now I cannot turn off the DFS again...even after resetting everything as it was last night. Maybe I mixed up versions of the DISKBOOT (doubtful) thus good time to try your new one. Thanks...later.
Ok, with the new DISKBOOT I can still get DFS off but only in Program mode, not in Long Shutter either in ALT or not in ALT mode.
What you made work a couple days ago still works:, DFS for long exposures but only in P mode as far as I can tell. Whatever changes are in the new bin do not jump out at me.
Please clarify; what is the difference (other than script execution) of pressing the shutter in ALT mode versus not in ALT? The OverRides still seem to work either way so I wonder what is supposed to be off when ALT is off but was loaded on boot? DFS is still undecided. With the new DISKBOOT I just restarted, set a OverRide shutter of 5", turned ALT to OFF, then fired single shots in Program mode. The first 2 did not use DFS. The next shot, and all afterwards, did use DFS. Nothing else touched in between and lighting was very dark with no changes. I can still get what I need most as long as I start off with Program and ALT turned on.
I am thinking we should take up a collection to send you a spiffy new Elph300HS or whatever its called across the pond. Wish you were closer so I could just send you mine to play with until you tire of it.
Cheers.
-
Please clarify; what is the difference (other than script execution) of pressing the shutter in ALT mode versus not in ALT?
Pressing the shutter in alt mode only starts a script. It never shoots, unless the script shoots. If the script does not touch the override values, then overrides set in the menu should take effect.
Shooting outside of alt mode uses whatever overrides you have in effect.
You should be aware of the somewhat confusing disable overrides setting: http://chdk.wikia.com/wiki/CHDK_User_Manual#Disable_Overrides (http://chdk.wikia.com/wiki/CHDK_User_Manual#Disable_Overrides) and the fact it has a shortcut.
However, the dark frame subtraction option isn't an override in this sense.
It's possible sensor temperature is one of the factors in the cameras decision to take a dark frame or not. If so, this might affect the override appearing to work for the first few shots and then stop working.
-
Please clarify; what is the difference (other than script execution) of pressing the shutter in ALT mode versus not in ALT?
You should be aware of the somewhat confusing disable overrides setting: http://chdk.wikia.com/wiki/CHDK_User_Manual#Disable_Overrides (http://chdk.wikia.com/wiki/CHDK_User_Manual#Disable_Overrides) and the fact it has a shortcut.
It's possible sensor temperature is one of the factors in the cameras decision to take a dark frame or not. If so, this might affect the override appearing to work for the first few shots and then stop working.
I actually did RTFM when I started but that section on Overrides should make more sense if i read it again now. Its possible I have a setting that is screwing up something else down the line. As far as sensor temp....good point. I will be suprised if it heats up after only 2 shots of 5-10sec but I have been suprised many times before. I will give it a test that ensures the sensor stays cool and post results.
Many thanks again for your help. I would have no chance of getting this 24mm Elph for timelapse work without your input so far.
-
I tried some intervallometer but i don't find one than lcd off function work. Someone can help me?
-
I tried some intervallometer but i don't find one than lcd off function work. Someone can help me?
I posted this when you asked this question some time ago :
http://chdk.setepontos.com/index.php?topic=6341.msg80187#msg80187 (http://chdk.setepontos.com/index.php?topic=6341.msg80187#msg80187)
You were having trouble to get any script to run - did you finally over come that problem ?
Were you able to make the posted script run except for the lcd off function ?
-
Making Badpixel.bin:
Fails always for me with release 1714. I tried different ISO's.
I went back to 1486 and it worked.
-
Making Badpixel.bin:
Fails always for me with release 1714. I tried different ISO's.
I went back to 1486 and it worked.
Once you've got a working badpixel.bin file - keep it somewhere safe. Then you can use DNG with the latest versions of CHDK (assuming there is some problem or another) by just copying it to the SD card.
-
Making Badpixel.bin:
Fails always for me with release 1714. I tried different ISO's.
I went back to 1486 and it worked.
Can you provide more information on how it failed ?
-
Hi,
It takes one (rarely two) pictures then gives a fail message. The message gives no further info. I don't know what more to report. Maybe the routine itself should give more detailed messages as to why it failed if it knows why.
Can you provide more information on how it failed ?
-
Hi,
It takes one (rarely two) pictures then gives a fail message. The message gives no further info. I don't know what more to report.
Whether it takes one or two pictures is an important piece of information.
-
@imtheguy
Next try. This time I tried to disable the dark frame at two locations. Also switched compilers, in case my usual compiler (toolchain) screwed up somehow. If this still isn't 100% reliable, then some big amount of Canon's code would have to be checked and "fixed". I'd rather not do that.
You can reset your CHDK settings if you think they got corrupted: Miscellaneous Stuff -> Reset Options to Default (but you probably already knew this).
I believe, this behaviour should exist in a number of newer cameras (especially CMOS ones), but apparently no one else has noticed or reported it.
CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.35MB (http://www.zshare.net/download/99373616490529d2/)
Index: platform/ixus220_elph300hs/sub/101g/capt_seq.c
===================================================================
--- platform/ixus220_elph300hs/sub/101g/capt_seq.c (revision 1725)
+++ platform/ixus220_elph300hs/sub/101g/capt_seq.c (working copy)
@@ -2,7 +2,7 @@
#include "platform.h"
#include "core.h"
-static long *nrflag = (long*)(0x7514+0x8); // FF18775C & FF1877C8
+static long *nrflag = (long*)(0x7200+0x08);
#define NR_AUTO (0) // have to explictly reset value back to 0 to enable auto
#define PAUSE_FOR_FILE_COUNTER 100 // Enable delay in capt_seq_hook_raw_here to ensure file counter is updated
@@ -13,6 +13,22 @@
// while(1);
//}
+void __attribute__((naked,noinline)) disable_nr_when_needed()
+{
+asm volatile(
+ "STMFD SP!, {R1-R12,LR}\n"
+ "MOV R4, R0\n"
+ "BL core_get_noise_reduction_value\n"
+ "CMP R0, #1\n" // NOISE_REDUCTION_OFF
+ "BNE loc_dontsetnr\n"
+ "MOV R4, #1\n"
+"loc_dontsetnr:\n"
+ "MOV R0, R4\n"
+ "LDMFD SP!, {R1-R12,PC}\n"
+ );
+}
+
+
void __attribute__((naked,noinline)) capt_seq_task() {
// FF882920 IXUS 220: DONE
@@ -104,7 +120,7 @@
" LDR R8, [R0,#0xC] \n"
" MOV R0, R8 \n"
-" BL sub_FF98B018 \n"
+" BL sub_FF98B018_my \n" // ->
" BL capt_seq_hook_raw_here\n" // added
@@ -333,6 +349,159 @@
);
}
+
+
+void __attribute__((naked,noinline)) sub_FF98B018_my( ) {
+asm volatile (
+ " STMFD SP!, {R3-R7,LR}\n"
+ " LDR R5, =0x3D48C\n"
+ " MOV R4, R0\n"
+ " LDR R0, [R5, #0x28]\n"
+ " LDR R7, =0x820C\n"
+ " CMP R0, #0\n"
+ " MOV R6, #0\n"
+ " BNE loc_FF98B0A8\n"
+ " LDR R0, [R5, #0xBC]\n"
+ " CMP R0, #1\n"
+ " BNE loc_FF98B090\n"
+ " LDRH R0, [R5]\n"
+ " CMP R0, R7\n"
+ " LDRNEH R0, [R5, #0x96]\n"
+ " CMPNE R0, #3\n"
+ " LDRNE R0, [R4, #8]\n"
+ " CMPNE R0, #1\n"
+ " BLS loc_FF98B074\n"
+ " BL sub_FF832D6C\n"
+ " TST R0, #1\n"
+ " BEQ loc_FF98B0A8\n"
+ " BL sub_FF888708\n"
+ " B loc_FF98B0A0\n"
+"loc_FF98B074:\n"
+ " MOV R0, #0xC\n"
+ " BL sub_FF8886A0\n"
+ " TST R0, #1\n"
+ " BEQ loc_FF98B0A8\n"
+ " BL sub_FF98B84C\n"
+ " BL sub_FF8807AC\n"
+ " B loc_FF98B0A0\n"
+"loc_FF98B090:\n"
+ " MOV R0, #0xC\n"
+ " BL sub_FF8886A0\n"
+ " TST R0, #1\n"
+ " BEQ loc_FF98B0A8\n"
+"loc_FF98B0A0:\n"
+ " MOV R0, #1\n"
+ " LDMFD SP!, {R3-R7,PC}\n"
+"loc_FF98B0A8:\n"
+ " BL sub_FF88318C\n"
+ " LDR R0, [R5, #0x28]\n"
+ " CMP R0, #0\n"
+ " BNE loc_FF98B170\n"
+ " MOV R0, R4\n"
+ " BL sub_FF98A948\n"
+ " TST R0, #1\n"
+ " LDMNEFD SP!, {R3-R7,PC}\n"
+ " MOV R0, R4\n"
+ " BL sub_FF98ACFC\n"
+ " BL sub_FF98B790\n"
+ " LDR R0, [R5, #0xBC]\n"
+ " CMP R0, #1\n"
+ " BNE loc_FF98B0FC\n"
+ " LDRH R0, [R5]\n"
+ " CMP R0, R7\n"
+ " LDRNEH R0, [R5, #0x96]\n"
+ " CMPNE R0, #3\n"
+ " LDRNE R0, [R4, #8]\n"
+ " CMPNE R0, #1\n"
+ " BHI loc_FF98B104\n"
+"loc_FF98B0FC:\n"
+ " MOV R0, #2\n"
+ " BL sub_FF889FEC\n"
+"loc_FF98B104:\n"
+ " BL capt_seq_hook_set_nr\n" // +
+ " LDRH R0, [R5]\n"
+ " SUB R1, R0, #0x8200\n"
+ " SUBS R1, R1, #0x2D\n"
+ " BNE loc_FF98B160\n"
+ " MOV R5, #1\n"
+ " MOV R2, #2\n"
+ " MOV R1, SP\n"
+ " ADD R0, R2, #0x15C\n"
+ " STR R5, [SP]\n"
+ " BL sub_FF895E60\n"
+ " TST R0, #1\n"
+ " MOVNE R1, #0xBC\n"
+ " LDRNE R0, =0xFF98B28C\n"
+ " BLNE sub_FF81EC88\n"
+ " LDRH R0, [SP]\n"
+ " CMP R0, #1\n"
+ " BLS loc_FF98B158\n"
+ " MOV R0, R4\n"
+ " STR R5, [R4, #0xE4]\n"
+ " BL sub_FFAF1030_my\n" // nr-related (read)
+ " B loc_FF98B168\n"
+"loc_FF98B158:\n"
+ " MOV R0, #0\n"
+ " STR R0, [R4, #0xE4]\n"
+"loc_FF98B160:\n"
+ " MOV R0, R4\n"
+ " BL sub_FFAF0C70_my\n" // nr-related (read)
+"loc_FF98B168:\n"
+ " MOV R6, R0\n"
+ " B loc_FF98B180\n"
+"loc_FF98B170:\n"
+ " LDR R0, =0x71AC\n"
+ " LDR R0, [R0]\n"
+ " CMP R0, #0\n"
+ " MOVNE R6, #0x1D\n"
+"loc_FF98B180:\n"
+ " MOV R0, R6\n"
+ " LDMFD SP!, {R3-R7,PC}\n"
+ );
+}
+
+void __attribute__((naked,noinline)) sub_FFAF1030_my( ) {
+asm volatile (
+" STMFD SP!, {R4-R11,LR} \n"
+" SUB SP, SP, #0x1C \n"
+" MOV R4, R0 \n"
+" BL sub_FF98BCC4 \n"
+" MVN R1, #0 \n"
+" BL sub_FF88DC0C \n"
+" LDR R0, =0xFF98AA5C \n"
+" MOV R1, R4 \n"
+" BL sub_FF8C0990 \n"
+" LDR R8, =0xD880 \n"
+" MOV R5, #0 \n"
+" MOV R0, R4 \n"
+" STR R5, [R8] \n"
+" BL sub_FF98A9C0 \n"
+" MOV R0, R4 \n"
+" BL sub_FF98ADD0 \n" // gives nr value in r0
+" BL disable_nr_when_needed \n" //+
+" LDR PC, =0xFFAF1070\n" // continue in ROM
+ );
+}
+
+void __attribute__((naked,noinline)) sub_FFAF0C70_my( ) {
+asm volatile (
+" STMFD SP!, {R3-R7,LR} \n"
+" MOV R4, R0 \n"
+" BL sub_FF98BCC4 \n"
+" MVN R1, #0 \n"
+" BL sub_FF88DC0C \n"
+" LDR R0, =0xFF98AA5C \n"
+" MOV R1, R4 \n"
+" BL sub_FF8C0990 \n"
+" MOV R0, R4 \n"
+" BL sub_FF98A9C0 \n"
+" MOV R0, R4 \n"
+" BL sub_FF98ADD0 \n" // gives nr value in r0
+" BL disable_nr_when_needed \n" //+
+" LDR PC, =0xFFAF0CA0\n" // continue in ROM
+ );
+}
+
/*************************************************************/
void __attribute__((naked,noinline)) exp_drv_task(){
-
I just tried it and it took two pictures then failed.
Jon
Whether it takes one or two pictures is an important piece of information.
-
@imtheguy
Next try.
and a heck of a great try it is. Now I can use DFS with any settings, <alt> on or off, and with no perceived limit before it kicks back in. Did not go beyond 10 shots yet. You nailed it this time. The only funky think that happened is after switching settings back and forth a couple times I could no longer access the CHDK menu. Camera not locked, just no menu. I dont plan to do such stress tests in the field though. Geat job, great work. I will continue some more DFS testing later including raw, long runs and badpixel files.
Take a break! Thanks again, Lee
-
I just tried it and it took two pictures then failed.
So it gave you the "badpixel.bin failed." message ?
Does it sometimes only take one picture ? And if so, what happens in that case, does it give you the error message or just stop ?
What capture mode do you have the camera in ? FWIW, badpixel will not work in the half sized low light/high iso/fast burst modes.
-
I just tried it and it took two pictures then failed.
Jon
Can you create an empty badpixel.bin file in the CHDK folder and then take a few photos of a light colored wall as DNG files (using the ISO you were trying) .
Upload the DNG files to a file hosting site and post the link here please.
Phil.
-
and a heck of a great try it is. Now I can use DFS with any settings, <alt> on or off, and with no perceived limit before it kicks back in.
That's cool :) The only funky think that happened is after switching settings back and forth a couple times I could no longer access the CHDK menu. Camera not locked, just no menu.
That's not so cool. It shouldn't happen. Can you reproduce it? Is it related to setting the dark frame on/off?
Something strange is going on here and I don't like it... It can be the toolchain, it can be a bug in the port, or it can be a DryOS bug like this: https://bitbucket.org/hudson/magic-lantern/changeset/99e80332797c
-
The only funky think that happened is after switching settings back and forth a couple times I could no longer access the CHDK menu. Camera not locked, just no menu.
That's not so cool. It shouldn't happen. Can you reproduce it? Is it related to setting the dark frame on/off?
Something strange is going on here and I don't like it... It can be the toolchain, it can be a bug in the port, or it can be a DryOS bug like this: https://bitbucket.org/hudson/magic-lantern/changeset/99e80332797c
[/quote]
I will have to make a scripted test plan to reproduce that as i was doing too much to keep track of at the time. If I can reproduce it just once more while randomly playing, i will then write out a set of steps to follow until I can pin it down.
Going to try a 120minute star trail tonight. Lets see how beautiful this 24mm wide frame can make the stars around Polaris.
Will be stuck at 15sec exposure unless I can find a batch utility that will modify the EXIF of all the shots from the hard-wired max of 15sec to the longer one I want to use. More like 25-30sec. The StarTrail plotting program apparently draws based on the EXIF thus I get gaps when shooting at 25sec and plotting at 15sec. There is software to fill in the gaps but the right way is to correct the exif. More later.....
-
Here is the dng:
https://rapidshare.com/files/2812965999/IMG_0030.DNG (https://rapidshare.com/files/2812965999/IMG_0030.DNG)
Just for completeness here is the jpeg
https://rapidshare.com/files/3398062624/IMG_0030.JPG (https://rapidshare.com/files/3398062624/IMG_0030.JPG)
In doing further testing it has worked occasionally. Its hard to say just what are the conditions under which it succeeds.
Jon
Can you create an empty badpixel.bin file in the CHDK folder and then take a few photos of a light colored wall as DNG files (using the ISO you were trying) .
Upload the DNG files to a file hosting site and post the link here please.
Phil.
-
In doing further testing it has worked occasionally. Its hard to say just what are the conditions under which it succeeds.
Jon
Looks like there are variations on the sensor across this camera model - yours has a slightly smaller active area than the previous files posted.
Try the attached version and see if it works any better.
Phil.
-
It worked 3 out of 4 times in auto-iso mode, but with fixed iso 400 and iso 1600 it failed. Auto-iso was choosing iso around 400.
Jon
Looks like there are variations on the sensor across this camera model - yours has a slightly smaller active area than the previous files posted.
Try the attached version and see if it works any better.
Phil.
-
It worked 3 out of 4 times in auto-iso mode, but with fixed iso 400 and iso 1600 it failed. Auto-iso was choosing iso around 400.
Jon
Does it give the same count each time (when it works)?
Try zooming to the telephoto zoom position and see if it works better.
Attached is a version that will displays the count of bad pixels from the two different images taken if it fails (it fails because the counts are different). Try different settings and see how much the counts vary.
Phil.
-
I tried some intervallometer but i don't find one than lcd off function work. Someone can help me?
I posted this when you asked this question some time ago :
http://chdk.setepontos.com/index.php?topic=6341.msg80187#msg80187 (http://chdk.setepontos.com/index.php?topic=6341.msg80187#msg80187)
You were having trouble to get any script to run - did you finally over come that problem ?
Were you able to make the posted script run except for the lcd off function ?
Exatly the request is the same, in january i tried your solution but it had a problem, so i wait. Now i don't remember exactly why it didn't work correctly, tomorrow i try that solution and report the experience in that post. Thank you for now
-
Hi,
I did some trials with your test version.
When it worked it always got 14845 bad pixels
autoISO unzoomed:worked
ISO400 unzoomed: failed 14858-14861
ISO400 zoomed: worked
ISO400 zoomed: worked
ISO1600 zoomed: failed 15053-15127
ISO100 zoomed: worked
autoISO zoomed: worked
ISO400 zoomed: worked
ISO400 unzoomed: failed 14874-14866
Maybe the pattern is zoomed + low or auto ISO works.
Jon
Does it give the same count each time (when it works)?
Try zooming to the telephoto zoom position and see if it works better.
Attached is a version that will displays the count of bad pixels from the two different images taken if it fails (it fails because the counts are different). Try different settings and see how much the counts vary.
Phil.
-
You think that CHDK get access to the motion detector that is in the camera ?
im fairly shure that it could.....
Most people dont even know that the PowerShot 300HS has this.....
to prove it Let your camera fall to sleep and then wiggle it to wake it up.
OR
just like when you view your pictures on the camera turn the camera on its side and watch what happens..
now i feel that if i can get access to this in the camera there could be some More cool scripts made up for it.
I Do know...........
if you can control some of the Hardware of the camera with Chdk like you can this shuld be Just as easy as usen the Manual Focus or turning the ND filter on or off.
-
I tried some intervallometer but i don't find one than lcd off function work. Someone can help me?
I posted this when you asked this question some time ago :
http://chdk.setepontos.com/index.php?topic=6341.msg80187#msg80187 (http://chdk.setepontos.com/index.php?topic=6341.msg80187#msg80187)
You were having trouble to get any script to run - did you finally over come that problem ?
Were you able to make the posted script run except for the lcd off function ?
Then: to start thanks for the tips.
Now I'll explain my situation:
I used the code you gave me proposed
@title Intervalometer
@param a = interval (sec)
@default a 60
if get_mode = 0 then goto "in_rec"
sleep 1000
set_record 1
:wait_rec
sleep 100
if get_mode <> 0 then goto "wait_rec"
:in_rec
do
s = (a*1000)+get_tick_count
shoot
sleep 2000
set_backlight 0
do
sleep 500
until (s <= get_tick_count)
until ( 0 )
:restore
set_backlight 1
sleep 1000
end
The script works, but ...
although I have disabled the function of displaying the image after the shot, after shot, turn on the monitor for one second, not displaying the captured image, but the live view.
Is there a way to avoid this?
Another thing that we already have:
is possible lock the focus after the first shot?
Thank you again.
Andrea
-
The script works, but ...
although I have disabled the function of displaying the image after the shot, after shot, turn on the monitor for one second, not displaying the captured image, but the live view.
Is there a way to avoid this?
Not that I know of . The camera does this on its own so CHDK just keeps resetting it. The only other way around this on most cameras is to plug a video cable in (or at least the connector for a video cable). This will keep the display off all the time.
is possible lock the focus after the first shot?
Here you go, af_lock(1) command added below :
@title Intervalometer
@param a = interval (sec)
@default a 60
if get_mode = 0 then goto "in_rec"
sleep 1000
set_record 1
:wait_rec
sleep 100
if get_mode <> 0 then goto "wait_rec"
:in_rec
do
s = (a*1000)+get_tick_count
shoot
sleep 2000
set_backlight 0
set_aflock(1)
do
sleep 500
until (s <= get_tick_count)
until ( 0 )
:restore
set_backlight 1
sleep 1000
end
-
@waterwingz
Any chance you know how to write a script to start video and to lock exposure so it is not always changing ? There are quite a few people that would really like to have this working...
thanks in advance.
-
@waterwingz
Any chance you know how to write a script to start video and to lock exposure so it is not always changing ?
Not off the top of my head. I don't use video with my cameras but I guess a lot of people do. The script writing is the easy part - I just don't know if any of the set_TV() type functions do anything while you are in video mode ?
-
I have been trying out different combinations with this script (http://chdk.setepontos.com/index.php?topic=5295.45 (http://chdk.setepontos.com/index.php?topic=5295.45)) and the lock seems to work but the problem is that every time the camera moves it seems to reset and turn off the AE lock. I could be wrong about this, but I am not sure where to go from here.... Thanks for your help anyways...
Oh and by the way, the video on this camera is fantastic! I am pulling really high bit rates and the quality is great!
Is there a function for AE lock in bas?
-
I have been trying out different combinations with this script (http://chdk.setepontos.com/index.php?topic=5295.45 (http://chdk.setepontos.com/index.php?topic=5295.45)) and the lock seems to work but the problem is that every time the camera moves it seems to reset and turn off the AE lock.
That's a very technical script - it will take a lot of work to improve on it. Not sure what else to suggest assuming you got the right addressses in stub_entry_2.S for your camera model. Sorry.
-
I got the addresses from this page (http://trac.assembla.com/chdkde/changeset/880 (http://trac.assembla.com/chdkde/changeset/880)), and as I said it seems to work until the record button is pressed and there is movement. Thanks for checking it out... I guess I will have to wait until someone with a greater knowledge in this area looks at it.
Thanks again...
-
Sorry if I'm still here to ask questions.
Is there a way to extend the battery life? Changing an external battery pack for example, or something like that
-
Any news about exposure lock during video ?
i am really anxious on buying this camera and my retailer is going out of stock .
Can someone tell me if exposure lock for video is just a matter of time or there is the posiblity that exposure lock will be imposible for this model ?
-
For whomever is interested, I used Adobe's Lens Profile Creator to create a profile for DNG shooting for the ELPH300HS. It is by no means perfect, but with some minor adjustments in your RAW program, it's not too bad.
http://dl.dropbox.com/u/14988694/Canon%20PowerShot%20ELPH%20300HS%20%284.3-21.5%20mm%20f2.7-5.9%29%20-%20RAW.lcp (http://dl.dropbox.com/u/14988694/Canon%20PowerShot%20ELPH%20300HS%20%284.3-21.5%20mm%20f2.7-5.9%29%20-%20RAW.lcp)
Further distortion, vignetting, and color correction are in this file:
http://dl.dropbox.com/u/14988694/barreldist.xmp (http://dl.dropbox.com/u/14988694/barreldist.xmp)
I've found that it does have a bit of an orange tinge to it, but it seems to get the colors pretty close to what the ELPH300HS JPEG processing looks like [and in some cases, more accurately captures the colors in the scene].
(Also, I'm a newb with all these different file types, so if I posted some that aren't actually anything, just let me know)
-
Hello everyone.
Does anybody know if there is an effective motion detector for the ixus?
I tried many of those which are on the scripts page with no success.
The aim is to take pictures of birds. But if it's possible to set the script for lightning too, it would be awesome.
Sorry for my poor english and thank you in advance.
-
Hello & welcome !
Does anybody know if there is an effective motion detector for the ixus?
The best one - fudgey's "Fast MD with burst/preview mode":
* http://chdk.setepontos.com/index.php/topic,471.msg21328.html#msg21328 (http://chdk.setepontos.com/index.php/topic,471.msg21328.html#msg21328)
See also
* http://chdk.setepontos.com/index.php/topic,471.msg33474.html#msg33474 (http://chdk.setepontos.com/index.php/topic,471.msg33474.html#msg33474)
* http://chdk.setepontos.com/index.php?topic=7746.msg82003#msg82003 (http://chdk.setepontos.com/index.php?topic=7746.msg82003#msg82003)
-
Was anyone actually ABLE to shot lightning with one of the following scripts: http://chdk.setepontos.com/index.php/topic,471.msg21328.html#msg21328 (http://chdk.setepontos.com/index.php/topic,471.msg21328.html#msg21328)
http://chdk.setepontos.com/index.php/topic,471.msg33474.html#msg33474 (http://chdk.setepontos.com/index.php/topic,471.msg33474.html#msg33474)
http://chdk.setepontos.com/index.php?topic=7746.msg82003#msg82003 (http://chdk.setepontos.com/index.php?topic=7746.msg82003#msg82003)
And with elph 300hs aka ixus 200?
If yes, please tell me what configuration did you use on those scripts? Yesterday there was a storm and unfortunatelly my ixus 200hs didn't manage to capture any of the lightning :| It's summer so there will be more rainy lightning days. It would be great if there would be known to work script that allows to shot lightnings...
-
hello, could somebody update the status of this port in the chdk wiki? i read the last 10 pages of this topic but i still dont have a clear picture about the functional status of this firmware (e.g. what works, what doesnt work)
thank you
PS: i also failed the captcha 4 times... please do something about it. if you humiliate us with such a low quality captcha, why do we need to register?!
-
Most stuff works pretty well, video function is missing yet.
I use it all the time for raw/dngfiles, works just like a charm.
-
In case anyone searches for this later, none of the capt_seq.c files for the four firmware versions are hooked for wait_until_remote_button_is_released().
As such, it will not be possible to use USB remote sync functionality with these cameras ( although unsync'd USB remote operations are still supported).
-
I have written simple setup instructions here. Alex
https://docs.google.com/document/d/1rq7J1vUCXfQJTKcMHxChSp1C29NwZXGgb6WG8quyTHQ/edit
-
Most stuff works pretty well, video function is missing yet.
I use it all the time for raw/dngfiles, works just like a charm.
HI, im new to all this, ive tried to understand what are the new functions added to this camera, but i fail to do so
does it allow to manual set things like aperture, speed or exposure?
im between a sx150 and this, if i can make the elph300 manual, then im sold to it, but im still in doubt
also it would be awesome to zoom while recording, is it possible normally?
-
Hi Guys,
My camera elph 300HS (firmware 100C) doesnt have "Update firmware" option under Menu.
Has someone had similar problem?
-
Hi Guys,
My camera elph 300HS (firmware 100C) doesnt have "Update firmware" option under Menu.
Has someone had similar problem?
Are you powering on the camera with the "Play" button instead of the regular power button ? You have to do this to get the firmware update option.
You should also make sure that the file called PS.FI2 is in the root directory of the card. If the build you downloaded doesn't have this file, get the latest autobuild from http://mighty-hoernsche.de/ (http://mighty-hoernsche.de/)
If you copied the files using a Mac, this might apply http://chdk.wikia.com/wiki/FAQ/Mac#Still_Having_Trouble.3F (http://chdk.wikia.com/wiki/FAQ/Mac#Still_Having_Trouble.3F)
-
Hi Guys,
My camera elph 300HS (firmware 100C) doesnt have "Update firmware" option under Menu.
Has someone had similar problem?
Are you powering on the camera with the "Play" button instead of the regular power button ? You have to do this to get the firmware update option.
You should also make sure that the file called PS.FI2 is in the root directory of the card. If the build you downloaded doesn't have this file, get the latest autobuild from http://mighty-hoernsche.de/ (http://mighty-hoernsche.de/)
If you copied the files using a Mac, this might apply http://chdk.wikia.com/wiki/FAQ/Mac#Still_Having_Trouble.3F (http://chdk.wikia.com/wiki/FAQ/Mac#Still_Having_Trouble.3F)
I tried the latest zip file (I was using the zip from the first page before) and that worked.
Thanks for that.
After the boot, I see th CHDK logo at the start. I changed to the CHDK mode by pressing REC.
Also locked the SD card so it always boot CHDK.
The problem is:
Pressing the shutter doesnt do anything. It just says
*** STARTED ***
;)
*** FINISHED ***
Also using the zoom doesn't do anything.
I don't know squat about photography. I did CHDK so I can play with various settings before I decide if those super expensive DSLR are my cup of tea. So don't mind me overlooking something obvious.
Is there a way to just shoot pictures by setting options in Menu i.e shutter speed, shoot raw, etc?
-
The problem is:
Pressing the shutter doesnt do anything. It just says
*** STARTED ***
;)
*** FINISHED ***
Congratulations. You just ran the default script - which does nothing by default. You need to go to the script menu and pick a script that does something you want to do. Or download a script from the forum or wiki. Or write your own.
When you are in CHDK <ALT> mode, pressing the shutter button runs a script rather than takes a picture.
Also using the zoom doesn't do anything.
Again, this is what is supposed to happen in <ALT> mode. The various camera buttons do nothing - they are there so that a script can detect their value / state and do something appropriate.
Is there a way to just shoot pictures by setting options in Menu i.e shutter speed, shoot raw, etc?
Exit CHDK <ALT> mode after you set the options. If you have enabled overrides then those will be active when you press the shutter button.
-
I can't get the camera to turn auto dark frame off, is it possible this doesn't work yet with the current port?
<edit>
Some more info, my camera's firmware is 1.01a.
After fiddling some more i get (with dark frame substraction off in raw settings, shutter at 16 sec);
- dark frame substraction disabled (yes!) when pressing half-shoot, wait for focus confirm* and press full-shoot
- dark frame substraction enabled when pressing full-shoot without waiting
*auto focus confirm:
- when unable to focus dark frame is disabled
- when camera draws one or more green boxes on the lcd dark frame is disabled
- when camera draws single blue box the preset shutter speed does not work (only takes 4 sec shot)
- when camera shows enlarged section of focus point then either dark frame disable or shutter speed override does not work (can't remember which one, i can retest if asked)
-
Okay ... here's the current 1.1.0 version of CHDK for the elph300hs (ixus220) with the code for USB sync added. Its basicallly a copy of how the ixus115 (released on the same date as the ixus220) is implemented.
ixus220 f/w 1.00c (https://www.box.com/s/9a4ryvv845zhnny3ir9x)
ixus220 f/w 1.01a (https://www.box.com/s/c97i3rwalmiomm6gwzjr)
ixus220 f/w 1.01c (https://www.box.com/s/c97i3rwalmiomm6gwzjr)
ixus220 f/w 1.01g (https://www.box.com/s/b6w71hsgfpxzzx7izhir)
SD card lock booting method only at this point. (i.e. no firmware update booting option).
Feedback would be appreciated !
-
Thanks Waterginz.
I tested the sync with two Ixus 220 1.01g. I did the test with a timer on my LCD monitor (I know I should use CRT) and shutter speed 1/500 they are always in sync. Sync works as expected!
The only thing I noticed is that I can't take shot's immediately after each other I have to wait 2 or 3 seconds. Thanks for your effort! Much appreciated.
Out of curiosity I also tested the old inverted remote script and it is, as expected not as good as the sync method. It can capture two consecutive frames of the LCD monitor.
-
The only thing I noticed is that I can't take shot's immediately after each other I have to wait 2 or 3 seconds.
Can't think of any reason the sync code would change the cycle time for shots.
Do you have RAW enabled ? It takes time to write the Raw file to the card.
Otherwise, do you have the same problem taking two shots with sync disabled ?
-
I don't have the same problem with sync disabled. But for me it is not a real problem. It just that with sync enabled the camera will not focus again if you switch the 5v on immediately after the shot is taken.
-
I don't have the same problem with sync disabled. But for me it is not a real problem. It just that with sync enabled the camera will not focus again if you switch the 5v on immediately after the shot is taken.
One press mode is kind of a hack when using sync. It does the equivalent of "mashing the shutter button down" when you apply the USB power - it basically forces the camera through all operations and starts the shutter release process so that it can "sync" on the removal of USB power. If you use "two press", the behaviour is much more civilized as the first press allows exposure to be set and the focus locked.
-
One press mode is kind of a hack when using sync. It does the equivalent of "mashing the shutter button down" when you apply the USB power - it basically forces the camera through all operations and starts the shutter release process so that it can "sync" on the removal of USB power. If you use "two press", the behaviour is much more civilized as the first press allows exposure to be set and the focus locked.
Thanks for the explanation.
-
I have still have problems with the nice usb remote function, with sync enabled. It makes the camera' often (>10%) crash. The screen stays in the freezing process and the camera doesn't react to anything, I have to power off the camera to make it work again.
I have created a crash log hopping that someone does understand what is going wrong.
-
I have still have problems with the nice usb remote function, with sync enabled. It makes the camera' often (>10%) crash. The screen stays in the freezing process and the camera doesn't react to anything, I have to power off the camera to make it work again.
I have created a crash log hopping that someone does understand what is going wrong.
The camera crashes in a part of firmware which has the name "chaseframe". Do you have any "smart" feature of the camera turned on? By smart, I mean stuff like auto mode, face/blink/whatever detection, tracking AF. If so, try without.
edit: related to scene detection, is the cam in auto mode?
-
The camera crashes in a part of firmware which has the name "chaseframe". Do you have any "smart" feature of the camera turned on? By smart, I mean stuff like auto mode, face/blink/whatever detection, tracking AF. If so, try without. edit: related to scene detection, is the cam in auto mode?
The only thing the "sync" code does is hold the shooting task in a tight loop waiting for the USB power to be released. This seems to be harmless on most cameras but its possible, as srsa_4c has pointed out, that being stuck in that tight loop is a bad thing for some of the "advanced" camera features. It will be interesting to know if those features are enabled and if turning them off causes the problem to go away.
-
Af
The camera crashes in a part of firmware which has the name "chaseframe". Do you have any "smart" feature of the camera turned on? By smart, I mean stuff like auto mode, face/blink/whatever detection, tracking AF. If so, try without. edit: related to scene detection, is the cam in auto mode?
The only thing the "sync" code does is hold the shooting task in a tight loop waiting for the USB power to be released. This seems to be harmless on most cameras but its possible, as srsa_4c has pointed out, that being stuck in that tight loop is a bad thing for some of the "advanced" camera features. It will be interesting to know if those features are enabled and if turning them off causes the problem to go away.
Good point the problem seems to be related to the face recognition of the camera.
After disabling all the smart features and testing with various settings I still have the same problem. But I have discovered that the problem only occurs when a face is in the frame while focusing. So the problem certainly has to do something with the camera's face recognition. The problem is it is seems to be available in every mode and I have not found a method to disable it. The only thing that works is working in low light, perhaps because face recognition is not working in low light.
-
101G with last CHDK for 101G
1.
How to turn off LCD Display?
I have tried some "intervalometer" scripts, but they cant keep it off longer than some milliseconds (blink).
"review" is OFF (displaying the image after the shot)
What about hardware mod for this? Does this easy to implement addition button to power it off?
2.
There is "High-speed burst" mode in 3Mpx . How can I use it in script? (e.g. take 1 shot in full res and than immediately 10 shots with "High-speed burst")
3. How to record video? (video button has binded to ALT)
4. Fast buttons (top, left, right, zoom) does not work in ALT mode, except RAW (down). Also in script-parameter-set menu that buttons does not work.
I have understand that they works in not-ALT mode and with half-press. But "zoom" control - don't.
-
I can answer a few of your questions;
1: backlight: manipulating the backlight does not work with this port, the firmware functions called to turn backlight on and off as used in the port do not work.
1: set_backlight works when you set Disable LCD Off in CHDK settings to 'Always' :P
Also put a sleep(100) after a call to set_backlight, and if you wait for an event in a loop it is best to also include a set_backlight(0) there, some backlights are very hard to turn off.
Here's a code snippet that manages to turn the backlight off on the 220HS 100b
function expcontrol_shoot(dark)
press("shoot_half")
repeat
sleep(10)
set_backlight(0)
until get_shooting() == true
set_backlight(0)
sleep(500)
press("shoot_full")
sleep(100)
release("shoot_full")
sleep(100)
release("shoot_half")
repeat
sleep(10)
set_backlight(0)
until get_shooting() ~= true
3: Video: short press is Alt mode, long press is record ;)
-
For what it's worth, a picture of the X-Rite Passport.
It does get better colors in tungsten light.
software: http://xritephoto.com/ph_product_overview.aspx?ID=1257 (http://xritephoto.com/ph_product_overview.aspx?ID=1257)
photo: http://depositfiles.com/files/c4chvqspe (http://depositfiles.com/files/c4chvqspe)
Hope you'll find it usefull.
-
hey guys, is it possible to have the lens stay in when starting the camera with the playback button? (normal behavior) everything else is perfect but it's super annoying i can't start the camera without the lens coming out everytime..
thanks
-
hey guys, is it possible to have the lens stay in when starting the camera with the playback button?
Yes it is - just hold the Playback button while switching on until you see the splash screen.
hth,
wim
-
hey guys, is it possible to have the lens stay in when starting the camera with the playback button?
Yes it is - just hold the Playback button while switching on until you see the splash screen.
hth,
wim
ah thanks! that worked! but would it be possible to just change it so it works like that when you press the playback button only?
-
ah thanks! that worked! but would it be possible to just change it so it works like that when you press the playback button only?
If the lens extends when you press the play button, the port is not implemented correctly. The behavior should be:
any length press of play button powers on in play mode.
short press of power button powers on in play mode
long press of power button powers on in rec mode
Opening the lens unexpectedly risks damaging the camera, so should not be the default. The information about which button was pressed to start the camera is lost by the time CHDK is loaded, so the default must be play mode. The code can then detect if the power button is still pressed, and act accordingly.
-
Hi,
I'm using an IXUS 220 HS with the chdk-ptp alternative ptp client.
Things generally work well except for some irregular crashes. But this could be a chdk-ptp issue (I've posted about this in that thread)
Anyway, what I would like to know is if it is possible to set the focus distance with lua code with the IXUS 220 HS using "set_prop" and "set_focus(x)"?
The problem is, I'm using the camera as a sort of high quality webcam with shots taken and uploaded every 40 seconds using a Raspberry Pi, but at night it more often than not doesn't focus correctly so I'd like to be able to set the focus distance to guarantee the subject being in focus. Is this possible?
I am able to manually set the focus using the CHDK settings on the camera when it's not plugged in to anything, so manual focus does seem possible with this camera. Is it possible via lua code? If so, what steps do I need to make it manually focus?
-
I want to disable RAW+JPG recording, I only want RAW to be stored on the SD Card.
This Menu http://chdk.wikia.com/wiki/CHDK_for_Dummies#Raw (http://chdk.wikia.com/wiki/CHDK_for_Dummies#Raw) (http://images2.wikia.nocookie.net/__cb20071013223061/chdk/images/thumb/9/9c/Raw.jpg/200px-Raw.jpg (http://images2.wikia.nocookie.net/__cb20071013223061/chdk/images/thumb/9/9c/Raw.jpg/200px-Raw.jpg)) does not exist in my version, can't find that option. The described Menu is not there.
Thanks for you help!
-
I want to disable RAW+JPG recording, I only want RAW to be stored on the SD Card.
Sorry - its not currently possible to do this with CHDK. The JPG save is done in the Canon firmware and nobody has discovered a way to disable that.
This Menu http://chdk.wikia.com/wiki/CHDK_for_Dummies#Raw (http://chdk.wikia.com/wiki/CHDK_for_Dummies#Raw) (http://images2.wikia.nocookie.net/__cb20071013223061/chdk/images/thumb/9/9c/Raw.jpg/200px-Raw.jpg (http://images2.wikia.nocookie.net/__cb20071013223061/chdk/images/thumb/9/9c/Raw.jpg/200px-Raw.jpg)) does not exist in my version, can't find that option. The described Menu is not there.
That menu does not disable saving JPG - it is only there to let you decide where the RAW image should be saved on some cameras (in the same folder as the JPG or in its own folder). Those menu items are currently part of the main RAW menu if they are implemented for your camera.
-
The JPG save is done in the Canon firmware and nobody has discovered a way to disable that.
To be pedantic (this is the internet after all :P), srsa_4cs filewrite stuff can be used to do this so a way has been discovered, it just hasn't been implemented in the trunk yet. It also needs new code for each camera.
We could add a "raw only" option when this stuff goes into the trunk, but it's not really clear what the benefit would be. It happens at the end of jpeg processing so the time saving will be very marginal. If you are worried about space, you could just choose a small jpeg resolution. The camera will still waste some resources for every shot because it thinks it wrote a jpeg. You also obviously wouldn't be able to review your pictures (possibly including recreview, I haven't checked that)
@FaKK
What benefit do you expect to gain from disabling jpeg?
-
To be pedantic (this is the internet after all :P), srsa_4cs filewrite stuff can be used to do this so a way has been discovered, it just hasn't been implemented in the trunk yet. It also needs new code for each camera.
Next time I'll just say "can't be done".
-
@FaKK
What benefit do you expect to gain from disabling jpeg?
So far I only got a 2Gig SD Card ready with CHDK (fat, bootable bla bla), so I just
- need some more Space plus I thought,
- might be faster.
- safe battery (though my 220HS last very long!). As I develope all picture with Photoshop,
- don't need them JPGs anyway. Need to delete/overwrite them, more work for me.
Figured out "small" in Canon's setting is helping a little bit (DNG still full resolution) but then .. when I forget to put on SD write protection (to enable CHDK), I'll cry.
My Ixus' got a lucky day! Brand ne screen + newest CHDK version = looks nice :)
https://www.facebook.com/photo.php?fbid=247542898709427&set=a.247542838709433.60618.220902581373459&type=1&theater (https://www.facebook.com/photo.php?fbid=247542898709427&set=a.247542838709433.60618.220902581373459&type=1&theater)
Anybody needs a spare one? (glass broken, still works fine)
-
So far I only got a 2Gig SD Card ready with CHDK (fat, bootable bla bla)
- need some more Space
The IXUS 220 was released in 2011, so it will boot from FAT32. With SDHC cards somewhere under $1 / GB, a bigger card seems like the obvious choice.
-
Yesterday I made some night time lapse videos (just city lights with some traffic from the roof).
I've noticed that some pictures are blured (out of focus) and I don't know what is the reason? - example images of in and out of focus included in Attachment. Is it script (included INTERVAL.lua) or anything else (perhaps settings in a camera)
Camera settings when I took time lapse:
AF Frame: Center
AF Frame Size: Normal
Digital Zoom: Standard
AF-Point Zoom: off
Servo AF: off
AF-assist Beam: off
CHDK settings -> Extra Photo Operations
Override Shutter Speed: 3.2
Value Factor: 1
Override ISO Value: 1
Value Factor: 100
CHDK INTERVAL.LUA script settings:
interval (sec): 5
Here is the blured / out of focus version http://youtu.be/_CnW0F9I-pI (http://youtu.be/_CnW0F9I-pI) (Please watch in FullHD or 4k resolution)
And here is the version where I took blured / out of focus images away: http://youtu.be/uH4qQk0ubuc (http://youtu.be/uH4qQk0ubuc) (Please watch in FullHD or 4k resolution)
-
When I tried to edit it didn't allow me to include more attachments.
Anyway here are both exif files made with exiftool on ArchLinux.
The only big difference is Focus Distance Upper field:
in focus: 1.51 m out of focus: 65.53m
-
Here is the difference between those two photos presented with exiv2 tool on Linux:
The main difference is Subject distance for in_focus: 151 and for out of focus: 6553
-
I've noticed that some pictures are blured (out of focus) and I don't know what is the reason?
Since your "subject" is distant and doesn't move, you may want to use subject distance override (perhaps combined with AF lock). You can also find more sophisticated scripts here in the forum for timelapse.
-
What should the value be for Subject distance override? (something to infinity but I don't know number would represent that value).
Where do I set AF lock?
-
What should the value be for Subject distance override? (something to infinity but I don't know number would represent that value).
http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_Subject_Distance (http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_Subject_Distance)
Where do I set AF lock?
That's a Canon feature, press the shutter halfway, hold it and press the "left" button.
You can do these in the script too (if you'd like to change that), see the set_focus and set_aflock commands: http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page (http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page)
If you start the camera manually, setting AF lock may be enough before you start the script (just make sure the camera found the right focus).
Note that only a few recording modes (such as P) support AF lock.
-
That's awesome about Canon feature :) Didn't even know it was there :) Are there any more canon features with keybindings?
I'll try with this first and if this won't help I'll test w ith Override Subject Distance and set it to infinity. Thank you!
-
Are there any more Canon features with keybindings?
Exposure Lock : press the shutter halfway, hold it and press the "up" button.
-
I'm not sure if this is the right spot to ask this question, but what kind of RAW save times are people seeing with this camera and a class 10 sd card?
-
Panasonic 16GB Class 4:
4.06s 12.1MP DGN + JPG L
3.62s 12.1MP DGN + JPG S
-
Hy, how about exposure lock and focus lock during video ? is this possible on the 300elph ? . If not, does somebody know a chdk enabled camera that can do exposure and focus lock during video ? thank you !
-
If not, does somebody know a chdk enabled camera that can do exposure and focus lock during video ? thank you !
You might want to follow this thread : http://chdk.setepontos.com/index.php?topic=9533. (http://chdk.setepontos.com/index.php?topic=9533.)
-
Hi,
When i switch on my camera, the script loads by default. What is the shortcut keys so that the camera loads without CHDK. Meaning how to disable CHDK?
-
Meaning how to disable CHDK?
Move the "Lock" slider on your SD card to the "unlocked" position.
-
Hi!
I just installed CHDK on my ELPH300HS, firmware 100c build 2713.
Thanks for this nice work, I'm impressed!
I have what looks like a badpixel issue with DNG files, same as post 670
http://chdk.setepontos.com/index.php?topic=6341.msg81851#msg81851 (http://chdk.setepontos.com/index.php?topic=6341.msg81851#msg81851)
I get exactly what David01 got in the picture he posted -
http://chdk.setepontos.com/index.php?action=dlattach;topic=6341.0;attach=6127 (http://chdk.setepontos.com/index.php?action=dlattach;topic=6341.0;attach=6127)
I generated badpixel.bin twice.
Any help welcome!
Thanks in advance
Patrice
-
I have what looks like a badpixel issue with DNG files, same as post 670
http://chdk.setepontos.com/index.php?topic=6341.msg81851#msg81851 (http://chdk.setepontos.com/index.php?topic=6341.msg81851#msg81851)
Are you using DNG version 1.1 or DNG 1.3 ?
If you are using 1.3, try 1.1. DNG 1.3 uses a different badpixel removal method, which doesn't require badpixel.bin, but isn't supported by most non-adobe raw software. In programs that don't support 1.3, you will see the same effect as in the post you linked.
-
Are you using DNG version 1.1 or DNG 1.3 ?
If you are using 1.3, try 1.1. DNG 1.3 uses a different badpixel removal method, which doesn't require badpixel.bin, but isn't supported by most non-adobe raw software. In programs that don't support 1.3, you will see the same effect as in the post you linked.
You're right on it, changing DNG to 1.1 does the thing!
I use ufraw under Ubuntu. Any Linux raw software I tried gave me these spots with DNG 1.3. Darktable is able to read the CHDK CRW files for this camera, though, without spots in the result, but the conversion is so-so and getting an acceptable jpg is a lot of work.
Thanks a lot!
-
You're right on it, changing DNG to 1.1 does the thing!
I use ufraw under Ubuntu. Any Linux raw software I tried gave me these spots with DNG 1.3. Darktable is able to read the CHDK CRW files for this camera, though, without spots in the result, but the conversion is so-so and getting an acceptable jpg is a lot of work.
Thanks a lot!
If you don't mind building your own version of ufraw, then you can try my patch for that program to get it to automatically fix the bad pixels in DNG 1.3 images. You can get the patch at: http://chdk.setepontos.com/index.php?topic=9443.msg98900#msg98900 (http://chdk.setepontos.com/index.php?topic=9443.msg98900#msg98900)
-
Liveview palette bug reported here:
I've also found when enabling Viewfinder in livegui colors are somehow unreadable. Is this normal? (see attachment)
Patch and compiled version for 100c in attachment. Please test it and report.
-
Hi natraf!
I've tested your patch together with 100c version. I've just copied all files from both attachments to root of SD card. <- is this the right method?
So now my root SD card looks like this:
changelog.txt
CHDK
DISKBOOT.BIN
DCIM
ixus220_palette_trunk2778.patch
readme.txt
vers.req
I've noticed that zoom bar is not visible even though if I change fps to 30. (see attachments) Wat is good fps rate anyway?
I've also noticed when fps is set to 10 and in play mode and then I press menu and then rotate submenu it takes near 10seconds to show correct colours. If fps is set to 20 then everything looks ok except zoom bar is not shown...
-
Some more attachments about rotate at 10 fps (have to wait aprox 10 seconds that it looks like with 20fps instantly)
This also happens with other submenus at 10fps
-
And here is no zoom bar example. It's not shown at 10 20 or 30 fps
-
Some more updates about new chdk build and patch
When in play mode and I switch between display look. For a display look when it should show some more info like exposure time, iso, histogram there is nothing. See attachment please.
-
It looks like vid_get_bitmap_active_buffer is not implemented for this port, so you will sometimes see old bitmap data.
-
It looks like vid_get_bitmap_active_buffer is not implemented for this port, so you will sometimes see old bitmap data.
My fault.. new version attached.
@frojnd
You don't need to copy patch file, patch file is for source code. Just unzip ixus220_elph300hs-100c-1.2.0-liveview.zip to your sd-card as you did it previously.
-
Thank you natraf!
I've attached two photos of play menu when different set is present. There should be info about how many shots is left, iso value should be seen, but it's better than last time -> zebra is seen :)
-
And two photos of play and rec menu.
The help text isn't seen in play menu. But other than thet everything looks OK.
What is recommended fps rate for live view?
-
What is recommended fps rate for live view?
There is no specific recommended rate.
You should set the target rate to something lower than the maximum rate your USB and display system can sustain, otherwise the application may become unusable under linux. A lower frame rate will also put less load on the camera.
-
Where I can find FASTEST working motion capture script and settings for ELPH300? Default is too slow react for capture lightning. I used IXUS85 and settings from MDFB-080914 and it was MUCH faster
-
Where I can find FASTEST working motion capture script and settings for ELPH300? Default is too slow react for capture lightning. I used IXUS85 and settings from MDFB-080914 and it was MUCH faster
MDFB-080914 is widely regarded as the fastest script available (http://chdk.setepontos.com/index.php/topic,471.msg21328.html#msg21328 (http://chdk.setepontos.com/index.php/topic,471.msg21328.html#msg21328) ).
As far as setting go, you have to experiment. Newer cams seem to be slower than older cam, you can do some testing using information in this thread : http://chdk.setepontos.com/index.php?topic=9366.msg96633#msg96633 (http://chdk.setepontos.com/index.php?topic=9366.msg96633#msg96633)
-
I read about lua script engine faster than uBasic, in this case it does not help much, does it?
I think default MD script has messed up parameters or dont work properly with it settings,
I had try MDFB-080914 (VideoButtonModels) and had quick lack
Cameras was on different sectors so no right comparison, but anyway I dont see big improvements, despite CMOS and newer CPU in elph300
This cloud was rich of horisontal lightings.
with eelph300
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fthumb%2F6%2F66%2FLightning_IMG_1615.jpg%2F256px-Lightning_IMG_1615.jpg&hash=16143df703404a7818f89c6accdd8f73) (http://commons.wikimedia.org/wiki/File%3ALightning_IMG_1615.jpg)
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fthumb%2F1%2F1d%2FLightning_IMG_1641.jpg%2F256px-Lightning_IMG_1641.jpg&hash=46e226a40b13407d995740be2dc4a90c) (http://commons.wikimedia.org/wiki/File%3ALightning_IMG_1641.jpg)
ixus85 MDFB-080914
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fthumb%2F3%2F38%2FLightning_IMG_9489.JPG%2F256px-Lightning_IMG_9489.JPG&hash=760fd88f723cf127cb5fa044663ef26e) (http://commons.wikimedia.org/wiki/File%3ALightning_IMG_9489.JPG)
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fthumb%2Fb%2Fb3%2FLightning_IMG_9486.JPG%2F256px-Lightning_IMG_9486.JPG&hash=43bcae6ecaf161dc71739ec929eac789) (http://commons.wikimedia.org/wiki/File%3ALightning_IMG_9486.JPG)
and in the end capture of ball lightning (exposure 1s)
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fthumb%2F5%2F54%2FLightning_IMG_9492.JPG%2F256px-Lightning_IMG_9492.JPG&hash=acf724895a024d457521213bdbb49ad8) (http://commons.wikimedia.org/wiki/File%3ALightning_IMG_9492.JPG)
-
I read about lua script engine faster than uBasic, in this case it does not help much, does it?
The default CHDK script yield settings for Lua allow it run faster than uBASIC. However, this can be changed under script countrol : http://chdk.wikia.com/wiki/Script_commands#set_yield (http://chdk.wikia.com/wiki/Script_commands#set_yield) for uBASIC or Lua.
Regardless of that, both uBASIC and Lua call the same MD script function, which is written in "C" and they will thus have the same motion detection capture performance.
I think default MD script has messed up parameters or dont work properly with it settings,
The default settings need to be tuned for each application and specific camera. For example, not everyone wants to photograph lightening.
I had try MDFB-080914 (VideoButtonModels) and had quick lack
Some very nice shots!
-
The default settings need to be tuned for each application and specific camera
I read this simple script and see it has no check of (Trigger Delay<measure_interval) , which may cause continues shooting if novice does not understand what means "Trigger Delay". Also why default script (that is first to use by novice) does not show review of all capabilities (that may be adjusted to tasks by choosing more special scripts later)?
-
I read this simple script and see it has no check of (Trigger Delay<measure_interval) , which may cause continues shooting if novice does not understand what means "Trigger Delay".
I don't believe that matters. Trigger delay is just an intiial delay time that the script spends after md_detect_motion() is called. As the the MD code scans the LCD display buffer looking for motion, this give the display a little time to "settle". The measure_interval parameter determines how often the display buffer is scanned after the Trigger Delay has completed. The length of one has no effect on the other.
Also why default script (that is first to use by novice) does not show review of all capabilities (that may be adjusted to tasks by choosing more special scripts later)?
Those eight scripts were designed to be as short as possible and still usable. But at the last update, I added the two user @parameters that actually matter when adjusting MD response as people seem to be having a hard time with it. After that its up to the user to decide whether to modify those scripts or download better ones.
-
I just started with CHDK on my Elph 300 HS. Really good so far. Being able to shoot Raw with this tiny camera is great.
Has anyone created a Lens Profile to use in Lightroom/Photoshop? I searched the Adobe Lens Profile Downloader tool but none were available there.
Thanks.
-
Has anyone created a Lens Profile to use in Lightroom/Photoshop? I searched the Adobe Lens Profile Downloader tool but none were available there.
msl collected some camera and lenses profiles: Adobe camera & lens profiles (http://chdk.setepontos.com/index.php?topic=9268.msg95545#msg95545)
-
thanks for the quick reply.
i also found that user: rau89 posted a lens profile to this thread earlier: http://chdk.setepontos.com/index.php?topic=6341.msg84311;topicseen#msg84311 (http://chdk.setepontos.com/index.php?topic=6341.msg84311;topicseen#msg84311)
i'll try both of them out and see which works better.
another question:
my main reason for getting CHDK was to improve image quality taking pictures in Raw and processing them using Lightroom---do you guys note any difference? or is Canon's default jpeg processing good enough?
Thanks
-
my main reason for getting CHDK was to improve image quality taking pictures in Raw and processing them using Lightroom---do you guys note any difference? or is Canon's default jpeg processing good enough?
This has been the subject of much debate on this forum. To be blunt, Canon's jpg processing is usually pretty darn good. Still, a RAW image gives people a chance to optimize images to suit themselves. It just seems to me like a lot of work for not a lot of return compared to Canon JPG - IMHO.
-
With my A4000, the barrel distortion correction isn't perfect, and the white balance can be off by quite a bit. I also intend to use it for digitizing books, and JPEGs are not optimal for that. So, RAW is the safe option, though much more work.
-
my main reason for getting CHDK was to improve image quality taking pictures in Raw and processing them using Lightroom---do you guys note any difference? or is Canon's default jpeg processing good enough?
This has been the subject of much debate on this forum. To be blunt, Canon's jpg processing is usually pretty darn good. Still, a RAW image gives people a chance to optimize images to suit themselves. It just seems to me like a lot of work for not a lot of return compared to Canon JPG - IMHO.
thanks for the reply. thats what i figured also. however, the nerd in me still would like to give it a shot and see for myself. i am hoping that through this process, even if i end up reverting back to jpeg for simplicity sake, that i will get to learn a new software (lightroom) which i might end up using for my jpeg editing, and hopefully my overall photography will improve. i'm not a pro at all, just an average guy interested in taking better pictures. at some point, i'd also like to take some timelapse and try out bracketing/HDR.
cheers
-
thanks for the reply. thats what i figured also. however, the nerd in me still would like to give it a shot and see for myself. i am hoping that through this process, even if i end up reverting back to jpeg for simplicity sake, that i will get to learn a new software (lightroom) which i might end up using for my jpeg editing, and hopefully my overall photography will improve. i'm not a pro at all, just an average guy interested in taking better pictures. at some point, i'd also like to take some timelapse and try out bracketing/HDR.
Playing with RAW/DNG to see what you can do is what CHDK is all about. Especially if you are willing to take the time to experiment and learn. And you will get different effects than the default jpgs - whether they are better or not is "in the eye of the beholder".
Timelapse, HDR, 3D, USB remote, super high speed, very low speed, and Motion Detect (lightening or wildlife) fit into the fun experimental category too.
Good to see you have the right attitude about it all.
-
How camera switch "auto" affect to CHDK function?
How to set continues mode and fast burst mode by script?
-
Hello!
I have just tested CHDK (1.1) on my IXUS 220 HS and there is one little but annoying bug: when I power it on with the "play" button, it does start in shooting mode, and not playback mode (with the lens opening).
François.
-
Can I confirm that there is no exposure lock in video even with CHDK ?
-
Has anyone tried the lock exposure script written here for video yet??
http://chdk.setepontos.com/index.php?topic=5295.100 (http://chdk.setepontos.com/index.php?topic=5295.100)
-
Good news. Exposure lock works in movie recording when the Fast EV switch is enabled. Unfortunately I can't tell what the shutter and iso are at, but I guess it's a step forward.
-
How does video quality at 1080p compare with the S100 - with the quality turned all the way up ?
-
Hello
I've just discovered CHDK and installed it on my Canon IXUS220.
I can get it running, but I can't find how to do a manual focus...
In ALT mode I can turn "manual focus" On, but from this point I'm stuck...
If I press "DISP." twice, the camera freezes. If I use the zooming knob, the camera also freezes...
I'm using firmware version 1.01G...
Does anyone got a clue?
Thanks, Pidgey!
-
Simply put, the whole SD overrides system in CHDK is a bit of a mess. Some things work well in some cameras but not others. Some things crash but others do not. It's kind of random how well any particular camera will work. Feel free to play around with it but you may find it a frustrating experience. Sorry.
There has been a lot of work this year to fix the ability of scripts to focus manually with CHDK 1.3.0 but the menu / UI code has not yet been addressed. And even when it does get worked on, results to date suggest it will be better but still somewhat variable how well it will work from camera to camera.
Incidentally, are you trying to use the SD overrides options in the CHDK menu or simply the "shortcuts" in the < ALT > screen?
-
Incidentally, are you trying to use the SD overrides options in the CHDK menu or simply the "shortcuts" in the < ALT > screen?
Aha! The SD override option in the menu WORKS!
Thanks for helping!
-
Odd. Upgraded from 1.2 to latest 1.3.0-3804 and now alt mode is not working. It simply starts recording video. Anyone else experienced this?
I have 100c firmware version.
----
edit: it's play button since 1.3
-
Good news. Exposure lock works in movie recording when the Fast EV switch is enabled. Unfortunately I can't tell what the shutter and iso are at, but I guess it's a step forward.
I have 100c version And I tried to enable Fast EV switch. But it still locks only in play mode, when I press set for recording autofocus kicks in.
Also is it possible to manually lock focus with hardware buttons. I know it's built into canon orifinal firmware but I forgot what is the combination of keys. I need this for doing some sunrise time-lapse videos.
edit: after reading orignal docs for camera -> halfpress shutter button and then left button (macro)
-
I am having a odd problem with long exposures and noise reduction. It appears that noise reduction won't take place when I use any form of timer. But, when I just press the shutter with no timer, noise reduction takes place.
Here is my setup
- camera firmare 101c
- old, newest stable, and newest development (1.5.0) chdk tried
- set Tv override to 1 a minute exposure
- using averaging noise reduction in DNG 1.1
- dark frame subtraction ON from enhanced photo ops menu
- by just pressing shutter with no timer - long exposure noise reduction happens with an equally long exposure done after main exposure
- when camera's timer is used, or the intervalometer script is used, - no long exposure noise reduction happens
can anyone else replicate this problem? Or, am I doing something wrong?
one more note - it may be other overrides that are getting messed up as well when using a timer.
-
Or, am I doing something wrong?
Nope. Looking at the code, the dark frame override was never implemented on this camera >:(
capt_seq_hook_set_nr is commented out in every capt_seq, and probably in the wrong place. I may be able to come up with a build to test, but it will be a few days at least.
The remote and raw hook placement are also suspect.
-
Thank you for checking! Was starting to go bonkers trying different settings. I would be happy to test a new build when ready.
-
Hi,
A test version in attachments.
The capt_seq.c is based on ixus310 code.
-
Thank you for the test file. Not sure what I need to do with the patch file - I assume it is already incorporated into the test chdk code.
I am trying to get to DNG 1.1, but I need to create the bad pixel file first. When I try to create that bad pixel file, it fails every time. Or, loops over and over.
So I forget trying to set dng 1.1 and leave it at DNG 1.3 - that is unfortunate.
Then I tried long exposure without timer or intervalometer:
- dark frame off - no noise reduction occurs - good!
- dark frame on - noise reduction occurs - good!
Then I tried long exposure with timer or intervalometer:
- dark frame off - no noise reduction occurs - good!
- dark frame on - noise reduction occurs! - ***very good!***
I will try again to see if I can generate a badpixel file so that I can use DNG 1.1
This is definitely good progress - Thanks!
note - tried again to create that badpixel file and failed.
-
Thank you for the test file. Not sure what I need to do with the patch file - I assume it is already incorporated into the test chdk code.
Yes, the patch is for other developers to look at if they want.
I would be surprised if these changes made badpixel.bin generation fail, but you could try going back to the autobuild to test. badpixel.bin generation failing somewhat randomly on some cameras is an issue that has been around for a long time. It's possible you will have more luck if you take a few shots manually first to let the sensor temperature stabilize a bit.
-
Went back and loaded the autobuild - no problems creating the badpixel file.
Loaded the new test version again - can't build the badpixel file. The script itself seems to behave differently (erroneously)
-
Went back and loaded the autobuild - no problems creating the badpixel file.
Interesting. Can you report the free memory value shown by "Miscellaneious->Show Memory Info" for both builds.
Loaded the new test version again - can't build the badpixel file. The script itself seems to behave differently (erroneously)
Are you running a script, or using the built in badpixel.bin creation option in the raw menu? The script is obsolete and should not be used.
What is the output when you try to create badpixel.bin? If it disappears too quickly, you can see it in
"Miscellaneous->Console->Display last console"
When it succeeds, it should show the number of badpixels. It would be helpful to know that, as well as the output in the case it doesn't work.
-
Under the Raw menu, I am using 'Create badpixel.bin'
-----
For the test code:
Free Memory: 608824 bytes
CHDK size: 134404 bytes
loaded at: 0x1774ec
Under Console:
Wait please...
This takes a few seconds,
don't panic!
badpixel.bin failed
Please try again
------
For the autobuild:
Free Memory: 581040 bytes
CHDK size: 133748 bytes
loaded at: 0x1774ec
Under Console:
Wait please...
This takes a few seconds,
don't panic!
badpixel.bin created
Bad pixel count: 11417
-----
-
Hi, I forgot to patch boot.c, new patch and test version.
Please test and report.
-
Hi, a new test file (version 3), this time boot.c was rewritten using code_gen.c to use the patch in other firmware versions.
Please test and report.
-
Thanks for the new version. I tested version 3 - and there are some issues:
I can create the bad pixel file - which is good
However, once again dark frame noise reduction on long exposures fails when the timer is used - this is bad.
Correction - it fails when dfnr is set to 'auto' and timer is used. (even though dfnr occurs when timer is not used)
So, I can force the dfnr to occur by setting the mode to 'on' but 'auto' doesn't do it.
Not a huge issue, just a little strange.
-
Hi, new version. task_DvlpSeqTask removed.
-
Thanks for the new version. This new version I believe works similar to the previous version:
badpixel file - works, can create it
For long exposures:
dfnr - works in auto when not using timer
dfnr - does not work when in auto and using timer
dfnr - works when forced on
-
Will these changes be going into the autobuild?
-
Hi, sorry, during the next two weeks I wont have acces to my development pc and I can't work to fix the bugs.
If there is a developer who can help before that, the patches are in the attachments.
-
Hello again - anyone available to put the fixes into the release version?
just one minor issue remains:
dfnr - does not work when in auto and using timer
-
Hi, I'll write the patch for other firmware versions and I'll commit the changes during this week.
-
Thank you!
-
The changes were committed to trunk rev. 2931 (https://app.assembla.com/spaces/chdk/subversion/commits/4931).
-
Test version with filewrite support.
-
Test version with filewrite support.
Upon pluging the USB cable into the camera it crashes.
It does say:
A camera error was detected
Will shut dow automatically
Restart camera
E41which I guess the attached ROMLOG.txt means by the final
00001200: UI:EmergencyShutDownDisplay
-
http://chdk.setepontos.com/index.php?topic=6341.msg77822#msg77822 (http://chdk.setepontos.com/index.php?topic=6341.msg77822#msg77822)
indicates that the HARDWARE DEFECT!! ShutdownReason[9] ErrorNo[41] isn't new. Without being able to connect to the camera via PTP FWT is kind of hard to test...
-
Thanks for the report.New version with changes in platform_kbd.h KEY_MASK0 was apparently wrong.
-
Thanks for the report.New version with changes in platform_kbd.h KEY_MASK0 was apparently wrong.
Same effect still present.
-
And still present :haha continued from https://chdk.setepontos.com/index.php?topic=13893.msg141785#msg141785
Yes I meant to imply that by " crashed when CHDK is loaded and USB cable gets plugged in", I should have been more verbose. I tried without CHDK and it does not show any odd behaviour.
I expected as much, but wanted to be sure. Turns out this is an old problem, as you noticed last time around https://chdk.setepontos.com/index.php?topic=6341.msg77822#msg77822
Here's a test build. I don't expect it to work (fixes same keymask issue nafraf and philmoz identified) but also displays some debug info.
Assuming the the problem isn't fixed, try enabling USB remote in CHDK settings and connecting to a PC. If it doesn't crash, the PC should not see it, and the USB value on the display should change from 0 to 1.
edit: now with ∞% more file attachment
-
Assuming the the problem isn't fixed, try enabling USB remote in CHDK settings and connecting to a PC. If it doesn't crash, the PC should not see it, and the USB value on the display should change from 0 to 1.
Nope, it's not fixed but what you write works. I see the 1 in USB-Remote mode. If I leave the cable plugged and disable Remote the cam crashes the second I leave ALT mode, so when the change becomes effective. Are values P0 through P2 of relevance to you?
-
A couple of things to try.
- What happens if the USB data lines are not connected? You could try either a USB remote cable or an older 5V USB "charger" that's missing the data lines.
- Does it crash when CHDK was started using the "firm update" method on an unlocked card?
-
- Does it crash when CHDK was started using the "firm update" method on an unlocked card?
No... Who'd a thunk it?
EDIT: But that is not because it would work. It displays USB:1 but the PC does not see the camera and CHDKPTP can't connect to it. The camera does switch to play mode upon USB-Cable insertion, after loading CHDK via FW-Update the cam is in rec mode. Switching to play before US-Plug-in changes nothing.
-
- Does it crash when CHDK was started using the "firm update" method on an unlocked card?
No...
What about locking a card without CHDK (removing diskboot.bin) and connecting USB?
-
A couple of things to try.
- What happens if the USB data lines are not connected? You could try either a USB remote cable or an older 5V USB "charger" that's missing the data lines.
OK, I have dug out a USB remote cable with button cells to give the 5V. If I use that and Remote is not enabled in CHDK I can briefly depress the shutter button and the camera will go to play and come back out of it. I can depress alittle longer so that I see the USB 1 display in play mode for half a second and it will come out unharmed if I depress and hold it goes to play mode and crashes after like 1 sek. New Romlog attached in case this crashes differently with only power lines and no data lines...
-
What about locking a card without CHDK (removing diskboot.bin) and connecting USB?
No problems. CHDKPTP will connect but since there is no CHDK the PTP versions don't match and nothing wrks, just saying it finds the camera with the LibUSB driver and connects ok.
-
- Does it crash when CHDK was started using the "firm update" method on an unlocked card?
No... Who'd a thunk it?
EDIT: But that is not because it would work. It displays USB:1 but the PC does not see the camera and CHDKPTP can't connect to it. The camera does switch to play mode upon USB-Cable insertion,
Did you disable USB remote before trying this? USB remote normally disables PTP completely.
after loading CHDK via FW-Update the cam is in rec mode. Switching to play before US-Plug-in changes nothing.
So if you start the camera in playback and firmware update, it switches to rec when the update loads?
With diskboot enabled, does it start in rec if you short press the play or power button?
-
With diskboot enabled, does it start in rec if you short press the play or power button?
Yes it does. That should be the catch of the day...
-
- Does it crash when CHDK was started using the "firm update" method on an unlocked card?
No... Who'd a thunk it?
EDIT: But that is not because it would work. It displays USB:1 but the PC does not see the camera and CHDKPTP can't connect to it. The camera does switch to play mode upon USB-Cable insertion,
Did you disable USB remote before trying this? USB remote normally disables PTP completely.
Yes I just re-iterated this. Remote is off.
When I start the camera in Play, and load CHDK by FW-update the cam goes to Rec. If I then insert Usb cable, the camera goes to Play mode. The USB readout in your test build goes to 1. The camera is not seen by the PC. Remote is still off. I can even when USB-cable is in go to ALT mode and look at the remote stuff. If I turn Remote on, the camera goes back to Rec. If I turn Remote off again the camera goes back to Play like it did before, not being seen by the PC.
-
With diskboot enabled, does it start in rec if you short press the play or power button?
Yes it does. That should be the catch of the day...
Thanks. That's a bug, although maybe not connected to our bug. If you hold the power or play button when booting with diskboot, does it start in play mode?
If so, try connecting to USB that way, without switching to rec.
When I start the camera in Play, and load CHDK by FW-update the cam goes to Rec. If I then insert Usb cable, the camera goes to Play mode.
What happens if you load with firm update and switch the camera to play with the play button before plugging it in?
Are values P0 through P2 of relevance to you?
Those are physw_status values. Don't think we need them at this point.
-
With diskboot enabled, does it start in rec if you short press the play or power button?
Yes it does. That should be the catch of the day...
Thanks. That's a bug, although maybe not connected to our bug. If you hold the power or play button when booting with diskboot, does it start in play mode?
No, hold Power on goes to Rec. Hold play starts the Camera briefly and after having shown CHDK splash screen it shuts off again.
This looks like plain power down, not like a crash. I set the clock to 2222 and there was no fresh ROMLOG after this, what I got was old.
I naively thought this might be related to "our bug". I thought oh, what if upon USB plug-in switching to play does not work as it should?
-
Hold play starts the Camera briefly and after having shown CHDK splash screen it shuts off again.
If you release play after the splash screen, does it boot in play mode?
Normal behavior with CHDK is supposed to be: Clicking either button starts in play mode, long press power starts in rec. The reason this differs from normal firmware behavior is that once CHDK boots, the information about which button was used to start is lost unless it's still held down.
I naively thought this might be related to "our bug".
It could be, in a roundabout way. Here's a build which might fix the startup logic
-
If you release play after the splash screen, does it boot in play mode?
Yes that is possible with the current trunk build. Even when started in Play like this the crash on UB-Plug-in occurs.
Here's a build which might fix the startup logic
That works, it now starts in Play, long press of Play button still shuts down the camera, starting using either button the USB-Crash is still with us.
-
That works, it now starts in Play, long press of Play button still shuts down the camera,
That's normal. Just to confirm, long press power does switch to rec mode?
starting using either button the USB-Crash is still with us.
:( Not too surprising.
-
Just to confirm, long press power does switch to rec mode?
Yes
-
Here's another test build. I don't expect this to fix it, just cleans up some extraneous but probably harmless stuff in loader
-
Here's another test build. I don't expect this to fix it, just cleans up some extraneous but probably harmless stuff in loader
Confirmed, the USB-Crash is still there.
The new version boots into play with both short presses to Play and Rec, goes into Rec if Rec button is being held during power on, turns off if Play is being held. So seems you did not break anything in the clean-up.
-
The new version boots into play with both short presses to Play and Rec, goes into Rec if Rec button is being held during power on, turns off if Play is being held. So seems you did not break anything in the clean-up.
Thanks. I checked those changes in.
I also removed KEY_DISPLAY from the keyboard definition and ALT options. This was defined as an alias for the down button which really makes no sense. down arrow as an alt button would be quite unusable.
I'm at a bit of a loss for the PTP crash.
* The platform ASM code is mostly code-gen, so risk of typos should be low
* The USB bit is correctly identified, add_ptp_handler is correctly identified.
* Loader code seems normal. It had the "SD card power cycle" logic, incorrectly referencing an LED MMIO. Taking that out had no impact on the crash
* Free memory was reported to be reasonable in earlier posts.
Other ideas:
* Disable CHDK tasks and see if the effect is still there
* Maybe there's something in the function commented out for diskboot that needs to be called, similar to some SD card issues? However, it looks pretty normal to other cameras of the same era (2011, Digic 4, Dry 47, propset 4) as does the rest of the boot / restart code
* Try to figure out where the HardwareDefect call originates and work back from that
* something bad elsewhere trashing memory
c1oud seemed to report that it was fixed in https://chdk.setepontos.com/index.php?topic=6341.msg81752#msg81752 but the relevant changes were apparently committed.
I feel like it should be something headslappingly obvious, but I don't see it yet...
-
* Disable CHDK tasks and see if the effect is still there
Here's a test build for this one. It has *all* CHDK hooks disabled, so there will be no CHDK splash screen or UI, and it will show card locked for autoboot. The play/rec behavior at power on should still be CHDK.
-
* Disable CHDK tasks and see if the effect is still there
Here's a test build for this one. It has *all* CHDK hooks disabled, so there will be no CHDK splash screen or UI, and it will show card locked for autoboot. The play/rec behavior at power on should still be CHDK.
Yes it does show card is locked. It still crashes on USB 5V Power. The remote cable is enough it does not need data lines, shows play briefly and then the restart camera error message - did I show a pic of that before?
-
Could we be chasing ghosts? I'll re-dump the firmware. If there is a difference either mine is broken or the archived one is.
Edit: FW deleted.
-
Here we go, other half added to previous post.
Forum did not accept *.oo1 *.002 hence compressed again...
Edit: FW deleted.
-
Yes it does show card is locked. It still crashes on USB 5V Power. The remote cable is enough it does not need data lines
Thanks. That's a useful data point. Suggests either something is wrong in the loader/boot code, or this model has some particular requirements for the USB hardware initialization.
Could we be chasing ghosts? I'll re-dump the firmware. If there is a difference either mine is broken or the archived one is.
I don't think so, multiple people reported this exact error for this model (on multiple different fw versions) going back to 2011 https://chdk.setepontos.com/index.php?topic=6341.msg77822#msg77822
You can upload dumps to a file hosting site (google drive, dropbox, box.com whatever) rather than posting multiple parts here.
-
* Maybe there's something in the function commented out for diskboot that needs to be called, similar to some SD card issues? However, it looks pretty normal to other cameras of the same era (2011, Digic 4, Dry 47, propset 4) as does the rest of the boot / restart code
@koshy Low hopes for this one, but here's a test of it anyway.
-
Low hopes for this one, but here's a test of it anyway.
Yes, sadly the remote shutter cable is still enough to kill it. All as before in that regard.
-
Yes, sadly the remote shutter cable is still enough to kill it. All as before in that regard.
Thanks. Moving on to
* Try to figure out where the HardwareDefect call originates and work back from that
Can you check on a trunk build:
Under CHDK Miscellaneous -> tools -> Memory browser, set the address to 0x2488.
Report the value after DWORD
HardwareDefect(0x00290000) is only called from one function I could find: ff85d730 (ixus220 101a). That function is called by two different functions ff831b38 and ff85908c. Both of these are clearly related to the USB layer, referencing "DiUSB20DM.c" and interrupt handler "DiUSB20Hal" respectively. They are eventually called from TrnsCtrlTask and the function that creates it.
Equivalent functions on elph130 are ff178e68 (calls HardwareDefect) ff07cccc ("DiUSB20DM.c") and ff07c3cc ("DiUSB20Hal"). Incidentally, elph180 appears to use a different driver, the strings are "DaUSB20..."
ff85d730 checks if the variable at 0x2488 is and returns if it is, otherwise, sets it to 0 can calls HardwareDefect. On elph130, the equivalent variable (0x6558) seems to be zero both before and after USB is plugged in.
edit:
There are a couple functions that set the 0x2488 variable: ff85d6f4 and ff85d720. The second one is called from ff85908c, which also conditionally calls the one the triggers HardwareDefect later.
-
@koshy:
Looking back, I'm not clear if the PTP crash bug was confirmed when loading CHDK using firm update, from an unlocked card. Initially, there were [urlhttps://chdk.setepontos.com/index.php?topic=6341.msg141800#msg141800]issues with the camera switching to rec[/url] but that should be fixed now.
So if it isn't isn't confirmed, can you try on the current trunk:
CHDK installed, card unlocked.
Run firm update to start CHDK
Plug in USB
-
So if it isn't isn't confirmed, can you try on the current trunk:
CHDK installed, card unlocked.
Run firm update to start CHDK
Plug in USB
Nothing happens. The PC does not see the camera. Remote is not enabled.
Want a test build with the USB bit visible again?
Without CHDK, the PC sees the camera just fine, with the card locked we get the crash.
-
Can you check on a trunk build:
Under CHDK Miscellaneous -> tools -> Memory browser, set the address to 0x2488.
Report the value after DWORD
1
Is it just me or does the memory browser have a small bug? You start out with increments 4 which is the minimum stepping you can use, using the zoom setting you can select larger increments. While 100 and 1000 and so forth are multiples of 4 the second choice - 10 - is not. So, I got myself entangled in a place where I could not reach 0x2488 but only 0x2486 and I then had to fiddle with the 10 again to correct this. Long story short: Should the ten be a twelve or an eight?
Edit: I figured I'd try this just in case. When I display the 0x2488 value and then plug in the USB cable the value's display stays at one until the screen goes black from the crash. I can't see it going to 0. It still migh in the moment the screen goes black.
-
Nothing happens. The PC does not see the camera. Remote is not enabled.
:blink:
That's interesting. Can you try the same test with A2200?
Can you check on a trunk build:
Under CHDK Miscellaneous -> tools -> Memory browser, set the address to 0x2488.
Report the value after DWORD
1
:blink:
That's interesting too. I expected it would only be set somewhere immediately in the connection process, so you probably wouldn't see it. My impression is it's some kind of error flag.
Is it just me or does the memory browser have a small bug? You start out with increments 4 which is the minimum stepping you can use, using the zoom setting you can select larger increments. While 100 and 1000 and so forth are multiples of 4 the second choice - 10 - is not. So, I got myself entangled in a place where I could not reach 0x2488 but only 0x2486 and I then had to fiddle with the 10 again to correct this. Long story short: Should the ten be a twelve or an eight?
It's all hex, so 0x10 is 16. You should not be able to get 0x2486?!? If you have "0x10" selected, the last digit should not change. It certainly doesn't on my cams.
On some of these displays it can be hard to tell some digits like B, 8, 0 apart.
Edit: I figured I'd try this just in case. When I display the 0x2488 value and then plug in the USB cable the value's display stays at one until the screen goes black from the crash. I can't see it going to 0. It still migh in the moment the screen goes black.
Yeah, I was originally going to suggest that but realized it would probably be ambiguous.
-
Is it just me or does the memory browser have a small bug? You start out with increments 4 which is the minimum stepping you can use, using the zoom setting you can select larger increments. While 100 and 1000 and so forth are multiples of 4 the second choice - 10 - is not. So, I got myself entangled in a place where I could not reach 0x2488 but only 0x2486 and I then had to fiddle with the 10 again to correct this. Long story short: Should the ten be a twelve or an eight?
It's all hex, so 0x10 is 16. You should not be able to get 0x2486?!? If you have "0x10" selected, the last digit should not change. It certainly doesn't on my cams.
On some of these displays it can be hard to tell some digits like B, 8, 0 apart.
Thank you, I have no idea what I saw, a trick of either the mind or the light I guess. Or deprivation of sleep...
-
Nothing happens. The PC does not see the camera. Remote is not enabled.
:blink:
That's interesting. Can you try the same test with A2200?
Sure, loaded trunk CHDK 5296 on A2200 by FW update, plugged a USB cable in connected with CHDKPTP, switched to Rec nothing out of the ordinary. Figured that's nuts and with earlier confusion re-tried Ixus 220 in the same way but no nothing. No crash no, camera on Windows device manager, none for CHDKPTP. Without CHDK CHDKPTP shows the cam but says the expected host:2.8 cam 1 and warns about incompatibility etc. upon connect.
-
Here's another test build. Please report the values shown for AD, M1 and M2.
No need to try connecting USB.
Sure, loaded trunk CHDK 5296 on A2200 by FW update, plugged a USB cable in connected with CHDKPTP, switched to Rec nothing out of the ordinary. Figured that's nuts and with earlier confusion re-tried Ixus 220 in the same way but no nothing. No crash no, camera on Windows device manager, none for CHDKPTP.
Thanks. A2200 behavior is expected.
I was using A2200 as a comparison since it's another dryos 47, digic IV camera released around the same time. Comparing the firmware with Ghidra versioning (https://chdk.setepontos.com/index.php?topic=13718.msg140436#msg140436), much of the reboot related code is identical. I did find one notable difference: On Ixus 220, SD power is apparently controlled by i2c, while on a2200, it's controlled by direct MMIO like earlier cameras.
The presence of i2c seems to be related to HDMI support, which ixus220 has and a2200 doesn't. None of this obviously relates to the USB problem, but
ixus310_elph500hs is also dryos 47 and has the same i2c functions, and doesn't have the USB crash ixus220 does. Your PTP test of ixus310 did have the motionvector crash in remoteshoot, but that's definitely a different thing. Nothing jumps out as different in the ixus310 CHDK port. I'll do some comparison of the Canon firmware later.
-
Here's another test build. Please report the values shown for AD, M1 and M2.
When CHDK is invoked by FW Update all four values are 0 (or 0x00000000)
Upon USB Plug-in
AD: cycles 0x1ff through 0x205
M1: 0x10100
M2: 0
USB: 1
Camera not seen by PC.
When CHDK is loaded on boot with a locked SD card. M2 is 0x1 instead of 0.
-
Here's another test build. Please report the values shown for AD, M1 and M2.
When CHDK is invoked by FW Update all four values are 0 (or 0x00000000)
Upon USB Plug-in
AD: cycles 0x1ff through 0x205
M1: 0x10100
M2: 0
USB: 1
Camera not seen by PC.
When CHDK is loaded on boot with a locked SD card. M2 is 0x1 instead of 0.
Thanks.
Additional details, in case anyone has ideas:
AD is the A/D channel that returns USB +5 voltage (0x1ff = 511, 5.1 volts?). This is checked by some code related to the variable at 0x2488 that triggers the HardwareDefect. Specifically ff85d6f4 calls ff860d24(11) which returns the value of MMIO 0xc0900054, which is the A/D value (with some fiddling) and sets *0x2488 = 1 if the value is < 0x15b (437). ff860d24 is also the underlying function of GetAdChValue
M1 is MMIO 0xc0720008. Some other code related to the 0x2488 checks this. On elph140, it's 0 when USB isn't present, and 0x24100000 when it is. It appears to go through some other values when USB is plugged/unplugged. Plugged into a powered hub with no computer attached, it's 0x20010200. Plugged into USB charger (presumably just +5v), it appears to be 0x00100000.
If CHDK USB remote is enabled, it stays 0.
Code around ff832104 checks for *(0xc0720008) & 0x100 and calls the ff85d6f4 function mentioned above if set. Some code around called from Restart also checks this for 0x100, skipping operations on other 0xc072* MMIOs if it's set.
Other code checks 0xc0720008 & 0x8000
I guess the 0xc072* MMIOs are maybe registers for the USB controller? Tracing back from these could maybe identify initialization code.`
M2 is the 0x2488 value.
-
CHDK installed, card unlocked.
Run firm update to start CHDK
Nothing happens.
NO Firrnware-Update visible in Canon-menu :o, never...
... because I had 2 .Fi2 files on the card ... :haha :lol
(101a, && no https://zadig.akeo.ie/) ... yet...
Overige parameters ->
Gebruikersmenu ->
Edit: There (on PC) is only the DCIM visible && *.FI2 files:
-
Zebra was sqeezed in screens upper/2. These lines are enough to fix it. :D
// from Ix265
int vid_get_viewport_display_xoffset_proper() { return vid_get_viewport_display_xoffset()<<1; }
int vid_get_viewport_display_yoffset_proper() { return vid_get_viewport_display_yoffset() * vid_get_viewport_yscale(); }
int vid_get_viewport_height_proper() { return vid_get_viewport_height() * vid_get_viewport_yscale(); }
int vid_get_viewport_fullscreen_height() { return 240 * vid_get_viewport_yscale();}
Default.Lua ==> Dutch; Edited palette ... :-*