how to avoid animation with SlidingMenu

Here are some quick/dirty methods which may assist:

a) Does your rotary encoder use the MCU's QEI Module?  If so - can you confirm that the QEI Module can "stay up with" and properly manage your encoder?

b) Try to use a single, GPIO Port for external signal inputs - rather than several ports.  (enabling a single Port Read - rather than multiple)

c) Trace is wonderful w/IAR.  Poor man's trace remains - Led (bit) set on entry to code routine - bit cleared upon exit.  Monitored on Logic Analyzer or Scope enables pretty accurate measurement - revealing which program sectors are, "time hogs."

d) Insure that you truly understand, "Prioritizing MCU Interrupts."  Carefully consider this ordering - insuring that critical code sectors are adequately serviced.

e) It may be that, "Screen Dumps" to OLED may be reduced in frequency - without negative impact upon usability.  You may want to "paint" the entire screen in a methodical manner - should, "paint differentiation" be the cause of added time w/in this routine...  Or - if you "know" - and can "track" changes impacting the screen field - you may be able to more quickly execute, limited/selective area Screen Repaints...

Thanks CB1,

In the meantime - after writing my inquiry - I changed the code in slider-menu sources so I can now avoid sliding which can save me up some computing time 'cause now I can adopt sliding from 16 times (default case) down to 1 time. I introduced some global variable which can be set from outside to accommodate the cool painting stuff towards processor load.

But this will not save the world!

Now to your remarks:

a) Yep - but this is only some user-interface encoder. It reads out some rotary wheel which acts as user input. When my main will not passing by then the user-input will get ignored. The same with the buttons on the board wich will get (not) polled. The button 'driver' in qs-logger loocks a little quirky.

b) I always have done so, when possible. The app I build requires reading values from two IO-ports (16 bit ), give them out on two ports ( 16 bit ) and needs one/two synching inputs on some other GPIO port. In this scenario I now suffer only one of the synching inputs is involved - on the 16 bit input ports ( where I currently only use one port with 8 bit and hope to scale up the app later ). During development until now I excessivly used ( and will further use due to requirements regarding usage of the whole tool/app ) CAN-bus. With CAN I can observe usefull (valid an on-time ) trace-output regarding the states my ISR reach following the synching input signals. I use CAN  sending within interrupts - I shame a little bit talking about, but that's it ... This all works up to some KHz input frequency.

c) Its to late to change tools I afraid. I have rewritten some tool which originaly was written for some C168 and have the job to extend its functionality. The C168 board I got seemed not to be fit for future so I decided to use some other hardware - the 4F232 seemed to fit the requrements. With these choise I produced some opponents in the departement 'cause they want to keep the uC farm as small as possible. That keeps me allone and forces me to have success with my choice in the next weeks 'cause I alread have invested some not neglectible amout of time in this project ...

d) How to insure that? I have if-def'd in the code the priorisation of interrupts, beside to leaving them on default. I have played wit effects of both, but honestly said not deeply enough. I will fetch it now ...

e) Unfortunately i used the qs-logger stub with all its macros and extended this. QS-logger's menu structure looks cool and throwing it away and writing some new will not make me more friends because parts of my software work well and they were already accepted by my customer...

--> new questions <--

# Is it recommended to change to some better timed system using TI's RTOS with the mcu-sdk? I have downloaded it but tend to spare the extend of integrating this because I cannot yet estimate the new problems which will come with...

# The mcu-sdk gave no hint about graphical stuff. No example seems to use grlib in conjunction with rt code. I think the graphics driver for the 4F232 eva board uses extensivly SPI access, so the bottleneck may be on some totaly other place... Is it recommended using TI-RTOS with grlib?

# I hope that I could decouple user-interaction from graphics by using button and encoder readout in some other rt-task which ensures users inputs. Is this an easy task for me because well prepared or a bunch of work?

thanks a lot

--jens

@ Jens:

Many of your questions/points are bit too TI specific for me - we must await TI (or another) for those assists.

You either "interrupt" on the lead sync edge - or continually loop on that sync pin - awaiting the sync.  You then read that port as the first instruction in your, "Sync_Signal ISR."  (you are vulnerable to any signal change during that brief time interval - (Sync Assert to ISR's service and port read)  You can "fix" that uncertainty "window" with an 8 bit latch - clocked by the lead edge of your sync pulse.  If "back to back" syncs are not too quick - this latch can reduce the SW burden that these input "captures" currently demand.  (i.e. you can read/react to any such changes at a lower - more relaxed rate - as the data has been "captured.")

Interrups may be effectively prioritized via the StellarisWare function, "IntPrioritySet()" - which is well described w/in SW-DRL-UG.  Highest priority is awarded to the lowest values - w/in that function.  Insure that your most critical functions receive the highest priority.  Experimentation will quickly build your confidence/understanding.

You gave no response to my suggestion of setting - then clearing - some bit as a means to learn the execution time of different code segments.  Once you glean these facts - you'll be far better able to determine "if" your objective is even possible - and if so - how best to achieve it. 

You can eliminate the Graphic Display as a source of your timing problems by replacing each display call w/a far simpler/faster "bit toggle."  This will reveal - if indeed - the call to and execution w/in the display routine is your problem.

And - unknown is the speed of your input transitions, encoder frequency, and regularity of screen refresh.  We don't know if were fighting "magnitudes" of time issues - or if we're "just missing."  Appears that a variety of "hard numbers" will best reveal what your choices should be...

I come from the display industry - often - with involved displays - we dedicate an MCU to the display - to substantially "unburden" the main MCU.  You may consider this - should your "time measurements" place substantial "blame" upon display service routines.  You state that client "likes" that display - are you quite sure that you can reliably purchase that exact display - in the time-frame, prices and quantities needed?  (these are not yet mainstream - like LCDs - and often are subject to production delays and unwanted/unexpected IC changes...  Caveat Emptor...