EKK-LM3S811 game example scrolling code

It's not that important since it's just about a "game example"-code but there seems to be a mistake in the code gs_ev-lm3s811.c which comes with the Keil MDK evaluation-version on the "Stallaris CD" V1.01 and is also present in the Driver-Library Version 852 which I have just downloaded from the web-site. The code seems to be a wrong here:

Code:


 
[...]
if(
ulIdx 96)
{
   for(
ulLoop 0ulLoop ulIdxulLoop++)
   {
      
g_pucFrame[ulLoop 95 ulIdx] =  
         
pucImage[ulLoop];
[...]






When ulIdx reaches 96 and ulLoop is 0 the array-index is 0+95-96=-1. I found this when I compiled the example with the GNU-Toolchain (Codesourcery 2006-gq/gcc 4.1.0): the scrolling of the contest URL "freezes" when reaching the left side of the display (when ulIDX is 96). With a binary compiled with the RV-toolchain (from Keil MDK V3.03beta) the text scrolls completly. I wonder how the RV-toolchain could handle the "-1". Anyway: I have hopefully fixed this (starting with if (ulIDX

http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_cortex.html

Martin Thomas

Post edited by: mthomas, at: 2006/10/15 10:14

5 Replies

  • Thanks for this fix!

    1) Do you have any idea when Cortex support will be rolled into the official WinArm chain?

    2) Have you tried to compile the gcc sources from CodeSourcery? I looked at their code once but they didn't seem to have makefiles and it looked like a lot of work.
  • englere wrote:

    Thanks for this fix!
    1) Do you have any idea when Cortex support will be rolled into the official WinArm chain?


    I hope the Codesourcery-people will modify the
    code-base for the "official" gcc soon but I do not have any information when this will happen. Will send an e-mail to codesourcery and ask about this.


    2) Have you tried to compile the gcc sources from CodeSourcery? I looked at their code once but they didn't seem to have makefiles and it looked like a lot of work.


    No, so far I have not tried to build gcc from the Codesourcery-sources since Codesourcery already provides precompiled binaries for Win32 hosts. The Codesourcery package and the GNU-toolchain that comes with WinARM can co-exist on the same machine (I have used the build-utils (make, sh) from WinARM (taken from the MinGW-project) and the GNU-Toolchain from Codesourcery to build the LMI driver-library and examples).

    Martin Thomas
  • englere wrote:

    Thanks for this fix!
    1) Do you have any idea when Cortex support will be rolled into the official WinArm chain?


    I hope the Codesourcery-people will modify the
    code-base for the "official" gcc soon but I do not have any information when this will happen. Will send an e-mail to codesourcery and ask about this.


    2) Have you tried to compile the gcc sources from CodeSourcery? I looked at their code once but they didn't seem to have makefiles and it looked like a lot of work.


    No, so far I have not tried to build gcc from the Codesourcery-sources since Codesourcery already provides precompiled binaries for Win32 hosts. The Codesourcery package and the GNU-toolchain that comes with WinARM can co-exist on the same machine (I have used the build-utils (make, sh) from WinARM (taken from the MinGW-project) and the GNU-Toolchain from Codesourcery to build the LMI driver-library and examples).

    Martin Thomas
  • Martin,

    You are correct that this code is in error; thanks for reporting it. Interestingly, it works just fine with the version of CodeSourcery that we have in-house (well, it doesn't crash!). Wonder what has changed?

    The actual fix to the code is the following:

    Code:


     
            
    if(ulIdx 96)
            {
                for(
    ulLoop 0ulLoop ulIdxulLoop++)
                {
                    
    g_pucFrame[ulLoop 96 ulIdx] = pucImage[ulLoop];
                    
    g_pucFrame[ulLoop 96 ulIdx 96] =
                        
    pucImage[ulLoop ulWidth];
                }
            }






    I.e. the "ulLoop + 95" inside the loop is changed to "ulLoop + 96".

    It is a subtle difference, one that you're very unlikely to actually notice when watching the display (especially since it is so small!). But, if you watch closely (or single step through the screen updates with a debugger) with the original code, you'll see that when it enters this section of code (i.e. when the scrolled image first appears from the right side of the display), the image does not utilize the far right column of the display. Once the image reaches the left side of the display, it will pause for one update (1/30th of a second) and then start utilizing the far right column of the display for the remainder of the scrolling.

    The fix above corrects the scrolling behavior; the initial phase utilizes the far right column and there is no pause. This fix was incorporated into the latest release of the driver library, which was posted to the web site yesterday.

    --Brian
  • Thanks for the information and the "official" bug-fix.

    Martin Thomas