>                                // Build the output string
>                        *preadarray =  '@';        // Bit 0 - String start identifier
>                        *(preadarray + 1) =  '0';                // Bit 1 - Unit identifer high digit
>                        *(preadarray + 2) =  '2';                // Bit 2 - Unit identifier low digit
>                        *(preadarray + 3) =  'R';                // Bit 3 - Command character
>                        *(preadarray + 4) =  'D';                // Bit 4 - Command Character
>                        *(preadarray + 17) = '0';                // Bit 17 - ERROR IDENTIFIER
>                        *(preadarray + 18) = (watchdog_count + 48);        // Bit 18 - ERROR QUANTITY
>                        *(preadarray + 19) = '0';                // Bit 19 - Dummy FCS character
>                        *(preadarray + 20) = '0';                // Bit 20 - Dummy FCS character
>                        *(preadarray + 21) = '*';        // Bit 21 - String end identifier
>                        *(preadarray + 22) = '\n';        // Bit 22 - New Line                
>                        *(preadarray + 23) = '\r';        // Bit 23 - Carriage return                
>                        *(preadarray + 24) = '\0';        // Bit 24 - End of String
>                                
>                        if (watchdog_count >0) //Notify the home computer there has been errors
>                                {
>                                *(preadarray + 17) = 'W';
>                                }
>                          itoa(well_pressure, (preadarray + 5) );
>                          itoa (regulated_pressure,  (preadarray + 9));
>                          itoa (temperature,  (preadarray + 13));
>                                        
>                        //Right justify the number fields
>                        for (i = 8; i <= 16; (i = i + 4))        // 3 Fields
>                                {
>                                for (j = 3; j >= 1; j--)                  // 4 Characters
>                                        {
>                                        for (k = 0; k < 3; k++)
>                                                {                                        
>                                                if (*(preadarray + i - k) == 0)
>                                                        {
>                                                         *(preadarray + i - k) = *(preadarray + i - k - 1);
>                                                     *(preadarray + i - k - 1) = 0;
>                                                        }
>                                                }
>                                        }
>                                }
>                        for ( i = 4; i <= 18; i++)
>                                {
>        // Change any NULLS to '0'
>                                if ( *(preadarray + i) == 0 ) *(preadarray + i) = '0';
>                                }
>                                
>        //calculate the FCS (Frame Check Sequence) for the outgoing string
>                                *(preadarray + 17) = 87;
>                                *(preadarray + 18) = 51;
>
>        result = *preadarray;        //First byte of string to check
>        
>        for ( j = 1; (*(preadarray + j) == 0  ) || ( j <= 18 ) ; j++)
>                {
>                result ^= (*(preadarray + j));   //XOR operation        
>                }        
>                fcs_high = 48 +(result >> 4);
>                /*If it's more than "9" then make it Alpha*/
>                if (fcs_high >  57) fcs_high = fcs_high + 7;
>                fcs_low = 48 + (result & 0b00001111);
>                //If it's more than "9" then make it Alpha
>                if (fcs_low > 57)        fcs_low = fcs_low + 7;                
>                *(preadarray + 19) = fcs_high;        // Bit 19 - FCS high digit        
>                *(preadarray + 20) = fcs_low;        // Bit 20 - FCS low digit

>                //Send out the string
> putsUSART (readarray);

