Archive

Archive for the ‘Communications’ Category

Aug
19

Serial Communications

1 CommentCommunicationsAugust 19th, 2009

 

“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 (Motorola) and Microwire (National Semiconductor) protocols.


The Dallas Semiconductor 1-Wire bus is described. Many code examples are included as modules which will provide the basis for the readers own PIC microcontroller applications. By Roger Stevens (8-1/2 x 11″, 520 pages).








bullet

View Serial Communications Table of Contents

bullet

Download The Source Code For Serial Communications

Aug
19

Serial Communication Under Win32 to program on a PC

No commentsCommunicationsAugust 19th, 2009

Serial 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 least different and at the worst, no longer present. Some of the Win32 API function for setting up the communications port have not changed with respect to their Win16 counterparts. However, the functions used to open, close, read, and write to the port do not exist, nor do the messages generated by the driver when an I/O event occurs. If, like me, you move from 16-bit DOS right into 32-bit Windows, the change is even more pronounced, as you can no longer use an interrupt routine to perform serial communications and you must learn new methods of performing the required tasks of serial I/O.


Having said that, the Win32 API does offer improved support for communication devices. Win32 eliminates the need to deal with communication devices in a nonstandard way; it also eliminates the need to deal with the hardware directly. Instead, you perform serial communication with the standard Win32 file I/O functions. For those moving from 16-bit Windows, Table 1 lists the Win32 API equivalents for the 16-bit API functions.

 

































16-bit API Win-32 API
OpenComm CreateFile
CloseComm CloseHandle
FlushComm PurgeComm
GetComError ClearCommError
ReadComm ReadFile
WriteComm WriteFile
SetCommEventMask SetCommMask
GetCommEventMask GetCommMask
EnableCommEventNotification WaitComEvent*
UngetCommChar -None-
*WaitCommEvent will not post WM_COMMNOTIFY messages

Table 1: 16-bit Communication Functions and their Win32 Equivalents


While the Win32 API does make it simple to open a port and start sending and receiving data, I soon found that there is more to serial I/O than that. For example, as always, you must configure the port with the right set of options and timeout values for these operations to work as expected. This article presents a class that encapsulates the Win32 API functions used for serial communication and simplifies their use. This class also provides some member functions that make it easy to start and stop a separate thread for sending and receiving data. Some sample programs are included on the CUJ ftp site to demonstrate how the class can be used. (See p. 3 for instructions on downloading source code from CUJ.) I developed and tested the code using Borland C++ 5.01 and Visual C++ 4.2.


Class CSerialPort


Listing 1 (SerialPort.h) shows the class declaration for CSerialPort and its supporting definitions. The class consists of some protected data members that track the state of the object, a set of configuration functions, a set of I/O functions, and wrappers for the Win32 API functions relating to serial communication. The class also provides built-in support for overlapped I/O and for starting and stopping a separate thread to send and/or receive data via the port. More often than not, the basic class can be used as is unless there is a need for specialized read/write operations. In those cases, its fairly easy to derive a class from CSerialPort and override one or more of its virtual functions. This will enable you to set up customized, multithreaded, serial communications. To date, I have not needed the classs overlapped read/write features beyond the polled I/O support provided by the WaitCommEvent and CheckForCommEvent functions. Most of my applications have made good use of the StartCommThread function, though.


To create a communication object, simply pass its constructor the name of the port you want to open. By default CSerialPort initializes the port for 19,200 bps, no parity, eight data bits, one stop bit, hardware flow control, no read timeouts, one-second write timeouts, and enables monitoring of EV_RXCHAR events. Once the object is created, you can alter these settings with the configuration member functions shown in Table 2. The Win32 wrapper functions such as SetCommState, SetupComm, and SetCommTimeouts can be used if necessary, but the functions in Table 2 take care of many of the low-level details associated with initializing the required structures. Each of the functions in Table 2 also combines several steps into a single function call. Once the port is opened and configured, use the ReadCommBlock and WriteCommBlock member functions to send and receive data.

 





















Function Purpose
SetBaudRate Sets the baud rate (bps)
SetParityDataStop Change parity, data bits, stop bit settings
SetBufferSizes Change input/output buffer sizes used by Windows
SetReadTimeouts Change the read timeouts
SetWriteTimeouts Change the write timeouts
SetCommMask Specify which set of comm events to monitor

Table 2: CSerialPort Configuration Functions


Listing 2 (Terminal.cpp) shows the ubiquitous dumb terminal program, reworked to take advantage of the 32-bit environment and utilize the basic CSerialPort class. The DumbTerminal function calls the StartCommThread member function to start a separate thread to handle incoming serial data (signaled by the EV_RXCHAR communication events) while the main thread waits for keyboard input and writes it out to the port. Note that by allowing a separate thread to handle incoming serial port data you can eliminate the need to continuously poll for both forms of input in the main thread. Thus the application consumes less CPU time without the programmer expending any special effort.


TermPoll.cpp, included on the CUJ ftp site, is a less efficient implementation of Terminal.cpp that illustrates this point. In the TermPoll version, the Sleep function must be called to introduce a slight delay in the main loop. This prevents the CPU from reaching 100% continuous utilization. Using separate threads instead to send and recieve data especially makes sense in a GUI application; the main thread remains responsive to user-interface events.


A CSerialPort object can receive notification of certain communication events. To select which notifications your object will receive, use the SetCommMask member function. The events are specified by ORing together constants such as EV_RXCHAR, EV_ERR, etc. defined in WINBASE.H. When constructed, the class enables EV_RXCHAR automatically, so if thats the only notification you need, you dont need to call SetCommMask in your application.


Selecting which notifications the object is to receive is different than enabling the object to actually receive notification. After selecting the events of interest with SetCommMask, you must enable the object to receive notification by calling WaitCommEvent. (This situation is analogous to setting an interrupt mask and then later enabling interrupts by executing a special instruction.) I did not implement WaitCommEvent quite like its API equivalent in Win32. My version splits the APIcall into two separate functions. Member function WaitCommEvent should be used to enable notification; use CheckForCommEvent to see if any have occurred.


I implemented these functions this way to enable a program to either block while waiting for an event to occur (by calling CheckForCommEvent(TRUE)) or poll for events as needed (CheckForCommEvent(FALSE)). The return value is a bit mask of the events that have occurred; it is zero if none are available or an error occurred. As with the Win32 API, WaitCommEvent must be called again to re-enable event notification after CheckForCommEvent returns a value other than zero. Refer to the CommReader thread function in Listing 2 for an example of their use.

The GUITerm Example


The GUITerm example demonstrates the use of CSerialPort in an MFC application. It provides a dumb terminal much like the console mode example and it can also perform a basic XMODEM file transfer. This example also demonstrates stopping and restarting a thread function for the port object and a way to use timeouts on read operations. The application uses the document/view model. In this case, the document manages the serial port object and the view simply displays received data and passes key presses on to the document for transmission. When the Connect option is chosen, the document object opens the serial port and starts a thread to handle incoming data. This approach is similar to that of the Terminal.cpp example presented above. The difference here is that when data arrives, the receiver thread sends a WM_COMMDATA message (defined by the application as WM_USER + 500) to the view object, which causes it to insert the received data into the edit control used for display purposes. This application behaves somewhat like 16-bit Windows, in which the communications driver generates a WM_COMMNOTIFY event when data arrives.


The XMODEM protocol used for the file transfer requires specific timeout values for its read and write operations. The application temporarily alters the ports timeout settings for the duration of the transfer and resets them afterwards. Under Windows, all communications resources have an associated set of timeout parameters that affect the behavior of read and write operations. Timeouts can cause a read or write operation to finish even though the specified number of characters have not been read or written. When this occurs, it is not treated as an error. The read or write functions return value indicates success but the count of bytes actually read or written will be less than what was requested.


There are two types of timeouts: interval timeouts and total timeouts. Read operations can utilize either or both forms of timeout. Write operations only use total timeouts. An interval timeout occurs when the time between the receipt of any two characters exceeds a specified number of milliseconds. Timing starts when the first character is received and is restarted when each new character arrives. A total timeout occurs when the total amount of time consumed by a read or write operation exceeds a calculated number of milliseconds. Timing starts immediately when the I/O operation begins. The number of milliseconds is calculated as follows:

Total_Timeout = (Multiplier * Number_Of_Bytes) + Constant

The use of a multiplier value allows for longer timeouts based on the number of bytes being read or written. If you do not need both a multiplier and a constant, you can set the unwanted parameter to zero. If both parameters are zero, total timeouts are disabled for the given operation and the read or write will not return until all bytes have been read or written.


Table 3 summarizes the various values and combinations of valid read timeouts. Because read operations can utilize either or both forms, you must take extra care to ensure that they are set correctly for your application. Setting the read timeouts too low can result in a read operation stopping early and possibly giving the impression that data loss occurred. Setting timeouts too high usually is not a problem, especially when a separate thread is handling the receive operation. However, it may become a problem if the receiver thread is also responsible for other operations besides checking the port for incoming data. With a little experimentation, you can determine whether or not the classs default behavior of disabling read timeouts and setting the write timeout to one second is sufficient for your needs.

  I = Interval ms
