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