> A week ago, I had a banking problem with the 18F1320 firmware. That's
> working OK, there are a few memory locations left. Running the program
> under MPLAB SIM is OK, but after burning and verifying the chip, which
> communicates RS-232 with a PC Com port running 9600 baud with RealTerm,
> the line of 24 characters, randomly, but mostly gobbles a character in
> the middle, inserts a line feed and sometimes gobbles the end.
>
> Here's what the string should look like:
>
>  @02RD031901140167W33F*
>
> And here's what happens frequently, the line feeds aren't always the
> same location:
>
>  @02RD031
>          01140167W30C*
>
> and here's ASCII + HEX , the new line at "W" was added to keep line length.
>
> @40 030 232 R52 D44 030 333 131  0A 030 131 131 434 030 131 636 737
> W57 333 030 C43 *2A  0A  0D  00
>
>
> I have tried 2 PC's, 2 PIC boards, and 3 PICS with no change.
>
> Here's pieces of the code:
>
> > #pragma udata access accessram
> > near char readarray[25];
> > #pragma udata
> char c;
>
> start: TRISA = 0b00000111; // AN0 (RA0), AN1 (RA1), and AN2 (RA2) to
> input (1).
> TRISB = 0b00010000;     //RX (RB4), port set to input (1), TX (RB1) and
> others stay output(0).
> ADCON1 = 0b01111000;    // AN0, AN1 and AN2 as analog (0), set AN5 (RB1)
> and AN6 (RB4) as digital (1).
> RCSTAbits.SPEN = 1;             // set serial port enable bit
> TXSTAbits.TXEN = 1;             // set transmit enable bit
>
>  /* Open the USART configured as 8N1, 9600 baud, in polled mode */
> OpenUSART (USART_TX_INT_OFF     &
>          USART_RX_INT_ON                       &
>         USART_ASYNCH_MODE              &
>         USART_EIGHT_BIT                &
>         USART_CONT_RX                  &
>         USART_BRGH_HIGH, 51);  // 9600 = 51, 2400 = 207, 19.2K= 25
>
>
> >                               // Build the output string
> >                       *preadarray =  '@';     // Bit 0 - String start
> identifier
> >                       *(preadarray + 1) =  '0';               // Bit 1 -
> Unit identifer high digit
> >                       *(preadarray + 2) =  '2';               // Bit 2 -
> Unit identifier low digit
> >                       *(preadarray + 3) =  'R';               // Bit 3 -
> Command character
> >                       *(preadarray + 4) =  'D';               // Bit 4 -
> Command Character
> >                       *(preadarray + 17) = '0';               // Bit 17 -
> ERROR IDENTIFIER
> >                       *(preadarray + 18) = (watchdog_count + 48);     //
> Bit 18 - ERROR QUANTITY
> >                       *(preadarray + 19) = '0';               // Bit 19 -
> Dummy FCS character
> >                       *(preadarray + 20) = '0';               // Bit 20 -
> Dummy FCS character
> >                       *(preadarray + 21) = '*';       // Bit 21 - String
> end identifier
> >                       *(preadarray + 22) = '\n';      // Bit 22 - New
> Line
> >                       *(preadarray + 23) = '\r';      // Bit 23 -
> Carriage return
> >                       *(preadarray + 24) = '\0';      // Bit 24 - End of
> String
> >
> >                       if (watchdog_count >0) //Notify the home computer
> there has been errors
> >                               {
> >                               *(preadarray + 17) = 'W';
> >                               }
> >                       itoa(well_pressure, (preadarray + 5) );
> >                       itoa (regulated_pressure,  (preadarray + 9));
> >                       itoa (temperature,  (preadarray + 13));
> >
> >                       //Right justify the number fields
> >                       for (i = 8; i <= 16; (i = i + 4))       // 3 Fields
> >                               {
> >                               for (j = 3; j >= 1; j--)                //
> 4 Characters
> >                                       {
> >                                       for (k = 0; k < 3; k++)
> >                                               {
> >                                               if (*(preadarray + i - k)
> == 0)
> >                                                       {
> >                                                        *(preadarray + i -
> k) = *(preadarray + i - k - 1);
> >                                                *(preadarray + i - k - 1)
> = 0;
> >                                                       }
> >                                               }
> >                                       }
> >                               }
> >                       for ( i = 4; i <= 18; i++)
> >                               {
> >       // Change any NULLS to '0'
> >                               if ( *(preadarray + i) == 0 ) *(preadarray
> + i) = '0';
> >                               }
> >
> >       //calculate the FCS (Frame Check Sequence) for the outgoing string
> >                               *(preadarray + 17) = 87;
> >                               *(preadarray + 18) = 51;
> >
> >       result = *preadarray;   //First byte of string to check
> >
> >       for ( j = 1; (*(preadarray + j) == 0  ) || ( j <= 18 ) ; j++)
> >               {
> >               result ^= (*(preadarray + j));   //XOR operation
> >               }
> >               fcs_high = 48 +(result >> 4);
> >               /*If it's more than "9" then make it Alpha*/
> >               if (fcs_high >  57) fcs_high = fcs_high + 7;
> >               fcs_low = 48 + (result & 0b00001111);
> >               //If it's more than "9" then make it Alpha
> >               if (fcs_low > 57)       fcs_low = fcs_low + 7;
> >               *(preadarray + 19) = fcs_high;  // Bit 19 - FCS high digit
> >               *(preadarray + 20) = fcs_low;   // Bit 20 - FCS low digit
>
> >               //Send out the string
> > putsUSART (readarray);
>
> I have also tried as the argument to putsUSART : preadarray, with no
> change, and  *(preadarray) , and "near" which did not compile.
>
> The program has had major reorganization , with little actual new code
> recently. Prior to the major change there has not been this trouble for
> several years and numerous small changes.
>
> The outputting area previously was as below, with no problems before the
> major change:
>
>        for ( i = 0; i <= 23 ; i++)
>        {
>        while ( TXSTAbits.TRMT == 0)// The transmit is busy when 0
>                TXREG = (near) *(preadarray + i);
>        }
>
> Also I have tried this variation which was the same issue
>
>
>        c =  (far) *(preadarray + i);
>        TXREG = c;
>
>
> As I said, everything works as expected in MPLAB SIM, but the actual
> chip output is bad. Comments appreciated. :)
>
>
>
>
>
>
>
>
>
>
>
>
>
>

