Searching \ for '[PIC] MPLAB SIM PROBLEM - help' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.sxlist.com/techref/microchip/languages.htm?key=mplab
Search entire site for: 'MPLAB SIM PROBLEM - help'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] MPLAB SIM PROBLEM - help'
2009\06\01@220120 by Carl Denk

flavicon
face
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


{Quote hidden}

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. :)        














2009\06\02@004456 by John Coppens

flavicon
face
On Mon, 01 Jun 2009 22:01:04 -0400
Carl Denk <spam_OUTcdenkTakeThisOuTspamwindstream.net> wrote:

> >                for (j = 3; j >= 1; j--)        // 4 Characters

This loop only does 3 characters, not 4 as the comment says?

John

2009\06\02@042540 by Tamas Rudnai

face picon face
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 <.....cdenkKILLspamspam@spam@windstream.net> wrote:

{Quote hidden}

> -

2009\06\02@092416 by olin piclist

face picon face
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.

2009\06\02@092734 by Carl Denk

flavicon
face
Thanks for the comment, the comment should read 3, not 4. there are 4
digits, to right justify, at most 3 shifts are needed.

Also, I should note, I have experimented with adjusting the baud rate,
using 2400, and by tweaking the USART_BRGH_HIGH, 51 by trying values
from 49 to 53, with either no change or at extremes no communication.  
What I find wierd, is generally digital things  are consistent, doing
the same thing over and over again, where this is random things, over
and over. But if I program a chip to the original program, it's is very
stable as expected, and this is same chip and hardware. The "readarray"
is getting built properly, at least per MPLAB SIM.

John Coppens wrote:
{Quote hidden}

2009\06\02@095444 by Carl Denk

flavicon
face
The original program did use TMRT/TXREG, here's the code that is
commented out at the moment. There was the same behavior.

 for ( i = 0; i <= 23 ; i++)
       {
       while ( TXSTAbits.TRMT == 0)// The transmit is busy when 0
               TXREG = (near) *(preadarray + i);
       }

What low level firmware are you referring to? The 1320's silicon? All this has been working for several years, with exactly the same hardware/software (except for the XP udates, etc.). I can program a 1320 with the original software and everything is fine, have swapped out all hardware with same results makes me feel strongly (still very open to other thoughts)that it's my "C" program, something like a pointer or other storage declaration going to 1 byte and should be 2 bytes. But as I said before most generally, digital things are good at duplicating over, and over, and that's not happening.

Thanks again. :)



Olin Lathrop wrote:
{Quote hidden}

2009\06\02@101306 by Dario Greggio

face picon face
Olin Lathrop ha scritto:
>
> 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


yeap, I was thinking of the same, but then again I stopped when
considering the LF issue.
What about Fast IRQ errata, possibly applicable to that PIC and possibly
creating any sort of thing?

2009\06\02@101758 by Carl Denk

flavicon
face
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.

If I understand correctly, limit the arithmetic of the pointer to 2
terms, and decrement first, then use the pointer, but then that might
upset the progression of the pointer in a loop. Along that line of
thinking, add  a temporary pointer:
Something like this.

char *p_temp;
p_temp = preadarray +i -1;
putsUSART (*ptemp);

As for the string terminator, look down 2/3 in the code for the line:
(And yea, code is hard to read in an E-mail instead of an editor with
indents and colors) :)

*(preadarray + 24) = '\0';      // Bit 24 - End of String

At least as far as MPLAB SIM indicates the "readarray" array is getting
formed, and adjusted good. And the output of transmit, as seen both in
the watch window (with breakpoints), and the output window, is happening
as expected. But burn/verify (Microengineering lab EPIC parallel
programmer), plug the PIC board into a PC com port, send the command
string (normally ties to RS-485), and the slightly garbled output
results. I can program the same or other chips with the original
software and everything is fine. The 1 major changes to the software:
1: Added coding to do software filtering of ADC. This resulted in memory
overflow issues that the PICLIST helped solve by using accessram.
2: I had read that when using banked memory, arrays neede to be accessed
with pointers, and I made those changes. Some of the issues I had went
away at that point.
3: The flow of the process was changed. Originally  the ADC values were
only gotten when the appropriate RS-485 control string was received, and
then the reply string is sent. Now, the ADC values are continually  
gotten, and scaled/adjusted. When the control string is received, the
PIC goes to sending the most current values. Incidentally, none of these
values change  quickly. Trying to reduce the waiting time on the PLC at
the other end of the RS-485.

