configuration of uart

Re: configuration of uart

Postby tunelabguy » Tue Sep 30, 2014 8:04 pm

phoenix2000 wrote:;) but there still questions :?: doesn't the usart of c18 have a mechanism like this ?
what is rxBuffer.idx ?is it in c18 or another compiler or you define it?

It is difficult for the compiler to provide you with a fully generic interrupt-driven buffered serial port. Just look at how complicated the Windows API is for serial communications. It takes a lot of program memory to provide that level of generality. That is difficult to fit into the memory-constrained microcontrollers.

When I implement an interrupt-driven serial port, I will often have the interrupt service routine perform some of the application-level parsing of the input. This makes it unnecessary to buffer an entire message in RAM. At the very least, you want to let the ISR detect packet termination characters. This does make the ISR less re-useable, but it greatly reduces the demands on memory (both RAM and program).
User avatar
tunelabguy
Verified identity
 
Posts: 29
Joined: Sun Jul 20, 2014 9:41 pm
PIC experience: Professional 5+ years with MCHP products

Re: configuration of uart

Postby phoenix2000 » Wed Oct 01, 2014 12:34 pm

finally i could do it,yessss :D :mrgreen:
i could send data via micro to sim900 but i couldn't receive data from sim900 ,although it sent it (because data were shown on my laptop)
why?!!! it was the question that was making me crazy for 3 days:twisted: :evil:
finally today thanks god i did it.want to know how? :twisted:
the problem was voltage.the voltage of logic level of pin of sim900 is about 3 volt but for the micro was about 5 volt.after that i reduced the vdd of micro controller it got OK and could understand the logic level.
thank u vloki,you helped me so much :mrgreen:
User avatar
phoenix2000
 
Posts: 20
Joined: Thu Jul 10, 2014 3:36 am
PIC experience: EE Student

Re: configuration of uart

Postby phoenix2000 » Wed Oct 01, 2014 1:03 pm

tunelabguy wrote:It is difficult for the compiler to provide you with a fully generic interrupt-driven buffered serial port. Just look at how complicated the Windows API is for serial communications. It takes a lot of program memory to provide that level of generality. That is difficult to fit into the memory-constrained microcontrollers.

yes,but only checks and tells us if any error happened,i don't think this take so much memory and by the way if the library doesn't do it we should check for error it and fix it.
and there is a thing that i can't undersatand.in ReadUSART() function of c18 usart library we have these :

if(RCSTAbits.FERR) // If a framing error occured
USART_Status.FRAME_ERROR = 1; // Set the status bit

if(RCSTAbits.OERR) // If an overrun error occured
USART_Status.OVERRUN_ERROR = 1; // Set the status bit

but i don't why they put it?it can only tells us that there is a error !why they didn't change it to fix the error by sth like:
if(RCSTA&0x06) //more efficient way than following commented method to check for reception error
//if(RCSTAbits.FERR==1 || RCSTAbits.OERR==1 )
{
RCSTAbits.CREN=0; //Overrun error (can be cleared by clearing bit CREN)
recieved_data=RCREG; //clear Framing error
RCSTAbits.CREN=1;
}

tunelabguy wrote:When I implement an interrupt-driven serial port, I will often have the interrupt service routine perform some of the application-level parsing of the input. This makes it unnecessary to buffer an entire message in RAM. At the very least, you want to let the ISR detect packet termination characters. This does make the ISR less re-useable, but it greatly reduces the demands on memory (both RAM and program).

would you please explain it simpler. :?: with an example.thank u very much ;)
User avatar
phoenix2000
 
Posts: 20
Joined: Thu Jul 10, 2014 3:36 am
PIC experience: EE Student

Re: configuration of uart

Postby vloki » Wed Oct 01, 2014 4:53 pm