> On Mon, 01 Jun 2009 22:01:04 -0400
> Carl Denk <cdenkKILLspamwindstream.net> wrote:
>
>  
>>>                for (j = 3; j >= 1; j--)        // 4 Characters
>>>      
>
> This loop only does 3 characters, not 4 as the comment says?
>
> John
>  

> Carl Denk wrote:
>  
>> Here's what the string should look like:
>>
>>   @02RD031901140167W33F*
>>
>> And here's what happens frequently, the line feeds aren't always the
>> same location:
>>
>>   @02RD031
>>           01140167W30C*
>>    
>
> Some PIC UARTs have a bug where they insert a null due to a race condition.
> I haven't heard of anything inserting a line feed.  Are you using some low
> level firmware that's maybe too clever by a half as the Brits would say?
> You don't know what crap the compiler's UART routine is doing under the
> hood.  Try replacing the byte output routine with a simple wait for TRMT
> loop then write to TXREG.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
>  

> Hi Carl,
>
> If you use pointer arithmetics like this "*(preadarray + i - k) = *(
> preadarray + i - k - 1);" I think it would be easier to do that like "
> readarray[ i - k ] = readarray[ i - k - 1 ];".
>
> Also when you use the array as a string you would need to make sure that the
> end of the string is closed by a '\0' character -- I can't see where is that
> happen,
>
> Tamas
>
>
>
> On Tue, Jun 2, 2009 at 3:01 AM, Carl Denk <.....cdenkKILLspam.....windstream.net> wrote:
>
>  
>> A week ago, I had a banking problem with the 18F1320 firmware. That's
>> working OK, there are a few memory locations left. Running the program
>> under MPLAB SIM is OK, but after burning and verifying the chip, which
>> communicates RS-232 with a PC Com port running 9600 baud with RealTerm,
>> the line of 24 characters, randomly, but mostly gobbles a character in
>> the middle, inserts a line feed and sometimes gobbles the end.
>>
>> Here's what the string should look like:
>>
>>  @02RD031901140167W33F*
>>
>> And here's what happens frequently, the line feeds aren't always the
>> same location:
>>
>>  @02RD031
>>          01140167W30C*
>>
>> and here's ASCII + HEX , the new line at "W" was added to keep line length.
>>
>> @40 030 232 R52 D44 030 333 131  0A 030 131 131 434 030 131 636 737
>> W57 333 030 C43 *2A  0A  0D  00
>>
>>
>> I have tried 2 PC's, 2 PIC boards, and 3 PICS with no change.
>>
>> Here's pieces of the code:
>>
>>    
>>> #pragma udata access accessram
>>> near char readarray[25];
>>> #pragma udata
>>>      
>> char c;
>>
>> start: TRISA = 0b00000111; // AN0 (RA0), AN1 (RA1), and AN2 (RA2) to
>> input (1).
>> TRISB = 0b00010000;     //RX (RB4), port set to input (1), TX (RB1) and
>> others stay output(0).
>> ADCON1 = 0b01111000;    // AN0, AN1 and AN2 as analog (0), set AN5 (RB1)
>> and AN6 (RB4) as digital (1).
>> RCSTAbits.SPEN = 1;             // set serial port enable bit
>> TXSTAbits.TXEN = 1;             // set transmit enable bit
>>
>>  /* Open the USART configured as 8N1, 9600 baud, in polled mode */
>> OpenUSART (USART_TX_INT_OFF     &
>>          USART_RX_INT_ON                       &
>>         USART_ASYNCH_MODE              &
>>         USART_EIGHT_BIT                &
>>         USART_CONT_RX                  &
>>         USART_BRGH_HIGH, 51);  // 9600 = 51, 2400 = 207, 19.2K= 25
>>
>>
>>    
>>>                               // Build the output string
>>>                       *preadarray =  '@';     // Bit 0 - String start
>>>      
>> identifier
>>    
>>>                       *(preadarray + 1) =  '0';               // Bit 1 -
>>>      
>> Unit identifer high digit
>>    
>>>                       *(preadarray + 2) =  '2';               // Bit 2 -
>>>      
>> Unit identifier low digit
>>    
>>>                       *(preadarray + 3) =  'R';               // Bit 3 -
>>>      
>> Command character
>>    
>>>                       *(preadarray + 4) =  'D';               // Bit 4 -
>>>      
>> Command Character
>>    
>>>                       *(preadarray + 17) = '0';               // Bit 17 -
>>>      
>> ERROR IDENTIFIER
>>    
>>>                       *(preadarray + 18) = (watchdog_count + 48);     //
>>>      
>> Bit 18 - ERROR QUANTITY
>>    
>>>                       *(preadarray + 19) = '0';               // Bit 19 -
>>>      
>> Dummy FCS character
>>    
>>>                       *(preadarray + 20) = '0';               // Bit 20 -
>>>      
>> Dummy FCS character
>>    
>>>                       *(preadarray + 21) = '*';       // Bit 21 - String
>>>      
>> end identifier
>>    
>>>                       *(preadarray + 22) = '\n';      // Bit 22 - New
>>>      
>> Line
>>    
>>>                       *(preadarray + 23) = '\r';      // Bit 23 -
>>>      
>> Carriage return
>>    
>>>                       *(preadarray + 24) = '\0';      // Bit 24 - End of
>>>      
>> String
>>    
>>>                       if (watchdog_count >0) //Notify the home computer
>>>      
>> there has been errors
>>    
>>>                               {
>>>                               *(preadarray + 17) = 'W';
>>>                               }
>>>                       itoa(well_pressure, (preadarray + 5) );
>>>                       itoa (regulated_pressure,  (preadarray + 9));
>>>                       itoa (temperature,  (preadarray + 13));
>>>
>>>                       //Right justify the number fields
>>>                       for (i = 8; i <= 16; (i = i + 4))       // 3 Fields
>>>                               {
>>>                               for (j = 3; j >= 1; j--)                //
>>>      
>> 4 Characters
>>    
>>>                                       {
>>>                                       for (k = 0; k < 3; k++)
>>>                                               {
>>>                                               if (*(preadarray + i - k)
>>>      
>> == 0)
>>    
>>>                                                       {
>>>                                                        *(preadarray + i -
>>>      
>> k) = *(preadarray + i - k - 1);
>>    
>>>                                                *(preadarray + i - k - 1)
>>>      
>> = 0;
>>    
>>>                                                       }
>>>                                               }
>>>                                       }
>>>                               }
>>>                       for ( i = 4; i <= 18; i++)
>>>                               {
>>>       // Change any NULLS to '0'
>>>                               if ( *(preadarray + i) == 0 ) *(preadarray
>>>      
>> + i) = '0';
>>    
>>>                               }
>>>
>>>       //calculate the FCS (Frame Check Sequence) for the outgoing string
>>>                               *(preadarray + 17) = 87;
>>>                               *(preadarray + 18) = 51;
>>>
>>>       result = *preadarray;   //First byte of string to check
>>>
>>>       for ( j = 1; (*(preadarray + j) == 0  ) || ( j <= 18 ) ; j++)
>>>               {
>>>               result ^= (*(preadarray + j));   //XOR operation
>>>               }
>>>               fcs_high = 48 +(result >> 4);
>>>               /*If it's more than "9" then make it Alpha*/
>>>               if (fcs_high >  57) fcs_high = fcs_high + 7;
>>>               fcs_low = 48 + (result & 0b00001111);
>>>               //If it's more than "9" then make it Alpha
>>>               if (fcs_low > 57)       fcs_low = fcs_low + 7;
>>>               *(preadarray + 19) = fcs_high;  // Bit 19 - FCS high digit
>>>               *(preadarray + 20) = fcs_low;   // Bit 20 - FCS low digit
>>>      
>>>               //Send out the string
>>> putsUSART (readarray);
>>>      
>> I have also tried as the argument to putsUSART : preadarray, with no
>> change, and  *(preadarray) , and "near" which did not compile.
>>
>> The program has had major reorganization , with little actual new code
>> recently. Prior to the major change there has not been this trouble for
>> several years and numerous small changes.
>>
>> The outputting area previously was as below, with no problems before the
>> major change:
>>
>>        for ( i = 0; i <= 23 ; i++)
>>        {
>>        while ( TXSTAbits.TRMT == 0)// The transmit is busy when 0
>>                TXREG = (near) *(preadarray + i);
>>        }
>>
>> Also I have tried this variation which was the same issue
>>
>>
>>        c =  (far) *(preadarray + i);
>>        TXREG = c;
>>
>>
>> As I said, everything works as expected in MPLAB SIM, but the actual
>> chip output is bad. Comments appreciated. :)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