T = Total ms (Multiplier * Bytes_Requested) + Constant

Interval Total Behavior
——————————————————
MAXDWORD 0 No read timeouts. Return immediately
with any available data.

MAXDWORD * Special case. If the interval and
multiplier values are both set to
MAXDWORD, and the constant is set to
any non-zero value less than MAXDWORD,
one of the following occurs:

If there are any characters in the
input buffer, return immediately with
those characters.

If there are no characters in the
input buffer, wait until a character
arrives and then return immediately.

If no character arrives within the
time specified by the constant value,
a timeout occurs.

0 0 Return only when the buffer is
completely filled. Timeouts are not
used.

0 T Returns when the buffer is completely
filled or when T milliseconds have
elapsed since the beginning of the
operation.

I 0 Returns when the buffer is completely
filled or when I milliseconds have
elapsed between the receipt of any two
characters. Timing does not begin
until the first character is received.

I T Returns when the buffer is completely
filled or when either type of timeout
occurs.

Table 3: Behavior of Read Timeout Value Combinations

Conclusion


This article and the example code cover the most common uses for the CSerialPort class. Instead of covering the remaining member functions in detail, I refer you to the appropriate Win32 online documentation provided with the compilers. The wrapper functions are identical in name and form except for the omitted handle parameter that the class manages internally. One final point worth mentioning is that the wrapper functions will keep track of any error code resulting from the call. The inline member function CSerialPort::GetLastError will return the proper error value even if your application has called other Win32 functions that alter what the API-level ::GetLastError returns.


To date, I have used CSerialPort to communicate with other PCs and modems as well as with hand-held data collection devices and cash registers. It is a versatile class in its own right and provides a solid foundation from which to build specialized serial communication classes. By letting CSerialPort handle the underlying details it also makes the transition from the 16-bit to the 32-bit platform a much easier task.

Jul
07

IEEE1394

No commentsCommunicationsJuly 7th, 2009

IEEE1394


IEEE1394, also called “FireWire”

“1394 right now is specified to run up to 400Mbits per second and 800Mbits in the future. It will be plug and cable backwards compatible. ”

Often used to transfer movies from digital camcorders machine_vision.html#digital_cameras … machine_vision.html#IEEE-1394_digital_camera


    “Services is a big part of IT. Hardware is increasingly underappreciated, so it comes down to other factors like price or services,” Intelligent Businsess Research Services analyst Kevin McIsaac told ZDNet Australia.

    The company is also attempting to redefine itself in other ways. Dell recently acquired hosted e-mail archiving and security company MessageOne for $155 million. But perhaps its most significant move was the $1.4 billion acquisition of EqualLogic, a player in the nascent iSCSI storage market, repositioning the PC maker as an owner of storage IP for the first time, rather than simply a reseller.

Jul
07

VoIP Solution For Free VoIP Calls

No commentsCommunicationsJuly 7th, 2009

Human beings have devised many activities which have been focussed on the basic purpose of getting the items that they need. Hence the barter system saw the light of a bright sunny day with the businesses now being the major as well as the latest form of the activities that human beings have undertaken for the purpose of earning money as it is the exchange item for the items that human beings who are operating these businesses. VoIP is becoming the latest form of technologies which are being used in providing services in the new form of carrying out businesses with the medium of internet.


A business VoIP solution is therefore, now being provided as an offer into most of the VoIP service provider websites. These offers are mainly focussed on the whole communication needs of the organisation with features being offered to serve the various needs of a business regarding communication that are likely to arise. Hence the offers that are being offered by the various VoIP solution providers have features which are concentrated on handling the system of communication on a large scale and that too at the same time.


The global scenario has seen a major shift in the processes that are being the primary part of business and communication has therefore assumed quite an important role for the working of businesses. VoIP business solution has hence, assumed one of the major features in most of the prevalent forms of business with some of them reaping in record number of profits and also many new innovative tools for businesses. One of them is a VoIP PBX System which enables the offices and branches residing in all the major corners of the world to have a common communication medium in the form of a sort of a ‘global intranet’.

Almost every organisation and individual can enhance its business sales or image by using these business solutions. VoIP has been the major technology behind these business solutions and has been quite successful in improving the performance of the businesses that are harvesting the features of this fantastic technology. The world is therefore now a frequent visitor to the field of excellence of businesses the money has started to flow in amounts which are larger than they have ever been as a result of the inclusion of this majestic technology.


There have been many features that have led to the success of VoIP solutions for business to become a success. The organisations which have been using this feature are able to boast of the satisfied feedbacks of the customers about the advanced level of the quality of calls that are being frequently made. Hence, the elements like poor sound quality and irritating echoes are no longer a part of any call made to a distant location where a business deal has to be finalised and hence, the employee is quite busy negotiating with the client and can take the feature of unnecessary hassles described above.


Therefore, the VoIP solution provider who is in the process of giving the magnificent services of VoIP to business organisations is liable to have a successful business of its own and with the performance being a habitual feature in most of the offers, large number of business establishments are harping the advantages in an effort to stay one step ahead of their rivals. A VoIP business solution is therefore, being used by almost all those businesses who have a dynamic character and are therefore, always involved in the process of either inventing or discovering new technologies and then using them to accomplish their needs regarding communication in a manner which is always viable to be better than others.


 

Jul
07

serial data communication protocol Monitoring – ADC200/20

No commentsCommunicationsJuly 7th, 2009

This 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 waves and square waves that are periodic in nature, serial data comm waveforms are generally aperiodic. Using a modern digital instrument such as the PICO ADC200/20 makes capture and viewing of serial data easy.

This experiment demonstrates:
This experiment is suitable for:

  • First introductory data communications course for college/university.
  • Electronics experimenter such as a amateur radio operator.

Equipment Required:



  • ADC200/20 scope, scope probe.
  • PC with serial port.
  • Terminal program such as Hyperterminal for Win95/98, Terminal Win3.1 or Telix Linux.

Safety

Always keep in mind that the ground of the ADC200/20 is common to the ground of the PC and thus common to AC ground.

Experimental Setup

The experimental setup is shown in Figure 1. Serial data is accessed from the serial port on a standard PC. The serial port is generally either a DB9 connector or DB25 connector. Figure 2 shows a picture of a standard PC DB9 type serial port. An appropriate serial cable consisting of female/male DB9 connectors is connected to this port.

The ADC200/20 CH A input is connected to the Transmit Data and Ground connections on the serial port via the serial cable. Note that you can use the same PC that the ADC200/20 is connected to for the serial transmission or you can use a standalone PC. Figure 1 shows separate PCs for convenience.


Showing the connection between the serial port and the ADC-200/20
Figure 1 Experimental Setup


A DB male connector used for serial communication
Figure 2 Photo of PC Serial Port DB Male Connector


Experimental Procedure

1. Terminal Software Setup

One of the simplest serial data comm protocols is sending ASCII characters via a PC terminal program. Several popular terminal programs exist, depending on the PC operating system  (Win95/98, Win3.1, Linux, DOS, etc). Let�s examine Hyperterminal that commonly comes as part of the Win95/98 operating system.


To access Hyperterminal, follow the Start Button:
Start/Programs/Accessories/Communications/HyperTerminal/Hypertrm.exe

Once you have located the Hyperterminal directory, find the Hypertrm program and double click it. The program screen is shown below in Figure 3.



The hyperterminal screen
Figure 3 Hyperterminal Screen


Now you must setup the terminal parameters. Under File, locate New Connection. Give the connection the name Picotech and click OK. The Connect To box appears. Select the Connect using parameter to Direct to Com1 (assuming that serial port used is Com1. Check with your PC manual for settings for serial port). Click OK. Next the Port Settings box appears.


Accept the parameters as listed below:


  • Bits per sec = 2400
  • Data bits = 7
  • Parity = none
  • Stop bits = 1
  • Flow control = hardware


Finally under File, go to the Properties parameter and select the Settings tab. Go to ASCII Setup
and check off the box Echo typed characters locally. Save all settings under Picotech.htm. The terminal program is now setup. The proper settings are shown below in Figure 4.


The hyperterminal and COMM port configuration
Figure 4 Hyperterminal Terminal Properties Setup


2. ADC200/20 Scope Setup

Once the terminal program is configured, we are ready to send serial data. The terminal program will send data via the serial port in RS-232 format. Figure 9 shows the pinouts of the DB9 and DB25 type RS-232 connectors commonly found on serial ports.


Connect the ADC200/20 scope probe with the center conductor connected to the Transmit Data Terminal #3 and the ground conductor to Ground Terminal #5. Note this setting is for a DB9 connector. Adjust accordingly for a DB25.


In order to capture the one time asynchronous signal, the scope must be set for one time trigger.


Set the instrument as follows:


  • TxData to Input A, +/- 20V, DC, Probe x 1, Input B off
  • Time base = 500usec/div
  • Trigger = single, Input A, rising, 1000mV, -10% delay

Note that the scope is set to trigger with a rising voltage > 1 volt on input A.

3. Sending Serial Asynchronous Data and Capturing Results

