How were you able to discover the LED requiring multiple locations?? Any tips?
Wow, it's been a while since I touched on this. First, I must apologize for disappearing after dumping the firmware and finding LED addresses. After not making much progress on CHDK (couldn't get past crashes on boot), and switching computers, I didn't set up the CHDK development environment again. Sorry!
Anyway, I used Canon Basic to find the addresses I posted here. I wrote a script that wrote 0x46? to all the addresses within a range, ran it, and found what happened. Of course, these addresses often caused other strange things to happen, like adjusting screen brightness, firing the flash, etc. Many addresses caused the camera to crash.
Once I got a LED to light up, from there it became a binary search, finding out which addresses I could remove from the range and still get it to light up. There was a lot of trial and error with the crashes and the unexpected requirement to write to multiple addresses to get it to light up. The final version of the script lit both leds, then blinked them on a timer, only writing to the necessary addresses. Felt very satisfying after all that work.
I think I read somewhere in the development thread that my addresses only worked in canon basic scripts and not in the C code. Please check whatever's posted in the thread for current info, everything I know about this is from when the camera was brand new and nothing was working, and it looks like we've seen some great development by more persistent coders.
Thanks for getting back to me on this.? I've found a basic script that is stepping through addresses now.? My main question is how you found out about the unexpected requirement to write to multiple addresses?
"There was a lot of trial and error with the crashes and the unexpected requirement to write to multiple addresses to get it to light up."?
I'm wondering if it's possible the ELPH320HS I'm working with may have the same requirements.? And if that was something someone mentioned elsewhere or if that was found from firmware analysis.? ? Thanks! ?
Well, I found out I needed multiple addresses when I would lose the LED by removing any of multiple different addresses from the range. For example, if I cut the range in half and lost the LED, then tried the other half of the range and still didn't get the LED, I then knew there were at least 2 addresses I needed to get the LED to light up, and that one of them was in each half of the original range. It was all just experiments narrowing everything down as much as I could while still getting the LEDs to light up, until finally I found out the minimum requirements. You can also find addresses that crash by doing something visual like displaying text on screen at the end of the script. No visual change means it crashed. Finding the addresses that caused crashes then making sure to skip them in the loop was a major pain too. It took a few hours total to find the correct addresses.
Most developers don't go about it this way - I was very unconventional. If I remember correctly, most devs look in the assembly code in the firmware dump for patterns that could indicate LEDs. Check the forums, you'll probably find a method better than mine.
FWIW, this conversation will get a lot more attention if you hold it in the porting thread on the CHDK forum.
Talk pages on this wiki are not really a great place to share information.