Transfer protocol

[yalect]

Hi,
can I use 1byte (8bits) as start bit and stop bit and Parity to check Serial data transfer like below or I have to use 1 bit ?

Transmitter:
--------------
while (DATA!=Stop_byte)
       {
    for (count = 0; count < 8; count++)
    {
      DATA = (byte_start >> count);  // output = number shifted right * count

      if(DATA & 1)
     {
     PORTC = (1<< PINC0);
     }
     else
    {
     PORTC&= ~(1<< PINC0);
     }
     Delay_ms(1);
     }
        DATA=0;
         
    for (count = 0; count < 8; count++)
    {
      DATA = (info >> count);  // output = number shifted right * count

      if(DATA & 1)
     {
     PORTC = (1<< PINC0);
     }
     else
    {
     PORTC&= ~(1<< PINC0);
     }
     Delay_ms(1);
     }
         for (count = 0; count < 8; count++)
      {
       DATA = (Parity >> count);  // output = number shifted right * count
   
      if(DATA & 1)
     {
     PORTC = (1<< PINC0);
     }
     else
    {
     PORTC&= ~(1<< PINC0);
     }
     Delay_ms(1);
     }

      DDRC=0x00;
   for (count = 0; count < 8;  count++)/*; count++)*/
     {
     if(PINC & (1<<PINC0))
     {
    DATA|=(1<<count);
     }
     else
    {
     DATA &= ~(1<<count);
     }

      Delay_ms(1);

}

}
 }
********************************************************************************************************
*******************************************************************************************************
Reciever:
--------------
          while(DATA!=byte_start)
       {
      for (count = 0; count < 8;  count++)/*; count++)*/
     {
     if(PINC & (1<<PINC0))
     {
    DATA|=(1<<count);
     }
     else
    {
     DATA &= ~(1<<count);
     }

     Delay_ms(1);

}
     }
     while (DATA!=Parity)
        {
    for (count = 0; count < 8;  count++)/*; count++)*/
     {
     if(PINC & (1<<PINC0))
     {
      DATA|=(1<<count);
     }
     else
    {
     DATA &= ~(1<<count);
     }

     Delay_ms(1);

 }
     PORTA=DATA;
     for (count = 0; count < 8;  count++)
     {
     if(PINC & (1<<PINC0))
     {
    DATA|=(1<<count);
     }
     else
    {
     DATA &= ~(1<<count);
     }

     Delay_ms(1);

        }

         }

     DDRC = 0xff;
    for (count = 0; count < 8; count++)
    {
      DATA = (byte_end >> count);  // output = number shifted right * count

      if(DATA & 1)
     {
     PORTC = (1<< PINC0);
     }
     else
    {
     PORTC&= ~(1<< PINC0);
     }
     Delay_ms(1);
     }

                     }

Thank you

[technix]

As long as the two ends of the communication can speak to each other, the protocol is working. Multiple existing protocols uses a bytes-long starting and ending pattern already. (e.g. 32-bit for twisted pair Ethernet)

Do keep in mind that cooking up your own wire protocol means have to bit bang or resort to FPGA/CPLD to implement it. Implementing your own protocol as a layer 2 protocol on top of something standard (like UART) might be a better idea since it saves CPU cycles. You can read about the OSI model to grasp an idea on how protocol layering and tunnelling works.

[C]

When thinking about a Transfer protocol, you also need to think about additional things.

Is the receiver ready for data when it is sent?
What happens if the receiver does not have space for sent data?

Your start/stop bits identify a byte worth of data. Often you need many bytes of data in the form of an information block of data.
A good foundation identities information block and bytes of data.

Ethernet has a starting sequence that is unique for each block sent. These blocks are normally called packets.

All the following can identify the start of a packet of data.
HDLC, SDLC, CAN, SCSI, USB, Ethernet, SATA, SAS, HDMI and more.
With out hardware based packet start or the equal in software you get higher software overhead working around the problem.

[technix]

Is the receiver ready for data when it is sent?
What happens if the receiver does not have space for sent data?

If there is a way to recover from data loss, or if the data loss is tolerable, the sender can assume the receiver always have space for data and shoot on. However this does push the data recovery to the upper layer though, but those layers might also be better equipped to actually perform the data recovery since they can understand the packet structure and EDC/ECC used.

For a L1 or L2 protocol, it is often better to assume the receiver being ready, and let the L3 (or higher - e.g. TCP/IP handles packet recovery at L4) protocol handle the lost packet recovery.

Your start/stop bits identify a byte worth of data. Often you need many bytes of data in the form of an information block of data.
A good foundation identities information block and bytes of data.

Ethernet has a starting sequence that is unique for each block sent. These blocks are normally called packets.

