Gr64 pic 18f452 with c18 compiler

Legacy Legacy AirPrime modules
1

Hi, my modem is GR64_0001, i test it with windows hyperterminal and it’s ok, i made the code on c18 compiler and i found that the pic don’t send the right \r. I made several test with \r, \n, \r\n, \n\r, and nothing. The pic receives Restart and show it in a LCD, sends AT and the eco works, but when a send the CR returns nothing.

I changed the ATQ and ATE, and ATS3 to 45, aTS4 to 40, that to see if there was any change but nothing again.

My question is if the c18 compiler works to this application or not.

If anybody have any idea, i’ll really appreciate it.

Thanks a lot.

while(!DataRdyUSART());
getsUSART(restart,11);//receive restart with \r\n
Delay10KTCYx(50);

while(BusyUSART());
putrsUSART(“AT\r”);//i tried CR after receive the eco too.
Delay10KTCYx(50);

2

You need to ask Microchip about that - it has nothing to do with Wavecom, Open-AT, or the GR64.

Have you checked what your PIC is actually sending by connecting it to a PC?

3

sure, i wrote the complete code to send a sms, and it appears complete on windows hyperterminal including the CR, that the reason i’m worry, i know the pic, the compiler and the gr64 works, but when i tried to send it to module, don’t send the sms.

Thanks for answering.

4

The usual mistake is not waiting for the ‘>’ prompt…

5

The trouble with Hypoterminal is that you can’t tell if it is really a CR, or something else that just happens to cause Hypoterminal to move its cursor to the start of the line…

6

I tested too, i made a code to put each caracter from the hyperterminal to pic’s portb, It showed 0x0d, but the problem is that, i don’t know if when i press Enter sends just CR or CR and LF. I don’t know if the pic’s usart sends a copy of string, i made a code to write on Hyperterminal, pic reads the string and then writes the GR64 but nothing, i think that the problem is the pic or the compiler changes the value of the char CR.

Thanks you for answering again.

7

If you suspect the PIC or hyperterminal changes the CR LF, why not just send the actual characters for carriage return and line feed. (0x0D and 0x0A instead of “\r\n”). That way you are sure you are sending the right characters.

8

Hiya,

Stop using Hyperterm!

For testing what characters are actually being shuffled up and down the serial line, I use Realterm http://realterm.sourceforge.net/. It can display the data as ASCII, HEX, or a combination of both. Realterm is a little funny to use, but once you’re used to it, it is a very useful tool.

For general purpose terminal, I use TeraTerm Pro http://ttssh2.sourceforge.jp/. TeraTerm will do either Telnet or Serial connections, is smart enough to display only the COM ports available and not in use in the system (handy if you have a number of different USB to Serial adapters), and has a simple Macro/Scripting language.

ciao, Dave

9

Not necessarily.

The compiler’s runtime libraries may do some translation(s) - particularly if using printf.

10

Hiya,

True.

However, the following, while a little long winded and probably inefficient will definitely output the individual CR & LF characters using printf:

printf("myString%c%c", 0x0D, 0x0A);

BTW, which version of the C18 compiler are you using? There are different optimizations available depending on if you are using the free trial version or have paid for the full licence.

cheers, Dave

11

Just for the sake of completeness, that may be true of the PIC libraries (I have no idea), but it’s not universally true.

The Keil C51 libraries, at least, apply the “new-line” translation to the output from printf - so “new-lines” can still get translated irrespective of what tricks you use with printf… :frowning:

12

Hiya,

Now there’s a trap for new players! I haven’t seen this in the PIC libraries - at least against the 18F6722 & 18F2525.

Where in the library is the translation happening? If you do a

putc(0x0d); putc(0x0a);

(or equivalent), is this also translated?

cheers, Dave

13

Getting off-topic but, for the record:

The printf in Keil’s C51 library calls putchar to do the actual output - see notes at the end of keil.com/support/man/docs/c51/c51_printf.htm

It is the default implementation of putchar (provided by Keil) that does the translation:

/*
 * putchar (full version):  expands '\n' into CR LF and handles
 *                          XON/XOFF (Ctrl+S/Ctrl+Q) protocol
 */
char putchar (char c)  {

  if (c == '\n')  {
    if (RI)  {
      if (SBUF == XOFF)  {
        do  {
          RI = 0;
          while (!RI);
        }
        while (SBUF != XON);
        RI = 0; 
      }
    }
    while (!TI);
    TI = 0;
    SBUF = 0x0d;                         /* output CR  */
  }
  if (RI)  {
    if (SBUF == XOFF)  {
      do  {
        RI = 0;
        while (!RI);
      }
      while (SBUF != XON);
      RI = 0; 
    }
  }
  while (!TI);
  TI = 0;
  return (SBUF = c);
}

so anything else that goes via putchar will also do the translation.

As you can see above, the source is provided - so the user can adapt this to their own requirements…
See: keil.com/support/man/docs/c5 … utchar.htm

There isn’t a putc in the Keil C51 library; see: keil.com/support/man/docs/c5 … stream.htm

The default putchar in the library would do the translation;
You could write your own putc and/or putchar to not do translation…

Don’t know about the Keil ARM tools…

14

Hi again, i really appreciate your advices.

I´m working now with Realterm, it is better than hyperterminal, i’m using a full version c18 compiler with upgrade “MPLAB-C18-Upgrade-v3_20” from microchip web page.

I’ll continue trying , and trying. I will tell you how everything is going on.

Thanks a lot, again.

15

Ok, my friends, i could send one sms from pic.

Thank you all.

16

For the benefit of future readers who might have similar problems, please describe what was actually causing your problem, and how you fixed it.