Hi all,
I have both an MSP430F5529LP and an MSP-EXP432P401R launchpad, along with a BOOSTXL-K350QVGA-S1. I am using the IAR tools for MSP430 and for ARM Cortex-M respectively. I am trying to run a comparison of the TI Graphics Library demos from GRLIB_3_21_00_00 on both processors.
First of all, when trying to perform a "screen calibration", I had continuous problems getting xMin and yMin values that were considered "in range" by the validateCalibration() function in touch_P401R.c. Even using a stylus and trying to hit the dead center of the red dots, I kept getting "INVALID CALIBRATION". I finally looked at the values in the debugger, and they were very repeatable, so I eventually modified the code to open up the limits a bit so that I could pass the initial calibration.
Next, I expected to see that the MSP432 would "paint" the graphics images on the LCD quite a bit faster, since it's a 32-bit ARM vs. 16-bit MSP430, and is running at 48 MHz for the MSP432 vs. 25 MHz for the MSP430. Much to my surprise, it seems like the painting of the graphics images is actually slower on the MSP432 than on the MSP430! I checked optimizations, etc., and it looks like they are all turned off for these demos.
I have not actually measured the execution time to draw the graphics images on the display, but to my untrained eye, I'd say that the MSP432 seems to draw about 50% to 100% slower than the MSP430! I have to admit that I was pretty shocked. It's not a show-stopper, and most users might not even notice, but I expected to see exactly the opposite, with the MSP432 doing the work faster than the MSP430.
Have any of you tried similar experiments? Have you seen similar behavior? Do you have any suggestions on things to try or configuration changes that might need to be made so that the MSP432 behaves faster than the MSP430? One suspicion that I have not had time to investigate is whether the SPI interface to the display is being configured to a slower clock rate than on the MSP430. There could also be differences in the CPU clock or peripheral clock initializations that would affect this behavior, but I did not want to sink a lot of time into this without checking with other Graphics Library users first.
Also, have any of you experienced the same kind of rejection of initial calibration? If so, what did you do to solve it? I'm assuming (perhaps incorrectly), that the xMin and yMin values were calculated based on expected ADC readings from the display Booster Pack, but maybe the default range is simply too tight, or has an offset that has not been accounted for.
Any help or suggestions are appreciated. I have not tried any compiler optimizations for speed, either, since often optimizations will interfere with ease of debugging.
Thanks in advance for your help, Graphics Library gurus!
Scott