With the Terminal PC we are now ready to send and capture ASCII data. Try sending an ASCII G first. To do this, first set Cap Lock on the keyboard to on. Then simply press G. Ensure that the correct character is sent out, as it will echo on the Hyperterminal display. If you are using the same PC for both Terminal and the ADC200/20 display, you will have to size both windows so that they are visible.


Now in order to capture and display the result on the scope, hit the run button. The scope will now trigger with any voltage rising on input A >1 volt. Press the G again. You should see a display similar to Figure 5 below. Note the cursors have been set to measure the duration of the start bit.


Try another character, say the numeral 8. The display for 8 is shown in Figure 6. Note to clear the display press stop, then run again.



ADC-200/20 screen shot for the ASCII character code G
Figure 5 ASCII G As Displayed on ADC200/20



ADC-200/20 screen shot for the ASCII character code 8
Figure 6 ASCII 8 As Displayed on ADC200/20


Further Questions



  • Does the waveform shown in Figure 6 match what should be seen for ASCII 8 ?.
  • How wide would a bit be if the data speed was changed to 4800 bit/sec?.

Jul
07

Serial Ports and Digital I/O

No commentsCommunicationsJuly 7th, 2009

4.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 you have. This information is etched on the bottom side of the printed circuit board, or you can readily determine your version by examining the diagrams below to find the one that matches your board.

Version 175-0188 Rev. A & B


The RS-232 transceiver may be used as a 5-wire RS-232 channel or as two 3-wire RS-232 channels at the expense of the RS-485 channel by adding 0 W surface-mounted resistors at R61 and R62 as shown in Figure 6(a). The RS-485 chip (U10) and the associated bias and termination resistors (R58, R59, and R60) shown in Figure 7 must be removed when configuring the TCP/IP Development Board for either one 5-wire RS-232 or two 3-wire RS-232.





Figure 6(a). RS-232/RS-485 Serial Communication Options

Table 2(a) summarizes the options. Note that the parameters in the serMode software function call must also be set to match the hardware configuration being used.
















































    Table 2(a). Serial Communication Configurations (Version 175-0188 Rev. A & B)

    Item

    Factory Default

    One 3-wire RS-232
    & RS-485

    Two 3-wire RS-232

    One 5-wire RS-232
    R58-R60
    		In
    		 Out
    		 Out
    R61-R62
    		Out
    		 In
    		 In
    U10
    		In
    		 Out
    		 Out
    J7-3 & J5-3
    		RS-485+
    		 TxB
    		 TxB
    J7-4 & J5-4
    		RS-485-
    		 RxB
    		 RxB
    J7-6
    		TxC
    		 TxC
    		 RTS
    J7-7
    		RxC
    		 RxC
    		 CTS


Version 175-0188 Rev. C


The RS-232 transceiver may be used as a 5-wire RS-232 channel or as two 3-wire RS-232 channels at the expense of the RS-485 channel, which is connected through 0 W surface-mounted resistors at R82 and R83 as shown in Figure 6(b). R82 and R83, shown in Figure 6(b), must be removed when configuring the TCP/IP Development Board for either one 5-wire RS-232 or two 3-wire RS-232. U10 and the associated bias and termination resistors (R58, R59, and R60) must also be removed, but R82 and R83 are left installed, if you wish the TxB and RxB RS-232 signals to be available on header J5.




Figure 6(b). RS-232/RS-485 Serial Communication Options

Table 2(b) summarizes the options. Note that the parameters in the serMode software function call must also be set to match the hardware configuration being used.











































































    Table 2(b). Serial Communication Configurations (Version 175-0188 Rev. C)

    Item

    Factory Default

    One 3-wire RS-232
    & RS-485

    Two 3-wire RS-232

    One 5-wire RS-232

    RS-232
    on J5
    R58-R60
    		In
    		 –
    		 –
    		 Out
    R61-R62
    		Out
    		 In
    		 In
    		 In
    R82-R83
    		In
    		 Out
    		 Out
    		 In
    U10
    		In
    		 In
    		 In
    		 Out
    J7-3
    		RS-485+
    		 TxB
    		 TxB
    		 TxB
    J7-4
    		RS-485-
    		 RxB
    		 RxB
    		 RxB
    J7-6
    		TxC
    		 TxC
    		 RTS
    		 TxC or RTS
    J7-7
    		RxC
    		 RxC
    		 CTS
    		 RxC or CTS
    J5-3
    		RS-485+
    		 –
    		 –
    		 TxB
    J5-4
    		RS-485-
    		 –
    		 –
    		 RxB


Version 175-0206


The RS-232 transceiver may be used as a 5-wire RS-232 channel or as two 3-wire RS-232 channels at the expense of the RS-485 channel, which is connected through jumpers across header JP7 as shown in Figure 6(c). The jumper configurations are shown in Figure 6(c).





Figure 6(c). RS-232/RS-485 Serial Communication Options

Table 2(c) summarizes the options. Note that the parameters in the serMode software function call must also be set to match the hardware configuration being used.





































































    Table 2(c). Serial Communication Configurations (Version 175-0206)

    Item

    Factory Default

    One 3-wire RS-232
    & RS-485

    Two 3-wire RS-232

    One 5-wire RS-232

    RS-232
    on J5
    Header JP7
    		3-5
    4-6
    		 1-3
    2-4
    		 1-3
    2-4
    		 1-5
    2-6
    Header JP6
    		1-2
    5-6
    		 –
    		 –
    		 No jumpers installed
    U10
    		In
    		 In
    		 In
    		 Out
    J7-3
    		RS-485+
    		 TxB
    		 TxB
    		 –
    J7-4
    		RS-485-
    		 RxB
    		 RxB
    		 –
    J7-6
    		TxC
    		 TxC
    		 RTS
    		 TxC or RTS
    J7-7
    		RxC
    		 RxC
    		 CTS
    		 RxC or CTS
    J5-3
    		RS-485+
    		 –
    		 –
    		 TxB
    J5-4
    		RS-485-
    		 –
    		 –
    		 RxB


4.1.1 RS-232


The TCP/IP Development Boards RS-232 serial channel is connected to an RS-232 transceiver, U11. U11 provides the voltage output, slew rate, and input voltage immunity required to meet the RS-232 serial communication protocol. Basically, the chip translates the Rabbit 2000s 0 V to +Vcc signals to RS-232 signal levels. Note that the polarity is reversed in an RS-232 circuit so that +5 V is output as approximately -10 V and 0 V is output as approximately +10 V. U11 also provides the proper line loading for reliable communication.

The maximum baud rate is 115,200 bps. RS-232 can be used effectively at this baud rate for distances up to 15 m.


4.1.2 RS-485


The TCP/IP Development Board has one RS-485 serial channel, which is connected to the Rabbit 2000 Serial Port B through U10, an RS-485 transceiver. The chips slew rate limiters provide for a maximum baud rate of 250,000 bps, which allows for a network of up to 1200 m (or 4000 ft). The half-duplex communication uses the Rabbit 2000s PC0 pin to control the data enable on the communication line.


The RS-485 signals are available on pins 3 and 4 of header J7, and on J5, the RJ-12 jack.


The TCP/IP Development Board can be used in an RS-485 multidrop network. Connect the 485+ to 485+ and 485- to 485- using single twisted-pair wires (nonstranded, tinned).


Alternatively, the RS-485 multidrop network may be hooked up using cables with RJ-12 plugs. Note that the RJ-12 jack has +RAW_485 and GND, which means that only one TCP/IP Development Board needs to be connected to an external power source via an AC adapter. When doing so, ensure that the AC adapter has sufficient capacity for the network — each TCP/IP Development Board nominally draws 100 mA at 24 VDC.







CAUTION:
 If you plan to connect a power supply to more than one TCP/IP Development Board in an RS-485 network using the RJ-12 jacks, rework the RS-485 cables so they do not connect +RAW_RS485 through the RJ-12 jack to the boards in the network.






NOTE The RS-485 port is available only in the factory default configuration. The RS-485 port will not be available when you select the configuration option for both 3-wire RS-232 ports or one 5-wire RS-232 port.


The TCP/IP Development Board comes with a 220 W termination resistor and two 680 W bias resistors installed and enabled with jumpers across pins 1-2 and 5-6 on header JP6, as shown in Figure 7.




Figure 7. RS-485 Termination and Bias Resistors

The bias and termination resistors in a multidrop network should only be enabled on both end nodes of the network. Disable the termination and bias resistors on the intervening TCP/IP Development Boards in the network by removing both jumpers from header JP6. Note that older versions of the TCP/IP Development Board do not have this jumper feature, and the surface-mounted bias and termination resistors shown in Figure 7 have to be removed in networks containing more than 10 TCP/IP Development Boards.


4.1.3 Programming Port


The TCP/IP Development Board has a 10-pin programming header labeled J4. The programming port uses the Rabbit 2000s Serial Port A for communication. The Rabbit 2000 startup-mode pins (SMODE0, SMODE1) are presented to the programming port so that an externally connected device can force the TCP/IP Development Board to start up in an external bootstrap mode.






NOTE Refer to the Rabbit 2000 Microprocessor Users Manual for more information related to the bootstrap mode.


