تحميل الهوت ميل الجديد مجانا 2010 hotmail

protocol_considerations

If you design a new serial protocol, here are some ideas and suggestions you may want to consider:

• Say your receiver is busy for a few microseconds and drops a character or two. You might be able to check for a FIFO buffer overrun hardware flag.
  
• When you turn on a device, how does it know when to start talking ? Who talks first ?
  
• The bit-synchronization problem:
  

  When a receiver is first turned on, how does it know where one transmitted bit ends and the next starts ? Also, what is the bit rate ? Pretty simple for clean RS-485 (and most other hard-wired communications hardware) where you can just watch the edges; more difficult when there is noise (as in nearly all wireless hardware).
  

  Often dedicated hardware synchronizes things to the nearest byte; then higher-level protocols in software deal with frame synchronization.

  
  
• The frame-synchronization problem:
  

  Say the device that is *supposed* to talk first starts talking, but the other device doesnt get turned on until the middle of a “sentence”. How does the receiver know to throw away the (incomprehensible) rest of the “sentence”, and re-synchronize at the start of a new sentence ? (Same thing applies to buffer overrun).
  

  Typically one re-synchronizes by transmitting a unique byte sequence (a “header” or “start-of-message”) that will not (or “probably will not”) be embedded in the middle of a sentence.

  Including the newline and/or carriage return ( suggested by Dmitri Katchalov Date: 27 Jan 2000 ) in this byte sequence helps make it more human-readable.

  
  
• Robert Morris http://www.pdos.lcs.mit.edu/~rtm/ claims that “the Grid routing protocol lets collections of radio-equipped nodes automatically configure their own cooperative network, without relying on any pre-installed infrastructure. He also suspects “a power-saving scheme for an ad-hoc net, that allows radio receivers to spend most of their time turned off. … [perhaps] elect one node per region to buffer messages, so that other nodes can wake up from time to time and poll. Batch traffic, use geo routing to improve batching effectiveness by favoring batching over shortest path. Overall point: we will actually save you battery power, so dont worry about battery used by forwarding for others. [FIXME: link to low-power electronics]
  
• http://members.tripod.com/~mdileo/ “The Tiny Embedded Network is an Open Protocol I designed to interconnect embedded devices in a local area network. The protocol specifications are free and open and I plan to make available the basic routines as well. Is this a power + data bus ? Lots of other PIC stuff. [FIXME: PIC]
  
• CO149s Fundamental Dicta(TM) http://muppetlabs.com/~chris/dicta.html lists lots of protocol design tips, including:
  
  
  
  • 1. The packet has to know how to get back, too.
    
  • 3. The network you are using is experimental technology and always will be.
    
  • 5. The network is constructed of physical components.
  
  
• Subject: Embedded RS-485 Protocol Needed! Newsgroups: comp.arch.embedded

