At 18:36 24/08/99 -0400, you wrote:
>>  The trick is to only discard one byte instead of the whole
>>buffer or a whole packet's worth of bytes. Then the receiver
>
>A good way to synch yourself is to use a mechanism such as this:
>
>void sendc (char c)
>        {
>        if (c >= 0xe0)
>                {
>                putc (0x1b);
>                putc (c);
>                }
>        else
>                putc (c + 0x20);
>        }
>
>void sendmsg (char *s, int count)
>        {
>        int i;
>        char c;
>
>        putc (0x02);
>        for (i = 0; i < count; i++)
>                {
>                c = *s++;
>                sendc (c);
>                CRC = crcfunc (CRC, c);
>                }
>        s = (char*)&CRC;
>        for (i = 0, i < sizeof (CRC); i++)
>                sendc (*s++);
>        putc (0x0d);
>        }
>
>While this is not perfect (because the CRC should be handled as a
>network-level thing) is does work quite well.  The code above is also
>generic enough that it should compile pretty easily on your machine - just
>define a few variables (CRC and the message you are sending) and the
crcfunc().
>
>The receiving end simply looks until it reads a 0x02, then reads and
>buffers all chars until
>        a) it detects the 0x0d, which causes it to validate and forward the
>message, or
>        b) it detects a buffer overrun, which causes it to look for the
0x02 again.
>
>The receiver code is almost as simple, and is "left as an exercise for the
>student."
>
>Hope this helps.
>
>We use this ALL the time.
>
>Andy
>
>==================================================================
>Andy Kunz               Life is what we do to prepare for Eternity
>------------------------------------------------------------------
>andy@rc-hydros.com      http://www.rc-hydros.com     - Race Boats
>andy@montanadesign.com  http://www.montanadesign.com - Electronics
>==================================================================
>
>


Hey Andy,
Why not include the rest of it? You know the header bit so that others can
understand the 0x02 (STX) bits nad that so they can see what is going on.
Also some may think that the first part is a bit strainge where you include
the EXCAPE detection/insertion bits. But then again maybe tell them that it
is an X25 implementation.

Also, the sizeof bit may get some people, but does meand that the size of
the CRC can be altered with little trouble.

Ahhug! Type casting! s = (char*) &CRC (But I do this too!)
Ahhug! Global varibale CRC! Naughty!

I also see that this is targeted at an 8bit device, as others out there may
think that the code if

        c= *s++;

Is a waste of a variable (And they would be right!), however you could
force this as a near variable, but this does limit the code very much
indeed. So one could say that this code segment does meet the best of all
worlds.

And just for the end bit, the second for next loop is in error!

Oh Andy you have come down a setp or two :)

But it could be simpler!


#include CRC.h

void
sendmsg (char *s,
                int count)
{
 CRCVAULE CRC;          /*(Assume that this is an int and not globle as above)*/
 char c;

        putc (0x02);
         while (count--)
        {
                c = *s++;
                sendc (c);
                CRC = crcfunc (CRC, c);
        }

       s = (char*)&CRC;
       for (c = 0; c < sizeof (CRC); c++)
                sendc (*s++);

       putc (0x0d);

}/*end sendmsg*/


And on top of that the method does have the ability to loose sync if the
CRC contains 0x0d in the data stream. This can lead to a packet that will
never get though if sych is lost at the wrong time, as I see you add 0x20
to the character, assuming that only ASCII is sent then this does cause
some concern for me, but then again I am always concerened but if it is an
X25 implementation, then there is a lenght in the header that will prevent
this from occuring.

Dennis

Waiting to be flamed