Appreciate the comments, keep them coming.

Tamas Rudnai wrote:
{Quote hidden}

>> --

2009\06\02@102445 by olin piclist

face picon face
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.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\02@103900 by olin piclist

face picon face
Carl Denk wrote:
> 2: I had read that when using banked memory, arrays neede
> to be accessed with pointers, and I made those changes.

Anything where the address is computed at run time needs to be accessed thru
a FSR, but the compiler should hide all that.  This has nothing to do with
banked versus unbanked memory.

You are becoming the poster child for why one should do the first few
projects in assembler instead of jumping in with a compiler, thinking
erroneously it will just take care of all low level issues for you.  Your
lack of understanding of what is happening at the machine level is getting
you into trouble.  You will be forever bumping into strange symptoms that
you have little chance of resolving until you sit down and learn the PIC and
understand the compiler and linker for real.

This sounds like a simple project that is ideal for doing in assembler so
that you learn what is really going on.  And no, I don't want to hear about
how you don't have time to learn that.  You don't have time not to learn it.
Look at how much time you've already wasted by not understanding.  If you'd
applied that to RTFM and a little practise you'd probably be done now.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\02@103958 by Tamas Rudnai

face picon face
On Tue, Jun 2, 2009 at 3:25 PM, Olin Lathrop <EraseMEolin_piclistspam_OUTspamTakeThisOuTembedinc.com>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.


Good catch Olin!

It should be like:

// block the flow till we can send a char...
while ( TXSTAbits.TRMT == 0) {  /* The transmit is busy when 0 */  }
// now we can transmit -- however, we have no timeout this way...
TXREG = (near) *(preadarray + i);

Tamas
--
http://www.mcuhobby.com

2009\06\02@104337 by Dario Greggio

face picon face
Olin Lathrop ha scritto:
> 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.


yeah, looks like a semicolon's missing.

from C18 libraries:

char Busy1USART(void)
{
  if(!TXSTA1bits.TRMT) // Is the transmit shift register empty
    return 1;          // No, return FALSE
    return 0;            // Return TRUE
}


void Write1USART(char data)
{
  if(TXSTA1bits.TX9)  // 9-bit mode?
  {
    TXSTA1bits.TX9D = 0;       // Set the TX9D bit according to the
    if(USART1_Status.TX_NINE)  // USART1 Tx 9th bit in status reg
      TXSTA1bits.TX9D = 1;
  }

  TXREG1 = data;      // Write the data byte to the USART2
}

2009\06\02@112453 by Scott

picon face
On Tue, Jun 2, 2009 at 10:17 AM, Carl Denk <cdenkspamspam_OUTwindstream.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

2009\06\02@121436 by Robert Young

picon face


> From: @spam@olin_piclistKILLspamspamembedinc.com
> To: KILLspampiclistKILLspamspammit.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

2009\06\02@123050 by Carl Denk

flavicon
face
The semi-colon got lost in copy/paste, it's there in the code. :(

Robert Young wrote:
>  
>> From: RemoveMEolin_piclistTakeThisOuTspamembedinc.com
>> To: spamBeGonepiclistspamBeGonespammit.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
>  

2009\06\02@125518 by Rikard Bosnjakovic

picon face
On Tue, Jun 2, 2009 at 18:30, Carl Denk <TakeThisOuTcdenkEraseMEspamspam_OUTwindstream.net> wrote:

> The semi-colon got lost in copy/paste, it's there in the code. :(

For readability, perhaps you could use pastebin when showing source code?


--
- Rikard - http://bos.hack.org/cv/

2009\06\02@131121 by Carl Denk

flavicon
face
sorry, not familiar with pastebin, can you point me to instructions. :)

Rikard Bosnjakovic wrote:
> On Tue, Jun 2, 2009 at 18:30, Carl Denk <RemoveMEcdenkspamTakeThisOuTwindstream.net> wrote:
>
>  
>> The semi-colon got lost in copy/paste, it's there in the code. :(
>>    
>
> For readability, perhaps you could use pastebin when showing source code?
>
>
>  

2009\06\02@131946 by Isaac Marino Bavaresco

flavicon
face
Scott escreveu:
> On Tue, Jun 2, 2009 at 10:17 AM, Carl Denk <cdenkEraseMEspam.....windstream.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;
>  

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

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\02@132609 by olin piclist

face picon face
Rikard Bosnjakovic wrote:
> For readability, perhaps you could use pastebin when showing source
> code?

No, don't do that.  I'm not going to chase down a link in a PIClist message
just because someone else doesn't know how to use copy and paste, and I'm
not the only one.  The best messages are short, to the point, and
self-contained.  Just make sure the original is properly formatted, with no
tabs of course.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\02@133116 by Isaac Marino Bavaresco

flavicon
face
Carl Denk escreveu:
{Quote hidden}

And the indentation also helps to create confusion.

I usually signal such constructs with: "; /* Empty statement */" or "{
/* Empty statement */ }", to avoid getting confused later if the
semicolon gets lost or overlooked.

Sometimes it is better to put a "ClrWdt();" inside the loop.

Regards,

Isaac



__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\02@133204 by olin piclist
face picon face
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?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\02@133315 by Carl Denk

flavicon
face
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:
{Quote hidden}

2009\06\02@134512 by Carl Denk

flavicon
face
Thanks, good to know what works, when it doesn't look like it should. I
think I'll try to stick to the basics as shown in my K & R 1st edition,
and "The C Programmer's Handbook" by AT&T Bell labs, c/o 1985.  :) :)

With the changes over the years, I should update my references, can
someone suggest?

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

2009\06\02@134619 by Kevin Jones

flavicon
face

>
> > 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?

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
 

2009\06\02@141043 by Tamas Rudnai

face picon face
On Tue, Jun 2, 2009 at 5:30 PM, Carl Denk <RemoveMEcdenkTakeThisOuTspamspamwindstream.net> wrote:

> The semi-colon got lost in copy/paste, it's there in the code. :(
>

Semicolon is generally a bad idea after a while or other loops. It is error
prone, hard to spot etc. Some compiler would give you a warn for that -- and
if you use plint it would tell you what's wrong with your code before you
are wondering why is that not working,,,

The generic rule is that even if the language itself allows you to no not to
use brackets just put it everywhere -- even when there is no iteration body.
It is even better if you put a small comment that the body left empty
intended.

Tamas
--
http://www.mcuhobby.com

2009\06\02@141423 by Bob Ammerman

picon face

----- Original Message -----
From: "Olin Lathrop" <EraseMEolin_piclistspamspamspamBeGoneembedinc.com>
To: "Microcontroller discussion list - Public." <RemoveMEpiclistKILLspamspammit.edu>
Sent: Tuesday, June 02, 2009 1:29 PM
Subject: Re: [PIC] MPLAB SIM PROBLEM - help


> 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?

Olin,

Believe it or not he is right. C *defines*   "a[b]" to mean the same thing
as *(a+b)

Strange and ugly, but true.

-- Bob Ammerman
RAm Systems


2009\06\02@142138 by Rikard Bosnjakovic

picon face
On Tue, Jun 2, 2009 at 19:11, Carl Denk <cdenkSTOPspamspamspam_OUTwindstream.net> wrote:

> sorry, not familiar with pastebin, can you point me to instructions. :)

http://pastebin.com/


--
- Rikard - http://bos.hack.org/cv/

2009\06\02@142348 by Rikard Bosnjakovic

picon face
On Tue, Jun 2, 2009 at 19:27, Olin Lathrop <spamBeGoneolin_piclistSTOPspamspamEraseMEembedinc.com> wrote:

