The SX1 IS Porting Thread

pev69

reyalp

pev69
Also I am planning to change the GUI-drawing system, because at the moment it is a bit mixed up ...
I know, this all sounds so pompous, but I'll see what I can do 😀

Pompous or not, if you can do it, that would be GREAT. The gui system is a mess. FWIW, I found the variable that stores the current canon bitmap buffer for the SD990. This is listed in lib.c along with hints to finding it.

Hey, good, and thanks. I'm further encouraged now 😀

I'll try to look at the zebra stuff as soon as I can if none of the other devs get to it, but I'm going to be quite busy for the next few days 🙁

Great. Although it is a really small change, and does not change anything for other cameras (for which the CAM_HAS_VARIABLE_ASPECT is not defined), so you could just replace the files in the trunk right away 😉.

EDIT: Well, the only significant change for other cameras is that the buffer is cleared once it has been succesfully malloc'ed.

elorup

Thanks to all cracks starting that port! Great work and fascinating to follow the conversations. Keep on please.

I've played around with it a bit and also tried to get the Motion Detection scripts running (several ones from the CHDK site). Without any success. My SX1 IS always fired within some intervall even without any motion to detect.

Also changed the several parameter settings, but without getting the desired behaviour.

Has anyone of you had success with that already?

e.g.
http://chdk.wikia.com/wiki/UBASIC/Scripts:Lightning_script_--_Fudgey
http://chdk.wikia.com/wiki/UBASIC/Scripts:_Multipurpose_Motion_Detection
http://chdk.wikia.com/wiki/UBASIC/Scripts:_Lightning_Photography

Regards from Zurich
Eric

alexpreyer

I'm not sure if this thread is the right place to diskuss this, but here are my experiences.
Ich tried this one:

https://chdk.setepontos.com/d/471/87

And it worked for me. Tested not much, but the motion dectection worked.
You have to be careful, because most of the motion detect scripts are for digic II/III and not testet for the digicIV which the SX1 is having.

elorup

Hi alexpreyer,

