Looked at your github and am really amazed at all you have figured out and documented. Looks better documented than most new code!
Thank you
I made great use of IDA 6.6 and the Hex-Rays decompiler. It automated all the disassembly and decompilation; my job was going and figuring out what e.g. the function
sub_801C504 and variable
dword_20003908 did.
1. Looks like C++ because I see the word 'class' around a lot. Is this why you commented 'everything is global' ie. the decompiler put all the class object data in one big pile?
Um I'm not sure where you've seen the word 'class'. I did a search of the repo and could not find that word anywhere. What I mean by 'everything is global' is that there are several functions (e.g.
meas_ohms_calc_50M_offset(digits, factor)) where all the intermediate variables are stored as globals and only read/written in that function. This makes no sense and I'm pretty sure it can't be caused by the compiler.
2. Since you have modified firmware already (and tested by Dave somewhere) does that mean you were able to recompile the code. I don't see how that could happen without all the object definitions, headers ect. Could you illuminate further. Is the binary just patched ? I didn't see any C++ code.
No, I'm not yet able to recompile the code. I do want to have that available so everyone can play with the firmware, but I haven't taken the time to try it, see what's missing, etc. It's definitely possible, but may be a crazy amount of work. And I still would have no way to test it. For now, I just hand-assembled ARM instructions and patched the binary. It's a lot easier because the compiler wasn't very efficient and so space can easily be made for new code.
is the assembly for the bit I patched, and
is it after the patch. You can see I was able to make more efficient use of registers and fit in an extra test, store, and branch that does
if (autorange_changed_range) meter_mode_range_change_delay = 0;