I think this has something to do with the PIC serial IN buffer, a small 
FIFO. When data is received before the receive register is free, a bit in 
the control-byte is set, that prevents further interrupts from this serial 
input.

Jo Scherpenisse

----- Original Message ----- 
From: "Quintin Beukes" <quintin@last.za.net>
To: "Microcontroller discussion list - Public." <piclist@mit.edu>
Sent: Friday, October 09, 2009 12:04 PM
Subject: [PIC] Serial data methods


> Hey,
>
> I'm not sure what the correct term is here, Ausart? UART?
>
> Either way, we receive data from a Digi ConnectME on the serial
> interface. The RCIF is flagged, the interrupt service routine invoked
> and the byte read with RCREG. What we do then is put it into a
> character buffer until a newline is received, at which time we know
> the full "request" or "command" was received (we use the newline as a
> terminator, as it makes it easy to debug the program with terminal
> software like minicom or netcat.
>
> I was just curious for patterns/idioms around data processing,
> techniques people use. It's always good to learn of these things,
> because you might just do it in the "not the best way for your
> requirements".
>
> One problem I noticed with this technique is the speed at which the
> ISR executes. I pasted my complete ISR (the SerialRecordChar is merely
> a macro that maps to the correct recording method, which is currently
> only the one described above. Further, the __serialRecordChar(c)
> method is configured to inline. If this wasn't possible I would embed
> it, but since it currently is I prefer to have clearly defined "logic
> modules". What i mean by this is that the fact that the character is
> recorded in a separate function doesn't affect the performance.
>
> Now, the problem I found here is that if I make the routine a bit
> slower, I have found I can complete "crash" the serial interface. One
> easy way of doing this is to put a few putchar('X') calls into the
> different execution paths of the record method. Then send it more 4 or
> more bytes at once. After this the interrupt is never called again for
> RCIF, though the program's execution continues without a problem. Even
> the timer is still executed.
>
> To further describe exactly how this system communicates on the
> serial. We wait for commands/requests, they basically consist of one
> or more ascii characters (0x20 up to 0x7e), followed by a terminator
> (0x0d or 0x0a). If 2 or more terminators are sent (like on windows
> \r\n), then the extra ones are simply ignored). We don't do much error
> checking in here, as the system communicates with one entity and if an
> invalid command would be received then it will simply be ignored later
> on. It is quite fool proof currently and can recover from any invalid
> command by simply terminating it and sending a new one. Beyond this,
> the device will always communicate with our other devices, so we
> safely sacrifice this integrity for performance, integrity which isn't
> critical anyway.
>
> So, any advice, hints, idioms or patterns would be appreciated.
>
>
> void interrupt __kmsIntVector( void )
>
> {
>
>    if (TMR0IF)
>
>    {
>
>            ....
>    }
>
>
>
> #if defined(SERIAL_ENABLED) && SERIAL_ENABLED == 1
>    if (RCIF)
>
>    {
>
>        char c = RCREG;
>
>
>
>        SerialRecordCharacter(c);
>
>
>
>        RCIF = 0;
>
>    }
>
> #endif
> }
>
>
>
> void __serialRecordChar(char c)
>
> {
>
> if (c == CR || c == LF)
>
> {
>
> // first character
>
> if (__serial.bufIndex == 0)
>
> {
>
> return;
>
> }
>
>
>
> __serial.buf[__serial.bufIndex] = 0;
>
> __serial.dataAvailable = 1;
>
> __serial.bufIndex = 0;
>
> }
>
> else
>
> {
>
> __serial.buf[__serial.bufIndex++] = c;
>
>
>
> // buffer is full
>
> if (__serial.bufIndex == SERIAL_BUFFER_SIZE)
>
> {
>
> __serial.bufIndex = 0;
>
> }
>
> }
>
> }
>
> Quintin Beukes
> -- 
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist


--------------------------------------------------------------------------------



Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 8.5.421 / Virusdatabase: 270.14.8/2423 - datum van uitgifte: 
10/08/09 18:33:00

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist