In another thread, we am looking at the use of the Automation interface on VDSP as part oan automated testing framework for data race analysis
Basically my background automation GUI captures the state of VDSP and restarts the processor.
The issue is find out how to minimize the time when inside the GUI -- so I have a general purpose timer going on the Blackfin that is kepet activated during emualtion mode. This gives me consisteent timing.
If you close all source windows on VDSP, reload your code (which opens all source windows "small") and run the code, the GUI takes a total time of X ms (around 140 ms)
If you now click to maximize the source window size inside VDSP, the GUI takes a total of around X + 40 to X + 50 ms-- meaning painting the samll window is 40 ms faster than painting a large window.
Is this time "windows" determined or "VDSP code" determined??
For those that are curious
Bringing up the CYCLES window over the top of the disassembler window and maximize the CYCLES window means that VDSP responds the fastest (by quite a bit)
Have tried making the whole VDSP window smaller, but the time does not seem to change
Here are some rough numbers for speed of a GUI using the automation interface using 33 MHz HHPC-ICE with the same source screen present
int measuredGUIWriteTimeRegister = 14; // MS
int measuredGUIReadTimeRegister = 6; // MS
int measuredGUIWriteTimeMemory = 23; // MS
int measuredGUIReadTimeMemory = 3; // MS
int measuredGUIMemorySymbolListTime = 2; // MS -- can be removed by using static variables that determine where everything is
int measuredInOutVDSPTime = 65; // MS
int measureSwitchSourceFileDisplay = 30; // MS
We have a testing framework based on UnitTest running on Blackfin. We were hoping to co-opt VDSP to handle data watch matches causing emualtion.
The conclusion appears to be that testing and debugging is faster using an on system testing framework rather than via VDSP.
It has been suggested that we try using the CPLB as a dta watch mechanism which would cuase the faster exception rather than emulations.
M. Smith and M. Helmi