• [FIXME: summarize]
  

  On Newsgroups: comp.arch.embedded , sometime before 1999-01-29, Edward K asked: >I need a small (low C code size), simple protocol to drive a proprietary
  >network based on RS-485. I dont want to get into TCP/IP for obvious reasons.
  >The clients on the RS485 bus would be based on a small 8 bit micro so speed
  >and efficiency are important.

  In response, Robert Reimiller 1999-01-29 suggested:
  

  
  

  I have a small network (about a dozen nodes right now) using PIC processors. Although it doesnt use RS-485 voltage levels, the operation is about the same. It uses a very simple message packet : Length – 1 byte
  Source ID – 1 byte
  Destination ID – 1 byte
  Message Type – 1 byte
  <variable length message>
  Additive Checksum – 1 byte
  Exclusive-OR Checksum – 1 byte

  This is a binary protocol so I used SLIP framing characters to determine the packet boundaries, very simple to implement.
  

  A practical next step would be to use UDP/IP Packets, that way you could interface the system to router that supports SLIP.
  

  Bob

  
  

  In response, Ian Wilson 1999-01-29 commented:

  Length as the first byte can cause all sort of mess in a noisy environment – consider what would happen to the when it receives noise. It would read the noise as a length and go off happily looking for the next x bytes before trying to crack the packet and seeing a back checksum. If the channel is very noisy so that you are getting continuous transitions at you receiver you can completely lock out you network. A better header for a noisy channel is a header sequence that is fixed. I does add overhead but will minimise the amount of false packets.
  

  We use a time passed poll response system quite often. The master polls a slave and the waits for a response – if the reply has not started in a few milli-seconds the master assumes no reply is going to happen. Since replies are longer than a few ms this increases throughput on networks with lots of devices (128 or 250) where the most common reply is “nothing to report”.
  

  Also consider adding a sequence number to the packet. If a slave sees the same sequence number it saw on the last poll it knows the master did not receive its last reply – saves having a seperate ACK reply from the master to the slave. the master holds a differenet seq number for each slave and only increments it on a successfully decoded reply. Keep seq number = 0 as a special case that forces the slave to reset its seq number. Let the seq number increment wrap around from 255 to 1.
  

  Ian Wilson ——————————– Considered Solutions considered@ozemail.no.spam.com.au (do the no spam thing to make a valid email address)

  
  

  Mark Odell 1999-01-29 commented:
  

  
  

  Xmodem sends the length byte followed by the ~length byte. Then a checksum at the end. It was unlikely that the length and ~length would screw up randomly to still work. Besides, a practical max. packet size can help prevent you from going too far off in the weeds.
  

  My RS-485 protocol ran on 8051s with a single master that polled all 20 slave devices for status. I think the packet was destAddr, len, ~len, payload[len], 8-bit checksum. Worked okay for me over about a mile of total network distance.
  

  - Mark

  Subject: Re: Embedded RS-485 Protocol Needed!
  Date: 31 Jan 1999 00:00:00 GMT
  From: Ian Wilson
  Newsgroups: comp.arch.embedded

  <notjimbob at worldnet.att.net> (James Meyer) wrote:

  >On Fri, 29 Jan 1999 04:15:07 GMT, leafs at ozemail.com.au (Ian Wilson)
  >wrote:

  >>back checksum. If the channel is very noisy so that you are getting
  >>continuous transitions at you receiver you can completely lock out you
  >>network.

  > One would think that if the channel were getting continuous
  >transitions because of noise, that the channel would be completely
  >useless and *no* combination of packet parameters would be any better
  >than any other.

  No – this is not the case. Many RF receivers do not squelch (turn
  off) their outputs when the is no transmission – as the carrier detect
  circuit is often more complex and less reliable and more power hungry
  than the receiver (in micopower applications). So you have continuous
  streams of noise induced transitions. When a transmission arrives it
  is much higher than the noise level and so the receiver behaves
  correctly. What you dont want is the noise induced stuff to bugger
  up your network throughput.

  This sort of thing can happen even on wired networks – where you have
  heavy machines turning on and off or thyristor circuits nearby. Maybe
  not to the same degree but you can get false transitions. If a packet
  is not designed well then the network can fail. This is where:

  1) fixed header sequences,
  2) timeouts,
  3) error detection/correction codes,
  4) Ack/nack protocols

  make the difference between a system that works in good conditions
  only vs one that is truely robust. In designing for volume making a
  system robust at the expense of a few weeks of software and protocol
  design is definitely the way to go.

  Ian Wilson
  ——————————–
  Considered Solutions
  considered@ozemail.no.spam.com.au

  (do the no spam thing to make a valid email address)

  
  

  
  

  Subject: Re: Embedded RS-485 Protocol Needed!
  Date: 01 Feb 1999 00:00:00 GMT
  From: Bill Gatliff <gatliff at haulpak.com>
  Organization: Komatsu Mining Systems
  Newsgroups: comp.arch.embedded

  …
  

  SAE has a standard called J1708. Basically, all it says is that an idle period of ten or more bit times between bytes marks the end/begin of a packet, packets are at most N bytes in length, and that each packet starts with a destination byte and ends with a checksum. For the most part, you can put whatever you want inside.

  In a noisy environment or one where collisions can occur (like RS485), you *do not* want to depend on receiving a length byte. Idle timing is the best way to go.
  

  Likewise, you dont want to deal with a negative acknowledgement (where the receiver tells the sender that the packet was corrupted). Instead, only acknowledge the correctly received ones, and let the transmitter resend a packet if it doesnt get a response.
  

  To do it right all you need is about 50 lines of C code– I think even the timer is optional if youre clever.
  

  Heavy-duty trucks arent the worst network environment in the world, but theyre pretty bad. Despite this, J1708 works very well– nearly every truck on the road today uses it.
  

  Just my $0.02.
  

  b.g.
  

  – William A. Gatliff Senior Design Engineer Komatsu Mining Systems

  
  
• “An additional timeout on the receiver end to stop it from hanging within a packet”
  
• S.N.A.P. Scaleable Node Address Protocol http://www.hth.com/snap/ “a free and open network protocol.” has free source code for AVR, PIC, Palm Pilot, and other popular processors.

Related posts:

