If the DisplayStop function is called immediately after a DisplayPatternManualStep, the DisplayPatternManualStep will fail to execute properly. A delay of 100 ms is sufficient to prevent this. Needs to be fixed in firmware, I guess.
Hi Srinivasan,
Can you provide more details on the behavior - Frame rate, number of patterns. What is the MCU firmware version you are using?
Tried runing batch file with repeated calls in order DisplayPatternManualStep and then DisplayStop without any delay. I am not able observe any problem with the system. FYI, i am using MCU #2.1.5.
Details on the two APIs usage -
1) The DisplayPatternManualStep would advance to next pattern as defined in the ImageOrderLUT.
2) The DisplayStop function would basically stop the pattern refresh execution functionality. The pattern display pointer would reset back and point to 1st pattern of ImageOrderLUT.
If the API called in order #1 after #2 you will notice that after #2 image on screen goes blank and again calling #1 would result in display of 1st pattern.
Regards,
Sanjeev
The bug occurs with any number of patterns.
I believe that this is happenning because my frame rate has been set very low - 5 hz. It does not occur at, say, 500 hz. It seems that with low frame rates the following displaystop overrides the ManualStep (which has not yet completed due to the low frame rate).
This would explain why the delay helps - it lets the ManualStep finish.
Is the problem you are referring is about the "frame" not being displayed completely for the said duration when DisplayStop is called immediately after DisplayPatternManualStep at very low frequency like 6Hz?
If it is then here is the explanation for the behavior -
DisplayStop function never waits for completion of frame display. This interface is basically meant to stop pattern refresh immediately after receive the command. Because of this the behavior appears at very low frequency.
Suggested use case is to call DisplayStop only when you want to end the current patterns display execution in the system.