> I'm not going to chase down a link

Well, noone will force you to.


--
- Rikard - http://bos.hack.org/cv/

2009\06\02@142454 by Gerhard Fiedler

picon face
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

2009\06\02@145154 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
> 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?
Exactly the same as the base type of x;

>   Can you show complete example code that
> actually compiles using this construct?
>  

#include <p18cxxx.h>

char x[16];

void main( void )
   {
   x[0] = 1;
   1[x] = 2;

   while( 1 )
       {
       ClrWdt();
       3[x]++;
       4[x]--;
       }
   }

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\02@145313 by Isaac Marino Bavaresco

flavicon
face
Carl Denk escreveu:
{Quote hidden}

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/

2009\06\02@150325 by olin piclist

face picon face
Isaac Marino Bavaresco 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...
>
> And the indentation also helps to create confusion.
>
> I usually signal such constructs with: "; /* Empty statement */" or "{
> /* Empty statement */ }", to avoid getting confused later if the
> semicolon gets lost or overlooked.
>
> Sometimes it is better to put a "ClrWdt();" inside the loop.

Good thing we have higher level languages that make the program action so
nice and clear.  Nobody would ever figure out such a long and complicated
code snippet like:

uloop  btfss   txsta, trmt  ;UART ready for another byte ?
      goto    uloop        ;no, go back and check again


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\02@150748 by olin piclist

face picon face
Carl Denk wrote:
> Yes, that's where I saw the pointers needed - large data, I was being
> conservative.

Again, go learn how the PIC works so you can try real engineering instead of
waving a dead fish in the hopes of getting your program to work.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\02@151336 by olin piclist

face picon face
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.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\02@151903 by olin piclist

face picon face
Rikard Bosnjakovic wrote:
>> I'm not going to chase down a link
>
> Well, noone will force you to.

Which is completely irrelevant.  The point is that someone wishing to
maximize responses to a question here should post a reasonably self
contained message.  Links are OK for auxilliary reference material, such as
a datasheet, but if the question is about code then you should post the
code, neatly formatted of course.

It is often useful to reply to such a question by quoting some of the code.
The harder you make it, the less likely it will be for people to take the
time to do it.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\02@152052 by Isaac Marino Bavaresco

flavicon
face
Isaac Marino Bavaresco escreveu:
{Quote hidden}

Sorry, it should read "a" and "c".

> Regards,
>
> Isaac
>  

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\02@152729 by olin piclist

face picon face
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?
>
> Exactly the same as the base type of x;

But I thought the data type of a C expression was governed only by the
expression itself, not how the value is then used.  So you're saying that
1[p] can have a different data type depending on what type of variable its
value is assigned to?  That makes even less sense.  How would the compiler
know what to increment, for example, if you wrote 1[p]++ if it could be
referring to a single byte, 2 byte integer, 4 byte integer, and possibly
other things?

{Quote hidden}

Wow.  I'll take you're word for the fact that it compiled.  I knew C sucked,
but it is really irresponsible of it to allow something like this.  I need
to go wash the slime off my monitor now.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\06\02@154011 by Dario Greggio

face picon face
Olin Lathrop ha scritto:

> Wow.  I'll take you're word for the fact that it compiled.  I knew C sucked,
> but it is really irresponsible of it to allow something like this.  I need
> to go wash the slime off my monitor now.

LOL :)
needless I agree with you Olin, though I love C.
I'd just take a look at the produced code *for that specific platform* :)

Dario

2009\06\02@154620 by Kevin Jones

flavicon
face

> >> 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

2009\06\02@154621 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
> 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
>  

No, in the "a[b]" case, "b" has a type "pointer to something" attached,
and the expression "a+b" inherits the type.
1+12 has type "int" and can't be used as a pointer unless it is cast to
something else.

> 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.
>  


__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\02@154919 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
> 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?
>>>      
>> Exactly the same as the base type of x;
>>    
>
> But I thought the data type of a C expression was governed only by the
> expression itself, not how the value is then used.  So you're saying that
> 1[p] can have a different data type depending on what type of variable its
> value is assigned to?  That makes even less sense.  How would the compiler
> know what to increment, for example, if you wrote 1[p]++ if it could be
> referring to a single byte, 2 byte integer, 4 byte integer, and possibly
> other things?
>  

Sorry, again I typed a different thing than I was thinking. It should
read "Exactly the same as the base type of '*p' ".

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\02@155141 by Rikard Bosnjakovic

picon face
On Tue, Jun 2, 2009 at 21:28, Olin Lathrop <@spam@olin_piclist@spam@spamspam_OUTembedinc.com> wrote:

> Wow.  I'll take you're word for the fact that it compiled.  I knew C sucked,
> but it is really irresponsible of it to allow something like this.  I need
> to go wash the slime off my monitor now.

Like someone else already noted, the array construct n[m] (array n,
element m) is *by definition* the same as *(n+m) using pointer
arithmetic.

Note the word *arithmetic*. It means that *(n+m) is the same as *(m+n)
using the commutative law of mathematics
(http://www.mathnstuff.com/math/spoken/here/1words/c/c29.htm)

Now when we have *(m+n), which is perfectly valid, we can go backwards
using the definition. This means m[n] is valid, where n is still the
array and m is still the index. Nothing ugly here, so you should
probably replace your monitor or read more about C.


--
- Rikard - http://bos.hack.org/cv/

2009\06\02@160253 by Carl Denk

flavicon
face
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.. :)

Isaac Marino Bavaresco wrote:
{Quote hidden}

>

2009\06\02@160851 by Tamas Rudnai

face picon face
On Tue, Jun 2, 2009 at 8:50 PM, Rikard Bosnjakovic <
spamBeGonerikard.bosnjakovicspamKILLspamgmail.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
--
http://www.mcuhobby.com

2009\06\02@161105 by Isaac Marino Bavaresco

flavicon
face
Kevin Jones escreveu:
>>>> 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
>  


In a previous post I confused myself and said (wrongly) that the
expression has the same type of 'x'. That is not true, the expression
has the same type of '*p', and it works independently of the type of 'x'.

Bob Ammerman noted that "a[b]" is "*(a+b)", so "1[p]" becomes "*(1+p)",
which is perfectly valid and unequivocal.

Regards,

Isaac




__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\02@162946 by Bob Ammerman

picon face

----- Original Message -----
From: "Kevin Jones" <.....krjone01spam_OUTspamaye.net>
To: "Microcontroller discussion list - Public." <TakeThisOuTpiclist.....spamTakeThisOuTmit.edu>
Sent: Tuesday, June 02, 2009 1:45 PM
Subject: Re: [PIC] MPLAB SIM PROBLEM - help


{Quote hidden}

This compiles fine in ANSI C.

a[b],
b[a], and
*(b+a)

are all equivalent ways of saying the same thing in C.

-- Bob Ammerman
RAm Systems


2009\06\02@163042 by Bob Ammerman

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

and these are valid, too!

"abcde"[i]

or even i["abcde"]

Yikes,

-- Bob Ammerman
RAm Systems

2009\06\02@163244 by Bob Ammerman

picon face

----- Original Message -----
From: "Gerhard Fiedler" <TakeThisOuTlistsKILLspamspamspamconnectionbrazil.com>
To: "Microcontroller discussion list - Public." <.....piclistspamRemoveMEmit.edu>
Sent: Tuesday, June 02, 2009 2:21 PM
Subject: Re: [PIC] MPLAB SIM PROBLEM - help


{Quote hidden}

Not true. As I mentioned before

a[b] === b[a] === *(a+b) === *(b+a)

This means that as long as one of a and b is a pointer (or array name) and
the other an integer type then the syntax is perfectly valid "C". There are
no restrictions on the type pointed to.

-- Bob Ammerman
RAm Systems

2009\06\02@163720 by Bob Ammerman

picon face

----- Original Message -----
From: "Olin Lathrop" <RemoveMEolin_piclistspamspamBeGoneembedinc.com>
To: "Microcontroller discussion list - Public." <spamBeGonepiclist@spam@spamspam_OUTmit.edu>
Sent: Tuesday, June 02, 2009 3:14 PM
Subject: Re: [PIC] MPLAB SIM PROBLEM - help