> The semi-colon got lost in copy/paste, it's there in the code. :(
>
> Robert Young wrote:
>  
>>  
>>    
>>> From: EraseMEolin_piclistembedinc.com
>>> To: RemoveMEpiclistEraseMEEraseMEmit.edu
>>> Subject: Re: [PIC] MPLAB SIM PROBLEM - help
>>> Date: Tue, 2 Jun 2009 10:25:48 -0400
>>>
>>> Carl Denk wrote:
>>>    
>>>      
>>>>  while ( TXSTAbits.TRMT == 0)// The transmit is busy when 0
>>>>    TXREG = (near) *(preadarray + i);
>>>>      
>>>>        
>>> I don't use C (yucc) very often, but that looks messed up.  Isn't that
>>> writing to TXREG continually until TRMT is set?  You should be waiting until
>>> TRMT is set, and then writing to TXREG only once.
>>>    
>>>      
>> Looks like he missed out the semicolon at the end of the "while" statement...
>>
>> Rob

> On Tue, Jun 2, 2009 at 10:17 AM, Carl Denk <RemoveMEcdenkspam_OUTKILLspamwindstream.net> wrote:
>
>  
>> I read somewhere that when using banked storage, the arrays should be
>> referenced with pointers. One of the major changes to the program was to
>> use pointers, at least on the arrays in the access area.
>>
>>    
>
> Tamas' suggestion to use normal array indexing is fine (i.e. you do not need
> to use pointers because the array itself is a pointer).
> Code such as below will work fine:
>
> uint8_t buffer[BUFFER_SIZE];
>
> buffer[i] = data;
>
> There is a suggestion from Microchip (in the C18 user guide) to use pointers
> to large data objects (large, in this case, means that the object crosses a
> bank boundary).
>
> In the project I am currently working on, I have a queue that takes up three
> banks, accessed with "normal" array indexing like that above. Under the
> hood, I imagine the compiler places the base array address in the FSR[H:L]
> registers and then adds the index to them.
>
> -Scott
>  