The programming port is used to start the TCP/IP Development Board in a mode where the TCP/IP Development Board will download a program from the port and then execute the program. The programming port transmits information to and from a PC while a program is being debugged.


The TCP/IP Development Board can be reset from the programming port.

The Rabbit 2000 status pin is also presented to the programming port. The status pin is an output that can be used to send a general digital signal.


4.1.4 Serial Communication Software


Library files included with Dynamic C provide a full range of serial communications support. The RS232.LIB library provides a set of circular-buffer-based serial functions. The PACKET.LIB library provides packet-based serial functions where packets can be delimited by the 9th bit, by transmission gaps, or with user-defined special characters. Both libraries provide blocking functions, which do not return until they are finished transmitting or receiving, and nonblocking functions, which must be called repeatedly until they are finished. For more information, see the Dynamic C Users Manual and Technical Note 213, Rabbit 2000 Serial Port Software.

The following function calls are specific to the TCP/IP Development Board.







int serMode (int mode);




User interface to set up up serial communication lines for the TCP/IP Development Board. Call this function after serXOpen().
Parameters

mode is the defined serial port configuration of the devices installed.

























    Mode

    Serial Port

    B

    C

    0
    		 RS-485
    		 RS-232, 3-wire

    1
    		 RS-232, 3-wire
    		 RS-232, 3-wire

    2
    		 RS-232, 5-wire
    		 CTS/RTS

Return Value


0 if correct mode, 1 if not.
See Also

    serB485Tx, serB485Rx






void serB485Tx();




Sets pin 3 (DE) high to disable Rx and enable Tx.
See Also

    serMode, serB485Rx






void serB485Rx();




Resets pin 3 (DE) low to enable Rx and disable Tx.
See Also

    serMode, serB485Tx

4.1.4.1 Sample Serial Communication Programs

RS-232




  1. Connect RX to TX as shown in Figure 8 below.





Figure 8. TCP/IP Development Board Setup
for RS-232 Serial Communication Demonstration



  1. Connect the programming cable to header J4 on the TCP/IP Development Board. Apply power to the TCP/IP Development Board.



  2. Open the sample program SAMPLESICOMICOM232.C and press F9.


This program demonstrates a simple RS-232 loopback displayed in the Dynamic C STDIO window.

RS-485




  1. Connect 485+ to 485+, 485- to 485-, and GND to GND as shown in Figure 9 below. If you do not have a separate wall transformer for the other board, also connect PWR to PWR as shown in Figure 9.




Figure 9. TCP/IP Development Board Setup
for RS-485 Serial Communication Demonstration



  1. Connect the programming cable to header J4 on one TCP/IP Development Board. This will be the slave, the other board will be the master. Apply power to the TCP/IP Development Boards.



  2. Open the sample program SAMPLESICOMICOM485.C. You will find some code for the master, and some code for the slave. Copy and save the master and slave versions separately.



  3. Open the sample slave program and press F9.



  4. Connect the programming cable to header J4 on the master TCP/IP Development Board.



  5. Open the master program and press F9.


This program demonstrates a simple RS-485 transmission of lower-case letters to a slave. The slave will send back converted upper case letters back to the master, which then displays them in the Dynamic C STDIO window.

4.2 Digital I/O


4.2.1 Digital Inputs


Pins 8-11 on header J7 have the four digital inputs IN0-IN3. Each of the four digital 0 V to 5 V inputs is protected over a range of -36 V to +36 V. The TCP/IP Development Board is factory-configured for the digital inputs to be pulled up to +5 V, but the digital inputs can also be pulled down by moving the surface-mounted jumper at JP4. The jumper settings and the location of JP4 are shown in Figure 10.





Figure 10. Surface-Mounted Jumper Configurations for Selecting
Pullup/Pulldown on the Digital Inputs

4.2.2 Digital Outputs


Pins 12-15 on header J7 have the four digital outputs OUT0-OUT3. Each of the four open-collector digital outputs can sink up to 200 mA at 40 V DC.


4.2.3 Digital I/O Software







void digOut (int channel, int value);




Sets the state of a digital output.
Parameters


channel is the output channel number (0, 1, 2, or 3).


value is the output value (0 or 1).
Return Value


None.
See Also

    digIn






int digIn (int channel);




Reads the state of a digital input.
Parameters


channel is the input channel number (0, 1, 2, or 3).
Return Value


The state of the input (0 or 1).
See Also

    digOut

4.2.4 Sample Digital I/O Programs




  1. Connect the programming cable to header J4 on the TCP/IP Development Board. Apply power to the TCP/IP Development Board.



  2. Open the sample program SAMPLESICOMICOMIO.C and press F9.


This program demonstrates how to turn the I/O on and off.

Jul
07

Free Serial Communication Software RS232-RS422-RS485

No commentsCommunicationsJuly 7th, 2009

Our new comDebug program lets you communicate with almost any RS232, RS422, RS485 or Modbus serial device. Whats more, its free! Its extensive trouble-shooting capabilities make it ideal for solving comms problems, or for quickly checking that you can communicate with your instrument before starting to automatically acquire data.


Features



  • No programming required
  • Free technical support for life
  • Easy to use
  • Understands ASCII or binary data
  • For serial instruments that continually send data and those that need prompting
  • Quickly identify and correct communication errors

  • Insert cyclic redundancy checks (CRCs)
  • Send ASCII values, 16-bit 2s complement integers, unsigned integers, single bits of data, etc, to instruments
  • Control the state of the PCs serial port output lines
  • See the state of the serial port input lines
  • Send acknowledgements
  • Save settings in a file
  • Full hypertext Help
  • Up to 38400 baud
  • For Windows 95 and later
  • Optionally, with the new Windmill COMIML or free LabIML serial driver, continually send data from the instrument to the Windmill logging, charting and other data acquisition applications, or to third-party Windows software like Excel

No Programming Required


Simply select your communication settings or type your instruments commands: no need for any programming.


Serial Driver Software

What sort of Devices can you Read with comDebug?


With comDebug you can control both those serial devices that continuously output messages, and those that require commands before supplying data. With a flexible approach to building command strings, and parsing the received data strings to extract data values, the majority of analytical instruments are supported. These include GPS, sonar, DMR, gas analysers, pH transmitters, data loggers, titrators, particle analysers, pressure transmitters, water baths, hygrometers, I2C devices, plcs and laboratory scales.


You have the freedom to mix and match equipment from many different manufacturers in many combinations. For example, serial devices from A&D, Anton Paar, Ashtec, Bruël & Kjær, Datel, Datataker, Ecom, Edge Tech, Electro Industries, Fisher, Furuno, Garmin, Honeywell, Horiba, Mettler Toledo, Motorola, Molyteck, Newmar, NovAtel, Nu-Metrics, Omnistar, Omron, Orion, Parallax, Paroscientific, Patton, Phytron, Quantum Logic, Quest Scientific, Sartorius, Siemens, Telegan, Telemecanique, Texas Instruments, Transcell and TTi have all been handled by Windmill. Many channels of data can be accepted from each instrument.

“I would recommend ComDebug to any one who has to trouble shoot a serial card problem. I used it to locate a defective com card which the manufacturer said could not be. ”
Doyal J. McVicker Jr.


“Your software works great; its the only package that allows me to set the DTR line low…required by the TI (Texas Instruments) development board configuration.”
R E Rogers



“comDebug solved a problem I had debugging Phytron motor controllers”
J Stirling



“comDebug helped me solve an HP-IL (old Hewlett-Packard interface) to RS-232 interfacing problem.”
M O Tjebben



“Used it to simulate the data output of a Resistance Weld Control into our Web enabled PLC (programmable logic controller).”
J Franks


Free Technical Support for Life


award-most-popular


Our software is so easy to use we offer free technical support for life. If you have a question the first places to look are in the programs Help file or our FAQ. If you dont find the answer there then fill in our technical support form, fax us on +44 (0)161 833 2190 or call us on +44 (0)161 833 2782 (9 to 5 GMT or BST).


“comDebug is so easy to use I have not needed to read anything.”
RT, Reservoir Engineering Specialist Oil and Gas Production – Research. Using ParoScientific Quartz pressure transmitter.


“Great Software!”
GH, Audio Systems Engineer using Audion Precision System Two Cascade.



“No problems, it did exactly what I wanted it to do.”
SM, Electrical Engineer performing tests on a Modbus Variable speed drive.



“Outstanding little tool! Best freebie Ive ever seen! No problems, it worked perfectly.”
JF, Industrial Control Engineer.



“No problems, comDebug is a great resource.”
DA, Mineral Chemistry (Quantitative).



“Great little tool. Worked as advertised, no problems.”
JF, Industrial controls.


Download COMIML and comDebug Leaflet

You can download the COMIML and comDebug leaflet in pdf format.



  • For best quality but large file download comiml.pdf
  • For lower quality pictures but small file download comiml2.pdf.

source// http://www.windmill.co.uk/serial.html

Jul
07

Communication standards

No commentsCommunicationsJuly 7th, 2009