{Quote hidden}

No *(1+12) is not a valid expression because the value in the parens is of
an integer type and the dereference opeator * is not defined on an integer
type. Exactly one of the elements in the parens must be a pointer (or the
values have to otherwise evaluate to a single pointer and an integer). Note
that that implies that the following constructs (where i,j,k are integers
and p and q are pointers) are all legal:


(q-p)[p]
(p+i)[j]
(i+j)[p]
p[q-p]

etc.
etc.

to all sorts of ugliness.

-- Bob Ammerman
RAm Systems






2009\06\02@163911 by Bob Ammerman

picon face
>> >> 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


2009\06\02@164410 by Isaac Marino Bavaresco

flavicon
face
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/

2009\06\02@171932 by Carl Denk

flavicon
face
Thanks much for the examples, that helped. :)

Isaac Marino Bavaresco wrote:
{Quote hidden}

>

2009\06\02@175546 by Kevin Jones

flavicon
face

>
>Nope, this works as long as the type of x is assignment compatible with the
>type of *p.

Its the pointer arithmetic that keeps messing me up. The pointer type
carries around an implicit size of its target type and adds that in.
Its kind of like have a number in an different base.

Regards,
Kevin Jones

2009\06\02@175649 by Tamas Rudnai

face picon face
I have just tried this with an array -- seems to me that it works without
any problem:

100:                   array[1] = 1;
 00CE    0E01     MOVLW 0x1
 00D0    6E02     MOVWF 0x2, ACCESS
 00D2    6A03     CLRF 0x3, ACCESS
101:                   *(array+2) = 2;
 00D4    0E02     MOVLW 0x2
 00D6    6E04     MOVWF 0x4, ACCESS
 00D8    6A05     CLRF 0x5, ACCESS
102:                   *(3+array) = 3;
 00DA    0E03     MOVLW 0x3
 00DC    6E06     MOVWF 0x6, ACCESS
 00DE    6A07     CLRF 0x7, ACCESS
103:                   4[array] = 4;
 00E0    0E04     MOVLW 0x4
 00E2    6E08     MOVWF 0x8, ACCESS
 00E4    6A09     CLRF 0x9, ACCESS

Tamas



On Tue, Jun 2, 2009 at 9:39 PM, Bob Ammerman <TakeThisOuTrammermanspamspamverizon.net> wrote:

{Quote hidden}

> -

2009\06\02@201804 by Isaac Marino Bavaresco

flavicon
face
Tamas Rudnai escreveu:
> On Tue, Jun 2, 2009 at 8:50 PM, Rikard Bosnjakovic <
> rikard.bosnjakovicEraseMEspamgmail.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


__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\02@214607 by Isaac Marino Bavaresco

flavicon
face
Isaac Marino Bavaresco escreveu:
{Quote hidden}

OK, got the point now. It is not trully commutativity here, we are
talking about the sum of a pointer and an integer, opposing 1+p to p+1.
It is not true commutativity because p will always be the pointer and 1
will always be the integer index, independently of their position in the
expression.

The integer index will always be scaled (multiplied) by the size of the
element pointed by the pointer, and the pointer will always be the base
that will be added to the resulting offset.

It is commutativity just in the sense that they may be in any order and
the result will be the same.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\06\03@025645 by Tamas Rudnai

face picon face
On Wed, Jun 3, 2009 at 1:11 AM, Isaac Marino Bavaresco <
@spam@isaacbavarescoRemoveMEspamEraseMEyahoo.com.br> wrote:

{Quote hidden}

Yep, I know this. What I was confused was about n = *(10+p) -- I thought the
compiler gets the number 10, treats as an integer and silently converts as a
pointer and then gets the p and casts as an integer and as a results overall
messes up the size. But now it is clear. What is more confusing is n = 10[p]
which is still correctly calculated.

Thanks,
Tamas
--
http://www.mcuhobby.com

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...