hi all
i am using the pic 18f252.I am using the
receive interrupt of the USART in which i just check for the incoming data and
also check if there are any framing error and overflow error in the incomming
message(RCSTAbits.FERR and RCSTAbits.OERR).
but only in some cases i have framing errors (I
make port pins high if RCSTAbits.FERR == 1).what is that error ,when does it
happen and what care shuld be taken so that i do not miss on these frames that
are comming.
waiting for a reply
reagards
krishna ______________________________________ Micro-IAS mailserver for domain microtechnologies.net Microtechnologies India Ltd. http://www.microtechnologies.net |
|

framing error
--- In , "krishnap" <krishnap@m...> wrote: > but only in some cases i have framing errors (I make port pins high if RCSTAbits.FERR == 1).what is that error ,when does it happen It sounds like the clock is off a bit on one side or the other. A framing error is when the receiver doesn't see the right amount of time between the start and stop bits for the baud rate that it thinks its running at. If one side or the other is running a little too fast or too slow then you will see this error intermittently. Another possiblility is noise. What is your clock source for the PIC? Is it a crystal? If not then that is likely your problem as any other clock source is not accurate enough and will probably result in errors like you are seeing. --Scott |
hi
I am using a crystal of 11.0592 MHz with a
SPBRG value of 5 (which makes a baud of 115200 ).
what do you suggest to safegaurd against
framing error.I am communicating with a nokia 5110 mobile which also works at
the baud of 115200 and yes you are right the framing error does not always
arise it is only when i receive certain types of farme from the
mobile(Receiving a new message).
what all can be done to AVOID THIS
ERROR.
thanks
krishna
--- In p...@yahoogroups.com, "krishnap" <krishnap@m...> wrote: > but only in some cases i have framing errors (I make port pins high if RCSTAbits.FERR == 1).what is that error ,when does it happen It sounds like the clock is off a bit on one side or the other. A framing error is when the receiver doesn't see the right amount of time between the start and stop bits for the baud rate that it thinks its running at. If one side or the other is running a little too fast or too slow then you will see this error intermittently. Another possiblility is noise. What is your clock source for the PIC? Is it a crystal? If not then that is likely your problem as any other clock source is not accurate enough and will probably result in errors like you are seeing. --Scott ______________________________________ Micro-IAS mailserver for domain microtechnologies.net Microtechnologies India Ltd. http://www.microtechnologies.net |
|
The longer the continuous received frame is, the higher the sampling position error will become. Is there hand shaking available so as to periodically interrupt the transmission? That should resolve the problem, by allowing the receiver to resync itself. Chad --- krishnap <> wrote: > hi > I am using a crystal of 11.0592 MHz with a SPBRG value of 5 (which > makes a baud of 115200 ). > what do you suggest to safegaurd against framing error.I am > communicating with a nokia 5110 mobile which also works at the baud > of 115200 and yes you are right the framing error does not always > arise it is only when i receive certain types of farme from the > mobile(Receiving a new message). > what all can be done to AVOID THIS ERROR. > thanks > krishna > --- In , "krishnap" <krishnap@m...> wrote: > > but only in some cases i have framing errors (I make port pins high > if > RCSTAbits.FERR == 1).what is that error ,when does it happen > > It sounds like the clock is off a bit on one side or the other. A > framing error is > when the receiver doesn't see the right amount of time between the > start > and stop bits for the baud rate that it thinks its running at. If > one side or the > other is running a little too fast or too slow then you will see this > error > intermittently. Another possiblility is noise. > > What is your clock source for the PIC? Is it a crystal? If not then > that is likely > your problem as any other clock source is not accurate enough and > will > probably result in errors like you are seeing. > > --Scott > > > ______________________________________ > Micro-IAS mailserver for domain microtechnologies.net > Microtechnologies India Ltd. > http://www.microtechnologies.net > ===== My software has no bugs. Only undocumented features. __________________________________ |
(This response is being re-posted on-line at yahoo because yesterday's off-line post was bounced by yahoo for some reason). I spent a LOT of time last year interfacing to a Nokia 5110 with PIC's. Thing is, 115,200k is massively high for a little embedded processor. I had to set up some fancy buffering, which isn't easy when the packet size from those silly Nokia's often exceeded the total RAM capacity of the PICs I was using. (C74, F628 and F876's) The point I am making is that if you spend too much time trying to process the stream from within the interrupt you may be getting overruns which are not being flagged properly. The overrun error may be being cleared as you exit the interrupt, meanwhile a successive byte may have already started and the UART is misinterpreting a midstream data as a start bit. This will surely give you framing errors. Here is _some_ of my handler, which I now see, didn't bother to check for framing error as; 1. I didn't think it likely to occur and 2. If it did occur there is no means of recovery and no need to worry because the Nokia would eventually resend the block anyway. void interrupt isr(void) { #if defined (_16C74) || defined (_16F876) || defined (_16F628) // SCI (Serial Communications Receiver) interrupt while(RCIF) { // set when SCI receive register is loaded if (OERR) { CREN = 0; // clear the overrun error CREN = 1; } // we don't need to check framing error because it will be // cleared, if set, when RCREG is read fifo[fifoin++] = RCREG; if (fifoin == FIFOSIZE) fifoin = 0; if (fifoin != fifoout) b_fifoloaded = 1; // if the buffer catches up to itself, too bad, we will // eventually get a checksum or other error and do a reset #if defined(PICDEM2) && defined(DIAGS_OK) PORTB = fifoin | 0x60; #endif } --- In , "krishnap" <krishnap@m...> wrote: > hi all > i am using the pic 18f252.I am using the receive interrupt of the USART in which i just check for the incoming data and also check if there are any framing error and overflow error in the incomming message(RCSTAbits.FERR and RCSTAbits.OERR). > but only in some cases i have framing errors (I make port pins high if RCSTAbits.FERR == 1).what is that error ,when does it happen and what care shuld be taken so that i do not miss on these frames that are comming. |