thanks alot for your fast reply. Sounds very promising 😀 will move to a more appropriate place (https://chdk.setepontos.com/d/471/9) for further discussion on motion detection issues.

Regards,
Eric

pev69

It is still possible, that if the motion detection has problems in SX1, it is a porting issue, and therefore should be discussed here, at least if those of you who test it find no help in other MD threads in the forum. The variable aspect ratio may very well cause trouble there as well, and the viewport parameters may still be wrong. I have not tested these issues myself, but I will try to look into the MD code as well when I can. I have been rather busy with other things lately (last couple of days), so I have not been able to do much anything for CHDK.

fboesch

hi all! I was very quiet the last few days, due to private technical issues...the last three days I was forced to finally "Migrate", "Clean", "Consolidate", "Update", etc, etc my private Client-Server environment @home, and so my virtual "Dev" Environment was offline.

I'm still here and still working (if times allows me) on the "PS.FI2" (1st Prio) ....and after that other issues (Continous AF notworking - 2nd Prio)....

@elorup: As you may have read: the Shooting in Series with Autofocus "ON" will not work. Cam will crash. May be this is also the reason why your Motion Scripts do not work...? --> try to set the Cam in "AF only on first pic" Shooting and try the scripts again. Would be interesting to hear if this works out (for now)

reyalp

pev69
Okay, here's the zebra modification for trunk 744. Unzip under the trunk744 dir and let it replace the files.
The changes in code are in core\gui_osd.c in functions gui_osd_zebra_init and gui_osd_draw_zebra. Plus definitions added for CAM_HAS_VARIABLE_ASPECT (include\camera.h) and PROPCASE_ASPECT_RATIO (include\propset2.h).

EDIT: There is a slight esthetic dismissal 😀 in the current logic when in 4:3 mode: canon's own OSD elements are not drawn on the black bars when zebra is visible; this is particularly noticable if you comment out the line
#define ZEBRA_CANONOSD_BORDER_RESTORE 1
near the beginning of the file core\gui_osd.c (this should cause all of canon's own elements to show with zebra, not just borders as the define does). It is due to the fact that I added a condition that nothing is drawn on the black bars when any zebra is drawn 😀. Will correct it later.

I've added this, with some minor changes. SVN #752

In the future, please post a patch rather than a zip of modified files. It makes it much easier to apply if there are changes between when you submit your change and when I commit it.

Sei

Motion detection with fudgey's script works on SX1 (version 080914 for cameras with video button from this thread). Although to run it correctly I had to mask right and bottom cells. Cells from those areas actuate shots without reason. I think intervalometer is in some part "guilty" of this. During tests I have manage to obtain 80-100ms of minimum delay.

elorup

pev69
It is still possible, that if the motion detection has problems in SX1, it is a porting issue, and therefore should be discussed here, at least if those of you who test it find no help in other MD threads in the forum. The variable aspect ratio may very well cause trouble there as well, and the viewport parameters may still be wrong. I have not tested these issues myself, but I will try to look into the MD code as well when I can. I have been rather busy with other things lately (last couple of days), so I have not been able to do much anything for CHDK.

Sei
Motion detection with fudgey's script works on SX1 (version 080914 for cameras with video button from this thread). Although to run it correctly I had to mask right and bottom cells. Cells from those areas actuate shots without reason. I think intervalometer is in some part "guilty" of this. During tests I have manage to obtain 80-100ms of minimum delay.

@pev69: OK, so I'll stay here in this thread. I suppose that it is an issue of porting still.

@sei: I tried fudgey's script (version 080914) but my SX1 IS was firing with constant interval. I also gave the masking a try, but didn't find the correct values for that. ~~Would you be so kind to send me the settings for the script which worked for you?~~ Sorry, I masked left and right cells not right and bottom ones!!! That's it.

@fboesch: thanks for the suggestion. Hmm, I also tried the script in MF mode. But I will try it again and more systematically tomorrow evening.

mig25

I have a quetion regarding green light for AF/red eyes reduction... It is almoust all the time blinks just before made a picture without CHDK. Also during 10s delay it was blinking. Now with CHDK not doing this any more... Is that a bug ?

pev69

mig25
I have a quetion regarding green light for AF/red eyes reduction... It is almoust all the time blinks just before made a picture without CHDK. Also during 10s delay it was blinking. Now with CHDK not doing this any more... Is that a bug ?

Good find, I did not notice this with CHDK since I've been only testing (and debugging) other features (than standard shooting) of it for now 😀

It seems to be used as a debug led in some repeating part of the code, and this continually interferes with the normal operation. As a quick fix for now, you can comment out the debug_led function body in platform\sx1\lib.c, so the lines:
[tt]
void debug_led(int state)
{
*(int*)LED_PR=state ? 0x46 : 0x44;
}
[/tt]
become:
[tt]
void debug_led(int state)
{
// *(int*)LED_PR=state ? 0x46 : 0x44;
}
[/tt]

But this must also be somehow remedied more future-proof at some point (or just remove calls to debug_led in the code, dunno).

reyalp

debug LED should normally be something else, like the direct print LED.

Shooting raw (among other things) normally flashes the debug LED.

edit:
here's a build with the debug LED disabled. The video card in my normal dev machine died, so I can't find the correct LED easily.

sx1-200h-0.9.8.zip

203.72KB

elorup

Tried again fudgey's motion detection script last evening and used default values plus the mask right=2 and bottom=2. So the camera only used the 8 cells in the upper left part. It worked and didn't constantly fire. I threw things in the cameras field of view and it took pics. I set the SX1 to MF, then to AF. Worked the same, though I didn't test for differences in speed.

Will continue testing.

pev69

I tested the SX1 LEDs with the uBASIC set_led command and it is rather interesting what it can do in SX1! I did not find any documentation about set_led other than an old thing in wikia which says "ONLY for S3 (and S2 I guess)" and is not valid for SX1, so here goes. The working syntax for SX1 is:

set_led a b

where a is the LED number from 0 to 4 and b is the state for the LED. Note that set_led accepts a third argument (for compatibility's sake, I guess, it is brightness in some older cams) that is ignored in SX1. The LED numbers in SX1 are:

0: power button green
1: power button orange
2: card/busy (red)
3: print/shortcut (blue)
4: AF/red-eye/timer (bright green)

The state is the interesting part, as I found that it can be 0 to 6:

0: off
1: on
2: blinking 2 Hz (on shorter than off)
3: blinking really fast (about 5 Hz)
4: blinking about 2,8 Hz (on longer than off)
5: 3 fast blinks then off
6: blinking 1 Hz (about equal on/off times)

As a curiosity, combining different blinkings for the two power-button LEDs make for interesting more complex multi-color blinkings 😀

EDIT: Oh, about the implementation, those are all done by calling an original firmware function and the firmware then has a LED driver that implements the blinkings. The uBASIC command just maps the LED numbers a bit differently (a bit strange: those 0,1,2,3,4 become 4,5,7,8,9) and then calls _LEDDrive that is in firmware.

EDIT2: Argh, edited for AF LED, I had previously enabled the debug_led, which caused the AF LED seem not to respond to set_led.

Sei

elorup
Tried again fudgey's motion detection script last evening and used default values plus the mask right=2 and bottom=2. So the camera only used the 8 cells in the upper left part.

When I was trying this script a mask right=1, bottom=1 was enough even for 9x9 cells. For minimum delay try changing the dimension to 3x3 and mask 1 right and 1 bottom. Set "compare interval" to 1, and "trigger delay" to 0. This should give you delay=100 ms or less (I measured 80 ms). If you will get better results it post here or let me know with private message.

elorup

Sei
When I was trying this script a mask right=1, bottom=1 was enough even for 9x9 cells. For minimum delay try changing the dimension to 3x3 and mask 1 right and 1 bottom. Set "compare interval" to 1, and "trigger delay" to 0. This should give you delay=100 ms or less (I measured 80 ms). If you will get better results it post here or let me know with private message.

I made it down to 65 ms (some shots even 45 ms, several 50 ms) 😁 using the Motion detector speed test
Columns=3
Rows=3
Threshold=10
Compare interval=1
Pixel Step=10
Trigger Delay=1
Masking=1 (Right=1, Bottom=1)

Set the camera to MF mode

derrobbie

I think I stumbled upon a issue with the OSD in combination with CHDK 0.9.8-755.
Everything works like it should but when I try to flip the display the image is instantly being projected in a mirror image as soon as I start to move the display.
And only when I start to rotate the display, it flips back.
And when I do the same, only with the CHDK menu being displayed, the complete CHDK OSD disapears.

pev69

derrobbie
I think I stumbled upon a issue with the OSD in combination with CHDK 0.9.8-755.
Everything works like it should but when I try to flip the display the image is instantly being projected in a mirror image as soon as I start to move the display.
And only when I start to rotate the display, it flips back.

Oh dear, yes, it looks like the firmware draws the overlay also mirrored, when the display is flipped out and not rotated. Well, this should be rather easy to fix, since the display flip/rotate status is already known to the code. I'll see if I can squeeze some time to fix this also. Darn, I haven't gotten much anything done to CHDK lately. My intention is still to rework the whole gui-drawing system and now also including this fix + edge overlay + ... 😀, whenever I get myself to kick myself in the asss to devote the time...

And when I do the same, only with the CHDK menu being displayed, the complete CHDK OSD disapears.

Yes, this is due to the fact that the menu is not redrawn unless the selection/settings/menu level is changed. If you get this, you can confirm that you are still in the menu by clicking up/down and behold the menu comes back (in this case also mirrored) 😀. One more thing to change/fix in the gui.

fe50

pev69

derrobbie
I think I stumbled upon a issue with the OSD in combination with CHDK 0.9.8-755.
Everything works like it should but when I try to flip the display the image is instantly being projected in a mirror image as soon as I start to move the display.
And only when I start to rotate the display, it flips back.

Oh dear, yes, it looks like the firmware draws the overlay also mirrored, when the display is flipped out and not rotated. Well, this should be rather easy to fix, since the display flip/rotate status is already known to the code. I'll see if I can squeeze some time to fix this also. Darn, I haven't gotten much anything done to CHDK lately. My intention is still to rework the whole gui-drawing system and now also including this fix + edge overlay + ... 😀, whenever I get myself to kick myself in the asss to devote the time...

No bug/issue - just set "Reverse Disp." to OFF in the Canon menu (1st tab) 😉

pev69

Thanks, fe50, for reminding, I did not remember there was an option for this. This would need to be taken into account in the fix. Hmm, I don't see a propcase reported yet for this, darn, needs to be discovered.

« Previous Page Next Page »