All the following can identify the start of a packet of data.
HDLC, SDLC, CAN, SCSI, USB, Ethernet, SATA, SAS, HDMI and more.
With out hardware based packet start or the equal in software you get higher software overhead working around the problem.

Not all data have to be packetized. If the protocol in question implements a virtual loop (like UART) the protocol can be stream based, and should packetization be needed be shoved to the higher layers. (e.g. PPP which packetizes on top of a serial link.)

[yalect]

Thank you
I have no much data about two bytes per transaction maybe that will be enought or it's better one start bit and stop bit
Thanks

[C]

yalect

You did not state what you are trying to do. but a low level fail or lack often leads to a huge around of software to work around the low level problem.

Sounds simple to just use a UART to connect two things. But with out a good low level foundation, your CPU will have to spend a huge amount of time working around the problem.

For example, To keep it simple most microcontrollers have a 9-bit mode for the UART. This mode lets you use 9-bits and still have 8 bit transparent data. With the 9-th bit you can use it to mark the start of something.
Most PC's do not support this 9-bit mode for uart's.

Something like PPP over UART adds a huge overhead for a small CPU and takes more time to send/receive data.

What looks like it just needs data, often needs status & control and often many streams of data, control/status.

[technix]

yalect

You did not state what you are trying to do. but a low level fail or lack often leads to a huge around of software to work around the low level problem.

Sounds simple to just use a UART to connect two things. But with out a good low level foundation, your CPU will have to spend a huge amount of time working around the problem.

For example, To keep it simple most microcontrollers have a 9-bit mode for the UART. This mode lets you use 9-bits and still have 8 bit transparent data. With the 9-th bit you can use it to mark the start of something.
Most PC's do not support this 9-bit mode for uart's.

Something like PPP over UART adds a huge overhead for a small CPU and takes more time to send/receive data.

What looks like it just needs data, often needs status & control and often many streams of data, control/status.

PPP is a big protocol, but along with TCP it makes the examples of creating a packet switched communications channel out of a virtual loop (IP over serial,) and a virtual loop out of packets (stream over IP.)

For this particular use it might be better to use a simple packetized L2 protocol on top of 115200bps 8-N-1 UART. For example:

Code: [Select]

struct l2_packet {
uint8_t sync_byte;
uint8_t type;
uint8_t length;
uint8_t data[];
uint8_t checksum;
}
The L2 protocol can be implemented using a simple state machine. The L2 protocol handles packetization, ECC/EDC and can provide reliable delivery through the use of confirmations and handshakes.

[yalect]

Thank you
But Does this code really work, I sumilated it protuse I got Parity byte right but the data transfer no, if some one try for me maybe there is problem?

[technix]

Thank you
But Does this code really work, I sumilated it protuse I got Parity byte right but the data transfer no, if some one try for me maybe there is problem?

Do you have a working UART (L1) driver? If not you need to sort that out first. What I have is here is just a L2 protocol.

[ebastler]

Thank you
But Does this code really work, I sumilated it protuse I got Parity byte right but the data transfer no, if some one try for me maybe there is problem?

I don't think your code will work. It assumes that the transmitter and the receiver are somehow, magically, aligned to a common timing on the ms level. But I can't see any mechanism to ensure that.

Your receiver simply reads a bit every millisecond. But what prevents it from reading just on the edge, when the transmitter changes its output? Also, the processor clocks of receiver and transmitter will not be exactly the same -- so the timing of the receiver will drift vs. the transmitter.

That's what the start bit in asynchronuous serial transmission is for: The receiver sits and waits until it sees a start bit. Then it reads one byte of data -- at bit times which are defined relative to the leading edge of the start bit. That way, the relative timing (phase) of the receiver and transmitter is defined. And their clocks only need to be stable and precise enough to ensure that the receiver and transmitter stay in sync over the duration of a single byte, which is uncritical. They will re-synchronize for each new byte, via the start bit.

I recommend that you use a conventional serial format. Depending on the microcontroller you use, it might have a UART built in which supports that in hardware?

[Buriedcode]

This is the second time this guy has posted this code.  First time I asked him to use code tags and got no reply.  This time it seems has has code he is convinced works (whatever his goal actually is) and is hoping for someone to correct it I think.

I'm guessing there's quite a big language barrier here.  So rather than write lots I'll just repeat what C asked.

yalect: What exactly are you trying to do?  Perhaps use an online translator.  Please provide detail of exactly what you want to do.  Simply saying "send bytes" can mean many things.

You have posted code that to me looks like "bit banging UART" for an AVR microcontroller.  Correct?  If so, there are plenty of examples on the web, google "software UART AVR"

AVR's have a built-in USART you can use instead.  But as you are trying to do it in software, I am assuming that you cannot use it.

Also, again, if you post code, please use code tags.  Highlight the code you have pasted then click the "#" symbol above.  Or enclose it in [ code ] and [ /code ] without the spaces.