1. serial communications roger stevens downloadSerial Communications”  is a comprehensive advanced level book which details various methods for implementing serial communications between a Microchip PIC (R) microcontroller and an external device. Asynchronous serial communications is covered both by using an on-chip USART and by bit-bang methods. The RS-232 standard is explained. A discussion of synchronous serial communications includes the I2C [...]...
2. Serial Ports and Digital I/O4.1 Serial Communication In the factory-default configuration, the TCP/IP Development Board has one RS-232 (3-wire) serial channel, one RS-485 serial channel, and one synchronous CMOS serial channel. The TCP/IP Development Board may be configured for 5-wire RS-232 or two 3-wire RS-232 channels. The exact configuration instructions depend on the version of the TCP/IP Development Board [...]...
3. Serial Communications  “Serial Communications” is a comprehensive book which details various methods for implementing serial communications between a Microchip PIC microcontroller and an external device. Asynchronous serial communications is covered both by using an on-chip USART and by bit-bang methods. The RS-232 standard is explained. A discussion of synchronous serial communications includes the I2C (Philips Semiconductors), SPI [...]...
4. Serial Communications A C++ Developers Guide 2nd EditionBill Jacques noticed that the SendSingleFile() function in Zmodem.cpp gets stuck in an infinite loop if the remote end has an allocation problem. He sends an update of the function (as a Word Doc.) Bill wrote a Win32-specific version of the function, so dont try to include this code if you are running in some other environment. You will have to replace the existing function in Zmodem.cpp....
5. serial protocol convertersserial protocol converters See also FIXME serial ADCs and DACs. RS-232 to PC keyboard (often called “wedges” — the most common versions allow you to plug a barcode reader FIXME barcode (RS-232) and a standard PC keyboard into the wedge, and then you plug the wedge into the keyboard port of a PC.) Often used [...]...
6. Controller Area Network (CAN)Controller Area Network (CAN) [What is the endianness of CAN ? ]"CAN we talk? : Distributed systems require protocols for communication between devices. CAN and SPI are two of the most common." article by Niall Murphy 2003-05-14 http://www.embedded.com/story/OEG20030509S0042 ...
7. A little bit of information about the PC serial portA little bit of information about the PC serial port Jan Axelson http://lvr.com/ has lots of information about RS-232 and RS-485 #rs485 http://sourceforge.net/projects/libserial/ “A collection of C++ classes which allow the serial port on POSIX systems to be accessed like an iostream object. …” Programming Notes For Central Data Serial Ports http://www.cd.com/prog.html has lots of [...]...
8. Wireless serial connection network wireless signal transmissionINTRODUCTION: Data collection, serial communication and wireless signal transmission are a common applications in industrial, medical and scientific area. Sensors data or even the machine control command are used serial communication protocol to transmit to other machines. The user has to carry around an RS232 cable as the communication media.   UART-Link is a low [...]...
9. Serial communication between the Ardunio and ProcessingThis week’s lab focused on exploring the Arduino’s capability to communicate using a Serial connection.  I was very excited to learn how to set up this kind of communication system as it opens up a whole new set of development possibilities.  Being able to interface physical computing components with Processing (or Flash) is just downright [...]...
10. Serial Communication Under Win32 to program on a PCSerial ports used to be easy to program on a PC. Then they got more complex, then unreachable. Now they can be made to look simple again. Introduction Anyone porting 16-bit serial communication code to 32-bit Windows NT or Windows 95 faces a common problem: the familiar methods of implementing communication are at the very [...]...
11. Mac Serial PortMac Serial Port I have pushed the Mac serial ports to 1 Mbps; email me for more info. Comments? the communications protocol for the Mac QuickCam takes advantage of many of the Mac serial ports to communicate at 918 Kbps (synchronous). /* the protocol description *was* available at http://www.connectix.com/connect/files/driver/mac.pdf */ [1.4] How fast can the [...]...
12. TCP/IP protocol  Summary: TCP and IP were developed by a Department of Defense (DOD) research project to connect a number different networks designed by different vendors into a network of networks (the “Internet”). It was initially successful because it delivered a few basic services that everyone needs (file transfer, electronic mail, remote logon) across a very [...]...
13. serial data communication protocol Monitoring – ADC200/20This experiment demonstrates how a serial data communication protocol can be successfully monitored. Serial data communications represents the fundamental method by which information is transported in our modern world. Convergence between communications and computers has caused all forms of information to be digitized for easy transport in serial format. Unlike analog waveforms such as sine [...]...
14. iSeries Meter and Controllers – Direct Connection to EthernetiSeries Meter and Controllers – Direct Connection to Ethernet(Each device has own IP Address) EMBEDDED INTERNETThe OMEGA® iSeries devices connect directly to an Ethernet network with a standard RJ-45 connector and can send and receive data in standard TCP/IP packets. (Please specify EI or C4EI option.)The iSeries devices can serve Web pages over an Ethernet [...]...
15. Using Windows NT Embeddeds serial console administration with Windows XP EmbeddedWhen Windows XP Embedded first started shipping, it was leaps and bounds better then original Windows NT Embedded. All the new PC technologies such as USB, IEEE 1394, multimedia, plug-n-play technologies, and ACPI were supported. The tools and database were improved. Many Embedded Enabling Features (EEF) were carried over and improved: the new Enhanced Write [...]...