Seeking opinions on HP 16533/16534A oscilloscope card

[rtr989]

Ida pro disassemble vp and lib16534.sl without errors, but I have no clue where to start looking for a place of slowing down...
when i start scope, vp loads lib16534.sl library, but i can`t find place in code where it`s happens.
The Start and repetititve start buttons is in libWorkspace.sl library...
so, I stuck...

[MarkL]

What kind of assembly did IDA make for you?  Did it read and integrate the symbol file from lib16534.sl?  Can you assemble what IDA produced and will it run?

If you had the C source, you could do profiling.  I don't know if an equivalent exists for assembler, but you might be able to call out to the C library and have monitor() to set it up.

Another thing to do is to probe the ADC to confirm it's being read out at a high speed.  I doubt the card or backplane is constraining the data readout, but it wouldn't hurt to confirm this before digging into the software side.  You'd have to figure out which ADC pins were the data bus and bus clock.

Without the original source code, I think it's going be be difficult to figure out what's slowing it down.  I don't think it's worth the effort, but if you want to pursue it, I'll add where I can.

[rtr989]

What kind of assembly did IDA make for you?  Did it read and integrate the symbol file from lib16534.sl?  Can you assemble what IDA produced and will it run?

If you had the C source, you could do profiling.  I don't know if an equivalent exists for assembler, but you might be able to call out to the C library and have monitor() to set it up.

Another thing to do is to probe the ADC to confirm it's being read out at a high speed.  I doubt the card or backplane is constraining the data readout, but it wouldn't hurt to confirm this before digging into the software side.  You'd have to figure out which ADC pins were the data bus and bus clock.

Without the original source code, I think it's going be be difficult to figure out what's slowing it down.  I don't think it's worth the effort, but if you want to pursue it, I'll add where I can.

of course IDA can`t generate C source code for HPUX binary, and it can disassemble only one executable file, to complete the picture need to consider at least lib16534.sl and libWorkspace.sl...
I'm studying the question of how to add libraries to the project..
And you right, the game is not worth the candle, but I'm just curious and I do it in my spare time..

[MarkL]

...
of course IDA can`t generate C source code for HPUX binary, and it can disassemble only one executable file, to complete the picture need to consider at least lib16534.sl and libWorkspace.sl...
I'm studying the question of how to add libraries to the project..
...

Right, I wasn't suggesting it can re-create the C code, but I was thinking you could start to insert some profiling or other tracking methods into the assembly and load that.

There's an interestingly named symbol called "read_data__6HWFISOFUii" and maybe IDA identified that as a subroutine.   "FISO" is a term used for the ADC's on-chip buffer (Fast In Slow Out), so this might be a routine which reads the data from the ADC.  Possibly it's a place to start.  It might also be possible to set a breakpoint there (or in other places) with the debugger and dump the stack to start to get an idea of the callers' identities.

[MarkL]

I said:

...
It might also be possible to set a breakpoint there (or in other places) with the debugger and dump the stack to start to get an idea of the callers' identities.

Seems that adb doesn't support shared libraries, but dde does and it's much more pleasant to use.  There's a menu option under "Execution" and you can turn on debugging for specific loaded libarires (in this case lib16534.sl).

It will also disassemble the code for you around the execution point, but it's still rather raw.  I've never used IDA but I understand that it tries to comment the disassembled code.  Maybe looking at the IDA output at the same time while working with dde will be more useful.

In a very cursory play with dde, it seems that much more often than not, when the scope is running and I randomly interrupt vp, it's in \\HWFISO::read_data().  It could be an indication that it's spending a lot of time collecting data from the scope card.  On the other hand there are some suspiciously named callers on the stack like "timedRunEvent" which might have a role in pacing the acquisitions.

All food for thought.