> Yes, that's where I saw the pointers needed - large data, I was being
> conservative. I have the  thought that the extra pointer arithmetic is
> causing a marginal timing problem with the extra overhead and going to
> pursue, keeping that to a minimum in the send loop. But that doesn't
> explain why the problem persists when using
> putsUSART (readarray);  And I'm saying exactly the same symptoms. Also,
> I did try 2400 baud instead of the usual 9600 with no change.
>
> I did check both the errata and silicon errata. Since I don't use
> autobaud detect, there wasn't anything, except, an issue of not starting
> from code 0x00, and they want a "nop" there. That might account for some
> of the no response I have experienced, thinking it was my code.
>
> Scott wrote:
>  
>> On Tue, Jun 2, 2009 at 10:17 AM, Carl Denk <KILLspamcdenkspamBeGonewindstream.net> wrote:
>>
>>  
>>    
>>> I read somewhere that when using banked storage, the arrays should be
>>> referenced with pointers. One of the major changes to the program was to
>>> use pointers, at least on the arrays in the access area.
>>>
>>>    
>>>      
>> Tamas' suggestion to use normal array indexing is fine (i.e. you do not need
>> to use pointers because the array itself is a pointer).
>> Code such as below will work fine:
>>
>> uint8_t buffer[BUFFER_SIZE];
>>
>> buffer[i] = data;
>>
>> There is a suggestion from Microchip (in the C18 user guide) to use pointers
>> to large data objects (large, in this case, means that the object crosses a
>> bank boundary).
>>
>> In the project I am currently working on, I have a queue that takes up three
>> banks, accessed with "normal" array indexing like that above. Under the
>> hood, I imagine the compiler places the base array address in the FSR[H:L]
>> registers and then adds the index to them.
>>
>> -Scott

