A580 porting - minor progress - page 9 - General Discussion and Assistance

reyalp

14111

Re: A580 porting - minor progress

« Reply #80 on: 24 / February / 2009, 22:28:47 »

Advertisements

Quote from: mariush on 24 / February / 2009, 19:53:48

I've written a few lines in PHP and determined that the buttons (at least for left, up, down, right) are the same as in A720.

I don't understand why the camera would still say that the card is locked. Isn't the code supposed to hide this by modifying those three words physw?

Yes, but it may be a different bit than on the a720.

Quote

Code: [Select]
C:\CHDK\trunk>gmake clean makefile.inc:204: platform/a580/sub/101b: Permission denied makefile.inc:204: /makefile.inc: No such file or directory gmake: *** No rule to make target `/makefile.inc'. Stop.
The makefile.inc are in the right places so any clue why this would happen?

Set PLATFORM and PLATFORMSUB on the command line.

Logged

Don't forget what the H stands for.

maneck

1

Re: A580 porting - minor progress

« Reply #81 on: 25 / February / 2009, 16:43:43 »

Mariush, big thanks for the effort from another a580 owner!

Logged

mariush

63

Re: A580 porting - minor progress

« Reply #82 on: 26 / February / 2009, 16:46:50 »

well... I think I'm going to be stuck here for some time if I don't get a clue about what to do...

I've went again through all the keys and found that the KEY_SHOOT_FULL and KEY_PRINT different, so I commented out the whole keymap array and replaced it with my own, but with the corrected values.
so now it looks like this:

Code: [Select]

static KeyMap keymap[] = {
	{ 2, KEY_UP		, 0x00000010 }, 
	{ 2, KEY_DOWN		, 0x00000020 }, 
	{ 2, KEY_LEFT		, 0x00000080 }, 
	{ 2, KEY_RIGHT		, 0x00000040 }, 
	{ 2, KEY_SET		, 0x00000100 }, 
	{ 1, KEY_SHOOT_FULL	, 0x02000000 }, // was 0xC0000000
	{ 1, KEY_SHOOT_HALF	, 0x40000000 }, 
	{ 2, KEY_ZOOM_IN	, 0x00000004 }, 
	{ 2, KEY_ZOOM_OUT	, 0x00000008 }, 
	{ 2, KEY_MENU		, 0x00000200 }, 
	{ 2, KEY_DISPLAY	, 0x00000400 }, 
	{ 2, KEY_PRINT		, 0x00080000 }, // was 0x00000800
	{ 1, KEY_ERASE		, 0x00800000 }, 
	{ 0, 0, 0 }	
};

...and now it's strange but when I press keys they no longer update on the screen but when I press the shoot button I still get the seconds in the top right corner.

I really don't know where to continue from this point, to check what functions could fail and freeze the camera when I press the print key or when I switch to record mode.

I was thinking of adding one at a time functions like gui_batt_draw_osd() , gui_space_draw_osd() and so on, that appear several lines below in the same function where I added the debug code.

It just pisses me off that I have to take out and insert the card so many times. Why didn't you guys implement something like logging to a file (enabled/disabled with an ifdef or something) which could allow then to see what was the last function entered...

Logged

whim

2046
A495/590/620/630 ixus70/115/220/230/300/870 S95

Re: A580 porting - minor progress

« Reply #83 on: 26 / February / 2009, 17:58:12 »

Quote

Why didn't you guys implement something like logging to a file (enabled/disabled with an ifdef or something) which could allow then to see what was the last function entered...

pure guesswork on my part here, but isn't that what:

CAM_CONSOLE_LOG_ENABLED // Development: internal camera stdout -> A/stdout.txt

(defined in include/camera.h) is for ?

wim

Logged

*Wikia FAQ *GCC Compiler Shell for Windows

mariush

63

Re: A580 porting - minor progress

« Reply #84 on: 26 / February / 2009, 18:46:54 »

I didn't check, it could be.
But I guess it wouldn't help when it crashes inside a function like "EnterToCompensationEVF" becaus eyou wouldn't know from where it was called.
Or like kbd_process ... if i get an assert from memcpy or something i wouldn't know what function called from kbd_process caused it.

If there were functions like entered('EnterToCompensationEVF') and exited(); I would see in the created file right at the bottom something like:

kbd_process
-> kbd_use_up_down_left_right_as_fast_switch
-> -> EnterToCompensationEVF
EOF

Again I don't have a lot of experience with C but I assume that if the contents of these functions "entered" / "exited" would be in an ifdef then when compiling without that define they would be left out completely so there would be no speed/performance loss. It would be lots of help to debug stuff though.

Logged

reyalp

14111

Re: A580 porting - minor progress

« Reply #85 on: 26 / February / 2009, 22:02:50 »

Quote from: mariush on 26 / February / 2009, 16:46:50

It just pisses me off that I have to take out and insert the card so many times. Why didn't you guys implement something like logging to a file (enabled/disabled with an ifdef or something) which could allow then to see what was the last function entered...

Apparently no one else has felt the time expended and resulting mess in the code was a good trade against the benefit. If you feel differently, feel free to implement it.

Nothing is stopping you from writing to a file a various points. Writing a simple log function and spamming it in various places of interest should only take you a few minutes. I do this fairly frequently, but I wouldn't check it in because it's messy, specific to whatever problem I'm chasing, and not that much effort to do again if I need it.

CAM_CONSOLE_LOG does not do this. AFAIK it should capture the cameras own log output.

Logged

Don't forget what the H stands for.

mariush

63

Re: A580 porting - minor progress

« Reply #86 on: 27 / February / 2009, 15:28:28 »

I tried adding logging to file but obviously it didn't work, open returns invalid handle, probably because it detects the card locked.

I don't know how to make it ignore the lock card indicator, I followed exactly how A720 firmware was, almost all key codes are correct (and if I change them they no longer update on screen at all)

By the way, I created a debug.c and a debug.h file and tried calling the functions from conf.c after i added at the start #include "debug.h" but the compile process didn't even touch the new files. I ended up adding the logging functions to conf.c.
Is there some special process to add files in the source?

Logged

reyalp

14111

Re: A580 porting - minor progress

« Reply #87 on: 27 / February / 2009, 16:39:50 »

Quote from: mariush on 27 / February / 2009, 15:28:28

I tried adding logging to file but obviously it didn't work, open returns invalid handle, probably because it detects the card locked.

Uh, then how would the magic logging function you think we should have added work ?

There will be a bit in physw_status that indicates the card is locked. You need to figure out which bit it is. You ought to be able to find this from the firmware: the strings "SD Protect" and "SD Not Protect" take you right to a function that checks.

Quote

By the way, I created a debug.c and a debug.h file and tried calling the functions from conf.c after i added at the start #include "debug.h" but the compile process didn't even touch the new files. I ended up adding the logging functions to conf.c.
Is there some special process to add files in the source?

Yes,
1) Understand the makefiles.
2) Make the appropriate changes.

I'm sorry if this isn't a helpful answer, but you are the one attempting something that appears to be well beyond your current skill set. If you want to do it successfully, you'll have to educate yourself.

In any case, for quick and dirty debugging, just throw it wherever is most convenient, and delete it when you no longer need it.

Logged

Don't forget what the H stands for.

mariush

63

Re: A580 porting - minor progress

« Reply #88 on: 27 / February / 2009, 17:10:05 »

I thought you would use some of the functions already existing in the firmware (like Assert that I noticed in several important functions or that stdout output functions) which I thought they'd ignore the card lock.

Thanks for the tip about the strings, I was actually looking for "Card locked!" but I couldn't find it anywhere.

If I determine that bit, where does it have to be changed? I guess those values are updated constantly so I would have to keep refreshing the value, or to set it right before attempting to open a file?
Will it be something like "physw[2] = physw[2] | 0x8000" ?

I appreciate your help and you're right that what I want is above my current skill set, I won't get upset because you say it because I know it's true. Learning C (or C++) is for a long time in my to do list (and I even got books to do it) but I have to earn some money to afford computers and house rent using VB and PHP so learning time is very limited.

I just feel that if I get a better debugging included in the code, I can pinpoint where it fails. I have a feeling that all the trouble is caused by some incorrect subs in stubs_entry_2.s and it's just too much time consuming to add blinking code everywhere or check each sub again.

Logged

reyalp

14111

Re: A580 porting - minor progress

« Reply #89 on: 27 / February / 2009, 19:09:56 »

Quote from: mariush on 27 / February / 2009, 17:10:05

If I determine that bit, where does it have to be changed? I guess those values are updated constantly so I would have to keep refreshing the value, or to set it right before attempting to open a file?
Will it be something like "physw[2] = physw[2] | 0x8000" ?

You will do it exactly like the existing code, only with a different bit (unless the a580 is somehow unique, but this seems unlikely given that both older and newer cams work the same way.)

In the a720 kbd.c you have:

Code: [Select]

#define SD_READONLY_FLAG (0x20000)
...
    if (conf.remote_enable) {
      physw_status[2] = physw_status[2] & ~(SD_READONLY_FLAG | USB_MASK);
     }
    else physw_status[2] = physw_status[2] & ~SD_READONLY_FLAG;

Assuming the bit is in the 3rd word of physw_status (it appears to be, based on sub_FFC31838), then you just need to define SD_READONLY_FLAG correctly.

Logged

Don't forget what the H stands for.