I never use that ReadUSART() function ...
No need to call a function that does useless things (for me)
and needs to save and restore context in addition :-(

I only use the functions for setting up the USART which are
usually called only once during initialization (openUSART & baudUSART)

The macros (busyUSART ...) or ok for me too.
vloki
Verified identity
 
Posts: 186
Joined: Wed May 28, 2014 8:42 am
Location: Germany
PIC experience: Professional 5+ years with MCHP products

Re: configuration of uart

Postby tunelabguy » Wed Oct 01, 2014 8:29 pm

phoenix2000 wrote:would you please explain it simpler. :?: with an example.thank u very much ;)

OK, here is a sample portion of the interrupt service routine for an interrupt-driven transmit and receive function for a PIC16F1823:
Code: Select all
  if(PIR1.RCIF)   //..RCREG1 is full.  RCIF will be cleared when RCREG is read
  {
    isrChar = RCREG;   //..this clears RCIF, and moves char. into variable: "isrChar".
    if(RCSTA.OERR)      //..in case there was an overrun error, we need to clear it.
    {
      RCSTA.CREN = 0;
      RCSTA.CREN = 1;
    }
    else
    {
      if(serialState.completeCmdRcvd)  //..this is a bit test
      {
          //..do nothing because previous command has not been handled yet
      }
      else if(isrChar == 'A')      //..address designator
      {
        serialState.Arcvd = 1;
        num16 = 0;
      }
      else if ('B' <= isrChar && isrChar <= 'Z')   //..a command letter
      {
        cmdAddr = num16;
        num16 = 0;
        serialCmdLetter = isrChar;
        serialState.CmdLetterRcvd = 1;
      }
      else if('0' <= isrChar && isrChar <= '9')   //..a number, either address or parm
      {
        num16 += num16;   // 2 x
        isrTemp16 = num16;   //..also = 2 x
        num16 <<= 2;      // 8x
        num16 += isrTemp16;  //num16 is now 10x what it was before
        num16 += (isrChar-'0');  //..add in this most recent digit
      }
      else if(isrChar == 0x0d)   //..carriage return (CR) ?
      {
        if(serialState.cmdLetterRcvd)  //..
        {
          cmdParm = num16;
          serialState.completeCmdRcvd = 1;
          serialState.cmdLetterRcvd = 0;   //..so another CR will not cause this command to be repeated
        }
      }
    }
  }

  if(TxNextToSend < TxEnd)
  {
    isrChar = TxBuf[TxNextToSend];
    PIE1.TXIE = 1;      //..in case we got here because of some other interrupt..
    if(PIR1.TXIF)
    {
      TXREG = isrChar;
      TxNextToSend++;
    }
  }
  else
  {
    PIE1.TXIE = 0;
  }

Remember, this may not apply to you, because this ISR is customized for my specific application. In this application, the PIC is parsing packets that start with the letter "A" (for address), followed by a number (the address), followed by a command letter (B-Z) followed by another number (a parameter value), followed by a carriage return character. When such a packet is received, the address, the command letter, and the parameter value are all available in variables for the main program to look at. The main program is periodically polling the flag, serialState.completeCmdRcvd , to tell when the ISR has received a packet. When a packet is received, no further data will be processed by the ISR until the main program has acknowledged the reception of the packet by clearing the serialState.completeCmdRcvd flag.

Note how no character buffer is needed. The received characters go into dedicated variables, like serialCmdLetter, or are fed into the accumulation of a decimal number in num16. By the way, I used the addition method of multiplying by 10 so that I avoid having to save and restore the dedicated multiplication registers.

This ISR also handles a generic interrupt-driven output function, which writes from a small buffer, TxBuf. Note that the buffer is not a circular buffer. Therefore this implementation requires the background to fill the buffer, set TxEnd and TxNextToSend, and then enable transmit interrupts. This implementation cannot handle an application where the main program needs to be writing more data to the output buffer before the previous packet has been completely sent. So this implemention is not for everyone either. You have to know your application and what you can get away with and what you can't.
User avatar
tunelabguy
Verified identity
 
Posts: 29
Joined: Sun Jul 20, 2014 9:41 pm
PIC experience: Professional 5+ years with MCHP products

Previous

Return to SCI/USART/EUSART

Who is online

Users browsing this forum: No registered users and 3 guests

cron