> Carl Denk escreveu:
>  
>> Yes, that's where I saw the pointers needed - large data, I was being
>> conservative. I have the  thought that the extra pointer arithmetic is
>> causing a marginal timing problem with the extra overhead and going to
>> pursue, keeping that to a minimum in the send loop. But that doesn't
>> explain why the problem persists when using
>> putsUSART (readarray);  And I'm saying exactly the same symptoms. Also,
>> I did try 2400 baud instead of the usual 9600 with no change.
>>
>> I did check both the errata and silicon errata. Since I don't use
>> autobaud detect, there wasn't anything, except, an issue of not starting
>> from code 0x00, and they want a "nop" there. That might account for some
>> of the no response I have experienced, thinking it was my code.
>>
>> Scott wrote:
>>  
>>    
>>> On Tue, Jun 2, 2009 at 10:17 AM, Carl Denk <EraseMEcdenkEraseMEwindstream.net> wrote:
>>>
>>>  
>>>    
>>>      
>>>> I read somewhere that when using banked storage, the arrays should be
>>>> referenced with pointers. One of the major changes to the program was to
>>>> use pointers, at least on the arrays in the access area.
>>>>
>>>>    
>>>>      
>>>>        
>>> Tamas' suggestion to use normal array indexing is fine (i.e. you do not need
>>> to use pointers because the array itself is a pointer).
>>> Code such as below will work fine:
>>>
>>> uint8_t buffer[BUFFER_SIZE];
>>>
>>> buffer[i] = data;
>>>
>>> There is a suggestion from Microchip (in the C18 user guide) to use pointers
>>> to large data objects (large, in this case, means that the object crosses a
>>> bank boundary).
>>>
>>> In the project I am currently working on, I have a queue that takes up three
>>> banks, accessed with "normal" array indexing like that above. Under the
>>> hood, I imagine the compiler places the base array address in the FSR[H:L]
>>> registers and then adds the index to them.
>>>
>>> -Scott
>>>      
>
>
> You are right, the problem with multi-bank variables arise when the
> compiler uses compile-time generated addresses to access data.
>
> For instance, if you write:
>
> char x[512];
> ....
> char a, b;
> a = x[0];
> b = x[256];
>
>
> The compiler generates a "movlb" instruction for the first access, but
> for the second access it thinks it already selected the bank of variable
> x and don't generate the "movlb" again.
>
> It's obviously a bug in the code generator.
> You may get this bug if you use constant indexes (as above), if you use
> a variable as an index then everything is OK.
>
> Another way to get the bug is to define a RAM section bigger than 256
> bytes and defining several variables in it that lay in different banks
> of the same section.
> Eg.:
>
> char a;
> char b[256];
> char c;
>
> If you access "a" and "b" in sequence then the bug happens.
>  