standard protocols

  • http://webopedia.internet.com/Standards/Communications_Standards/ (pointers to the Hayes AT command set for modems, the RS-232c standard, the RS-485 standard, the CCITT Group 4 fax standard, and several file transfer protocols). [FIXME: last time I checked, left out any mention of S11 -- perhaps give them the pointers below ?]
  • http://www.rad.wfubmc.edu/~chim/modemstuff/chapter06.html#6.4 has lots of details on the “S” registers, including the S11 DTMF Dialing Speed register. For example, S11= sets the DTMF pulse time to milliseconds and the time between pulses to milliseconds.
  • http://www.gem.co.za/FAQ/FRAMES/Hayescommands.html also documents S11.
  • http://www.citilink.com/~kae/faq/connecting/general/hayes.html claims that the minimum value for S11 is 50 ms, which seems incorrect — my modem works fine with S11=[FIXME]
  • Protocols/Standards/Guides http://www.repairfaq.org/filipg/LINK/F_LINK_IN.html#LINKIN_004
  • Controller Area Network (CAN) #can
  • Standard for Sensor Transducer Interface http://standards.ieee.org/announcements/electindustrange.html

    • IEEE P1451.0 (TM), “Standard for a Smart Transducer Interface for Sensors and Actuators; Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats,” will be a new standard containing a common set of functions, communications protocols and TEDS formats for various physical communications media. It will aid interoperability among IEEE 1451 (TM) standards and simplify the creation of standards for different physical layers. 

    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.

    • Jul
    07

    Mac Serial Port

    No commentsCommunicationsJuly 7th, 2009

    Mac 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 Macintosh serial ports really go? ——————————————————–

    Orignally the MacOS supported up to an asynchronous data rate of 57600 bps though the serial hardware could support much higher transfer rates externally clocked (as much as 16 times synchronously). The AV and Powermac introduced a different SCC clock and DMA based serial driver which allowed 115,200 and 230,400 bps. …

    While the ability to achive these speeds was useful in the days of communications software (see [3.1]) its importance dwindled with the introduction of Intenet communications and PPP (see [5.3]). The reason is that many non-text files on the Internet are already compressed which renders the built in MNP5 and V.42bis compression methods virturally useless. In addition due to limiations in equipment and phone line quality even a 56K modem rarely gets a sustained throughput over 50K.

    For these reasons the modem scripts that come with Open Transport have 57600 bps as the maximum serial speed for a modem.


    – comp.sys.mac.comm FAQ http://members.aol.com/BruceG6069/csm-comm-FAQ.txt

    David Carys experiences


    David Carys experiences with a pulse generator hooked to HSKi …. Mac data out (TxD+ and TxD-) changes only on rising edge of clock. (works fine when *input* data changes only on rising edge of clock).

    clock specs: 4Vpp seems adequate, but it *must* go below ground. I used a green (all green LEDs are around 2.0 V, its a physical property of quantum electronics) LED in my level-shift circuit to give me +1 V and -4 V on my clock. It was very distorted (more triangular than square), but it worked OK transmitting stuff back and forth between 2 macs. (using custom software).

    _Inside Macintosh IV_ has a nice circuit diagram on p. 249.

    The Macintosh Toolbox provides support for serial speeds up to a maximum of 57 600 bps. All my standard modem software is set to 57 600 bps; the 2 modems I use can handle talking to the Mac at that speed.

    Technically speaking, however, the Mac serial port hardware can go much faster. You just need special hardware and special software.

    Ive witnessed a (prototype) gizmo that plugs into the Mac modem port and talks at 1 000 000 bps (roughly 1 Mega-bit / second) with a (1 MHz) pulse generator hooked to HSKi. (Of course, the 2 Macs involved were doing *nothing* but run my communication code).

    (The hardware guys cranked it to 2 Mbps — most characters still made it through, but many were lost.). It went that fast plugged into a PowerBook 520 or when plugged into a Quadra 605.

    I got the information I needed to write software for a Mac to interface to this gizmo from the book _Inside Macintosh:Devices_ , a few paragraphs that talk about a “synchronous modem” connection.

    _Inside Macintosh_ from Apple says that Mac serial port hardware can be made to go at 500Kbps (900 Kbps or more on most recent models) by supplying a appropriate clock on HSKi. the book seems to indicate GPiA is used for devices with *different* transmit and receive rates. Wierd.

    the GPi line … it appears that the Mac SE has one connected, while the Mac Classic and the Mac Plus has no connection to that line (?).

    I used the “officially sanctioned” call from the new Inside Macintosh books, const Byte external_clock = 0×40;
    gOSErr = Control(gOutputRefNum, 16, &(external_clock)); /* set bit 6 to enable external clocking */

    This works fine on my PowerBook520c, a Quadra, and a PowerPC (the only machines I tested my homebrew program, cable, and oscillator on). Mac data out (TxD+ and TxD-) changes only on rising edge of clock. Communication works fine when *input* data changes only on rising edge of clock. (This was the easiest to do — I simply connect the same clock to both Macs). (I never got around to testing whether it would still work if input data changes on falling edge of clock — I figure, if it works, dont fix it).

    RS-232 is quiescent *low* (normally low, at -5V on Mac serial port) I have succeded in writing a program that uses a toolbox call “set up Serial A to use HSKi as the receive and transmit clock”. The normal serial toolbox calls only let me go up to 57Kbps. They say “its easy — just poke the appropriate values in the Z8530 SCC. If you dont know its address, just dissassemble the Mac ROMs and figure out how Apple did it”. But of course they want the thing to work plugged into the serial port of *any* Macintosh, including the 1996 models. _Inside Macintosh_ from Apple says that Mac serial port hardware can be made to go at 500Kbps (900 Kbps or more on most recent models) by supplying a appropriate clock (on HSKi, I think). I *think* its easier to use the same clock as both transmit and receive, but the book seems to indicate GPiA is used for devices with *different* transmit and receive rates. Wierd. Surely someone, somewhere has done this before; Id appreciate any programming tips, pointers to magazine articles, books, etc. Ill post a summary of emailed responses, as well as a report on how well they work on my Quadra and on my friends Mac PowerPC. -dc




    Date: Tue, 5 Dec 89 16:36:44 EST
    From: zben at umd5.umd.edu (Ben Cranston)
    Subject: Serial port document (long)

    MIT EE claims it is benign but confusing. Caveat Solderor…

    This document contains notes on the Macintosh serial port and its use, with
    concentration on hardware interface issues.

    *** DANGER WARNING WILL ROBINSON!!! ***
    The DB-25 on the back of a Macintosh is NOT a serial port! It is a SCSI
    parallel port. Any attempt to use this connector as a serial port will NOT
    function correctly and may cause damage to the Macintosh and/or the equipment
    being connected.

    The two serial ports of a Macintosh are mini-Din-8 connectors which are
    labeled with a telephone (the “modem port”) and a printer (“printer port”).
    This is the pinout of the serial connectors. We are looking at the back
    of the Macintosh (or alternatively at the BACK of a male plug):

    Macintosh Plus Serial Connectors (Mini-DIN-8)

    /——###—— 1 HSKo Output Handshake
    / ### (Zilog 8530 DTR pin)
    / 2 HSKi / Clock Input Handshake or extern clk
    / [|] [|] [|] (Depending on 8530 mode)
    / 8 7 6 3 TxD- Transmit data (minus)
    | |
    | | 4 Ground Signal ground
    | === === === |
    | 5 4 3 | 5 RxD- Receive data (minus)
    | |
    | | 6 TxD+ Transmit data (plus)
    —-+ === === +—-/
    ###| 2 1 |###/ 7 N/C (no connection)
    ##| |##/
    | |/ 8 RxD+ Receive data (plus)
    ——###——/
    ###

    Note this is a RS-422 interface so the signals come in a balanced pair,
    a positive (plus) and a negative (minus), for each data signal. As we shall
    see below, there is an easy method for matching this to RS-232.

    We buy the mini-Din-8 connectors at our local electronics surplus store.
    They cost just under four dollars each, but are not quite as nice as the
    Apple molded plugs (for example, they dont have the nice orienting-D shape).
    We are now carefully removing the pins from the connector, soldering the wires
    to the pin, then replacing the pin in the connector body. We fan out the
    end of the (stranded) wire into a little umbrella around the head of the pin,
    then we solder all around. A “third hand” reduces this task from impossible
    to merely tedious.

    On the original 128K and the 512K upgrade machines (which have a DB-9 connector
    instead of the mini-Din-8) the Output Handshake line was held in a “marking”
    condition by hardware (a small resistor to the appropriate power supply rail).
    On later Macintoshes there are logic and a line driver for this line. This
    change introduces the following incompatabilities:

    1. SOME of the older terminal programs dont have the code to explicitly
    drive HSKo high.

    2. SOME terminal programs drop HSKo when they close down.

    3. SOME modems require DTR and will drop carrier if DTR goes away.

    If the cable design given below, mapping HSKo to DTR, is used, there are two
    recognized pathological conditions which can happen:

    A. Cannot use modem at all, because of 1 and 3 together.

    B. Modem drops out when switching between terminal programs, 2 and 3 together.

    Of course, some people consider B a feature, in that it will hang up the
    phone when you switch off the computer. Personally, I hang up the phone when
    I am done and I like to switch from terminal program to terminal program.
    If one of the above conditions happen, there are only three alternatives.

    I. If at ALL possible, set your modem up to IGNORE DTR and stay connected.
    Look for a DIP switch for this. I personally made this choice.

    II. Use only terminal programs which “properly” drive HSKo.
    You get to operationally define “properly” :-)

    III. Drive DTR from DSR at the modem end of the cable, as described below.

    Macintosh to modem (or other DCE device):

    DIN-8 MALE DB-25 MALE

    GROUND 4 O–+——————–O 7 GROUND
    RECV DATA + 8 O–+

    RECV DATA – 5 O———————–O 3 RD (Receive Data)

    XMIT DATA – 3 O———————–O 2 TD (Transmit Data)

    HANDSHAKE OUT 1 O–+
    HANDSHAKE IN 2 O–+——————–O 20 DTR (Data Terminal Ready)

    Note that in RS-232 the data signals are inverted (marking is minus) while
    the control signals are not (marking is plus). Thus the transmit data
    minus signal from the Mac is just right for driving the modem. Leave the
    transmit data plus signal disconnected. If you ground this you will short
    out a driver, and it will probably get hot. Similarly the receive data
    signal from the modem/DCE is inverted, so it can drive the Macs receive
    data minus line, but in this case the receive data plus line is grounded to
    prevent any extraneous signals from being induced into the circuit.

    Note also that we are driving both HSKi and DTR from HSKo so the problems
    described above can happen. An alternative arrangement would drive these
    signals from the modem/DCEs source of DSR, like this:

    +–O 6 DSR (Data Set Ready)
    HANDSHAKE IN 2 O——————–+–O 20 DTR (Data Terminal Ready)

    Some dumb modems might require Request To Send (RTS) which one would wire
    like this:

    +–O 6 DSR (Data Set Ready)
    HANDSHAKE IN 2 O——————–+–O 20 DTR (Data Terminal Ready)
    +–O 4 RTS (Request To Send)

    Finally, if you have only 3-wire cable and dont need DTR handshake, you
    can wire each side to be happy like this:

    HANDSHAKE OUT 1 O–+ +–O 6 DSR (Data Set Ready)
    HANDSHAKE IN 2 O–+ +–O 20 DTR (Data Terminal Ready)
    +–O 4 RTS (Request To Send)

    Macintosh to terminal (or other DTE device):

    DIN-8 MALE DB-25 FEMALE

    GROUND 4 O–+——————–O 7 GROUND
    RECV DATA + 8 O–+

    RECV DATA – 5 O———————–O 2 TD (Transmit Data)

    XMIT DATA – 3 O———————–O 3 RD (Receive Data)

    HANDSHAKE IN 2 O———————–O 20 DTR (Data Terminal Ready)

    The same analysis applies with respect to the data signals, except that
    in this case the transmit and receive are switched around, since one guys
    transmit should be the other guys receive and vice versa. Note receive
    data plus is grounded while transmit data plus is left disconnected.

    For this particular cable we have wired the terminal/DTEs DTR back into
    the Macintoshes HSKi to implement a hardware handshake. Assume the
    terminal side is a printer that is being overrun. One of the things these
    printers can do is drop DTR. By wiring it through to the handshake input
    we make it possible for the Macintosh software to temporarily pause in
    sending, until the printers buffers empty out and the printer reasserts
    the DTR signal.

    Some terminal devices may need to see DSR (Data Set Ready) or CD
    (Carrier Detect) or CTS (Clear to Send), in which case they may be driven
    >From an appropriate source.

    +–O 20 DTR (Data Terminal Ready)
    This is probably appropriate +–O 6 DSR (Data Set Ready)
    for a communications terminal +–O 8 CD (Carrier Detect)
    in which DTR is a totally static
    signal and does not move. +–O 4 RTS (Request To Send)
    +–O 5 CTS (Clear To Send)

    or

    +–O 4 RTS (Request To Send)
    This is probably appropriate +–O 6 DSR (Data Set Ready)
    for a printer that flaps DTR +–O 5 CTS (Clear To Send)
    as the buffer fills and empties. +–O 8 CD (Carrier Detect)

    The logic is to drive from whichever of DTR or RTS is NOT flapping around
    as buffers fill and empty or as the terminal transmits and receives…

    To connect directly to an IBM PC we believe CD must be asserted. That is,
    an IBM PC will not accept data unless it also sees the CD signal.

    128K/512K MACINTOSH

    Somebody on comp.sys.mac.hardware asked for cables for a 128K/512K Mac!
    I didnt know there were any more of those out there!!! :-) Here are
    the corresponding connections, please use these in conjunction with the
    analysis and suggestions provided above:

    128K/512K Macintosh to modem (or other DCE device):

    DB-9 MALE DB-25 MALE

    GROUND 3 O–+——————–O 7 GROUND
    RECV DATA + 8 O–+

    RECV DATA – 9 O———————–O 3 RD (Receive Data)

    XMIT DATA – 5 O———————–O 2 TD (Transmit Data)

    + 12 Volts 6 O–+
    HANDSHAKE 7 O–+——————–O 20 DTR (Data Terminal Ready)

    128K/512K Macintosh to terminal (or other DTE device):

    DB-9 MALE DB-25 FEMALE

    GROUND 3 O–+——————–O 7 GROUND
    RECV DATA + 8 O–+

    RECV DATA – 9 O———————–O 2 TD (Transmit Data)

    XMIT DATA – 5 O———————–O 3 RD (Receive Data)

    HANDSHAKE 7 O———————–O 20 DTR (Data Terminal Ready)

    FINAL CLOSURE

    On the DB-25 pin 1 is the FRAME ground and pin 7 is the SIGNAL ground.
    Equipment that requires connection to pin 1 is badly designed (IMHO).
    As a very last resort you might try a 1 to 7 jumper.

    As you can imagine from seeing all these alternatives, an RS232 breakout
    box is real handy, since you can try all these patches without having to
    warm up a soldering iron. The only other thing I can say is:

    IF IT DONT WORK, DONT LEAVE IT TURNED ON LONG ENOUGH TO GET HOT!

    Communications driver chips are built very ruggedly and will stand an
    amazing amount of mistreatment for a short period of time. But if you
    let two drivers fight for an hour one or both of them will burn out…

    Ive read this over a dozen times to make sure there arent any totally
    glaring errors, but I cannot be responsible for anybodys smoked hardware.
    Lets be careful out there!

    Ben Cranston <zben at Trantor.UMD.EDU>
    Network Infrastructures Group
    Computer Science Center
    University of Maryland at College Park
    of Ulm

    Macintosh Serial Connector (Mini-DIN-8)
    (looking into *cable*)

    /——###—— 1 HSKo Output Handshake
    / ### (Zilog 8530 DTR pin)
    / 2 HSKi / Clock Input Handshake or extern clk
    / [|] [|] [|] (Depending on 8530 mode)
    / 6 7 8 3 TxD- Transmit data (minus)
    | |
    | | 4 Ground Signal ground
    | === === === |
    | 3 4 5 | 5 RxD- Receive data (minus)
    | |
    | | 6 TxD+ Transmit data (plus)
    —-+ === === +—-/
    ###| 1 2 |###/ 7 N/C (no connection)
    ##| |##/
    | |/ 8 RxD+ Receive data (plus)
    ——###——/
    ###

    Pin
    # Name typical color typical color
    (white cable)(grey cable)
    1 HSKo red brown
    2 HSKi brown red
    3 TxD- green orange
    4 gnd yellow yellow
    5 RxD- orange green
    6 TxD+ black (nc)
    7 GPi purple (nc)
    8 RxD+ blue black

    (pin names from _Apple Mac Family Hardware Reference_ 1988)

    Laplink accelerator:
    using HSKo (typically +4.2 V) and gnd for power, put
    -1.5 V to 2.0 V, 0.75 MHz clock on (both) HSKi.
    Connected a Quadra 605 to a Mac Powerbook 160; 900KHz clock worked OK but 926 KHz failed.
    (1 HSK0)—diode>|–R–+–>+Vcc->oscillator>-||–+—>(2 HSKi)
    | |
    (4 gnd)-gnd—-diode>|-+ gnd——-LED>|-+

    oscillator>-||–+—>(2 HSKi)
    |
    gnd——-LED>|-+


    (another pinout document: ftp://ftp.armory.com/pub/user/rstevew/PINS/mac-232.pin )


    Date: Wed, 28 Jun 1995 00:15:36 -0500
    From: bill at scconsult.com (Bill Stewart-Cole)
    Subject: Info-Mac Digest V13 #69

    In Info-Mac Digest V13 #69, iedh1 at agt.gmeds.com (Dan Hofferth) writes >Responding to:
    >
    >>Date: Thu, 22 Jun 1995 17:13:47 +0200
    >>From: thomas at mb.ks.se (Thomas H Eberhard)
    >>
    >>Fast modems with budget mac?
    >>
    >>LC II (this also apply to the LC and all the Classics including the II and
    >>colors) According to “Guru” the modemport only support hardware handshake
    >>on output. Does that mean that I cant get fast input speed even with
    >>28800 modems??
    >
    >The Mac Plus, LC, and Classic do _not_ support hardware handshaking. The
    >Classic II and LC II _do_ support it, both send and receive. So your “guru”

    >is incorrect.

    Not quite correct. *EVERY* Mac supports what is called “Hardware Handshaking” in the Mac world. Technically some RS-232 purists will say this is strictly hardware flow control, and NO Mac can implement all the hardware handshaking of RS-232 (which includes hardware ring indication, hardware speed control, and other things) EVERY Mac serial port has a pair of handshake lines, one in and one out. (abbreviated HSKi and HSKo in pinout shorthand) SOME Macs (all but the classic sized models, the //si, and the LC & LC II) also have an additional input on pin 7 (which is disconnected in those other Macs) termed “general purpose by Apple and designated GPi. This is used by some programs like FirstClass (given the rare correct cable) to do hardware carrier detection.

    Hardware flow control is done with the pair of handshake lines in all Mac serial ports. HSKo is run to the modems RTS (Request to send) pin, and HSKi is run to the CTS (Clear to send) pin. A good modem cable runs HSKo also to the DTR pin, since that is useful for using DTR in uni-directional flow control and for older (non-compressing and slower) modems. A few cables will also wire GPi to CD, useful in a few programs, but sadly that is still rare in OEM cables. The effect of using an old-style modem cable on a fast or compression-capable modem is in fact that you can only implement flow control on the data stream from the computer, whereas the computer has no way (due to the cable, not the computer) to ever tell the modem to stop. This is a serious problem with slower Macs, which can easily fall behind the data rate of a fast modem.

    The reason that many people think the Plus, LC, and other Macs cannot do flow control is that Apples move to the better serial port (with GPi) was somewhat around the same time as the move from vanilla 2400 bps modems to v.42/v.42bis 2400 modems and 9600bps modems. Pure coincidence, but it meant that Apple was making port changes right as people were buying modems that did not work with their old cables. (Some modems even shipped with old-style cables, and in 1990 it was hard to find a hardware handshaking” cable except via mail-order) With Apple using a slightly enhanced serial port on high-end models of the day and high-end modems not working right without a special cable, it is easy to mistakenly connect the two.

    Of course I could have just said that I ran a Plus and used “hardware handshaking” for 4 years with 3 different modems that demanded it, but thats not so convincing perhaps. The proof is in the pinouts.

    – Bill Stewart-Cole What is Stewart-Cole Consulting? Hell if I know. Ill find out when I finish the web page. Newsgroups: comp.sys.mac.portables From: nirvana at cruzio.com Subject: Re: 150 vs 160 Organization: Cruzio Community Networking System, Santa Cruz, CA Date: Fri, 25 Nov 1994 09:28:11 GMT Sender: nirvana at cruzio.com (Leo Baschy) Lines: 36 rudolf mittelmann <rm at cast.uni-linz.ac.at> wrote: > I tried to use MacRecorder (a serial-device external microphone) on > a PB150 – but it did not work (with the newest MacRecorder driver > installed!). > I also could not get the CP Sound to work with it. > Why? > Did Apple cripple the ROMs to disallow sound input? Or what else > is missing? The problem is that “the” serial port device, the MacRecorder by Macromedia, has code that violates Inside Mac, therefore crashes. “The other” serial port device (a version of Voice Navigator from Articulate Systems) is no longer supported because the company now focuses on high-end automated dictation systems, Ive been told. A possible solution would be to fix the code of MacRecorder, but Ive tried to convince the manufacturers (its been transferred from one company to another) for more than four years without result. The new Connectix serial port camera is neat, but the sound is limited to 5kHz, which is not so good. If anybody knows a serial port sound input solution that works for the PB150 Id be more than glad to know about it and to write about it. We could even help out if anybody wants to fix the MacRecorder code, we have the know-how to rewrite that code from scratch. After all the manufacturer makes money on selling the hardware anyway, so they shouldnt mind if we write software that makes it work. Its just so much work, and little demand. – Leo Baschy nirvana at cruzio.com Nirvana Research (408) 459-9663 —


    From cary at agora.rdrop.com Wed Feb 1 19:31:33 1995
    Date: Wed, 16 Nov 1994 11:30:54 -0700 (MST)
    From: Mark Lankton <LANKTON%PISCES at VAXF.Colorado.EDU>
    Subject: synchronous serial port
    To: d.cary at ieee.org
    X-Vms-To: VAXF::IN%”d.cary at ieee.org”
    Mime-Version: 1.0
    Content-Transfer-Encoding: 7BIT
    Status: O
    X-Status:

    David,

    There is a fairly recent Control call you can make to the serial driver
    that lets you use HSKi as a clock, at least for receiving. I have never
    tried transmitting that way; all I have to do is listen to an instrument.

    The call goes like this:
    Control(driverNum,16,0×40); /* Set bit 6 to enable external clocking */

    By the way, setting bit 7 with this call means DTR will be unchanged when
    you close the driver (if you ever happen to care).

    I am right in the middle of building some new hardware to use this method;
    for years I have used a home-grown get-in-and-fiddle-with-the-Z8530 input
    driver. It always worked fine *except* for exploding on PowerBooks, and
    if I didnt have to work on PowerBooks and wasnt worried about maintaining
    it in the face of the changing device driver API, I would just keep on
    that way.

    One important note: the external clock signal apparently wants to be 1x
    the bit rate, not 16x as you might guess. And I am still trying to decide
    how important the clock polarity is.

    Information comes from NIM:Devices.

    Good luck, and please let me know how it goes for you.

    Mark Lankton
    Laboratory for Atmospheric and Space Physics
    University of Colorado

    From cary at agora.rdrop.com Wed Feb 1 19:32:31 1995
    Date: 22 Nov 94 05:57 EST
    From: intolabb at oasys.dt.navy.mil (Steven Intolubbe)
    Subject: high speed serial stuff
    To: d.cary at ieee.org

    .Hi David,

    Do you need to use a synchronous protocol, or do you just need to
    externally clock the serial port? The other problem is duty cycle
    of the data. Is it a constant stream, bursts, or do you request
    what you want when you want it? There is a toolbox call for setting
    the external clock mode (on HSKi) but it is in the new inside Mac
    books, which I dont have. I accessed the chip directly to set the
    external clock mode, and it appeared to work on the 840AV, but the
    toolbox would be the best way to do it. As far as synchronous modes
    go, I have also done that, all with direct chip register access,
    which is was very rude of me. If you want to run a machine in a
    synchronous mode, you should write a driver to replace apples serial
    manager (I didnt do that because I dont know how). Apple has a
    driver for one of their Personal Laserwriters that was supposed to
    be close to 1 Mbaud, so if you were in the APDA fold, Im sure they
    could help you out.

    Hope this helps,
    Steve

    APDA: (800)282-2732
    APDA developers support (408)974-4897

    Are the 2 serial ports on your machine inadequate ?

    Date: Fri, Jun 3, 1994, 20:51:26

    The only serial port boards for the Mac I know of are the “Hurdler” and the “Hustler” from Creative Solutions Inc.
    404-441-1617
    4701 Randolph Dr. Suite 12
    Rockville, Maryland 20852

    There are *lots* of serial port boards for the PC.

    Jul
    07

    A little bit of information about the PC serial port

    No commentsCommunicationsJuly 7th, 2009

    A little bit of information about the PC serial port



    From: helge at siemens.co.at (Helge-Wernhard Suess)
    Newsgroups: comp.os.ms-windows.programmer.misc
    Subject: Re: Question about serial ports
    Date: 12 Sep 1995 11:32:18 GMT
    Organization: Siemens AG Austria
    Lines: 26

    In <3253010398.350698279@ett.se>, <H.Olsen at ett.se> (Hakan Olsen) writes:

    >Hello,
    >
    >I am writing a program that does some commmunication via modem. My problem is
    >that I have not found any functions to initialize or communicate with the
    >serial ports on a PC. Are there any libraries containing useful functions for
    >serial communication? I would prefere if the libraries were for standard C
    >as I am not very familiar with C++.
    >
    >I am using Borland C/C++ 4.0
    >
    >Any help would be much appreciated!

    Look up the OpenComm(), CloseComm(), WriteComm(), ReadComm() etc.
    in your SDK helpfile. For a more elaborate communication (X, Y, Z-Modem)
    you should get (buy) a communication library supporting some of the
    common protocols.

    Helge ;-) =)

    ———————————————————-
    (c) All Thoughts are Mine — Genuine Genius
    ———————————————————-
    helge at siemens.co.at —– VIENNA — AUSTRIA
    ———————————————————-
    Subject: Re: ADB Physical Specs
    From: st93urnu at post.drexel.edu (Aaron D. Marasco)
    Date: Fri, 23 Feb 1996 17:24:21 -0500

    In article <31233605.5C70@gtri.gatech.edu>, Bryan Dunn
    <bryan.dunn at gtri.gatech.edu> wrote:

    >Hello all!

    >
    >Im designing some hardware that will use the ADB interface. Can anyone
    >suggest a good reference (on the net or in print) that describes ADB in
    >detail?
    >
    >Thanks in advance!
    >
    >Bryan

    “Guide to the Macintosh Family Hardware: Second Edition”

    Tells everything about the Macs up to the IIfx, including ADB, and a
    standard is a standard, so it shouldnt have changed (however, this *IS*
    Apple were talking about!)

    Anyway, it is a book I have for a school class, so I have all the info:

    $26.95 US, $34.95 CAN

    Addison-Wesley

    ISBN 0-201-52405-8

    I havent checked any of the online bookstores, you might get it cheaper!
    Also, its a paperback, to letcha know.

    _Inside AppleTalk, Second Edition_


    notes from _Inside AppleTalk, Second Edition_ by Sidhu, Andrews, Oppenheimer[1]. and from AMDs _Analog and Communications Products 1983 Data Book_[2]. and Apple _Macintosh Family Hardware Reference_ (1988) [3]. LocalTalk uses Synchronous Data Link Control (SDLC) frame format and a frequency modulation technique called FM-0. Each bit cell (nominally 4.34 usec -> nominal 230.4 Kbit/sec). differential, balanced voltage signaling over a maximum distance of 300 meters. … transformer provides ground isolation as well as protection from static discharge. “In the preferred hardware implementation of LocalTalk, a Zilog 8530 Serial Communications Controller (SCC) is used.” [1] The classic Macs and the Mac SE [3] both use the 8530 SCC, a 26LS30 differential transmitter, a 26LS32 differential receiver, and a fistfull of RFI filters. The Mac II replaces the 26LS32 with a 75175 differential receiver. (I have no info on other macs) (the Maxim MAX216 Low-Power AppleTalk Interface Transceiver looks interesting). The SCC is clocked at 3.672 MHz hooked to /RTxCa, /RTxCb, and PCLK. on classic, Mac SE, and Mac II. (Mac SE and Mac II has software switching of /RTxCa to the GPiA pin).[3] “dont access the SCC chip more often than once every 2.2 us. … on the Mac SE [and the Mac II] it is not neccessary to do so because [other circuits ensure the proper delay]“[3] “the transmitter and receiver hardware for LocalTalk is built into every Macintosh and AppleIIGS computer, …. and many peripheral devices …” “If you are designing your own AppleTalk hardware from scratch, it is easiest to use a 3.6864 MHz oscillator and a Z8530. This has been tested and works just fine.” [HW 545 - Serial I/O Port Q&As - Technical Notes - Developer Support ] “LocalTalk hardware can detect a flag byte, the distinctive bit sequence 01111110 ($7E).” [1], but i cant find any reference to this capability in [2]. Well, the hardware guys have done it again. Theyre making this gizmo that theyre hooking to the Mac serial port. They say it communicates “like a synchronous modem”. They want it to go at least 500Kbits/sec. “see that Z85C30 on the Mac motherboard there ? the databooks say it can go at 10MHz … cancha just poke the right values into it? dissassemble the Mac ROMs and figure out how Apple did it ? … But of course we want the thing to work plugged into the serial port of *any* Macintosh, including the 1996 models.” I know it can be done; the hardware guys had LapLink for Mac running on 2 Macs (homebuilt cable between them) “See that Oscope ? theyre pumping 750KHz into the HSKi input … LapLink just transferred a megabyte file at rougly 70KB/s.”

    Jul
    07

    serial protocol converters

    No commentsCommunicationsJuly 7th, 2009

    serial 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.)

    Jul
    07

    Controller Area Network (CAN)

    No commentsCommunicationsJuly 7th, 2009

    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

    … a text-based protocol. This is how most of the Internet works; HTTP and SMTP are both built on text protocols. This approach allows the protocol to remain architecture agnostic. Text is less efficient than a protocol where each byte is given a meaning, but the upside is a protocol thats easy for a human to read and debug.
    …
    The biggest difference between CAN and SPI is that the CAN protocol defines packets. In SPI (and serial interfaces in general), only the transmission of a byte is fully defined. Given a mechanism for byte transfer, software can provide a packet layer, but no standard size or type exists for a serial packet. Since packet transfer is standardized for CAN, its usually implemented in hardware. Implementing packets, including checksums and backoff-and-retry mechanisms, in hardware hides a whole family of low-level design issues from the software engineer.
    …
    There are a number of higher layer protocols that have been layered on top of the basic CAN specifications . These include SAE J1939, DeviceNet, and CANOpen. …
     
    points to the Linux CAN-bus driver project http://home.wanadoo.nl/arnaud/
    Open DeviceNet Vendor Association, Inc. http://www.odva.org/ (DeviceNet is a more detailed specification for CAN)
    information from “Hard real-time connectivity: Its in the CAN” article by Bruce Boyes in _Computer Design_ 1998-01, p. 88
    “CAN is a robust network designed for hard real-time distributed control systems in harsh environments. Its an open standard (and the subject of ISO 11898)…” … “CAN is a peer-to-peer network … packets with a maximum payload of 8 bytes … … adept at passing around simple commands or small amounts of data quickly… … not well-suited to moving around large files …” “can go up to 1 Mbit/s, CAN systems most commonly operate at 250 Kbit/s or 125 Kbit/s, because lower baud rates are more resistant to brief bursts of noise.” ” fiber-optic cable also is common. …” “The ISO 11898 document specifies a 120 Ohm nominal impedance using terminated twisted-pair media. … line length versus baud rate … … 40 m, 1 000 Kbits/s … 1 000 m, 50 Kbits/s …”
    “low cost and relative simplicity” “Kevin Parkinson … typically uses optically isolated chip-to-bus electronics using RS485 type drivers.”
    “Emphasis on content” “When data is transmitted by a CAN node, no other nodes are /addressed/; rather, the /content/ of the message (pressure, voltage, temperature, etc.) is designated by the identifier, which is unique throughout the network. The identifier also prioritizes the message. With care, this prioritizing guarantees the most important messages are transmitted with the least delay. … Arbitration is nondestructive. In the case of an overloaded network, the highest-priority messages still get through. … Latency … is also very low. … CAN hardware also provides message acknowledgment and automatic re-transmission in the event of an error.”
    “CAN data bits are either “dominant” or “recessive”. … A frame always begins with a dominant-level SOF (start-of-frame) bit. A dominant bit always “wins” over a recessive bit being transmitted at the same time. … If 2 nodes start transmitting concurrently, each node performs bit-wise arbitration to resolve the conflict. … A transmitter stops sending if it sends a recessive bit, but monitors a dominant bit. That guarantees a lower-priority CAN device immediately stops transmitting, while the higher-priority device continues unimpeded. The lower-priority device waits for the next bus idle time and tries again. … 2 nodes [should] never send the same [arbitration field] followed by different data …”
    “… ACK … indicates sucessful message … reception by at least one receiver … the hardware ACK is an important component of CANs real-time capability.”

    “For example, a vehicle wheel-speed sensor should transmit its data properly and let other nodes, if any, handle the data as they wish.”
    “The RTR bit permits any node to request data from another node.”
    “receiving nodes which detect a problem … transmit… in the end of frame space. The sender monitors the error flag, which triggers an automatic retransmission by the sending node.”
    “Honeywells Smart Distributed System (SDS) … DeviceNet (initiated by Allen-Bradley) … … DeviceNet and SDS also include specifications for rugged cable and connectors.”
    “The CAN in Automation (CiA) group (Erlangen, Germany) promotes the CAL”
    “CAN specification 2.0B describes the extended message frame with a 29-bit ID.”
    Siemens (SAE81C91), Motorola (MC68376), Intel (i82527), Philips (SJA1000), National Semiconductor (COP87L84BC). offer CAN controllers and/or microprocessors with CAN 2.0B capability.
    CAN extended message format (bit field width is not to scale)
    | Arbitration field | Control Field | Data field | CRC field | Response field
    Arbitration field:
    | SOF | 11 bit identifier | SSR | IDE | 18 bit identifier | RTR |
    Control field:
    | R1 | R0 | DLC |
    Data field:
    | Data: 0 to 8 bytes |
    CRC field:
    | 15 bit CRC |

    Response field:
    | ACK field | EOF 7 bits | INT 3 bits | bus idle (or another node starts transmitting)
    SOF: Start of Frame, a single dominant bit
    SRR: Substitute Remote Request
    IDE: identifier extension bit is recessive for extended format
    ID Fields: a total of 29 ID bits for extended frmat
    RTR: remote transmit request, dominant for data frames, recessive for remote frames.
    R1, R0 are reserved, dominant bits.
    DLC: a 4 bit data length code indicates the number of bytes in the data field.
    DATA: 0 to 8 bytes. A remote frame contains zero bytes.
    CRC: a 15 bit CRC and a recessive CRC delimiter bit. (Covers what ? just the data ?
    The entire packet before the CRC ? )
    ACK: acknoledgement is a single dominant bit followed by a recessive delimiter bit
    EOF: End of Frame: seven recessive bits end a frame
    INT: intermission is 3 bits between remote and data frames

    For an extended frame, this is a total of 64 to 128 bits (depending on data size). With 8 bytes of data, overhead (non-data bits) is therefore 1/2.