> #include <p18cxxx.h>
>
> char x[16];
>
> void main( void )
>     {
>     x[0] = 1;
>     1[x] = 2;
>
>     while( 1 )
>         {
>         ClrWdt();
>         3[x]++;
>         4[x]--;
>         }
>     }

>
> You are right, the problem with multi-bank variables arise when the
> compiler uses compile-time generated addresses to access data.
>
> For instance, if you write:
>
> char x[512];
> ....
> char a, b;
> a = x[0];
> b = x[256];
>
>
> The compiler generates a "movlb" instruction for the first access, but
> for the second access it thinks it already selected the bank of variable
> x and don't generate the "movlb" again.
>
> It's obviously a bug in the code generator.
> You may get this bug if you use constant indexes (as above), if you use
> a variable as an index then everything is OK.
>
> Another way to get the bug is to define a RAM section bigger than 256
> bytes and defining several variables in it that lay in different banks
> of the same section.
> Eg.:
>
> char a;
> char b[256];
> char c;
>
> If you access "a" and "b" in sequence then the bug happens.
>
>
> Regards,
>
> Isaac
>
> __________________________________________________
> Faça ligações para outros computadores com o novo Yahoo! Messenger
> http://br.beta.messenger.yahoo.com/
>

>
>>
>> > Many don't know, but "x = 1[p];" is valid and is the same as
>> > "x=p[1];".
>>

> In classic K&R C it would probably would compile with a default data
> type of int, or possibly char. I think ANSI c would require some type
> casting to get it to compile. Running however is a different story.
> If the memory location addressed as '1' is protected in the process
> space then its not going to get very far.
>
> Regards,
> Kevin Jones

> Olin Lathrop wrote:
>
>> Isaac Marino Bavaresco wrote:
>>> Many don't know, but "x = 1[p];" is valid and is the same as
>>> "x=p[1];".
>>
>> I find that hard to believe.  What data type would 1[p] have?  How
>> would it know the size of each element?  Can you show complete
>> example code that actually compiles using this construct?
>
> Both arrays need a declaration that defines their member type.
>
> 1[p] could point to (1 + p * sizeof(memberType)). (Not sure this is
> legal, but it could be -- given an implicit conversion from int to an
> array address.)
>
> p[1] would point to (p + 1 * sizeof(memberType)).
>
> If you declare the arrays so that sizeof(memberType)==1, this could
> work.
>
> I don't see any use for this "trick", though...
>
> Gerhard

> Bob Ammerman wrote:
>> Believe it or not he is right. C *defines*   "a[b]" to mean the same
>> thing as *(a+b)
>>
>> Strange and ugly, but true.
>
> Even when A is a constant?  Yucc.
>
> According to what you're saying, "*(1 + 12)" is a valid expression.  What
> data type does it have?  I can imagine that causing a alignment fault on
> quite a few machines unless the data type size is somehow the amount of
> storage covered by a memory address increment.

> Carl Denk escreveu:
>  
>> By "if you use a variable as an index then everything is OK. "
>>  it is meant that: the variable is a pointer??
>>
>> If that is true, then I did correctly by making access to the stuff in
>> accessram via. a pointer, and that was conservative thinking, I think.. :)
>>  
>>    
>
> I will try to explain with examples:
>
> char x[512];
> ....
> int i;
> char *p;
> char temp, temp2;
>
> temp = x[0];   // Probably OK
> temp2 = x[300]; // Problem
>
> i = 0;
> temp = x[i]; // OK
> i = 300;
> temp2 = x[i]; // OK
>
> p = x;
> temp = *p; // OK
> temp2 = p[300]; // OK
>
>
> The problem arises in the first example because the address of x[300] is
> known at build (link) time and is hard-coded in the program.
> The compiler try to optimize and sometimes mess things up.
> The first access (x[0]) is probably OK because it is the first access
> and the compiler (probably) will issue a "movlb x" before the actual
> access. For the second example, another "movlb' (different than "movlb
> x") is needed but probably the compiler will not generate it.
>
> All the other examples calculate the address at run-time and do it
> correctly. The address is calculated and put into an FSR (FSR0 almost
> certainly) and the access is done through an INDF (INDF0).
>
> Regards,
>
> Isaac
>
> __________________________________________________
> Faça ligações para outros computadores com o novo Yahoo! Messenger
> http://br.beta.messenger.yahoo.com/
>

> >> >> Many don't know, but "x = 1[p];" is valid and is the same as
> >> >> "x=p[1];".
> >> >>
> >
> > OK, this works if the type of  x is the fundamental pointer size,
> > byte. However, make x a structure that has many bytes, p an array of
> > those structures, and I think it breaks down. Consider that
> > if  sizeof(x) is 10 the and then p contains the address 5,  1[p]
> > evaluates to what address ? 1 + 5 or 1 + (5 * 10) ?  Either way I
> > don't think its going to be equal to p[1] which should be 5 + 10 = 15.
> >
> > Regards,
> > Kevin Jones
>
> Nope, this works as long as the type of x is assignment compatible with the
> type of *p.
>
> -- Bob Ammerman
> RAm Systems
>
>

> Tamas Rudnai escreveu:
>  
>> On Tue, Jun 2, 2009 at 8:50 PM, Rikard Bosnjakovic <
>> RemoveMErikard.bosnjakovicEraseMEspam_OUTgmail.com> wrote:
>>
>>  
>>    
>>> Note the word *arithmetic*. It means that *(n+m) is the same as *(m+n)
>>> using the commutative law of mathematics
>>>
>>>    
>>>      
>> These things are perfect if you are always use pointers to byte size types
>> (like char for example). In C the +n means +n*sizeof(m). For example if you
>> have a pointer to int32 to mem location 100 and want to address of the 4th
>> element in the array, you say *m+n = *100+(4*4) = 116. Now if you say *n+m =
>> *4+100 it is only 104 or if you say *4+(4*100) then again that's wrong.
>>
>> Tamas
>>  
>>    
>
> No, not true. The compiler knows the size of the object pointed to by
> the pointer and scales the index so you access the correct element.
>
> long *p, n;
> n = *(p+10) // Accesses the 11th element of the array, not the middle of
> the 3rd element.
>
> Regards,
>
> Isaac
>  

> > These things are perfect if you are always use pointers to byte size
> types
> > (like char for example). In C the +n means +n*sizeof(m). For example if
> you
> > have a pointer to int32 to mem location 100 and want to address of the
> 4th
> > element in the array, you say *m+n = *100+(4*4) = 116. Now if you say
> *n+m =
> > *4+100 it is only 104 or if you say *4+(4*100) then again that's wrong.
> >
> > Tamas
> >
>
> No, not true. The compiler knows the size of the object pointed to by
> the pointer and scales the index so you access the correct element.
>
> long *p, n;
> n = *(p+10) // Accesses the 11th element of the array, not the middle of
> the 3rd element.
>